Rozporządzenie 2216/2004 w sprawie standaryzowanego i zabezpieczonego systemu rejestrów stosownie do dyrektywy 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzji nr 280/2004/WE Parlamentu Europejskiego i Rady
Dz.U.UE.L.2004.386.1
Akt utracił mocROZPORZĄDZENIE KOMISJI (WE) NR 2216/2004
z dnia 21 grudnia 2004 r.
w sprawie standaryzowanego i zabezpieczonego systemu rejestrów stosownie do dyrektywy 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzji nr 280/2004/WE Parlamentu Europejskiego i Rady
(Dz.U.UE L z dnia 29 grudnia 2004 r.)
KOMISJA WSPÓLNOT EUROPEJSKICH,
uwzględniając Traktat ustanawiający Wspólnotę Europejską,
uwzględniając dyrektywę 2003/87/WE Parlamentu Europejskiego i Rady z dnia 13 października 2003 r. ustanawiającą system handlu przydziałami emisji gazów cieplarnianych we Wspólnocie oraz zmieniającą dyrektywę Rady 96/61/WE(1), w szczególności jej art. 19 ust. 3,
uwzględniając decyzję nr 280/2004/WE Parlamentu Europejskiego i Rady z dnia 11 lutego 2004 r. dotyczącą mechanizmu monitorowania emisji gazów cieplarnianych we Wspólnocie oraz wykonania Protokołu z Kioto(2), w szczególności jej art. 6 ust. 1 akapit pierwszy, zdanie drugie,
a także mając na uwadze, co następuje:
(1) Niezbędny jest zintegrowany wspólnotowy system rejestrów zawierający rejestry Wspólnoty oraz jej Państw Członkowskich ustanowione stosownie do art. 6 decyzji nr 280/2004/WE, które obejmują rejestry ustanowione stosownie do art. 19 dyrektywy 2003/87/WE oraz niezależny dziennik transakcji Wspólnoty ustanowiony stosownie do art. 20 tejże dyrektywy, w celu zapewnienia, aby wydawanie, przekazywanie i anulowanie przydziałów nie powodowało nieprawidłowości i aby transakcje były zgodne ze zobowiązaniami wynikającymi z Konwencji Ramowej Narodów Zjednoczonych w sprawie Zmian Klimatu (UNFCCC) oraz Protokołu z Kioto.
(2) Zgodnie z dyrektywą 2003/4/WE z dnia 28 stycznia 2003 r. w sprawie publicznego dostępu do informacji dotyczących środowiska(3) oraz decyzji 19/CP.7 Konferencji Stron UNFCCC należy regularnie udostępniać do publicznej wiadomości dokładne sprawozdania w celu zapewnienia, aby społeczeństwo miało dostęp do informacji utrzymywanych w zintegrowanym systemie rejestrów, z zastrzeżeniem określonych wymogów poufności.
(3) Należy przestrzegać ustawodawstwa Wspólnoty dotyczącego ochrony osób fizycznych w zakresie przetwarzania danych osobowych oraz swobodnego przepływu tych danych, w szczególności dyrektywy 95/46/WE w sprawie ochrony osób fizycznych w zakresie przetwarzania danych osobowych i swobodnego przepływu tych danych(4), dyrektywy 2002/58/WE dotyczącej przetwarzania danych osobowych i ochrony prywatności w sektorze łączności elektronicznej(5) oraz rozporządzenia (WE) nr 45/2001 o ochronie osób fizycznych w związku z przetwarzaniem danych osobowych przez instytucje i organy wspólnotowe i o swobodnym przepływie takich danych(6), tam, gdzie dotyczą one informacji utrzymywanych i przetwarzanych stosownie do niniejszego rozporządzenia.
(4) Każdy rejestr powinien zawierać jeden rachunek Strony dotyczący utrzymywania, jeden rachunek dotyczący wycofania oraz rachunki anulowania i wymiany wymagane stosownie do decyzji 19/CP.7 Konferencji Stron UNFCCC dla każdego okresu zobowiązania i każdy rejestr ustanowiony stosownie do art. 19 dyrektywy 2003/87/WE powinien zawierać rachunki utrzymywania przeznaczone dla operatorów i innych osób, wymagane do spełnienia wymagań tejże dyrektywy. Każdy taki rachunek powinien być stworzony zgodnie ze znormalizowanymi procedurami w celu zapewnienia integralności systemu rejestrów oraz publicznego dostępu do informacji utrzymywanych w tym systemie.
(5) Artykuł 6 decyzji nr 280/2004/WE wymaga, aby Wspólnota i jej Państwa Członkowskie zastosowały funkcjonalne i techniczne specyfikacje dotyczące standardów wymiany danych dla systemu rejestrów zgodnie z Protokołem z Kioto, opracowane stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC w sprawie ustanowienia i prowadzenia rejestrów i niezależnego dziennika transakcji Wspólnoty. Zastosowanie i opracowanie tych specyfikacji w odniesieniu do zintegrowanego systemu rejestrów Wspólnoty pozwala na włączenie rejestrów ustanowionych stosownie do art. 19 dyrektywy 2003/87/WE do rejestrów ustanowionych stosownie do art. 6 decyzji nr 2800/2004/WE.
(6) Niezależny dziennik transakcji Wspólnoty będzie wykonywał automatyczne sprawdzenia wszystkich procesów w systemie rejestrów Wspólnoty dotyczących przydziałów, zweryfikowanych emisji, rachunków i jednostek Kioto, a niezależny dziennik transakcji UNFCCC będzie wykonywał automatyczne sprawdzenia procesów dotyczących jednostek Kioto w celu zapewnienia, że nie ma nieprawidłowości. Procesy, które uzyskają negatywne wyniki tych sprawdzeń, zostaną przerwane w celu zapewnienia, aby transakcje w systemie rejestrów Wspólnoty spełniały wymagania dyrektywy 2003/87/WE oraz wymagania opracowane stosownie do UNFCCC i Protokołu z Kioto.
(7) Wszystkie transakcje w systemie rejestrów Wspólnoty powinny być wykonywane zgodnie ze znormalizowanymi procedurami i, gdzie to konieczne, zgodnie ze zharmonizowanym terminarzem, aby zapewnić zgodność z wymaganiami dyrektywy 2003/87/WE oraz z wymaganiami opracowanymi stosownie do UNFCCC i Protokołu z Kioto i aby zabezpieczyć integralność tego systemu.
(8) Należy zastosować minimum norm zabezpieczenia i zharmonizowanych wymogów do uwierzytelniania i praw dostępu w celu ochrony bezpieczeństwa informacji utrzymywanych w zintegrowanym systemie rejestrów Wspólnoty.
(9) Centralny Administrator i każdy administrator rejestrów powinien zapewnić, aby przerwy w działaniu zintegrowanego systemu rejestrów Wspólnoty były ograniczone do minimum poprzez podejmowanie wszelkich możliwych kroków w celu zapewnienia dostępności rejestrów oraz niezależnego dziennika transakcji Wspólnoty i poprzez zapewnienie solidnych systemów i procedur dla zabezpieczenia wszystkich informacji.
(10) Zapisy dotyczące wszystkich procesów, operatorów i osób fizycznych w systemie rejestrów Wspólnoty powinny być przechowywane zgodnie z normami rejestracji danych określonymi w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
(11) Pomocny w zapewnieniu integralności systemu rejestrów Wspólnoty będzie przejrzysty system grzywien oraz zakaz pobierania opłat od posiadaczy rachunków za określone transakcje w tymże systemie.
(12) Środki przewidziane w niniejszym rozporządzeniu są zgodne z opinią Komitetu przytoczoną w art. 23 ust. 1 dyrektywy 2003/87/WE oraz w art. 9 ust. 2 decyzji nr 280/2004/WE,
PRZYJMUJE NINIEJSZE ROZPORZĄDZENIE:
ROZDZIAŁ I
PRZEDMIOT I DEFINICJE
PRZEDMIOT I DEFINICJE
Przedmiot
Niniejsze rozporządzenie ustanawia ogólne przepisy, specyfikacje funkcjonalne i techniczne oraz wymagania dotyczące prowadzenia i utrzymania znormalizowanego i zabezpieczonego systemu rejestrów w postaci standaryzowanych elektronicznych baz danych zawierających wspólne elementy danych. Przewiduje ono także sprawny system łączności pomiędzy niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC.
Definicje
Na potrzeby niniejszego rozporządzenia znajdują zastosowanie definicje określone w art. 3 dyrektywy 2003/87/WE. Stosuje się ponadto następujące definicje:
ROZDZIAŁ II
REJESTRY I DZIENNIKI TRANSAKCJI
REJESTRY I DZIENNIKI TRANSAKCJI
Rejestry
Każdy rejestr będzie zdolny do prawidłowego wykonywania do dnia wejścia w życie niniejszego rozporządzenia wszystkich procesów dotyczących przydziałów Kioto i jednostek Kioto określonych w załączniku IX, z wyjątkiem procesów mających oznaczenia typu 04-00, 06-00, 07-00 i 08-00.
Do 31 marca 2005 r. każdy rejestr będzie zdolny do prawidłowego wykonywania procesów dotyczących przydziałów i jednostek Kioto mających oznaczenia typu 04-00, 06-00, 07-00 i 08-00, określonych w załączniku IX.
Każdy rejestr od dnia 1 lutego 2008 r. posiada zdolność do prawidłowego wykonywania wszystkich procedur dotyczących automatycznych zmian tabeli krajowego planu rozdziału uprawnień, które to procedury zostały opisane w załączniku XIa.
Skonsolidowane rejestry
Państwo Członkowskie lub Komisja może ustanowić, obsługiwać i utrzymywać swój rejestr w sposób skonsolidowany wraz z jednym lub większą liczbą Państw Członkowskich albo Wspólnotą pod warunkiem, że jego rejestr pozostanie rozróżnialny.
Niezależny dziennik transakcji Wspólnoty
Do dnia wejścia w życie niniejszego rozporządzenia niezależny dziennik transakcji Wspólnoty będzie zdolny do wykonywania procesu uzgadniania określonego w załączniku X i procesów administracyjnych określonych w załączniku XI.
Od dnia 1 lutego 2008 r. niezależny dziennik transakcji Wspólnoty posiada zdolność do prawidłowego wykonywania wszystkich procesów dotyczących automatycznych zmian tabeli krajowego planu rozdziałów uprawnień do emisji opisanych w załączniku XIa.
Łącze komunikacji pomiędzy rejestrami i niezależnymi dziennikami transakcji Wspólnoty
Po pomyślnym wykonaniu procedur testowania określonych w załączniku XIII i procedur inicjalizacji określonych w załączniku XIV oraz powiadomieniu o tym stosownego administratora rejestru Centralny Administrator uaktywnia łącze komunikacji.
Komisja może polecić Centralnemu Administratorowi, aby czasowo zawiesił łącze komunikacji pomiędzy danym rejestrem a niezależnym dziennikiem transakcji Wspólnoty lub aby zawiesił wszystkie lub niektóre z procesów wymienionych w załącznikach VIII i IX, jeżeli rejestr ten nie jest obsługiwany i utrzymywany zgodnie z przepisami niniejszego rozporządzenia.
Łącze komunikacyjne między niezależnymi dziennikami transakcji
Jeżeli łącze komunikacji między dziennikami transakcji, o których mowa w art. 7, zostanie ustanowione po wydaniu uprawnień na okres 2008-2012, zgodnie z art. 11 dyrektywy 2003/87/WE, administratorzy rejestru, po realizacji tego połączenia, zastępują wszelkie uprawnienia w swoim rejestrze taką samą ilością uprawnień uznanych przez międzynarodowy dziennik transakcji UNFCCC za jednostki przyznanej emisji.
Administratorzy rejestrów
Państwa Członkowskie i Komisja zapewniają, aby nie było konfliktu interesów pomiędzy administratorem rejestru a jego posiadaczami rachunków lub pomiędzy administratorem rejestru a Centralnym Administratorem.
ROZDZIAŁ III
ZAWARTOŚĆ REJESTRÓW
ZAWARTOŚĆ REJESTRÓW
SEKCJA 1
Składanie raportów i poufność
Składanie raportów i poufność
Składanie raportów
Poufność
SEKCJA 2
Rachunki
Rachunki
Rachunki
SEKCJA 3
Rachunki Stron
Rachunki Stron
Tworzenie rachunków Stron
Wnioskodawca dostarcza administratorowi rejestru informacje wymagane w sposób zasadny przez administratora rejestru. Informacje te obejmują informacje określone w załączniku IV.
Zamknięcie rachunków Stron
W ciągu 10 dni od otrzymania od stosownego kompetentnego organu Państwa Członkowskiego lub od Komisji wniosku o zamknięcie rachunku posiadania Strony administrator jego rejestru zamyka rachunek zgodnie z procedurą zamykania rachunku określoną w załączniku VIII.
Powiadomienie
Administrator rejestru niezwłocznie powiadamia posiadacza rachunku o utworzeniu lub uaktualnieniu jego rachunków Strony lub zamknięciu jego rachunków posiadania Strony.
SEKCJA 4
Rachunki posiadania operatora
Rachunki posiadania operatora
Tworzenie rachunków posiadania operatora
Utrzymywanie jednostek Kioto w rachunkach posiadania operatora
Rachunek posiadania operatora będzie zdolny do utrzymywania jednostek Kioto, gdy będzie to dopuszczone przez ustawodawstwo Państwa Członkowskiego lub Komisję.
Zamknięcie rachunków posiadania operatora
Propozycja jest składana, sprawdzana i wdrażana automatycznie przez niezależny dziennik transakcji Wspólnoty zgodnie z procedurami opisanymi w załączniku XIa.
Powiadomienie
Administrator rejestru niezwłocznie powiadamia posiadacza rachunku o utworzeniu, uaktualnieniu lub zamknięciu rachunku posiadania jego operatora.
SEKCJA 5
Osobiste rachunki posiadania
Osobiste rachunki posiadania
Utworzenie osobistych rachunków posiadania
Wnioskodawca dostarcza administratorowi rejestru informacje w sposób zasadny wymagane przez administratora rejestru. Informacje te obejmują informacje określone w załączniku IV.
2. 25 W ciągu 10 dni od otrzymania wniosku zgodnie z ust. 1 administrator rejestru tworzy w swoim rejestrze osobisty rachunek posiadania zgodnie z procedurą tworzenia rachunków określoną w załączniku VIII lub informuje osobę składającą wniosek o otwarcie rachunku o odmowie otwarcia rachunku.
Utrzymywanie jednostek Kioto na osobistych rachunkach posiadania
Osobisty rachunek posiadania jest zdolny do utrzymywania jednostek Kioto, gdy jest to dopuszczalne przez ustawodawstwo Państwa Członkowskiego lub Wspólnoty.
Zamknięcie osobistych rachunków posiadania
Zamknięcie rachunków i usunięcie upoważnionego przedstawiciela z inicjatywy administratora
Powiadomienie
Administrator rejestru niezwłocznie powiadamia każdego posiadacza rachunku o utworzeniu, uaktualnieniu lub zamknięciu jego rachunku posiadania.
Upoważnieni przedstawiciele
SEKCJA 6
Tabele
Tabele
Tabele
Każdy rejestr może zawierać dodatkowe tabele przeznaczone do innych celów.
Niezależny dziennik transakcji Wspólnoty może zawierać dodatkowe tabele przeznaczone do innych celów.
Tabela planu krajowego rozdzielenia zawarta w niezależnym dzienniku transakcji Wspólnoty zawiera informacje określone w załączniku XIV.
SEKCJA 7
Kody i identyfikatory
Kody i identyfikatory
Kody
Każdy rejestr zawiera kody wprowadzania określone w załączniku VII oraz kory odpowiedzi określone w załączniku XII w celu zapewnienia prawidłowej interpretacji informacji wymienianych podczas każdego procesu.
Kody identyfikacyjne i alfanumeryczne identyfikatory rachunków
Przed utworzeniem rachunku administrator przydziela do każdego rachunku jednoznaczny kod identyfikacji rachunku oraz alfanumeryczny identyfikator podany przez posiadacza rachunku w ramach informacji podanych zgodnie z załącznikami, odpowiednio, III i VI. Przed utworzeniem rachunku administrator rejestru przydziela również posiadaczowi rachunku jednoznaczny kod identyfikacji posiadacza rachunku zawierający elementy określone w załączniku VI.
ROZDZIAŁ IV
SPRAWDZENIA I PROCEDURY
SPRAWDZENIA I PROCEDURY
SEKCJA 1
Blokowanie rachunków
Blokowanie rachunków
Blokowanie rachunków posiadania operatorów
SEKCJA 2
Automatyczne sprawdzenia i proces uzgadniania danych
Automatyczne sprawdzenia i proces uzgadniania danych
Wykrycie rozbieżności przez niezależny dziennik transakcji Wspólnoty
Po odbiorze takiego kodu odpowiedzi dla procesu wymienionego w załączniku VIII, załączniku IX lub załączniku XIa administrator rejestru inicjującego zakańcza ten proces i powiadamia niezależny dziennik transakcji Wspólnoty.
Centralny administrator nie dokonuje aktualizacji informacji zawartych w niezależnym dzienniku transakcji Wspólnoty.
Zainteresowany administrator lub administratorzy rejestru niezwłocznie powiadamiają odnośnych posiadaczy rachunku o zakończeniu procesu.
Wykrycie niezgodności przez niezależny dziennik transakcji Wspólnoty
Wykonując ten proces, niezależny dziennik transakcji Wspólnoty sprawdza, czy stany posiadania jednostek Kioto i przydziałów w każdym rachunku w rejestrze są identyczne z zapisami utrzymywanymi w niezależnym dzienniku transakcji Wspólnoty.
Niezależny dziennik transakcji Wspólnoty rejestruje wszystkie zmiany wprowadzone do tabeli zweryfikowanych emisji.
Wykrycie rozbieżności i niezgodności przez niezależny dziennik transakcji UNFCCC
Automatyczne sprawdzenia rejestrów
Przed wykonywaniem jakiegokolwiek procesu i podczas jego wykonywania administrator rejestru zapewnia, aby w rejestrze prowadzone były odpowiednie automatyczne sprawdzenia w celu wykrycia rozbieżności i na tej podstawie przerwania procesów z góry, zanim będą prowadzone automatyczne sprawdzenia przez niezależny dziennik transakcji Wspólnoty lub niezależny dziennik transakcji UNFCCC.
SEKCJA 3
Wykonanie i finalizacja procesów
Wykonanie i finalizacja procesów
Procesy
Każdy proces przebiega zgodnie z pełną sekwencją wymiany komunikatów stosownej do tego typu procesu, zgodnie z opisem zawartym w załącznikach VIII, IX, X, XI oraz w załączniku XIa. Każdy komunikat odpowiada formatowi i wymogom informacyjnym opisanym przy użyciu języka opisu serwisów internetowych zgodnie z opracowaniem na podstawie UNFCCC lub protokołu z Kioto
Kody identyfikacji
Administrator rejestru nadaje każdemu procesowi wymienionemu w załącznikach VIII i XIa jednoznaczny kod identyfikacji korelacji, zaś każdemu procesowi wymienionemu w załączniku IX nadaje jednoznaczny kod identyfikacji transakcji.
Każdy taki kod identyfikacji zawiera elementy opisane w załączniku VI.
Finalizacja procesów dotyczących rachunków, automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji i zweryfikowanych emisji
Po utworzeniu łącza komunikacyjnego między dwoma niezależnymi dziennikami transakcji i w przypadku, gdy wszystkie procesy dotyczące rachunków, automatycznej zmiany tabeli krajowego planu rozdziału uprawnień do emisji i zweryfikowanych emisji zostały wykonane poprzez wymianę danych za pośrednictwem niezależnego dziennika transakcji UNFCCC, nastąpi finalizacja, o ile oba niezależne dzienniki transakcji pomyślnie powiadomią rejestr inicjujący, że nie wykryły żadnej rozbieżności w propozycji przesłanej przez ten rejestr inicjujący.
We wszystkich przypadkach innych niż przypadek opisany w pierwszym akapicie wszystkie procesy dotyczące rachunków, automatycznej zmiany tabeli krajowego planu rozdziału uprawnień do emisji i zweryfikowanych emisji są uważane za sfinalizowane, gdy niezależny dziennik transakcji Wspólnoty pomyślnie powiadomi rejestr inicjujący, że nie wykrył żadnej rozbieżności w propozycji przesłanej przez ten rejestr inicjujący.
Ręczne unieważnienie sfinalizowanych transakcji, które zostały błędnie zainicjowane
Centralny administrator w ciągu 30 dni kalendarzowych od otrzymania powiadomienia od administratora rejestru w przypadku opisanym w pierwszym akapicie ust. 2 przeprowadza ręczny zabieg na podstawie danych z niezależnego dziennika transakcji Wspólnoty, który to zabieg będzie odpowiadał zabiegowi opisanemu w powiadomieniu wysłanym przez administratora rejestru, jeżeli:
Finalizacja procesów dotyczących transakcji w rejestrach
Wszystkie procesy wymienione w załączniku IX, z wyjątkiem procesu zewnętrznego przekazania, są sfinalizowane, gdy obydwa niezależne dzienniki transakcji poinformowały rejestr inicjujący, że nie wykryły żadnych rozbieżności w propozycji przesłanej przez rejestr inicjujący, a rejestr inicjujący pomyślnie wysłał do obydwu niezależnych dzienników transakcji potwierdzenie, że uaktualnił swoje zapisy zgodnie ze swoją propozycją.
Jednakże przed ustanowieniem łącza komunikacji pomiędzy niezależnym dziennikiem transakcji Wspólnoty i niezależnym dziennikiem transakcji UNFCCC wszystkie procesy wymienione w załączniku IX, z wyjątkiem procesu zewnętrznego przekazania, będą sfinalizowane, gdy niezależny dziennik transakcji Wspólnoty poinformuje rejestr inicjujący, że nie wykrył żadnych rozbieżności w propozycji przesłanej przez rejestr inicjujący, a rejestr inicjujący pomyślnie wyśle do niezależnego dziennika transakcji Wspólnoty potwierdzenie, że uaktualnił swoje zapisy zgodnie ze swoją propozycją.
Finalizacja procesu zewnętrznego przekazania
Proces zewnętrznego przekazywania jest sfinalizowany, gdy obydwa niezależne dzienniki transakcji poinformowały rejestr nabywający, że nie wykryły żadnych rozbieżności w propozycji przesłanej przez rejestr inicjujący, a rejestr nabywający pomyślnie wysłał do obydwu niezależnych dzienników transakcji potwierdzenie, że uaktualnił swoje zapisy zgodnie z propozycją rejestru inicjującego.
Jednakże przed ustanowieniem łącza komunikacji pomiędzy niezależnym dziennikiem transakcji Wspólnoty i niezależnym dziennikiem transakcji UNFCCC proces zewnętrznego przekazania jest sfinalizowany, gdy niezależny dziennik transakcji Wspólnoty poinformuje rejestr nabywający, że nie wykrył żadnych rozbieżności w propozycji przesłanej przez rejestr inicjujący, a rejestr nabywający pomyślnie wyśle do niezależnego dziennika transakcji Wspólnoty potwierdzenie, że uaktualnił swoje zapisy zgodnie z propozycją rejestru inicjującego.
Finalizacja procesu uzgadniania
Proces uzgadniania wymieniony w załączniku X jest sfinalizowany, jeżeli wszystkie niezgodności pomiędzy informacjami zawartymi w rejestrze i informacjami zawartymi w niezależnym dzienniku transakcji Wspólnoty dla określonej godziny i dnia zostały rozwiązane, a proces uzgadniania został pomyślnie ponownie zainicjowany i zakończony dla tego rejestru.
ROZDZIAŁ V
TRANSAKCJE
TRANSAKCJE
SEKCJA 1 45
(skreślony)
(skreślony)
(skreślony)
(skreślony)
(skreślony)
(skreślony)
SEKCJA 2
Rozdzielenie i wydanie przydziałów na okres 2008-2012 oraz każdy kolejny pięcioletni okres
Rozdzielenie i wydanie przydziałów na okres 2008-2012 oraz każdy kolejny pięcioletni okres
Tabela planu krajowego rozdzielenia na okres 2008-2012 i każdy kolejny pięcioletni okres
Wszystkie takie korekty odnoszące się do nowych uczestników są wprowadzane w drodze procesu automatycznej zmiany tabeli krajowego planu rozdziału uprawnień do emisji opisanym w załączniku XIa do niniejszego rozporządzenia.
Wszystkie korekty, które nie odnoszą się do nowych uczestników, będą wprowadzane w drodze procedur inicjalizacji opisanych w załączniku XIV do niniejszego rozporządzenia. We wszystkich pozostałych przypadkach państwa członkowskie powiadamiają Komisję o korekcie swojego krajowego planu rozdziału uprawnień do emisji i jeżeli Komisja nie odrzuci korekty w drodze procedury opisanej w art. 9 ust. 3 dyrektywy 2003/87/WE, Komisja poleca centralnemu administratorowi wprowadzenie odpowiedniej korekty do tabeli krajowego planu rozdziału uprawnień do emisji przechowywanej w niezależnym dzienniku transakcji Wspólnoty w drodze procedur inicjalizacji opisanych w załączniku XIV do niniejszego rozporządzenia.
Korekta odbywa się zgodnie z procedurą wprowadzania korekt do przydziałów, określoną w załączniku IX.
Wydanie przydziałów
Po wprowadzeniu tabeli planu krajowego rozdzielenia do niezależnego dziennika transakcji wspólnoty, z zastrzeżeniem art. 44 ust. 2, do 28 lutego pierwszego roku okresu 2008-2012 i do 28 lutego pierwszego roku każdego kolejnego pięcioletniego okresu administrator rejestru wydaje łączną ilość przydziałów określoną w tabeli planu krajowego rozdzielenia na rachunek posiadania Strony przez konwersję na przydziały równej ilości jednostek AAU utrzymywanych na tym rachunku posiadania.
Konwersja ta odbywa się poprzez dodanie elementu przydziału do jednoznacznego kodu identyfikacji jednostki każdej takiej AAU składającego się z elementów określonych w załączniku VI.
Wydanie przydziałów na okres 2008-2012 i każdy kolejny pięcioletni okres odbywa się zgodnie z procedurą wydawania przydziałów (na okres 2008-2012 i dalsze lata) określoną w załączniku IX.
Rozdzielanie uprawnień między operatorów
Nie naruszając przepisów art. 44 ust. 2 i art. 47, do dnia 28 lutego 2008 r. i do dnia 28 lutego każdego kolejnego roku administrator rejestru przekazuje z rachunku posiadania Strony na odnośny rachunek posiadania operatora tę część łącznej ilości uprawnień wydanych przez dowolnego administratora rejestru na mocy art. 45, która została przydzielona do odpowiedniej instalacji na dany rok zgodnie z odnośną sekcją tabeli krajowego planu rozdziału uprawnień do emisji.
O ile zostało to przewidziane dla instalacji w krajowym planie rozdziału uprawnień do emisji państwa członkowskiego, administrator rejestru może przenieść tę część w późniejszym terminie każdego roku.
Uprawnienia są rozdzielane zgodnie z procedurą rozdzielania uprawnień opisaną w załączniku IX.
Odstąpienie przydziałów na polecenie kompetentnego organu
Jeśli poleci tak kompetentny organ stosownie do art. 16 ust. 1 dyrektywy 2003/87/WE, administrator rejestru dokonuje odstąpienia pewnego odsetka lub całej części łącznej ilości przydziałów wydanych na podstawie art. 45, która została przydzielona instalacji na określony rok, przez wprowadzenie liczby odstąpionych przydziałów do sekcji tabeli odstąpionych przydziałów przeznaczonej dla tej instalacji na ten rok. Te odstąpione przydziały pozostają na rachunku posiadania Strony.
Przydziały, które mają być odstąpione na polecenie kompetentnego organu, są odstępowane zgodnie z procedurą odstępowania przydziałów, określoną w załączniku IX.
Rozdzielanie uprawnień między nowych uczestników
Jeżeli administrator rejestru zostanie odpowiednio poinstruowany przez właściwy organ, to przenosi tę część uprawnień wydanych przez jakiegokolwiek administratora rejestru na mocy art. 45, która znajduje się na rachunku posiadania Strony, na rachunek posiadania operatora będącego nowym uczestnikiem zgodnie z odnośnym rozdziałem tabeli krajowego planu rozdziału uprawnień do emisji dla takiego nowego uczestnika za dany rok.
Uprawnienia są rozdzielane zgodnie z procedurą rozdzielania uprawnień opisaną w załączniku IX.
Rozdzielanie uprawnień po ich sprzedaży przez państwo członkowskie
Jeżeli zleci tak właściwy organ, po sprzedaży uprawnień posiadanych przez dane państwo członkowskie administrator rejestru przenosi ilość uprawnień z rachunku posiadania Strony na osobisty rachunek posiadania lub rachunek posiadania operatora, który kupuje uprawnienia.
Uprawnienia przenoszone w obrębie tego samego rejestru są przenoszone w drodze procesu "wewnętrznego przenoszenia" opisanego w załączniku IX. Uprawnienia przenoszone z jednego rejestru do drugiego są przenoszone w drodze procesu "zewnętrznego przenoszenia (2008-2012 i później)" opisanego w załączniku IX.
SEKCJA 3
Przekazania i uprawnienia
Przekazania i uprawnienia
Przekazy przydziałów i jednostek Kioto przez posiadaczy rachunków
Uprawnienie i rezerwa okresu zobowiązań
Stosownie do art. 8 decyzji nr 280/2004/WE, jeżeli Sekretariat UNFCCC poinformuje Państwo Członkowskie, że nie spełnia ono wymagań pozwalających mu na przekazanie lub nabycie jednostek ERU lub AAU albo użycie jednostek CER, odpowiedni organ Państwa Członkowskiego poleca administratorowi rejestru, aby nie inicjował tych transakcji wymagających takiego uprawnienia.
SEKCJA 4
Zweryfikowane emisje
Zweryfikowane emisje
Zweryfikowane emisje z instalacji
SEKCJA 5
Odstąpienie przydziałów
Odstąpienie przydziałów
Odstąpienie przydziałów
Operator dokonuje odstąpienia przydziałów dla danej instalacji przez złożenie wniosku lub, gdy jest to przewidziane w ustawodawstwie Państwa Członkowskiego, uznanie złożenia przez niego wniosku do administratora rejestru o:
Przekazanie i wpis odbywają się zgodnie z procedurą odstąpienia przydziałów określoną w załączniku IX.
Użycie jednostek CER i ERU
Użycie przez operatora jednostek CER i ERU zgodnie z art. 11a dyrektywy 2003/87/WE odnośnie do danej instalacji odbywa się poprzez złożenie przez operatora wniosku do administratora rejestru o:
Administrator rejestru przyjmuje wnioski dotyczące umorzenia jednostek CER i ERU tylko do wartości procentowej przydziału dokonanego dla każdej instalacji określonej przez ustawodawstwo państwa członkowskiego. CITL odrzuca wszelkie wnioski dotyczące umorzenia jednostek CER i ERU, które przewyższałyby maksymalny dozwolony poziom jednostek CER i ERU, które mogą być objęte tym umorzeniem w danym państwie członkowskim, lub które spowodowałyby umorzenie jednostek CER lub ERU, których nie można umorzyć zgodnie z art. 11a dyrektywy 2003/87/WE.
Przekazanie i wpis odbywają się zgodnie z procedurą odstąpienia przydziałów określoną w załączniku IX.
Jednostka CER lub ERU, która została już umorzona, nie może zostać umorzona ponownie ani przekazana na rachunek posiadania operatora lub osobisty rachunek posiadania w EU ETS.
Umorzone jednostki CER i ERU przekazuje się wyłącznie na rachunek wycofania.
(skreślony)
Obliczenia liczb statusu zgodności
Po dokonaniu wpisu do sekcji tabeli odstąpionych uprawnień lub tabeli zweryfikowanych emisji przeznaczonej dla danej instalacji administrator rejestru oblicza następujące wskaźniki:
Współczynnik korekty, o którym mowa w lit. b), jest równy zeru, jeżeli liczba za rok 2007 była większa od zera, jednak zachowuje wartość liczby za rok 2007 w przypadku, gdy liczba za rok 2007 jest mniejsza lub równa zeru.
Wpisy do tabeli statusu zgodności
Wpisy do tabeli zweryfikowanych emisji
Jeżeli w dniu 1 maja 2006 r. oraz w dniu 1 maja każdego kolejnego roku nie wprowadzono żadnej liczby zweryfikowanych emisji do tabeli zweryfikowanych emisji dla danej instalacji za poprzedni rok, jakakolwiek zastępcza liczba emisji określona zgodnie z art. 16 ust. 1 dyrektywy 2003/87/WE, która nie została obliczona możliwie jak najdokładniej zgodnie ze szczegółowymi wymaganiami wprowadzonymi przez państwo członkowskie na mocy załącznika V do dyrektywy 2003/87/WE, nie zostaje wprowadzona do tabeli zweryfikowanych emisji.
SEKCJA 6
Anulowanie i wycofanie
Anulowanie i wycofanie
(skreślony)
Anulowanie i wycofanie odstąpionych uprawnień na okres 2008-2012 i na kolejne okresy
SEKCJA 7 59
(skreślony)
(skreślony)
SEKCJA 8
Dobrowolne anulowanie i wycofanie
Dobrowolne anulowanie i wycofanie
Dobrowolne anulowanie przydziałów i jednostek Kioto
Wycofanie jednostek Kioto
ROZDZIAŁ VA 62
PROWADZENIE REJESTRÓW PRZEZ PAŃSTWA CZŁONKOWSKIE, KTÓRE NIE POSIADAJĄ JEDNOSTEK AAU
PROWADZENIE REJESTRÓW PRZEZ PAŃSTWA CZŁONKOWSKIE, KTÓRE NIE POSIADAJĄ JEDNOSTEK AAU
Prowadzenie rejestrów przez państwa członkowskie, które nie posiadają jednostek AAU
Łącze komunikacyjne między rejestrami prowadzonymi zgodnie z art. 63a i niezależny dziennik transakcji Wspólnoty
Rejestry prowadzone zgodnie z art. 63a porozumiewają się z niezależnym dziennikiem transakcji Wspólnoty poprzez łącze komunikacyjne ustanowione przez rejestr Wspólnoty.
Centralny administrator uruchamia łącze komunikacyjne po pomyślnym zakończeniu procedur testowania opisanych w załączniku XIII oraz procedur inicjalizacji opisanych w załączniku XIV i powiadamia o tym administratora rejestru Wspólnoty.
Rejestry prowadzone zgodnie z art. 63a: wykrycie rozbieżności i niezgodności przez niezależny dziennik transakcji UNFCCC
Niezależny dziennik transakcji UNFCCC informuje rejestr prowadzony zgodnie z art. 63a o jakichkolwiek rozbieżnościach wykrytych w procesie zainicjowanym przez ten rejestr poprzez administratora rejestru Wspólnoty.
Rejestr prowadzony zgodnie z art. 63a zakańcza proces, zaś administrator rejestru Wspólnoty powiadamia o tym niezależny dziennik transakcji UNFCCC. Administrator rejestru prowadzonego zgodnie z art. 63a oraz każdy inny zainteresowany administrator rejestru bezzwłocznie powiadamia odnośnych posiadaczy rachunków o zakończeniu procesu.
Rejestry prowadzone zgodnie z art. 63a: finalizacja procesów dotyczących rachunków, zweryfikowanych emisji i automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji
Po utworzeniu łącza komunikacyjnego między dwoma niezależnymi dziennikami transakcji, w przypadku gdy procesy dotyczące rachunków, zweryfikowanych emisji i automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji są kierowane poprzez niezależny dziennik transakcji UNFCCC, to procesy te są kończone w chwili, gdy oba niezależne dzienniki transakcji pomyślnie powiadomią rejestr Wspólnoty, że nie wykryły żadnych rozbieżności w propozycji zainicjowanej przez rejestr prowadzony zgodnie z art. 63a.
We wszystkich przypadkach innych niż wymienione w pierwszym akapicie wszystkie procesy opisane w załącznikach VIII i XIa są uznawane za zakończone w chwili, gdy niezależny dziennik transakcji Wspólnoty pomyślnie powiadomi rejestr Wspólnoty, że nie wykrył żadnych rozbieżności w propozycji zainicjowanej przez rejestr prowadzony zgodnie z art. 63a.
Rejestry prowadzone zgodnie z art. 63a: finalizacja procesów dotyczących transakcji w obrębie rejestrów
Wszystkie procesy wymienione w załączniku IX, z wyjątkiem procesu zewnętrznego przenoszenia, zostają zakończone w chwili, gdy oba niezależne dzienniki transakcji pomyślnie powiadomią rejestr Wspólnoty, że nie wykryły żadnych rozbieżności w propozycji zainicjowanej przez rejestr prowadzony zgodnie z art. 63a, zaś rejestr Wspólnoty pomyślnie wyśle potwierdzenie obu niezależnym dziennikom transakcji o tym, że rejestr prowadzony zgodnie z art. 63a przeprowadził aktualizację swoich zapisów zgodnie ze swoją propozycją.
Jednakże przed utworzeniem łącza komunikacyjnego między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC wszystkie procesy wymienione w załączniku IX, z wyjątkiem procesu zewnętrznego przenoszenia, zostają zakończone w chwili, gdy niezależny dziennik transakcji Wspólnoty powiadomi rejestr Wspólnoty o tym, że nie wykrył żadnych rozbieżności w propozycji zainicjowanej przez rejestr prowadzony zgodnie z art. 63a, zaś rejestr Wspólnoty pomyślnie wyśle potwierdzenie do niezależnego dziennika transakcji Wspólnoty, że rejestr prowadzony zgodnie z art. 63a przeprowadził aktualizację swoich zapisów zgodnie ze swoją propozycją.
Rejestry prowadzone zgodnie z art. 63a: finalizacja procesu zewnętrznego przenoszenia
Proces zewnętrznego przenoszenia związany z rejestrem prowadzonym zgodnie z art. 63a zostaje zakończony w chwili, gdy oba niezależne dzienniki transakcji powiadomią rejestr nabywający (lub rejestr Wspólnoty, jeżeli rejestr nabywający jest rejestrem prowadzonym zgodnie z art. 63a) o tym, że nie wykryły żadnych rozbieżności w propozycji wysłanej przez rejestr inicjujący (lub rejestr Wspólnoty, jeżeli rejestr inicjujący jest rejestrem prowadzonym zgodnie z art. 63a), zaś rejestr nabywający (lub rejestr Wspólnoty, jeżeli rejestr nabywający jest rejestrem prowadzonym zgodnie z art. 63a) pomyślnie wyśle potwierdzenie obu niezależnym dziennikom transakcji, że rejestr nabywający przeprowadził aktualizację swoich zapisów zgodnie z propozycją rejestru inicjującego.
Jednakże przed utworzeniem łącza komunikacyjnego między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC proces zewnętrznego przenoszenia związany z rejestrem prowadzonym zgodnie z art. 63a zostaje zakończony w chwili, gdy niezależny dziennik transakcji Wspólnoty powiadomi rejestr nabywający (lub rejestr Wspólnoty, jeżeli rejestr nabywający jest rejestrem prowadzonym zgodnie z art. 63a) o tym, że nie wykrył żadnych rozbieżności w propozycji wysłanej przez rejestr inicjujący (lub rejestr Wspólnoty, jeżeli rejestr inicjujący jest rejestrem prowadzonym zgodnie z art. 63a), zaś rejestr nabywający (lub rejestr Wspólnoty, jeżeli rejestr nabywający jest rejestrem prowadzonym zgodnie z art. 63a) pomyślnie wyśle potwierdzenie do niezależnego dziennika transakcji Wspólnoty, że dokonał on aktualizacji swoich zapisów zgodnie z propozycją rejestru inicjującego.
Rejestry prowadzone zgodnie z art. 63a: uwierzytelnianie
Rejestry prowadzone zgodnie z art. 63a są uwierzytelniane w niezależnym dzienniku transakcji UNFCCC poprzez rejestr Wspólnoty za pomocą cyfrowych certyfikatów wydawanych przez Sekretariat UNFCCC bądź jednostkę wskazaną przez Sekretariat UNFCCC.
Jednakże do chwili utworzenia łącza między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC rejestry są uwierzytelniane w niezależnym dzienniku transakcji Wspólnoty poprzez rejestr Wspólnoty za pomocą cyfrowych certyfikatów oraz nazw użytkownika i haseł podanych w załączniku XV. Komisja lub jednostka wskazana przez Komisję występuje jako organ certyfikacyjny w przypadku wszystkich cyfrowych certyfikatów i nadaje nazwy użytkownika oraz hasła.
Przepisy specjalne dotyczące niektórych obowiązków administratorów rejestrów prowadzonych zgodnie z art. 63a
Obowiązki przewidziane w art. 71 oraz art. 72 ust. 2 i 3 w odniesieniu do administratorów rejestrów prowadzonych zgodnie z art. 63a są wykonywane przez administratora rejestru Wspólnoty.
Rejestry obsługiwane zgodnie z art. 63a: rachunki
Rejestry prowadzone zgodnie z art. 63a: tabela krajowego planu rozdziału uprawnień do emisji na okres 2008-2012 i każdy kolejny okres pięciu lat
Rejestry prowadzone zgodnie z art. 63a po każdej korekcie tabeli krajowego planu rozdziału uprawnień do emisji wprowadzonej na podstawie art. 44 ust. 2, która nastąpi po wydaniu uprawnień na mocy art. 45 i która obniża łączną ilość uprawnień wydanych na mocy art. 45 za okres 2008-2012 lub kolejny okres pięciu lat, przenoszą liczbę uprawnień podaną przez właściwy organ z rachunków posiadania, o których mowa w art. 11 ust. 2 i art. 63i i na których znajdują się uprawnienia, na rachunek anulowania w rejestrze Wspólnoty za odnośny okres.
Rejestry prowadzone zgodnie z art. 63a: wydawanie uprawnień
Administrator rejestru prowadzonego zgodnie z art. 63a po wprowadzeniu tabeli krajowego planu rozdziału uprawnień do emisji do niezależnego dziennika transakcji Wspólnoty i z zastrzeżeniem postanowień art. 44 ust. 2, do dnia 28 lutego pierwszego roku okresu 2008-2012 i do dnia 28 lutego pierwszego roku każdego kolejnego okresu pięciu lat, wydaje łączną ilość uprawnień wyznaczoną w tabeli krajowego planu rozdziału uprawnień do emisji na rachunek posiadania Strony.
Wydając takie uprawnienia, administrator rejestru nadaje każdemu uprawnieniu jednoznaczny kod identyfikacji składający się z elementów opisanych w załączniku VI, w którym to kodzie początkowy typ jednostki to 0, zaś uzupełniający typ jednostki to 4.
Uprawnienia są wydawane zgodnie z procedurą wydawania uprawnień (rejestry, o których mowa w art. 63a) opisaną w załączniku IX.
Rejestry prowadzone zgodnie z art. 63a: przenoszenie uprawnień z rachunków posiadania operatora do rejestrów prowadzonych zgodnie z art. 63a i do innych rejestrów
Konwersja uprawnień
Rejestry prowadzone zgodnie z art. 63a: anulowanie na mocy art. 58 lub art. 62
Prowadząc anulowanie i wycofywanie zgodnie z art. 58 lub dobrowolne anulowanie zgodnie z art. 62, administrator rejestru prowadzonego zgodnie z art. 63a dokonuje anulowania, przenosząc uprawnienia zgodnie z wymaganiami zawartymi w art. 58 lub art. 62 na rachunek anulowania lub rachunek wycofania dziennika Wspólnoty.
Rejestry prowadzone zgodnie z art. 63a: anulowanie i wycofanie odstąpionych uprawnień i jednostek CER w okresie 2008-2012 i kolejnych okresach
Liczba uprawnień i jednostek CER przeznaczonych do anulowania jest równa łącznej liczbie odstąpionych uprawnień wprowadzonych do tabeli odstąpionych uprawnień od dnia 1 stycznia pierwszego roku odnośnego okresu do dnia 31 maja kolejnego roku i od dnia 1 czerwca poprzedniego roku do dnia 31 maja każdego kolejnego roku.
(skreślony)
Rejestry prowadzone zgodnie z art. 63a: anulowanie i wymiana uprawnień wydanych na okres 2008-2012 i kolejne okresy
ROZDZIAŁ VI
NORMY ZABEZPIECZENIA, UWIERZYTELNIENIE I PRAWA DOSTĘPU
NORMY ZABEZPIECZENIA, UWIERZYTELNIENIE I PRAWA DOSTĘPU
Normy zabezpieczenia
Uwierzytelnienie
Państwa Członkowskie i Wspólnota używają cyfrowych certyfikatów wydanych przez Sekretariat UNFCCC lub wyznaczoną przez nią jednostkę do uwierzytelniania połączeń swoich rejestrów i niezależnego dziennika transakcji Wspólnoty z niezależnym dziennikiem transakcji UNFCCC.
Jednakże od 1 stycznia, aż do ustanowienia łącza komunikacyjnego pomiędzy niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC tożsamość każdego rejestru i niezależnego dziennika transakcji jest uwierzytelniana przy użyciu cyfrowych certyfikatów oraz nazw użytkowników i haseł określonych w załączniku XV. Komisja lub wyznaczona przez nią jednostka pełni funkcję organu certyfikującego dla wszystkich cyfrowych certyfikatów oraz rozdziela nazwy użytkowników i hasła.
Dostęp do rejestrów
Administrator rejestru wydaje każdemu upoważnionemu przedstawicielowi nazwę użytkownika i hasło w celu umożliwienia mu takiego poziomu dostępu do rachunków lub procesów, do jakiego jest on upoważniony. Administratorzy rejestrów mogą według swojego uznania stawiać dodatkowe wymagania dotyczące zabezpieczenia, jeśli są one zgodne z przepisami niniejszego rozporządzenia.
Zawieszenie dostępu do rachunków
ROZDZIAŁ VII
DOSTĘPNOŚĆ I RZETELNOŚĆ INFORMACJI
DOSTĘPNOŚĆ I RZETELNOŚĆ INFORMACJI
Dostępność i rzetelność rejestrów i niezależnego dziennika transakcji Wspólnoty
Centralny Administrator i każdy administrator rejestru podejmuje wszelkie możliwe kroki w celu zapewnienia, aby:
Zapewniają oni, aby rejestr i niezależny dziennik transakcji Wspólnoty zawierały solidne systemy i procedury dla zabezpieczenia danych i niezwłocznego odzyskania wszystkich danych i wznowienia operacji w razie katastrofy.
Ograniczają przerwy w pracy rejestru i niezależnego dziennika transakcji Wspólnoty do minimum.
Komisja może polecić Centralnemu Administratorowi, aby zawiesił dostęp do niezależnego dziennika transakcji Wspólnoty, a administrator rejestru może zawiesić dostęp do swojego rejestru, jeżeli istnieje zasadne podejrzenie, że nastąpiło naruszenie bezpieczeństwa lub że występuje poważne zagrożenie dla bezpieczeństwa niezależnego dziennika transakcji Wspólnoty lub rejestru, które zagraża integralności niezależnego dziennika transakcji Wspólnoty lub rejestru bądź integralności systemu rejestrów, w tym integralności urządzeń zastępczych, o których mowa w art. 68.
Powiadomienie o zawieszeniu dostępu
Zawieszenie dostępu do uprawnień lub jednostek Kioto w przypadku podejrzenia oszukańczej transakcji
Obszar testujący każdego rejestru i niezależnego dziennika transakcji Wspólnoty
Zarządzanie zmianami
Po przeprowadzeniu takiej koordynacji centralny administrator decyduje o terminie wdrożenia przez rejestry i niezależny dziennik transakcji Wspólnoty każdej nowej wersji specyfikacji funkcjonalnych i technicznych standardów wymiany danych dla systemów rejestracji w ramach protokołu z Kioto.
ROZDZIAŁ VIII
ZAPISY I OPŁATY
ZAPISY I OPŁATY
Zapisy
Opłaty
Wszelkie opłaty, którymi administrator rejestru obciąża posiadaczy rachunków, winny być uzasadnione i wyraźnie wykazane w publicznym miejscu internetowej strony danego rejestru. Administratorzy rejestrów nie różnicują żadnych takich opłat na podstawie lokalizacji posiadacza rachunku we Wspólnocie.
Administratorzy rejestrów nie obciążają posiadaczy rachunków opłatami za transakcje wykonywane na przydziałach stosownie do art. 49, art. 52-54 oraz art. 58-63.
ROZDZIAŁ IX
PRZEPISY KOŃCOWE
PRZEPISY KOŃCOWE
Wejście w życie
Niniejsze rozporządzenie wchodzi w życie następnego dnia po jego opublikowaniu w Dzienniku Urzędowym Unii Europejskiej.
Sporządzono w Brukseli, 21 grudnia 2004.
W imieniu Komisji | |
Stavros DIMAS | |
Członek Komisji |
(1) Dz.U. L 275 z 25.10.2003, str. 32.
(2) Dz.U. L 49 z 19.2.2004, str. 1.
(3) Dz.U. L 41 z 14.2.2003, str. 26.
(4) Dz.U. L 281 z 23.11.1995, str. 31.
(5) Dz.U. L 201 z 31.7.2002, str. 37.
(6) Dz.U. L 8 z 12.1.2001, str. 1.
ZAŁĄCZNIKI
..................................................
..................................................
Grafiki zostały zamieszczone wyłącznie w Internecie. Obejrzenie grafik podczas pracy z programem Lex wymaga dostępu do Internetu.
..................................................
ZAŁĄCZNIK I
78 Wymagania dotyczące sprzętu i oprogramowania komputerowego dla rejestrów i niezależnego dziennika transakcji Wspólnoty
78 Wymagania dotyczące sprzętu i oprogramowania komputerowego dla rejestrów i niezależnego dziennika transakcji Wspólnoty
1. Każdy rejestr i niezależny dziennik transakcji Wspólnoty zawiera w swojej architekturze następujący sprzęt i oprogramowanie:
a) serwer WWW;
b) serwer aplikacji;
c) serwer bazy danych zainstalowany na odrębnej maszynie niż ta lub te, które są wykorzystywane dla serwera WWW lub serwera aplikacji;
d) zabezpieczenia typu firewall.
Wymagania dotyczące komunikacji
2. Jeżeli nie zostanie utworzone łącze komunikacyjne między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC:
a) zapis godziny w niezależnym dzienniku transakcji Wspólnoty i każdym rejestrze zostanie zsynchronizowany z uniwersalnym czasem koordynowanym;
b) wszystkie procesy dotyczące uprawnień, zweryfikowanych emisji, automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji i rachunków są wykonywane przez wymianę danych zapisanych w rozszerzalnym języku znakowania (XML) z wykorzystaniem protokołu SOAP w wersji 1.1 poprzez protokół przesyłu hipertekstu (HTTP) w wersji 1.1 (zakodowany styl zdalnego wywoływania procedur (RPC)).
3. Po utworzeniu łącza komunikacyjnego między niezależnym dziennikiem Wspólnoty a niezależnym dziennikiem transakcji UNFCCC:
a) zapisy godziny w niezależnym dzienniku transakcji UNFCCC, niezależnym dzienniku transakcji Wspólnoty i każdym rejestrze zostaną zsynchronizowane; oraz
b) wszystkie procesy dotyczące uprawnień i jednostek Kioto są wykonywane poprzez wymianę danych;
z zastosowaniem wymogów dotyczących sprzętu i oprogramowania określonych w specyfikacji funkcjonalnej i technicznej standardów wymiany danych w systemach rejestracji w ramach protokołu z Kioto, opracowanej na podstawie decyzji 24/CP.8 Konferencji Stron UNFCCC.
Jeżeli procesy dotyczące zweryfikowanych emisji, rachunków i automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji są wykonywane poprzez wymianę danych za pośrednictwem niezależnego dziennika transakcji UNFCCC i dalej do niezależnego dziennika transakcji Wspólnoty, wymiana danych jest prowadzona z zastosowaniem wymogów dotyczących sprzętu i oprogramowania określonych w specyfikacji funkcjonalnej i technicznej standardów wymiany danych w systemach rejestracji w ramach protokołu z Kioto, opracowanej na podstawie decyzji 24/CP.8 Konferencji Stron UNFCCC.
Jeżeli procesy dotyczące zweryfikowanych emisji, rachunków i automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji są wykonywane poprzez wymianę danych za pośrednictwem niezależnego dziennika transakcji Wspólnoty, wymiana danych jest prowadzona zgodnie z ust. 2 lit. b).
ZAŁĄCZNIK II
Tabele, które mają być zamieszczone w rejestrach Państw Członkowskich
Tabele, które mają być zamieszczone w rejestrach Państw Członkowskich
a) Lata: w indywidualnych komórkach, począwszy od 2005 r. w kolejności rosnącej.
b) Kod identyfikacyjny instalacji: w indywidualnych komórkach zawierających elementy przedstawione w załączniku VI i w kolejności rosnącej.
c) Zweryfikowane emisje: zweryfikowane emisje na określony rok dla określonej instalacji są wpisywane do komórki łączącej tenże rok z kodem identyfikacyjnym tej instalacji.
2. Każdy rejestr Państwa Członkowskiego ma możliwość tabelarycznego ujęcia następujących informacji, które wchodzą w skład tabeli odstąpionych przydziałów:
a) Lata: w indywidualnych komórkach, począwszy od 2005 r. w kolejności rosnącej.
b) Kod identyfikacyjny instalacji: w indywidualnych komórkach zawierających elementy przedstawione w załączniku VI i w kolejności rosnącej.
c) Odstąpione przydziały: ilość przydziałów odstąpionych zgodnie z art. 52, 53 i 54 za dany rok dla określonej instalacji jest wpisywana do trzech komórek łączących tenże rok z kodem identyfikacyjnym tej instalacji.
3. Każdy rejestr Państwa Członkowskiego ma możliwość tabelarycznego ujęcia następujących informacji, które wchodzą w skład tabeli statusu zgodności:
a) Lata: w indywidualnych komórkach, począwszy od 2005 r. w kolejności rosnącej.
b) Kod identyfikacyjny instalacji: w indywidualnych komórkach zawierających elementy przedstawione w załączniku VI i w kolejności rosnącej.
c) Status zgodności: status zgodności za określony rok dla określonej instalacji jest wpisywany do komórki łączącej tenże rok z kodem identyfikacyjnym tej instalacji. Status zgodności jest obliczany zgodnie z art. 55.
ZAŁĄCZNIK III
79 Informacje dotyczące każdego rachunku posiadania operatora, które mają być dostarczone administratorowi rejestru
79 Informacje dotyczące każdego rachunku posiadania operatora, które mają być dostarczone administratorowi rejestru
2. Kod identyfikacyjny pozwolenia określony przez kompetentny organ, składający się z elementów podanych w załączniku VI.
3. Kod identyfikacyjny instalacji składający się z elementów podanych w załączniku VI.
4. Identyfikator alfanumeryczny określony dla rachunku przez operatora, który winien być niepowtarzalny w rejestrze.
5. Nazwisko, adres, kod pocztowy, kraj, numer telefonu, numer telefaksu oraz adres poczty elektronicznej głównego upoważnionego przedstawiciela rachunku posiadania operatora, wyznaczonego przez operatora dla tego rachunku.
6. Nazwisko, adres, kod pocztowy, kraj, numer telefonu, numer telefaksu oraz adres poczty elektronicznej drugorzędnego upoważnionego przedstawiciela rachunku posiadania operatora, wyznaczonego przez operatora dla tego rachunku.
7. Nazwiska, adresy, kody pocztowe, kraj, numery telefonu, numery telefaksu oraz adresy poczty elektronicznej wszelkich dodatkowych upoważnionych przedstawicieli rachunku posiadania operatora, wyznaczonych przez operatora dla tego rachunku, wraz z ich prawami dostępu do rachunku.
8. Świadectwo potwierdzające tożsamość upoważnionych przedstawicieli rachunku posiadania operatora.
ZAŁĄCZNIK IV
80 Informacje dotyczące osobistych rachunków posiadania, które należy dostarczyć administratorowi rejestru
80 Informacje dotyczące osobistych rachunków posiadania, które należy dostarczyć administratorowi rejestru
Tabela IV-I
1 | Kod identyfikacyjny rachunku (nadany przez rejestr) |
2 | Typ rachunku |
3 | Okres zobowiązania |
4 | Identyfikator posiadacza rachunku (nadany przez rejestr) |
5 | Nazwisko posiadacza rachunku |
6 | Identyfikator rachunku (nadany przez posiadacza rachunku) |
7 | Adres posiadacza rachunku - kraj |
8 | Adres posiadacza rachunku - region |
9 | Adres posiadacza rachunku - miasto |
10 | Adres posiadacza rachunku - kod pocztowy |
11 | Adres posiadacza rachunku - ulica |
12 | Adres posiadacza rachunku - nr budynku |
13 | Adres posiadacza rachunku - nr rejestracyjny przedsiębiorstwa lub nr identyfikacyjny |
14 | Adres posiadacza rachunku - telefon 1 |
15 | Adres posiadacza rachunku - telefon 2 |
16 | Adres e-mail posiadacza rachunku |
17 | Data urodzenia (dla osób fizycznych) |
18 | Miejsce urodzenia (dla osób fizycznych) |
19 | Nr rejestracyjny VAT i kod państwa |
2. Dowód na to, że osoba składająca wniosek o otwarcie rachunku posiada otwarty rachunek bankowy w państwie członkowskim Europejskiego Obszaru Gospodarczego.
3. Dowód tożsamości osoby fizycznej składającej wniosek o otwarcie rachunku, który może stanowić kopia jednego z poniższych dokumentów:
a) dowód tożsamości wydany przez państwo należące do Europejskiego Obszaru Gospodarczego lub Organizacji Współpracy Gospodarczej i Rozwoju;
b) paszport.
4. Dowód adresu stałego zamieszkania posiadacza rachunku będącego osobą fizyczną, który może stanowić kopia jednego z poniższych dokumentów:
a) dokument tożsamości dostarczony zgodnie z pkt 3, jeżeli podany jest na nim adres stałego zamieszkania;
b) każdy inny dokument tożsamości wydany przez rząd, zawierający adres stałego zamieszkania;
c) jeżeli kraj stałego zamieszkania nie wydaje dokumentów tożsamości zawierających adres stałego zamieszkania, dokument wydany przez władze lokalne potwierdzający adres stałego zamieszkania osoby;
d) każdy inny dokument zwykle przyjmowany w państwie członkowskim administratora rachunku jako dowód miejsca stałego zamieszkania osoby.
5. Następujące dokumenty w przypadku osoby prawnej składającej wniosek o otwarcie rachunku:
a) kopia aktów założycielskich osoby prawnej oraz kopia dowodu rejestracji osoby prawnej;
b) dane rachunku bankowego;
c) potwierdzenie rejestracji VAT;
d) informacje dotyczące rzeczywistego beneficjenta osoby prawnej zgodnie z definicją w dyrektywie 2005/60/WE;
e) wykaz dyrektorów;
f) kopia sprawozdania rocznego lub najnowszych sprawdzonych przed audytorów sprawozdań finansowych lub - jeżeli sprawdzone przez audytorów sprawozdania finansowe nie są dostępne - kopia sprawozdań finansowych opatrzona pieczęcią urzędu skarbowego lub dyrektora finansowego.
6. Dowód zarejestrowanego adresu posiadacza rachunku będącego osobą prawną, jeżeli nie wynika on jasno z dokumentu przedłożonego zgodnie z pkt 5.
7. Informacja z rejestru karnego o osobie fizycznej składającej wniosek o otwarcie rachunku lub - jeżeli jest to osoba prawna - o jej dyrektorach.
8. Każda kopia dokumentu przedłożonego jako dowód zgodnie z niniejszym załącznikiem musi być poświadczona za zgodność z oryginałem przez notariusza lub inną osobę o podobnej funkcji określoną przez krajowego administratora. W przypadku dokumentów wydanych poza państwem członkowskim, które występuje o kopię, należy dokonać legalizacji kopii. Data uwierzytelnienia lub legalizacji nie może być wcześniejsza niż trzy miesiące przed datą wniosku.
9. Administrator rachunku może nałożyć wymóg, aby do przedkładanych dokumentów dołączono tłumaczenie przysięgłe na język określony przez administratora. W celu sprawdzenia dowodów przedłożonych zgodnie z niniejszym załącznikiem administrator rachunku może skorzystać z mechanizmów elektronicznych zamiast z dokumentów papierowych.
ZAŁĄCZNIK IVA
81 Informacje dotyczące upoważnionych przedstawicieli i dodatkowych upoważnionych przedstawicieli, które należy dostarczyć administratorowi rejestru
81 Informacje dotyczące upoważnionych przedstawicieli i dodatkowych upoważnionych przedstawicieli, które należy dostarczyć administratorowi rejestru
1 | Identyfikator osoby |
2 | Rodzaj upoważnionego przedstawiciela |
3 | Imię |
4 | Nazwisko |
5 | Tytuł |
6 | Stanowisko |
7 | Adres - kraj |
8 | Adres - region |
9 | Adres - miasto |
10 | Adres - kod pocztowy |
11 | Adres - ulica |
12 | Adres - numer budynku |
13 | Nr telefonu 1 |
14 | Nr telefonu 2 |
15 | Adres e-mail |
16 | Data urodzenia |
17 | Miejsce urodzenia |
18 | Preferowany język |
19 | Poziom poufności |
20 | Prawa dodatkowych upoważnionych przedstawicieli |
1. Informacje określone w tabeli IVa-I.
2. Podpisane stwierdzenie posiadacza rachunku potwierdzające, że pragnie on wyznaczyć daną osobę na upoważnionego przedstawiciela lub dodatkowego upoważnionego przedstawiciela.
3. Dowód tożsamości osoby wyznaczonej, który może stanowić kopia jednego z poniższych dokumentów:
a) dowód tożsamości wydany przez państwo należące do Europejskiego Obszaru Gospodarczego lub Organizacji Współpracy Gospodarczej i Rozwoju;
b) paszport.
4. Dowód adresu stałego zamieszkania osoby wyznaczonej, który może stanowić kopia jednego z poniższych dokumentów:
a) dokument tożsamości dostarczony zgodnie z pkt 3, jeżeli podany jest na nim adres stałego zamieszkania;
b) każdy inny dokument tożsamości wydany przez rząd, zawierający adres stałego zamieszkania;
c) jeżeli kraj stałego zamieszkania nie wydaje dokumentów tożsamości zawierających adres stałego zamieszkania, dokument wydany przez władze lokalne potwierdzający adres stałego zamieszkania osoby;
d) każdy inny dokument zwykle przyjmowany w państwie członkowskim administratora rachunku jako dowód miejsca stałego zamieszkania osoby.
5. Każda kopia dokumentu przedłożonego jako dowód zgodnie z niniejszym załącznikiem musi być poświadczona za zgodność z oryginałem przez notariusza lub inną osobę o podobnej funkcji określoną przez krajowego administratora. W przypadku dokumentów wydanych poza państwem członkowskim, które występuje o kopię, należy dokonać legalizacji kopii. Data uwierzytelnienia lub legalizacji nie może być wcześniejsza niż trzy miesiące przed datą wniosku.
6. Administrator rachunku może nałożyć wymóg, aby do przedkładanych dokumentów dołączono tłumaczenie przysięgłe na język określony przez administratora.
7. Administrator rachunku może skorzystać z mechanizmów elektronicznych zamiast dokumentów papierowych w celu sprawdzenia dowodów przedłożonych zgodnie z niniejszym załącznikiem.
ZAŁĄCZNIK V
Podstawowe zasady i warunki
Podstawowe zasady i warunki
1. Zależność pomiędzy posiadaczami rachunków a administratorami rejestrów.
Obowiązki posiadacza rachunku i upoważnionego przedstawiciela
2. Obowiązki posiadacza rachunku i upoważnionego przedstawiciela związane z zabezpieczeniem, nazwami użytkownika i hasłami oraz dostępem do strony WWW rejestru.
3. Obowiązek posiadacza rachunku i upoważnionego przedstawiciela wysłania danych na stronie WWW rejestru i zapewnienia, że wysłane dane są ścisłe.
4. Obowiązek posiadacza rachunku i upoważnionego przedstawiciela przestrzegania zasad używania strony WWW rejestru.
Obowiązki administratora rejestru
5. Obowiązek administratora rejestru wykonywania poleceń posiadacza rachunku.
6. Obowiązek administratora rejestru zarejestrowania danych posiadacza rachunku.
7. Obowiązek administratora rejestru utworzenia, uaktualnienia lub zamknięcia rachunku zgodnie z przepisami rozporządzenia.
Procedury procesowe
8. Przepisy dotyczące finalizacji i potwierdzenia procesów.
Płatność
9. Zasady i warunki dotyczące opłat rejestracyjnych za ustanowienie i prowadzenie rachunków.
Obsługa strony WWW rejestru
10. Przepisy dotyczące prawa administratora rejestru do dokonywania zmian na stronie WWW rejestru.
11. Warunki używania strony WWW rejestru.
Gwarancje i zabezpieczenia
12. Ścisłość informacji.
13. Uprawnienia do inicjowania procesów.
Zmiana podstawowych zasad i warunków wynikająca ze zmian w niniejszym rozporządzeniu lub zmian w krajowym ustawodawstwie
Zabezpieczenie i reakcja na przypadki naruszenia zabezpieczenia
Rozwiązanie sporów
14. Przepisy dotyczące sporów pomiędzy posiadaczami rachunków.
Odpowiedzialność
15. Granice odpowiedzialności administratora rejestru.
16. Granice odpowiedzialności posiadacza rachunku.
Prawa stron trzecich
Pośrednictwo, powiadomienia i obowiązujące prawo
ZAŁĄCZNIK VI
82 Definicje kodów identyfikacyjnych
82 Definicje kodów identyfikacyjnych
1. W niniejszym załączniku opisano elementy następujących kodów identyfikacyjnych:
a) kodu identyfikacji jednostki;
b) kodu identyfikacji rachunku;
c) kodu identyfikacji pozwolenia;
d) kodu identyfikacji posiadacza rachunku;
e) kodu identyfikacji instalacji;
f) kodu identyfikacji korelacji;
g) kodu identyfikacji transakcji;
h) kodu identyfikacji uzgodnienia;
i) kodu identyfikacji projektu.
Wersja kodów ISO3166 jest określona w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
Wyświetlanie i raportowanie kodów identyfikacyjnych
2. W celu wyświetlania i raportowania kodów identyfikacyjnych przedstawionych w niniejszym załączniku każdy element kodu identyfikacyjnego będzie oddzielony myślnikiem "-" i bez spacji. Zera nieznaczące w wartościach liczbowych nie są wyświetlane. Oddzielający myślnik "-" nie jest przechowywany w elementach kodu identyfikacyjnego.
Kod identyfikacji jednostki
3. W tabeli VI-1 wyszczególniono elementy kodu identyfikacji jednostki. Każdej jednostce Kioto i przydziałowi przypisany jest kod identyfikacji jednostki. Kody identyfikacji jednostek są generowane przez rejestry i są niepowtarzalne w całym systemie rejestrów.
4. Zestaw jednostek jest przesyłany jako blok jednostek określony przez początkowy identyfikator bloku i końcowy identyfikator bloku. Każda jednostka bloku jest identyczna, różniąc się jedynie swoim niepowtarzalnym elementem identyfikatora. Każdy niepowtarzalny element identyfikatora jednostek bloku jednostek jest elementem kolejnym. Gdy zachodzi potrzeba przeprowadzenia transakcji, prześledzenia lub innego rodzaju scharakteryzowania jednostki lub bloku jednostek, rejestry lub dzienniki transakcji tworzą wielorakie bloki jednostek z pojedynczego bloku jednostek. Podczas przesyłania pojedynczej jednostki początkowy identyfikator bloku i końcowy identyfikator bloku są jednakowe.
5. Wielorakie bloki jednostek nie pokrywają się ze sobą nawzajem pod względem elementu ich identyfikatora. Wielorakie bloki jednostek w tym samym komunikacie pojawiają się w tym komunikacie w kolejności rosnącej ich identyfikatora bloku.
Tabela VI-1: Kod identyfikacji jednostki
Element | Kolejność wyświetlania | Identyfikator wymagany dla następujących typów jednostek | Typ danych | Długość | Zakres kodów |
Rejestr tworzący | 1 | AAU, RMU, CER, ERU | A | 3 | ISO3166 (kod 2-literowy), "EU" dla rejestru Wspólnoty |
Typ jednostki | 2 | AAU, RMU, CER, ERU | N | 2 | 0 = nie jednostka Kioto |
1 = AAU | |||||
2 = RMU | |||||
3 = ERU przekształcona z AAU | |||||
4 = ERU przekształcona z RMU | |||||
5 = CER (nie lCER ani tCER) | |||||
6 = tCER | |||||
7 = lCER | |||||
Uzupełniający typ jednostki | 3 | AAU, RMU, CER, ERU | N | 2 | Puste dla jednostek Kioto |
1 = Przydział wydany na okres 2008-2012 i następne pięcioletnie okresy | |||||
2 = Przydział wydany na okres 2005-2007 | |||||
3 = Przydział na okoliczność siły wyższej | |||||
4 = Uprawnienie wydane na okres 2008-2012 i kolejne okresy pięciu lat przez państwo członkowskie nieposiadające jednostek AAU | |||||
Początek bloku szeregowego jednostek | 4 | AAU, RMU, CER, ERU | N | 15 | Jednoznaczne wartości liczbowe przypisane przez rejestr od 1 - 999 999 999 999 999 |
Koniec bloku szeregowego jednostek | 5 | AAU, RMU, CER, ERU | N | 15 | Jednoznaczne wartości liczbowe przypisane przez rejestr od 1 - 999 999 999 999 999 |
Pierwotny okres zobowiązania | 6 | AAU, RMU, CER, ERU | N | 2 | 0 = 2005 - 2007 |
1 = 2008 - 2012 | |||||
... | |||||
99 | |||||
Stosowalny okres zobowiązania | 7 | AAU, CER, ERU | N | 2 | 0 = 2005 - 2007 |
1 = 2008 - 2012 | |||||
... | |||||
99 | |||||
Działalność LULUCF | 8 | RMU, CER, ERU | N | 3 | 1 = Zalesianie i ponowne zalesianie |
2 = Wylesianie | |||||
3 = Gospodarka leśna | |||||
4 = Gospodarka terenami uprawnymi | |||||
5 = Gospodarka łąkami i pastwiskami | |||||
6 = Powtórna wegetacja | |||||
Identyfikator projektu | 9 | CER, ERU | N | 7 | Jednoznaczna wartość liczbowa przypisana dla projektu |
Ścieżka | 10 | ERU | N | 2 | 1 lub 2 |
Data wygaśnięcia | 11 | lCER, tCER | Data | Data upływu ważności jednostek lCER lub tCER |
6. W tabeli VI-2 wymieniono ważne kombinacje początkowego typu jednostki i dodatkowego typu jednostki. Przydział posiada uzupełniający typ jednostki bez względu na okres, na jaki został on wydany oraz to, czy został on przekształcony z AAU lub innej jednostki Kioto. AAU lub inna jednostka Kioto, która nie została przekształcona na przydział, nie posiada uzupełniającego typu jednostki. Po konwersji jednostki AAU na przydział zgodnie z przepisami niniejszego rozporządzenia uzupełniający typ jednostki ustawiany jest na 1. Po konwersji przydziału na jednostkę AAU zgodnie z przepisami niniejszego rozporządzenia nie ma uzupełniającego typu jednostki.
Tabela VI-2: Ważne kombinacje: początkowy typ jednostki - uzupełniający typ jednostki
Początkowy typ jednostki | Uzupełniający typ jednostki | Opis |
1 | [nie dotyczy] | AAU |
2 | [nie dotyczy] | RMU |
3 | [nie dotyczy] | ERU przekształcona z AAU |
4 | [nie dotyczy] | ERU przekształcona z RMU |
5 | [nie dotyczy] | CER (nie tCER ani lCER) |
6 | [nie dotyczy] | tCER |
7 | [nie dotyczy] | lCER |
1 | 1 | Przydział wydany na okres 2008-2012 i na kolejne 5-letnie okresy jest przekształcony z AAU |
0 | 2 | Przydział wydany na okres 2005-2007 i nieprzekształcony z AAU lub innej jednostki Kioto |
0 | 3 | Przydział na okoliczność siły wyższej |
0 | 4 | Uprawnienie wydane na okres 2008-2012 i kolejne okresy pięciu lat przez państwo członkowskie, które nie posiada jednostek AAU, które to uprawnienie nie jest przekształcane z jednostki AAU lub innej jednostki Kioto |
Kod identyfikacji rachunku
7. W tabeli VI-3 wyszczególniono elementy kodu identyfikacji rachunku. Każdy rachunek ma przypisany kod identyfikacji rachunku. Kody identyfikacji rachunku są generowane przez rejestry i są niepowtarzalne w całym systemie rejestrów. Kody identyfikacji rachunków dla rachunków, które zostały wcześniej zamknięte, nie są ponownie używane.
8. Kod identyfikacji rachunku posiadania operatora jest powiązany z jedną instalacją. Dana instalacja jest powiązana z jednym kodem identyfikacji rachunku posiadania operatora. Rachunki posiadania wymienione w art. 11 ust. 1 i 2 nie mają stosownego okresu zobowiązania, bez względu na typ rachunku.
Tabela VI-3: Kod identyfikacji rachunku
Element | Kolejność wyświetlania | Typ danych | Długość | Zakres kodów |
Rejestr tworzący | 1 | A | 3 | ISO3166 (kod dwuliterowy), "CDM" dla rejestru CDM, "EU" dla rejestru Wspólnoty |
Typ rachunku | 2 | N | 3 | 100 = Rachunek posiadania Strony |
120 = Rachunek posiadania operatora | ||||
121 = Osobisty rachunek posiadania | ||||
Pozostałe typy rachunków są takie, jak przedstawiono w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC | ||||
Identyfikator rachunku | 3 | N | 15 | Jednoznaczne wartości liczbowe przypisane przez rejestr od 1 do 999 999 999 999 999 |
Centralny administrator definiuje oddzielny podzakres tych wartości dla rejestru Wspólnoty i każdego rejestru prowadzonego w sposób skonsolidowany z rejestrem Wspólnoty | ||||
Stosowny okres zobowiązania | 4 | N | 2 | 0 dla rachunków posiadania |
0-99 dla rachunków wycofania i anulowania |
8a. Najpóźniej do dnia 1 stycznia 2010 roku administrator rejestru określa dwie ostatnie cyfry identyfikatora rachunku w formie niepowtarzalnej liczby walidacji numeru rachunku, która jest wynikiem funkcji logicznej zastosowanej wobec poprzednich numerów w identyfikatorze rachunku.
Kod identyfikacji pozwolenia
9. W tabeli VI-4 wyszczególniono elementy kodu identyfikacji pozwolenia. Każdemu pozwoleniu przypisany jest kod identyfikacji pozwolenia. Kody identyfikacji pozwolenia są generowane przez kompetentny organ i są niepowtarzalne w całym systemie rejestrów.
10. Kod identyfikacji pozwolenia jest przypisany jednemu operatorowi. Danemu operatorowi jest przypisany co najmniej jeden kod identyfikacji pozwolenia. Kod identyfikacji pozwolenia jest przypisany co najmniej jednej instalacji. Dana instalacja ma w danej chwili jeden kod identyfikacji pozwolenia.
Tabela VI-4: Kod identyfikacji pozwolenia
Element | Kolejność wyświetlania | Typ danych | Długość | Zakres kodów |
Rejestr tworzący | 1 | A | 3 | ISO3166 (kod dwuliterowy), "EU" dla rejestru Wspólnoty |
Identyfikator pozwolenia | 2 | A | 50 | ([0-9] | [A-Z] |["-"]) + |
Kod identyfikacji posiadacza rachunku
11. W tabeli VI-5 wyszczególniono elementy kodu identyfikacji posiadacza rachunku. Każdy posiadacz rachunku ma przypisany jeden kod identyfikacji posiadacza rachunku. Kody identyfikacji posiadacza rachunku są generowane przez rejestry i są niepowtarzalne w całym systemie rejestrów. Kody identyfikacji posiadacza rachunku nie są ponownie używane dla innego posiadacza rachunku i nie zmieniają się dla posiadacza rachunku w ciągu swojego istnienia.
Tabela VI-5: Kod identyfikacji posiadacza rachunku
Element | Kolejność wyświetlania | Typ danych | Długość | Zakres kodów |
Rejestr tworzący | 1 | A | 3 | Dwuliterowy kod ISO3166, "EU" dla rejestru Wspólnoty |
Identyfikator posiadacza rachunku | 2 | A | 50 | ([0-9] | [A-Z]) + |
Kod identyfikacji instalacji
12. W tabeli VI-6 wyszczególniono elementy kodu identyfikacji instalacji. Każdej instalacji przypisany jest kod identyfikacji instalacji. Kody identyfikacji instalacji są generowane przez rejestry i są niepowtarzalne w całym systemie rejestrów. Identyfikatorem instalacji jest liczba całkowita przypisana jako rosnący monotoniczny ciąg rozpoczynający się od 1. Identyfikatory instalacji nie zawierają przerw. Dlatego podczas generowania identyfikatora instalacji n rejestr wytwarza każdy identyfikator w przedziale od 1 do n-1. Kod identyfikacji instalacji nie zostaje ponownie użyty dla innej instalacji i nie zmienia się dla danej instalacji w ciągu swego istnienia.
13. Kod identyfikacji instalacji jest przypisany jednej instalacji. Danej instalacji przypisany jest jeden kod identyfikacji instalacji.
Tabela VI-6: Kod identyfikacji instalacji
Element | Kolejność wyświetlania | Typ danych | Długość | Zakres kodów |
Rejestr tworzący | 1 | A | 3 | ISO3166 (kod dwuliterowy), "EU" dla rejestru Wspólnoty |
Identyfikator instalacji | 2 | N | 15 | Jednoznaczne wartości liczbowe przypisane przez rejestr od 1 do 999 999 999 999 999 |
Kod identyfikacji korelacji
14. W tabeli VI-7 wyszczególniono elementy kodów identyfikacji korelacji. Każdemu procesowi, o którym mowa w załączniku VIII i załączniku XIa, zostaje nadany kod identyfikacji korelacji. Kody identyfikacji korelacji są generowane przez rejestry i są jednoznaczne w całym systemie rejestracji. Nie można powtórnie używać kodów identyfikacji korelacji. Przy ponownym przedstawieniu procesu dotyczącego rachunku lub zweryfikowanych emisji, który uprzednio został zakończony lub anulowany, system nadaje nowy jednoznaczny kod identyfikacji korelacji.
Tabela VI-7: Kod identyfikacji korelacji
Element | Kolejność wyświetlania | Typ danych | Długość | Zakres kodów |
Rejestr tworzący | 1 | A | 3 | ISO3166 (kod dwuliterowy), "EU" dla rejestru Wspólnoty |
Identyfikator korelacji | 2 | N | 15 | Jednoznaczne wartości liczbowe przypisane przez rejestr od 1 do 999 999 999 999 999 |
Kod identyfikacji transakcji
15. Każdemu procesowi według załącznika IX przypisany jest kod identyfikacji transakcji. Kody identyfikacji transakcji są generowane przez rejestry i są niepowtarzalne w całym systemie rejestrów. Kody identyfikacji transakcji nie są ponownie używane. Ponownie przedłożonemu procesowi dotyczącemu transakcji, który był uprzednio przerwany lub anulowany, zostaje przypisany nowy, jednoznaczny kod identyfikacji transakcji.
16. Elementy kodów identyfikacji transakcji są przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
Kod identyfikacji uzgodnienia
17. Każdemu procesowi według załącznika X przypisany jest kod identyfikacji uzgodnienia. Zanim zostanie ustanowione łącze komunikacji pomiędzy niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC, niezależny dziennik transakcji Wspólnoty generuje kod identyfikacji uzgodnienia podczas żądania od rejestrów informacji dotyczących uzgodnienia dla określonej godziny i dnia. Następnie rejestry otrzymują kod identyfikacji uzgodnienia od niezależnego dziennika transakcji UNFCCC. Kod identyfikacji uzgodnienia jest niepowtarzalny w całym systemie rejestrów i wszystkie komunikaty wymieniane na wszystkich etapach procesu uzgadniania dla określonej godziny i dnia używają tego samego kodu identyfikacji uzgodnienia.
18. Elementy kodów identyfikacji uzgodnienia są przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
Kod identyfikacji projektu
19. Każdemu projektowi jest przypisany kod identyfikacji projektu. Kody identyfikacji projektu są generowane przez radę wykonawczą CDM dla jednostek CER i przez odpowiedni organ Strony lub komitet nadzorczy według art. 6 zgodnie z decyzją 16/CP.7 Konferencji Stron UNFCCC dla jednostek ERU i są niepowtarzalne w całym systemie rejestrów.
20. Elementy kodów identyfikacji projektu są przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
ZAŁĄCZNIK VII
83 Wykaz kodów wejścia
83 Wykaz kodów wejścia
1. W niniejszym załączniku zdefiniowano kody dla wszystkich elementów i tabel obsługujących kody. Wersja ISO3166 kodów jest taka, jak podano w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemu rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
Kody specyficzne dla UE
2. Nazwa pola: Typ działania
Opis pola: Kod numeryczny wskazujący typ działania instalacji
Kod | Opis |
1 | Instalacje spalające o nominalnej ilości doprowadzonego ciepła ponad 20 MW |
2 | Rafinerie oleju mineralnego |
3 | Piece koksowe |
4 | Instalacje prażenia i spiekania rud (w tym rudy siarczkowej) |
5 | Instalacje do produkcji surówki lub stali (stapiania pierwotnego lub wtórnego), w tym instalacje do ciągłego odlewania |
6 | Instalacje do produkcji klinkieru cementowego w piecach obrotowych lub wapna w piecach obrotowych lub innych piecach |
7 | Instalacje do produkcji szkła, w tym także włókna szklanego |
8 | Instalacje do produkcji wyrobów ceramicznych przez wypalanie, w szczególności dachówek, cegieł, cegieł ogniotrwałych, płytek, wyrobów kamionkowych lub porcelany |
9 | Urządzenia przemysłowe do produkcji (a) pulpy z drewna lub innych surowców włóknistych (b) papieru i tekstury |
99 | Inne działanie wybrane stosownie do art. 24 dyrektywy 2003/87/WE |
3. Nazwa pola: Typ związku
Opis pola: Kod numeryczny wskazujący rodzaj związku pomiędzy rachunkiem a osobą lub operatorem
Kod | Opis |
1 | Posiadacz rachunku |
2 | Główny upoważniony przedstawiciel posiadacza rachunku |
3 | Drugorzędny upoważniony przedstawiciel posiadacza rachunku |
4 | Dodatkowy upoważniony przedstawiciel posiadacza rachunku |
5 | Upoważniony przedstawiciel weryfikatora |
6 | Osoba kontaktowa w sprawie instalacji |
4. Nazwa pola: Typ procesu
Opis pola: Kod numeryczny wskazujący typ procesu transakcji
Kod | Opis |
01-00 | Wydanie jednostek AAU i RMU |
02-00 | Konwersja jednostek AAU i RMU na jednostki ERU |
03-00 | Przekaz zewnętrzny (od 2008-2012) |
04-00 | Anulowanie (od 2008-2012) |
(skreślony) | |
06-00 | Anulowanie i wycofanie jednostek tCER i lCER |
07-00 | Przeniesienie jednostek Kioto i przydziałów wydanych na okres 2008-2012 i następne pięcioletnie okresy |
08-00 | Zmiana daty ważności jednostek tCER i lCER |
10-00 | Przekaz wewnętrzny |
01-51 | Wydanie przydziału (2005-2007) |
10-52 | Wydanie przydziału (od 2008-2012) |
10-53 | Rozdzielenie przydziałów |
01-54 | Wydanie przydziału na okoliczność siły wyższej |
10-55 | Korekta przydziału |
03-21 | Przekaz zewnętrzny (2005-2007) |
10-01 | Anulowanie przydziału (2005-2007) |
10-02 | Odstąpienie przydziału |
04-03 | Wycofanie (2005-2007) |
10-41 | Anulowanie i wymiana |
10-61 | Przekształcenie odstąpionych uprawnień na wycofanie (2008-2012 i później) |
10-62 | Przekształcenie nierozdzielonych uprawnień na wycofanie (2008-2012 i później) |
05-00 | Wycofanie jednostek Kioto (2008-2012 i później) |
05-01 | Wycofanie odstąpionych uprawnień (2008-2012 i później) |
05-02 | Wycofanie nierozdzielonych uprawnień (2008-2012 i później) |
01-22 | Wydanie uprawnienia (rejestry, o których mowa w art. 63a) |
03-00 | Przeniesienie zewnętrzne (między rejestrem, o którym mowa w art. 63a, a innym rejestrem) |
10-22 | Przeniesienie między dwoma rejestrami, o których mowa w art. 63a |
05-22 | Wycofanie (rejestry, o których mowa w art. 63a) |
5. Nazwa pola: Uzupełniający typ jednostki
Opis pola: Kod numeryczny wskazujący uzupełniający typ jednostki
Kod | Opis |
0 | Brak uzupełniającego typu jednostki |
1 | Przydział wydany na okres 2008-2012 oraz kolejne pięcioletnie okresy i przekształcony z AAU |
2 | Przydział wydany na okres 2005-2007 i nieprzekształcony z AAU lub innej jednostki Kioto |
3 | Przydział na okoliczność siły wyższej |
4 | Uprawnienie wydane na okres 2008-2012 i kolejne okresy pięciu lat przez państwo członkowskie, które nie posiada jednostek AAU, które to uprawnienie nie jest przekształcane z jednostki AAU lub innej jednostki Kioto |
6. Nazwa pola: Kod działania
Opis pola: Kod numeryczny wskazujący działanie w procesie uaktualniania rachunku
Kod | Opis |
1 | Dodanie osób do rachunku lub instalacji |
2 | Uaktualnienie osób |
3 | Usunięcie osób |
Kody UNFCCC
7. Kody UNFCCC są przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
ZAŁĄCZNIK VIII
84 Procesy dotyczące rachunków i zweryfikowanych emisji z kodami odpowiedzi
84 Procesy dotyczące rachunków i zweryfikowanych emisji z kodami odpowiedzi
1. Stosuje się następujące sekwencje komunikatów dla procesów dotyczących rachunku lub zweryfikowanych emisji:
a) upoważniony przedstawiciel rachunku składa wniosek do administratora danego rejestru;
b) administrator rejestru przypisuje wnioskowi jednoznaczny kod identyfikacji korelacji składający się z elementów przedstawionych w załączniku VI;
c) pod warunkiem że procesy te są wykonywane przez wymianę danych za pośrednictwem niezależnego dziennika transakcji UNFCCC i dalej do niezależnego dziennika transakcji Wspólnoty, administrator rejestru wywołuje odpowiednią operację z serwisu usług sieciowych zarządzania kontem niezależnego dziennika transakcji UNFCCC. We wszystkich innych przypadkach administrator rejestru wywołuje odpowiednią operację z serwisu usług sieciowych zarządzania kontem niezależnego dziennika transakcji Wspólnoty;
d) niezależny dziennik transakcji Wspólnoty dokonuje sprawdzenia poprawności wniosku przez wywołanie odpowiedniej funkcji walidacji w niezależnym dzienniku transakcji Wspólnoty;
e) jeżeli nastąpi poświadczenie poprawności, a tym samym przyjęcie wniosku, to niezależny dziennik transakcji Wspólnoty wnosi zmianę do utrzymywanych przez siebie informacji zgodnie z wnioskiem;
f) niezależny dziennik transakcji Wspólnoty wywołuje działanie "receiveAccountOperationOutcome" ("odbierz wynik działania na rachunku") w serwisie WWW rejestru, który wysłał wniosek, powiadamiając rejestr o tym, czy wniosek został pozytywnie poświadczony, a tym samym przyjęty, czy też została stwierdzona rozbieżność we wniosku, przez co wniosek został odrzucony;
g) jeśli nastąpiło poświadczenie poprawności wniosku, przez co wniosek został przyjęty, to administrator rejestru, który wysłał wniosek, zmienia informacje przechowywane w rejestrze zgodnie z tym poświadczonym wnioskiem; w przeciwnym razie, jeśli we wniosku stwierdzona została rozbieżność, przez co wniosek został odrzucony, to administrator rejestru, który wysłał wniosek, nie zmienia żadnych informacji przechowywanych w rejestrze, jak wymagał tego odrzucony wniosek.
Tabela VIII-1: Schemat sekwencji komunikatów dla procesów dotyczących rachunku lub zweryfikowanych emisji
2. Pod warunkiem że są one wykonywane poprzez wymianę danych za pośrednictwem niezależnego dziennika transakcji Wspólnoty i dalej do niezależnego dziennika transakcji UNFCCC, zaś administrator rejestru wysyłając żądanie, powinien otrzymać potwierdzenie odbioru z niezależnego dziennika transakcji UNFCCC w ciągu 60 sekund oraz powinien otrzymać powiadomienie o poświadczeniu z niezależnego dziennika transakcji Wspólnoty w ciągu 24 godzin. W każdym innym przypadku administrator rejestru wysyłając żądanie, powinien otrzymać potwierdzenie odbioru z niezależnego dziennika transakcji Wspólnoty w ciągu 60 sekund oraz powinien otrzymać powiadomienie o poświadczeniu z niezależnego dziennika transakcji Wspólnoty w ciągu 24 godzin.
3. Status procesu w trakcie sekwencji komunikatów jest następujący:
Tabela VIII-2: Schemat statusu procesów dotyczących rachunku lub zweryfikowanych emisji
4. Składniki i funkcje, które są wykorzystywane podczas sekwencji komunikatów, przedstawiono w tabelach od VIII-3 do VIII-18. Funkcje, które są publiczne, są realizowane tak, jak określono. Funkcje, które są prywatne, służą jedynie do celów informacyjnych. Wejścia wszystkich funkcji zostały skonstruowane tak, aby były zgodne z formatem i wymaganiami informacyjnymi opisanymi za pomocą języka serwisu WWW, przedstawionymi w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemu rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC. Dla oznaczenia faktu, iż dany element może pojawiać się wiele razy jako wejście, użyto gwiazdki "(*)".
Tabela VIII-3: Składniki i funkcje dla procesów dotyczących rachunku lub zweryfikowanych emisji
Składnik | Funkcja | Zakres |
MgmtOfAccountWS | CreateAccount() (Utworzenie rachunku) | Publiczny |
UpdateAccount() (Uaktualnienie rachunku) | Publiczny | |
CloseAccount() (Zamknięcie rachunku) | Publiczny | |
UpdateVerifiedEmissions()(Uaktualnienie zweryfikowanych emisji) | Publiczny | |
ReceiveAccountOperationOutcome() (Odebranie wyniku działania na rachunku) | Publiczny | |
AccountManagement | ValidateAccountCreation() (Poświadczenie ważności utworzenia rachunku) | Prywatny |
CreateAccount() (Utworzenie rachunku) | Prywatny | |
ValidateAccountUpdate() (Poświadczenie ważności uaktualnienia rachunku) | Prywatny | |
UpdateAccount() (Uaktualnienie rachunku) | Prywatny | |
ValidateAccountClosure() (Poświadczenie ważności zamknięcia rachunku) | Prywatny | |
CloseAccount() (Zamknięcie rachunku) | Prywatny | |
ValidateVerifiedEmissionsUpdate() (Poświadczenie ważności uaktualnienia zweryfikowanych emisji) | Prywatny | |
UpdateVerifiedEmissions() (Uaktualnienie zweryfikowanych emisji) | Prywatny | |
Data Validation | AuthenticateMessage() (Uwierzytelnienie komunikatu) | Prywatny |
CheckVersion() (Sprawdzenie wersji) | Prywatny | |
DataFormatChecks() (Sprawdzenia formatu danych) | Prywatny |
Table VIII-4: Składnik MgmtOfAccountWS
Zadanie | |
Zadaniem tego składnika jest obsługa wniosków serwisu WWW o zarządzanie rachunkami i zweryfikowanymi emisjami. | |
Funkcje udostępnione poprzez serwisy WWW | |
CreateAccount() | Obsługuje wnioski o utworzenie rachunku |
UpdateAccount() | Obsługuje wnioski o uaktualnienie rachunku |
CloseAccount() | Obsługuje wnioski o zamknięcie rachunku |
UpdateVerifiedEmissions() | Obsługuje wnioski o uaktualnienie zweryfikowanych emisji |
ReceiveAccountOperationOutcome() | Otrzymuje wynik ("przyjęto" lub "odrzucono") operacji na rachunku (utworzenie, uaktualnienie, ...) |
Pozostałe funkcje | |
Nie dotyczy. | |
Role | |
Niezależny dziennik transakcji Wspólnoty (dla wszystkich funkcji) oraz rejestr (tylko dla funkcji ReceiveAccount-OperationOutcome) |
Tabela VIII-5: Funkcja MgmtOfAccountWS.CreateAccount()
Zadanie | |
Funkcja ta służy do przyjmowania wniosku o utworzenie rachunku. | |
Niezależny dziennik transakcji Wspólnoty uwierzytelnia inicjujący rejestr (rejestr tworzący) przez wywołanie funkcji AuthenticateMessage() i sprawdza wersję inicjującego rejestru przez wywołanie funkcji CheckVersion(). | |
Jeżeli uwierzytelnienie i sprawdzenia wersji zakończą się pozytywnie, to odesłany zostaje identyfikator wyniku "1" bez jakichkolwiek kodów odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. | |
Jeżeli uwierzytelnienie lub sprawdzenia wersji zakończą się negatywnie, to odesłany zostaje identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | |
Jeżeli dana osoba (People) nie jest osobą fizyczną, to jej nazwa musi zostać umieszczona w parametrze LastName. | |
"PersonIdentifier" oznacza kod identyfikacji posiadacza rachunku składający się z elementów przedstawionych w załączniku VI. | |
"IdentifierInRegistry" oznacza alfanumeryczny identyfikator rachunku określony przez posiadacza rachunku stosownie do załączników III i IV. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
Account (*) | Obowiązkowy |
AccountType | Obowiązkowy |
AccountIdentifier | Obowiązkowy |
IdentifierInReg | Obowiązkowy |
CommitmentPeriod | Opcjonalny |
Installation | Opcjonalny |
InstallationIdentifier | Obowiązkowy |
PermitIdentifier | Obowiązkowy |
Name | Obowiązkowy |
MainActivityType | Obowiązkowy |
Country | Obowiązkowy |
PostalCode | Obowiązkowy |
City | Obowiązkowy |
Address1 | Obowiązkowy |
Address2 | Opcjonalny |
ParentCompany | Opcjonalny |
SubsidiaryCompany | Opcjonalny |
EPERIdentification | Opcjonalny |
Latitude | Opcjonalny |
Longitude | Opcjonalny |
ContactPeople (patrz: People) | Obowiązkowy |
People (*) | Obowiązkowy |
RelationshipCode | Obowiązkowy |
PersonIdentifier | Obowiązkowy |
FirstName | Opcjonalny |
LastName | Obowiązkowy |
Country | Obowiązkowy |
PostalCode | Obowiązkowy |
City | Obowiązkowy |
Address1 | Obowiązkowy |
Address2 | Opcjonalny |
PhoneNumber1 | Obowiązkowy |
PhoneNumber2 | Obowiązkowy |
FaxNumber | Opcjonalny |
Obowiązkowy | |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Response Code | Opcjonalny |
Użycia | |
- AuthenticateMessage | |
- WriteToFile | |
- CheckVersion | |
Użył | |
Nie dotyczy (wywoływane jako serwis WWW). |
Tabela VIII-6: Funkcja MgmtOfAccountWS.UpdateAccount()
Zadanie | |
Funkcja ta służy do przyjmowania wniosku o uaktualnienie rachunku. | |
Niezależny dziennik transakcji Wspólnoty uwierzytelnia inicjujący rejestr (rejestr tworzący) przez wywołanie funkcji AuthenticateMessage() i sprawdza wersję inicjującego rejestru przez wywołanie funkcji CheckVersion(). | |
Jeżeli uwierzytelnienie i sprawdzenia wersji zakończą się pozytywnie, to odesłany zostaje identyfikator wyniku "1" bez jakichkolwiek kodów odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. | |
Jeżeli uwierzytelnienie lub sprawdzenia wersji zakończą się negatywnie, to odesłany zostaje identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | |
Jeżeli dana osoba (People) nie jest osobą fizyczną, to jej nazwa musi zostać umieszczona w parametrze LastName. | |
"PersonIdentifier" oznacza kod identyfikacji posiadacza rachunku składający się z elementów przedstawionych w załączniku VI. | |
"IdentifierInRegistry" oznacza alfanumeryczny identyfikator rachunku określony przez posiadacza rachunku stosownie do załączników III i IV. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
Account (*) | Obowiązkowy |
AccountIdentifier | Obowiązkowy |
IdentifierInReg | Opcjonalny |
Installation | Opcjonalny |
PermitIdentifier | Opcjonalny |
Name | Opcjonalny |
MainActivityType | Opcjonalny |
Country | Opcjonalny |
PostalCode | Opcjonalny |
City | Opcjonalny |
Address1 | Opcjonalny |
Address2 | Opcjonalny |
ParentCompany | Opcjonalny |
SubsidiaryCompany | Opcjonalny |
EPERIdentification | Opcjonalny |
Latitude | Opcjonalny |
Longitude | Opcjonalny |
ContactPeople (patrz: People) | Opcjonalny |
People (*) | Opcjonalny |
Action | Obowiązkowy |
RelationshipCode | Obowiązkowy |
PersonIdentifier | Obowiązkowy |
FirstName | Opcjonalny |
LastName | Opcjonalny |
Country | Opcjonalny |
PostalCode | Opcjonalny |
City | Opcjonalny |
Address1 | Opcjonalny |
Address2 | Opcjonalny |
PhoneNumber1 | Opcjonalny |
PhoneNumber2 | Opcjonalny |
FaxNumber | Opcjonalny |
Opcjonalny | |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Response Code | Opcjonalny |
Użycia | |
- AuthenticateMessage | |
- WriteToFile | |
- CheckVersion | |
Użył | |
Nie dotyczy (wywoływane jako serwis WWW). |
Tabela VIII-7: Funkcja MgmtOfAccountWS.CloseAccount()
Zadanie | ||
Funkcja ta służy do przyjmowania wniosku o zamknięcie rachunku. | ||
Niezależny dziennik transakcji Wspólnoty uwierzytelnia inicjujący rejestr (rejestr tworzący) przez wywołanie funkcji AuthenticateMessage() i sprawdza wersję inicjującego rejestru przez wywołanie funkcji CheckVersion(). | ||
Jeżeli uwierzytelnienie i sprawdzenia wersji zakończą się pozytywnie, to odesłany zostaje identyfikator wyniku "1" bez jakichkolwiek kodów odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. | ||
Jeżeli uwierzytelnienie lub sprawdzenia wersji zakończą się negatywnie, to odesłany zostaje identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | ||
Parametry wejścia | ||
From | Obowiązkowy | |
To | Obowiązkowy | |
CorrelationId | Obowiązkowy | |
MajorVersion | Obowiązkowy | |
MinorVersion | Obowiązkowy | |
Account (*) | Obowiązkowy | |
AccountIdentifier | Obowiązkowy | |
Parametry wyjścia | ||
Result Identifier | Obowiązkowy | |
Response Code | Opcjonalny | |
Użycia | ||
- AuthenticateMessage | ||
- WriteToFile | ||
- CheckVersion | ||
Użył | ||
Nie dotyczy (wywoływane jako serwis WWW). |
Tabela VIII-8: Funkcja MgmtOfAccountWS.UpdateVerifiedEmissions()
Zadanie | ||
Funkcja ta służy do przyjmowania wniosków o uaktualnienie zweryfikowanych emisji. | ||
Niezależny dziennik transakcji Wspólnoty uwierzytelnia inicjujący rejestr (rejestr tworzący) przez wywołanie funkcji AuthenticateMessage() i sprawdza wersję inicjującego rejestru przez wywołanie funkcji CheckVersion(). | ||
Jeżeli uwierzytelnienie i sprawdzenia wersji zakończą się pozytywnie, to odesłany zostaje identyfikator wyniku "1" bez jakichkolwiek kodów odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. | ||
Jeżeli uwierzytelnienie lub sprawdzenia wersji zakończą się negatywnie, to odesłany zostaje identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | ||
Parametry wejścia | ||
From | Obowiązkowy | |
To | Obowiązkowy | |
CorrelationId | Obowiązkowy | |
MajorVersion | Obowiązkowy | |
MinorVersion | Obowiązkowy | |
VerifiedEmissions (*) | Obowiązkowy | |
Year | Obowiązkowy | |
Installations (*) | Obowiązkowy | |
InstallationIdentifier | Obowiązkowy | |
VerifiedEmission | Obowiązkowy | |
Parametry wyjścia | ||
Result Identifier | Obowiązkowy | |
Response Code | Opcjonalny | |
Użycia | ||
- AuthenticateMessage | ||
- WriteToFile | ||
- CheckVersion | ||
Użył | ||
Nie dotyczy (wywoływane jako serwis WWW). |
Tabela VIII-9: Funkcja MgmtOfAccountWS.ReceiveAccountOperationOutcome()
Zadanie | ||
Funkcja ta służy do przyjmowania wyniku działania związanego z zarządzaniem rachunkiem. | ||
Inicjujący rejestr (rejestr tworzący) uwierzytelnia niezależny dziennik transakcji UNFCCC (lub niezależny dziennik transakcji Wspólnoty, jeżeli wszystkie procesy, o których mowa w załączniku VIII, są wykonywane poprzez wymianę danych za pośrednictwem niezależnego dziennika transakcji Wspólnoty) przez wywołanie funkcji Authenticate Message() i sprawdza wersję dziennika transakcji przez wywołanie funkcji Check Version(). | ||
Jeżeli uwierzytelnienie i sprawdzenia wersji zakończą się pozytywnie, to odesłany zostaje identyfikator wyniku "1" bez jakichkolwiek kodów odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. | ||
Jeżeli uwierzytelnienie lub sprawdzenia wersji zakończą się negatywnie, to odesłany zostaje identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | ||
Jeżeli wynik jest "0" z jakiejkolwiek innej przyczyny lub błędu, wówczas lista kodów odpowiedzi zawiera pary (identyfikator rachunku lub instalacji wraz z odpowiadającym mu kodem odpowiedzi). | ||
Parametry wejścia | ||
From | Obowiązkowy | |
To | Obowiązkowy | |
CorrelationId | Obowiązkowy | |
MajorVersion | Obowiązkowy | |
MinorVersion | Obowiązkowy | |
Outcome | Obowiązkowy | |
Response List | Opcjonalny | |
Parametry wyjścia | ||
Result Identifier | Obowiązkowy | |
Response Code | Opcjonalny | |
Użycia | ||
- AuthenticateMessage | ||
- WriteToFile | ||
- CheckVersion | ||
Użył | ||
Nie dotyczy (wywoływane jako serwis WWW). |
Tabela VIII-10: Składnik AccountManagement
Zadanie | |
Zadaniem tego składnika jest udostępnienie funkcji poświadczenia ważności (walidacji) i uaktualnienia dla zarządzania rachunkami i zweryfikowanymi emisjami. | |
Funkcje udostępniane poprzez serwisy WWW | |
Nie dotyczy. | |
Pozostałe funkcje | |
ValidateAccountCreation() | Poświadcza ważność utworzenia rachunku |
ValidateAccountUpdate() | Poświadcza ważność uaktualnienia rachunku |
ValidateAccountClosure() | Poświadcza ważność zamknięcia rachunku |
ValidateVerifiedEmissionsUpdate() | Poświadcza ważność uaktualnienia zweryfikowanych emisji |
CreateAccount() | Tworzy rachunki |
UpdateAccount() | Uaktualnia rachunki |
CloseAccount() | Zamyka rachunki |
UpdateVerifiedEmissions() | Uaktualnia zweryfikowane emisje dla instalacji |
Role | |
Dziennik transakcji (wszystkie funkcje), rejestr (tylko dla informacji). |
Tabela VIII-11: Funkcja ManagementOfAccount.ValidateAccountCreation()
Zadanie | |
Funkcja ta służy do poświadczenia poprawności wniosku o utworzenie rachunku. | |
Jeśli próba poświadczenia poprawności (walidacji) zakończy się niepowodzeniem, to do listy kodów odpowiedzi zostaje dodany identyfikator rachunku i kod odpowiedzi. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
Account (*) | Obowiązkowy |
AccountType | Obowiązkowy |
AccountIdentifier | Obowiązkowy |
IdentifierInReg | Obowiązkowy |
CommitmentPeriod | Opcjonalny |
Installation | Opcjonalny |
InstallationIdentifier | Obowiązkowy |
PermitIdentifier | Obowiązkowy |
Name | Obowiązkowy |
MainActivityType | Obowiązkowy |
Country | Obowiązkowy |
PostalCode | Obowiązkowy |
City | Obowiązkowy |
Address1 | Obowiązkowy |
Address2 | Opcjonalny |
ParentCompany | Opcjonalny |
SubsidiaryCompany | Opcjonalny |
EPERIdentification | Opcjonalny |
Latitude | Opcjonalny |
Longitude | Opcjonalny |
ContactPeople (see People) | Obowiązkowy |
People (*) | Obowiązkowy |
RelationshipCode | Obowiązkowy |
PersonIdentifier | Obowiązkowy |
FirstName | Opcjonalny |
LastName | Obowiązkowy |
Country | Obowiązkowy |
PostalCode | Obowiązkowy |
City | Obowiązkowy |
Address1 | Obowiązkowy |
Address2 | Opcjonalny |
PhoneNumber1 | Obowiązkowy |
PhoneNumber2 | Opcjonalny |
FaxNumber | Opcjonalny |
Opcjonalny | |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Response List | Opcjonalny |
Komunikaty | |
Zakres od 7101 do 7110; zakres od 7122 do 7160; 7162. |
Tabela VIII-12: Funkcja ManagementOfAccount.CreateAccount()
Zadanie | |
Funkcja ta służy do tworzenia rachunków. | |
Dla każdego rachunku: | |
Utworzenie rachunku wraz z jego danymi | |
Utworzenie wszystkich osób (People) i ich danych, jeśli osoby takie jeszcze nie istniały i powiązanie ich z rachunkiem. | |
Uaktualnienie wszystkich informacji powiązanych z osobami (People), które już istnieją i które są powiązane z rachunkiem. | |
Utworzenie instalacji i danych dotyczących instalacji, jeżeli z rachunkiem jest powiązana jakaś instalacja. | |
Utworzenie wszystkich osób (People) powiązanych z instalacją (osoba kontaktowa), jeżeli osoby takie jeszcze nie istniały. | |
Uaktualnienie wszystkich informacji powiązanych z osobami (People), które już istnieją i które są powiązane z instalacją. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
Account (*) | Obowiązkowy |
AccountType | Obowiązkowy |
AccountIdentifier | Obowiązkowy |
IdentifierInReg | Obowiązkowy |
CommitmentPeriod | Opcjonalny |
Installation | Opcjonalny |
InstallationIdentifier | Obowiązkowy |
PermitIdentifier | Obowiązkowy |
PermitDate | Obowiązkowy |
Name | Obowiązkowy |
MainActivityType | Obowiązkowy |
Country | Obowiązkowy |
PostalCode | Obowiązkowy |
City | Obowiązkowy |
Address1 | Obowiązkowy |
Address2 | Opcjonalny |
ParentCompany | Opcjonalny |
SubsidiaryCompany | Opcjonalny |
EPERIdentification | Opcjonalny |
Latitude | Opcjonalny |
Longitude | Opcjonalny |
ContactPeople (patrz: People) | Obowiązkowy |
People (*) | Obowiązkowy |
RelationshipCode | Obowiązkowy |
PersonIdentifier | Obowiązkowy |
FirstName | Opcjonalny |
LastName | Obowiązkowy |
Country | Obowiązkowy |
PostalCode | Obowiązkowy |
City | Obowiązkowy |
Address1 | Obowiązkowy |
Address2 | Opcjonalny |
PhoneNumber1 | Obowiązkowy |
PhoneNumber2 | Opcjonalny |
FaxNumber | Opcjonalny |
Opcjonalny | |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Użycia | |
Nie dotyczy. | |
Użył | |
Nie dotyczy (wywoływane jako serwis WWW). |
Tabela VIII-13: Funkcja AccountManagement.ValidateAccountUpdate()
Zadanie | |
Funkcja ta służy do poświadczania poprawności wniosku o uaktualnienie rachunku. | |
Jeżeli próba poświadczenia poprawności (walidacji) zakończy się niepowodzeniem, to do listy kodów odpowiedzi zostaje dodany identyfikator rachunku i kod odpowiedzi. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
Account (*) | Obowiązkowy |
AccountIdentifier | Obowiązkowy |
IdentifierInReg | Opcjonalny |
Installation | Opcjonalny |
PermitIdentifier | Opcjonalny |
PermitDate | Opcjonalny |
Name | Opcjonalny |
MainActivityType | Opcjonalny |
Country | Opcjonalny |
PostalCode | Opcjonalny |
City | Opcjonalny |
Address1 | Opcjonalny |
Address2 | Opcjonalny |
ParentCompany | Opcjonalny |
SubsidiaryCompany | Opcjonalny |
EPERIdentification | Opcjonalny |
Latitude | Opcjonalny |
Longitude | Opcjonalny |
ContactPeople (see People) | Opcjonalny |
People (*) | Opcjonalny |
Action | Obowiązkowy |
RelationshipCode | Obowiązkowy |
PersonIdentifier | Obowiązkowy |
FirstName | Opcjonalny |
LastName | Opcjonalny |
Country | Opcjonalny |
PostalCode | Opcjonalny |
City | Opcjonalny |
Address1 | Opcjonalny |
Address2 | Opcjonalny |
PhoneNumber1 | Opcjonalny |
PhoneNumber2 | Opcjonalny |
FaxNumber | Opcjonalny |
Opcjonalny | |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Response List | Opcjonalny |
Komunikaty | |
Zakres od 7102 do 7107; zakres od 7111 do 7113; 7120; 7122; 7124; zakres od 7126 do 7158. |
Tabela VIII-14: Funkcja ManagementOfAccount.UpdateAccount()
Zadanie | |
Funkcja ta służy do uaktualnienia danych dotyczących rachunku. | |
Jeżeli działanie = "Add" ("dodanie") | |
Dla każdego dodawanego powiązania: | |
Jeśli istniały osoby (People), to następuje uaktualnienie jego danych, jeśli jest to wymagane. | |
Jeśli nie istniały osoby (People), to następuje utworzenie osób (People) i powiązanie ich z rachunkiem. | |
Jeżeli działanie = "Update" ("uaktualnienie") | |
Dla wszystkich osób (People), które są objęte uaktualnieniem i które są powiązane z rachunkiem, następuje uaktualnienie danych tych osób. | |
Jeżeli działanie = "Delete" ("usunięcie") | |
Usunięcie powiązania pomiędzy osobami (People) i rachunkiem (na przykład usuwany jest dodatkowy upoważniony przedstawiciel). | |
Jeżeli z rachunkiem jest powiązana instalacja, to następuje uaktualnienie danych instalacji, jeśli jest to wymagane. | |
Uaktualnienie danych dotyczących osób (People) powiązanych z instalacją, jeżeli zostały uprzednio podane dane (przy użyciu tych samych działań "Add", "Update" i "Delete"). | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
Account (*) | Obowiązkowy |
AccountType | Obowiązkowy |
AccountIdentifier | Obowiązkowy |
IdentifierInReg | Obowiązkowy |
Installation | Opcjonalny |
InstallationIdentifier | Obowiązkowy |
PermitIdentifier | Obowiązkowy |
PermitDate | Obowiązkowy |
Name | Obowiązkowy |
MainActivityType | Obowiązkowy |
Country | Obowiązkowy |
PostalCode | Obowiązkowy |
City | Obowiązkowy |
Address1 | Obowiązkowy |
Address2 | Opcjonalny |
ParentCompany | Opcjonalny |
SubsidiaryCompany | Opcjonalny |
EPERIdentification | Opcjonalny |
Latitude | Opcjonalny |
Longitude | Opcjonalny |
ContactPeople (patrz: People) | Obowiązkowy |
People (*) | Obowiązkowy |
RelationshipCode | Obowiązkowy |
PersonIdentifier | Obowiązkowy |
FirstName | Opcjonalny |
LastName | Obowiązkowy |
Country | Obowiązkowy |
PostalCode | Obowiązkowy |
City | Obowiązkowy |
Address1 | Obowiązkowy |
Address2 | Opcjonalny |
PhoneNumber1 | Opcjonalny |
PhoneNumber2 | Opcjonalny |
FaxNumber | Opcjonalny |
Opcjonalny | |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Użycia | |
Nie dotyczy. | |
Użył | |
Nie dotyczy (wywoływane jako serwis WWW). |
Tabela VIII-15: Funkcja ManagementOfAccount.ValidateAccountClosure()
Zadanie | |
Funkcja ta służy do poświadczenia ważności operacji zamknięcia rachunku. | |
Jeżeli próba poświadczenia ważności zakończy się wynikiem negatywnym, to do listy kodów odpowiedzi zostaje dodany identyfikator rachunku i kod odpowiedzi. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
Account (*) | Obowiązkowy |
Zadanie | |
AccountIdentifier | Obowiązkowy |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Response List | Opcjonalny |
Komunikaty | |
7111; zakres od 7114 do 7115; 7117; zakres od 7153 do 7156; 7158; 7161. |
Tabela VIII-16: Funkcja ManagementOfAccount.CloseAccount()
Zadanie | |
Funkcja ta służy do zamknięcia rachunku lub rachunków przez ustawienie daty końca ważności zamykanego rachunku (rachunków) na bieżącą datę. | |
Parametry wejścia | |
Registry | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
Account (*) | Obowiązkowy |
AccountIdentifier | Obowiązkowy |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Tabela VIII-17: Funkcja ManagementOfAccount.ValidateVerifiedEmissionsUpdate()
Zadanie | |
Funkcja ta służy do poświadczenia ważności uaktualnienia zweryfikowanych emisji. | |
Jeżeli próba poświadczenia ważności zakończy się wynikiem negatywnym, to do listy kodów odpowiedzi zostaje dodany identyfikator instalacji i kod odpowiedzi. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
VerifiedEmissions (*) | Obowiązkowy |
Year | Obowiązkowy |
Installations (*) | Obowiązkowy |
InstallationIdentifier | Obowiązkowy |
VerifiedEmission | Obowiązkowy |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Response List | Opcjonalny |
Komunikaty | |
Zakres od 7118 do 7119; zakres od 7152 do 7156; 7159; 7525. |
Tabela VIII-18: Funkcja ManagementOfAccount.UpdateVerifiedEmissions
Zadanie | |
Uaktualnianie zweryfikowanych emisji dla roku i określonej instalacji. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
VerifiedEmissions (*) | Obowiązkowy |
Year | Obowiązkowy |
Installations (*) | Obowiązkowy |
InstallationIdentifier | Obowiązkowy |
VerifiedEmission | Obowiązkowy |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Wstępne sprawdzenia dotyczące każdego procesu
5. Niezależny dziennik transakcji Wspólnoty sprawdza status rejestru dla każdego procesu dotyczącego rachunku lub zweryfikowanych emisji. Jeżeli łącze komunikacyjne pomiędzy rejestrem a niezależnym dziennikiem transakcji Wspólnoty nie zostało ustanowione lub zostało czasowo zawieszone stosownie do art. 6 ust. 3 w stosunku do żądanego procesu dotyczącego rachunku lub zweryfikowanych emisji, to proces ten zostaje odrzucony i odesłany zostaje kod odpowiedzi 7005.
6. Niezależny dziennik transakcji Wspólnoty prowadzi kontrolę wersji rejestru, kontrolę uwierzytelnienia rejestru oraz kontrolę wykonalności komunikatu w każdym procesie dotyczącym rachunku lub zweryfikowanych emisji i odsyła odpowiednie kody odpowiedzi po wykryciu rozbieżności, zgodnie z wytycznymi w tabeli XII-1 w zakresie od 7900 do 7999. Wymienione wyżej kontrole są równorzędne kontrolom związanym z kodami odpowiedzi, które określono w specyfikacji funkcjonalnej i technicznej standardów wymiany danych systemów rejestracji w ramach protokołu z Kioto, opracowanej na podstawie decyzji 24/CP.8 Konferencji Stron UNFCCC i które zostały przedstawione w ostatniej kolumnie tabeli XII-1 wraz z równorzędnymi kodami odpowiedzi w zakresie od 7900 do 7999. Jeżeli dana kontrola w ramach wspomnianych standardów wymiany danych, która jest równorzędna kontrolom o kodach odpowiedzi podanych w tabeli XII-1 w zakresie od 7900 do 7999 bądź wykonanie przez niezależny dziennik transakcji UNFCCC takiej kontroli zostanie zmienione przez administratora ITL, centralny administrator dezaktywuje równorzędną kontrolę.
7. Niezależny dziennik transakcji Wspólnoty dokonuje sprawdzeń integralności na każdym procesie dotyczącym rachunku lub zweryfikowanych emisji i w razie wykrycia rozbieżności odsyła kody odpowiedzi w zakresie od 7122 do 7159.
Drugorzędne sprawdzenia dotyczące każdego procesu
8. Niezależny dziennik transakcji Wspólnoty przeprowadza drugorzędne sprawdzenia na każdym procesie dotyczącym rachunku lub zweryfikowanych emisji, który pozytywnie przeszedł wszystkie wstępne sprawdzenia. Drugorzędne sprawdzenia wraz z odpowiadającymi im kodami odpowiedzi, które są odsyłane w razie wykrycia rozbieżności, przedstawiono w tabeli VIII-19.
Tabela VIII-19: Drugorzędne sprawdzenia
Opis procesu | Kody odpowiedzi niezależnego dziennika transakcji Wspólnoty |
Tworzenie rachunku | Zakres od 7101 do 7110 7160 |
Uaktualnienie rachunku | Zakres od 7102 do 7105 |
Zakres od 7107 do 7108 | |
7111 | |
7113 | |
7120 | |
7160 | |
Zamknięcie rachunku | 7111 |
Zakres od 7114 do 7115 | |
7117 | |
Uaktualnienie zweryfikowanych emisji | Zakres od 7118 do 7119 |
ZAŁĄCZNIK IX
85 Procesy dotyczące transakcji wraz z kodami odpowiedzi
85 Procesy dotyczące transakcji wraz z kodami odpowiedzi
1. Każdemu procesowi dotyczącemu transakcji przypisywany jest typ procesu składający się z początkowego typu procesu oraz uzupełniającego typu procesu. Początkowy typ procesu opisuje jego kategorię określoną w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC. Uzupełniający typ procesu opisuje jego kategorię określoną w przepisach niniejszego rozporządzenia, opracowanych stosownie do dyrektywy 2003/87/ WE. Typy procesów są przedstawione w tabeli IX-1.
Wymagania dotyczące każdego procesu
2. Sekwencja komunikatów dla procesów dotyczących transakcji, statusu transakcji oraz statusu jednostek Kioto i przydziałów użytych w transakcji podczas sekwencji komunikatów, a także składniki i funkcje wykorzystywane podczas sekwencji komunikatów są przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
Wstępne sprawdzenia dotyczące każdego procesu
3. Niezależny dziennik transakcji Wspólnoty sprawdza status rejestru dla każdego procesu dotyczącego transakcji. Jeżeli łącze komunikacyjne pomiędzy rejestrem i niezależnym dziennikiem transakcji Wspólnoty nie zostało ustanowione lub jest czasowo zawieszone stosownie do art. 6 ust. 3 w stosunku do żądanego procesu, to proces ten zostaje odrzucony i odesłane zostają kody odpowiedzi 7005 lub 7006.
4. Niezależny dziennik transakcji Wspólnoty prowadzi podane niżej kategorie kontroli wstępnej w odniesieniu do każdego procesu dotyczącego transakcji:
a) kontrola wersji rejestru i kontrola uwierzytelnienia rejestru;
b) kontrole wykonalności komunikatu;
c) kontrole integralności danych;
d) ogólne kontrole transakcji; oraz
e) kontrole sekwencji komunikatu.
Niezależny dziennik transakcji Wspólnoty odsyła odpowiednie kody odpowiedzi, jeżeli zostanie wykryta rozbieżność, zgodnie z wytycznymi podanymi w tabeli XII-1 w zakresie od 7900 do 7999. Wspomniane wyżej kontrole są równorzędne kontrolom związanym z kodami odpowiedzi, które podano w specyfikacji funkcjonalnej i technicznej standardów wymiany danych systemów rejestracji w ramach protokołu z Kioto, opracowanej na podstawie decyzji 24/CP.8 Konferencji Stron UNFCCC i zostały przedstawione w ostatniej kolumnie tabeli XII-1 wraz z równorzędnymi kodami odpowiedzi w zakresie od 7900 do 7999. Jeżeli dana kontrola w ramach wyżej wspomnianych standardów wymiany danych, która jest równorzędna kontrolom o kodach odpowiedzi podanych w tabeli XII-1 w zakresie od 7900 do 7999 oraz wykonanie przez niezależny dziennik transakcji UNFCCC takiej kontroli zostanie zmienione przez administratora ITL, centralny administrator dezaktywuje równorzędną kontrolę.
Drugorzędne i trzeciorzędne sprawdzenia dotyczące każdego procesu
5. Dla każdego procesu dotyczącego transakcji, który przeszedł wstępne sprawdzenia z wynikiem pozytywnym, niezależny dziennik transakcji Wspólnoty przeprowadza następujące drugorzędne sprawdzenia w celu ustalenia, czy:
a) jednostki Kioto lub przydziały są utrzymywane na rachunku przekazywania (w przypadku rozbieżności odsyłany jest kod odpowiedzi 7027);
b) w określonym rejestrze istnieje rachunek przekazywania (w przypadku rozbieżności odsyłany jest kod odpowiedzi 7021);
c) w określonym rejestrze istnieje rachunek nabywania (w przypadku rozbieżności odsyłany jest kod odpowiedzi 7020);
d) istnieją obydwa rachunki w tym samym rejestrze dla wewnętrznego przekazu (w przypadku rozbieżności odsyłany jest kod odpowiedzi 7022);
e) istnieją obydwa rachunki w różnych rejestrach dla zewnętrznego przekazu (w przypadku rozbieżności odsyłany jest kod odpowiedzi 7023);
f) rachunek przekazywania nie jest zablokowany stosownie do art. 27 (w przypadku rozbieżności odsyłany jest kod odpowiedzi 7025);
g) przydziały w przypadku siły wyższej nie są przekazywane (w przypadku rozbieżności odsyłany jest kod odpowiedzi 7024).
6. Niezależny dziennik transakcji Wspólnoty przeprowadza trzeciorzędne sprawdzenia na każdym procesie dotyczącym transakcji, która przeszła pozytywnie wszystkie wstępne sprawdzenia. Trzeciorzędne sprawdzenia wraz z odpowiadającymi im kodami odpowiedzi, które są odsyłane w razie stwierdzenia rozbieżności, przedstawiono w tabeli IX-1.
Tabela IX-1: Trzeciorzędne sprawdzenia
Opis procesu | Typ procesu | Kody odpowiedzi niezależnego dziennika transakcji Wspólnoty |
Wydanie jednostek AAU i RMU | 01-00 | [nie dotyczy] |
Konwersja jednostek AAU i RMU na jednostki ERU | 02-00 | 7218 |
Zewnętrzny przekaz (począwszy od 2008-2012) | 03-00 | Zakres od 7301 do 302 7304 Zakres od 7221 do 7222 |
Anulowanie (począwszy od 2008-2012) | 04-00 | [nie dotyczy] |
(skreślony) | ||
Anulowanie i wymiana jednostek tCER i lCER | 06-00 | [nie dotyczy] |
Przeniesienie jednostek Kioto i przydziałów wydanych na okres 2008-2012 i następne pięcioletnie okresy | 07-00 | [nie dotyczy] |
Zmiana daty ważności jednostek tCER i lCER | 08-00 | [nie dotyczy] |
Wewnętrzny przekaz | 10-00 | 7304 Zakres od 7406 do 7407 |
Wydanie przydziałów (2005-2007) | 01-51 | Zakres od 7201 do 7203 7219 |
Wydanie przydziałów (począwszy od 2008-2012) | 10-52 | Zakres od 7201 do 7203 7205 7219 |
Rozdzielenie przydziałów | 10-53 | 7202 7203 Zakres od 7206 do 7208 7214 7216 7304 7360 |
Wydanie przydziałów na okoliczność siły wyższej | 01-54 | 7202 Zakres od 7210 do 7211 7215 7217 7220 |
Korekta przydziałów | 10-55 | Zakres od 7212 do 7213 |
Zewnętrzny przekaz (2005-2007) | 03-21 | 7302 Zakres od 7304 do 7305 Zakres od 7406 do 7407 Zakres od 7221 do 7222 |
Anulowanie przydziałów (2005-2007) | 10-01 | 7212 7305 |
Odstąpienie przydziałów | 10-02 | 7202 7304 Zakres od 7353 do 7356 |
Wycofanie (2005-2007) | 04-03 | 7209 7305 7357 Zakres od 7360 do 7362 |
Anulowanie i wymiana | 10-41 | (od 2005 do 2007 r.) 7205 7212 7219 7360 7402 7404 Zakres od 7406 do 7407 (począwszy od 2008-2012) 7202 7205 7219 7360 Zakres od 7401 do 7402 Zakres od 7404 do 7407 (rejestry, o których mowa w art. 63a); 7219; Zakres od 7223 do 7224; 7360; 7402; 7404; 7406; Zakres od 7407 do 7408; 7202 |
Przekształcenie odstąpionych uprawnień na wycofanie (począwszy od 2008-2012) | 10-61 | 7358 |
Przekształcenie nierozdzielonych uprawnień na wycofanie (2008-2012 i później) | 10-62 | 7364, 7366 |
Wycofanie jednostek Kioto (2008-2012 i później) | 05-00 | 7360 7365 |
Wycofanie odstąpionych uprawnień (2008-2012 i później) | 05-01 | Zakres od 7359 do 7361 7365 |
Wycofanie nierozdzielonych uprawnień (2008-2012 i później) | 05-02 | 7360, 7361 Zakres od 7363 do 7365 |
Wydanie uprawnienia (rejestry, o których mowa w art. 63a) | 01-22 | Zakres od 7201 do 7203 7219 7224 |
Wycofanie (rejestry, o których mowa w art. 63a) | 05-22 | Zakres od 7227 do 7228 7357 Zakres od 7360 do 7362 |
Przeniesienie między dwoma rejestrami, o których mowa w art. 63a | 10-22 | 7302, 7304 Zakres od 7406 do 7407 7224 7228 |
7. (skreślony).
ZAŁĄCZNIK X
86 Proces uzgadniania wraz z kodami odpowiedzi
86 Proces uzgadniania wraz z kodami odpowiedzi
1. Jeżeli nie zostanie ustanowione łącze komunikacyjne między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC, każdy rejestr odpowiada na jakiekolwiek żądanie składane przez niezależny dziennik transakcji Wspólnoty i wymagające przedstawienia następujących informacji o określonej godzinie i dacie:
a) łączną ilość przydziałów utrzymywanych w każdym typie rachunku w danym rejestrze;
b) kody identyfikacji jednostek każdego przydziału utrzymywanego w każdym typie rachunku w tym rejestrze;
c) historię dziennika transakcji i dziennika rewizji każdego przydziału utrzymywanego w każdym typie rachunku w tym rejestrze;
d) łączną ilość przydziałów utrzymywanych w każdym rachunku w danym rejestrze;
e) kody identyfikacji jednostek każdego przydziału utrzymywanego w każdym rachunku w tym rejestrze; oraz
f) historię dziennika transakcji i dziennika rewizji każdego przydziału utrzymywanego w każdym rachunku w tym rejestrze.
2. Po ustanowieniu łącza komunikacyjnego między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC każdy rejestr będzie odpowiadał na każde żądanie składane przez niezależny dziennik transakcji UNFCCC i wymagające przedstawienia następujących informacji dla określonej godziny i daty:
a) łączną ilość przydziałów, jednostek AAU, RMU, ERU, CER (nie tCER lub lCER), lCER i tCER utrzymywanych w każdym typie rachunku w danym rejestrze;
b) kody identyfikacji jednostek każdego przydziału, jednostki AAU, RMU, ERU, CER (nie tCER ani lCER), lCER i tCER utrzymywanych w każdym typie rachunku tym rejestrze; oraz
c) historię dziennika transakcji i dziennika rewizji każdego przydziału, jednostki AAU, RMU, ERU, CER (nie tCER lub lCER), lCER i tCER utrzymywanych w każdym typie rachunku w tym rejestrze.
3. Po ustanowieniu łącza komunikacyjnego między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC każdy rejestr odpowiada na każde żądanie składane przez niezależny dziennik transakcji UNFCCC w imieniu niezależnego dziennika transakcji Wspólnoty lub przez niezależny dziennik transakcji Wspólnoty i wymagające przedstawienia następujących informacji dla określonej godziny i daty:
a) łączną ilość przydziałów, jednostek AAU, RMU, ERU, CER (nie tCER lub lCER), lCER i tCER utrzymywanych każdym rachunku w danym rejestrze;
b) kody identyfikacji jednostki każdego przydziału, jednostki AAU, RMU, ERU, CER (nie tCER lub lCER), lCER i tCER utrzymywanych w każdym rachunku tym rejestrze; oraz
c) historię dziennika transakcji i dziennika rewizji każdego przydziału, jednostki AAU, RMU, ERU, CER (nie tCER lub lCER), lCER i tCER utrzymywanych w każdym rachunku tym rejestrze.
4. Sekwencja komunikatów dla procesu uzgadniania, status procesu uzgadniania i status jednostek Kioto lub przydziałów występujących w procesie uzgadniania podczas sekwencji uzgadniania oraz składniki i funkcje wykorzystywane podczas sekwencji komunikatów są przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu Kioto, opracowanych stosownie do decyzji 24/ CP.8 Konferencji Stron UNFCCC.
Wstępne sprawdzenia dotyczące procesu
5. Niezależny dziennik transakcji Wspólnoty sprawdza status rejestru podczas procesu uzgadniania. Jeżeli łącze komunikacyjne pomiędzy rejestrem a niezależnym dziennikiem transakcji Wspólnoty nie zostało ustanowione lub jest czasowo zawieszone stosownie do art. 6 ust. 3 w stosunku do procesu uzgadniania, to proces zostaje odrzucony i odesłany zostaje kod odpowiedzi 7005.
6. Niezależny dziennik transakcji Wspólnoty prowadzi kontrolę wersji rejestru, kontrolę uwierzytelnienia rejestru, kontrolę wykonalności komunikatu oraz kontrolę integralności danych w procesie uzgadniania i odsyła odpowiednie kody odpowiedzi po wykryciu rozbieżności, zgodnie z wytycznymi podanymi w tabeli XII-1 w zakresie od 7900 do 7999. Wspomniane wyżej kontrole są równorzędne kontrolom związanym z kodami odpowiedzi, które opisano w specyfikacji funkcjonalnej i technicznej standardów wymiany danych systemów rejestracji w ramach protokołu z Kioto, opracowanej na podstawie decyzji 24/CP.8 Konferencji Stron UNFCCC, i są przedstawione w ostatniej kolumnie tabeli XII-1 wraz z równorzędnymi kodami odpowiedzi w zakresie od 7900 do 7999. Jeżeli dana kontrola w ramach wyżej wspomnianych standardów wymiany danych, równorzędna kontrolom, których kody odpowiedzi podano w ramach tabeli XII-1 w zakresie od 7900 do 7999 bądź wykonanie przez niezależny dziennik transakcji UNFCCC takiej kontroli zostanie zmienione przez administratora ITL, centralny administrator dezaktywuje równorzędną kontrolę.
Drugorzędne sprawdzenia dotyczące procesu
7. Po pomyślnym przejściu wstępnych sprawdzeń niezależny dziennik transakcji Wspólnoty przeprowadza drugorzędne sprawdzenia podczas procesu uzgadniania. Drugorzędne sprawdzenia wraz z odpowiadającymi im kodami odpowiedzi odsyłanymi w razie wykrycia niezgodności są przedstawione w tabeli X-1.
Tabela X-1: Drugorzędne sprawdzenia
Opis procesu | Kody odpowiedzi niezależnego dziennika transakcji Wspólnoty |
Uzgadnianie | Zakres: od 7501 do 7524 |
Interwencja ręczna
8. Jeżeli informacje przechowywane w rejestrze zostały zmienione w odpowiedzi na proces zainicjowany, lecz nie sfinalizowany stosownie do art. 34, 35 lub 36, to Centralny Administrator poleca administratorowi tegoż rejestru cofnięcie tego procesu przez przywrócenie informacji przechowywanych w tym rejestrze do pierwotnego stanu.
Jeżeli informacje przechowywane w rejestrze nie zostały zmienione w odpowiedzi na proces zainicjowany i sfinalizowany stosownie do art. 34, 35 lub 36, to Centralny Administrator poleca administratorowi tegoż rejestru sfinalizowanie tego procesu przed dokonanie odpowiednich zmian przechowywanych informacji.
9. Gdy w procesie uzgadniania zidentyfikowana została niezgodność, to Centralny Administrator dokonuje z zainteresowanym administratorem rejestru lub administratorami rejestrów uzgodnień mających na celu określenie pochodzenia tej niezgodności. Następnie, jeśli zachodzi taka potrzeba, Centralny Administrator zmienia informacje przechowywane w niezależnym dzienniku transakcji Wspólnoty lub żąda od zainteresowanego administratora rejestru lub administratorów rejestrów dokonania określonych ręcznych modyfikacji informacji przechowywanych w tymże rejestrze.
ZAŁĄCZNIK XI
87 Procesy administracyjne wraz z kodami odpowiedzi
87 Procesy administracyjne wraz z kodami odpowiedzi
1. Niezależny dziennik transakcji Wspólnoty udostępnia następujące procesy:
a) Wyczyszczenie transakcji: wszystkie procesy według załącznika IX, które zostały zainicjowane, lecz nie ukończone albo anulowane w ciągu 24 godzin zostają anulowane.
b) Zaległe jednostki: zidentyfikowane zostają wszystkie jednostki, które nie zostały anulowane stosownie do art. 60 lub 61 w dniu lub po 1 maja 2008 r. albo w dniu lub po 1 maja w pierwszym roku każdego kolejnego pięcioletniego okresu.
c) Status procesu: administrator rejestru może zapytać o status procesu według załącznika IX, który został zainicjowany przez tegoż administratora rejestru.
d) Synchronizacja czasu: na żądanie każdy administrator rejestru podaje systemowy czas swojego rejestru po to, aby można było sprawdzić i zsynchronizować zgodność pomiędzy systemowym czasem rejestru a systemowym czasem niezależnego dziennika transakcji Wspólnoty. Na żądanie administrator rejestru zmienia systemowy czas swojego rejestru w celu zapewnienia synchronizacji czasu.
2. Po ustanowieniu łącza komunikacyjnego między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC i jeżeli wszystkie procesy dotyczące uprawnień, zweryfikowanych emisji, rachunków, automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji oraz jednostek Kioto są wykonywane poprzez wymianę danych za pośrednictwem niezależnego dziennika transakcji UNFCCC i dalej do niezależnego dziennika transakcji Wspólnoty, niezależny dziennik transakcji Wspólnoty zapewnia tylko nadal proces administracyjny przewidziany w pkt 1 lit. b).
3. Każdy rejestr winien być zdolny do prawidłowego wykonywania dodatkowych procesów administracyjnych dostarczonych przez niezależny dziennik transakcji UNFCCC, a określonych w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
Wymagania dotyczące każdego procesu
4. Sekwencja komunikatów dla procesów administracyjnych oraz składniki i funkcje wykorzystywane podczas sekwencji komunikatów są przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
Sprawdzenia dotyczące każdego procesu
5. Jeżeli w czasie okresu wymienionego w ust. 2 niezależny dziennik transakcji Wspólnoty wykryje rozbieżność według ust. 1 lit. a), to odsyła odpowiednie kody odpowiedzi przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
6. Jeżeli niezależny dziennik transakcji Wspólnoty wykryje rozbieżność według ust. 1 lit. b), to odsyła kod odpowiedzi 7601.
7. Jeżeli w czasie okresu wymienionego w ust. 2 zostanie otrzymany od rejestru komunikat według ust. 1 lit. c) dla procesu wymienionego w załączniku IX, to niezależny dziennik Wspólnoty przeprowadza następujące sprawdzenia:
a) Statusu rejestru: jeżeli łącze komunikacyjne pomiędzy rejestrem a niezależnym dziennikiem transakcji Wspólnoty nie zostało ustanowione lub jest czasowo zawieszone stosownie do art. 6 ust. 3 w stosunku do żądanego procesu, to komunikat zostaje odrzucony i odesłany zostaje kod odpowiedzi 7005.
b) Wersji rejestru i uwierzytelnienia rejestru, wykonalności procesu oraz integralności danych: jeżeli niezależny dziennik transakcji Wspólnoty wykryje rozbieżność, to komunikat zostaje odrzucony i odesłane zostają odpowiednie kody odpowiedzi przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
8. Jeżeli w czasie okresu wymienionego w ust. 2 zostanie otrzymany od rejestru komunikat według ust. 1 lit. d), niezależny dziennik transakcji Wspólnoty przeprowadza następujące sprawdzenia:
a) Statusu rejestru: jeżeli łącze komunikacyjne pomiędzy rejestrem a niezależnym dziennikiem transakcji Wspólnoty nie zostało ustanowione lub jest czasowo zawieszone stosownie do art. 6 ust. 3 w stosunku do żądanego procesu, to komunikat zostaje odrzucony i odesłany zostaje kod odpowiedzi 7005.
b) Wersji rejestru i uwierzytelnienia rejestru, wykonalności procesu, integralności danych oraz synchronizacji czasu: jeżeli niezależny dziennik transakcji Wspólnoty wykryje rozbieżność, to komunikat zostaje odrzucony i odesłane zostają odpowiednie kody odpowiedzi przedstawione w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
ZAŁĄCZNIK XIA
88 Procesy dotyczące automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji
88 Procesy dotyczące automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji
Wymagania dotyczące każdego procesu:
2. Obowiązuje następująca sekwencja komunikatu w procesach dotyczących automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji:
a) administrator rejestru inicjuje proces automatycznej zmiany tabeli krajowego planu rozdziału uprawnień do emisji, nadając wnioskowi jednoznaczny kod identyfikacji korelacji składający się z elementów opisanych w załączniku VI;
b) administrator rejestru wywołuje odpowiednią operację z internetowego serwisu automatycznej zmiany tabeli krajowego planu rozdziału uprawnień do emisji w niezależnym dzienniku transakcji Wspólnoty;
c) niezależny dziennik transakcji Wspólnoty dokonuje sprawdzenia poprawności wniosku, wywołując odpowiednią funkcję z niezależnego dziennika transakcji Wspólnoty;
d) jeżeli poprawność wniosku zostanie potwierdzona i przez to wniosek został zaakceptowany, niezależny dziennik transakcji Wspólnoty zmienia przechowywane informacje zgodnie z tym wnioskiem;
e) niezależny dziennik transakcji Wspólnoty wywołuje operację "receiveNapManagementOutcome" w serwisie internetowym automatycznej zmiany tabeli krajowego planu rozdziału uprawnień do emisji rejestru, który wysłał wniosek, powiadamiając rejestr o tym, czy poprawność wniosku została potwierdzona i przez to wniosek został zaakceptowany lub czy we wniosku wykryto rozbieżność i wskutek tego został odrzucony;
f) jeżeli potwierdzono poprawność wniosku i przez to wniosek został zaakceptowany, administrator rejestru, który wysłał żądanie, zmienia informacje przechowywane w rejestrze zgodnie z żądaniem, którego poprawność potwierdzono; w przeciwnym przypadku, jeżeli we wniosku wykryto rozbieżność i wskutek tego został odrzucony, administrator rejestru, który wysłał wniosek, nie zmienia informacji przechowywanych w rejestrze zgodnie z takim odrzuconym wnioskiem.
3. Pod warunkiem, że procesy automatycznej zmiany tabeli krajowego planu rozdziału uprawnień do emisji są kierowane poprzez niezależny dziennik transakcji UNFCCC, administrator rejestru wysyłający żądanie powinien otrzymać potwierdzenie odbioru od niezależnego dziennika transakcji UNFCCC w ciągu 60 sekund oraz powinien otrzymać powiadomienie o potwierdzeniu poprawności wniosku od niezależnego dziennika transakcji Wspólnoty w ciągu 24 godzin. We wszystkich pozostałych przypadkach administrator rejestru wysyłający wniosek powinien otrzymać potwierdzenie odbioru od niezależnego dziennika transakcji Wspólnoty w ciągu 60 sekund oraz powinien otrzymać powiadomienie o potwierdzeniu poprawności wniosku od niezależnego dziennika transakcji Wspólnoty w ciągu 24 godzin;
4. Komponenty i funkcje wykorzystywane w sekwencji komunikatów przedstawiono w tabelach od XIa-1 do XIa-6. Dane wejściowe wszystkich funkcji zbudowano tak, by odpowiadały formatowi i wymogom informacyjnym opisanym z wykorzystaniem języka opisowego usług sieciowych określonego w specyfikacji funkcjonalnej i technicznej standardów wymiany danych systemów rejestracji w ramach protokołu z Kioto, opracowanej na podstawie decyzji 24/CP.8 Konferencji Stron UNFCCC. Gwiazdka "(*)" sygnalizuje fakt, że dany element może się pojawić wielokrotnie jako element danych wejściowych.
Tabela XIa-1: Komponenty i funkcje procesów dotyczących automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji
Komponent | Funkcja | Zakres |
NAPTableManagementWS | AddNEInstallationtoNAP() | Publiczny |
IncreaseNAPallocationtoNEInstallation() | Publiczny | |
RemoveNAPallocationofclosingInstallation() | Publiczny | |
IncreaseNAPallocationReserve | Publiczny | |
RemoveNAPallocationReserve | Publiczny |
Tabela XIa-2: Komponent NAPTableManagementWS
Zadanie | |
Zadaniem tego komponentu jest obsługa żądań internetowego serwisu w zakresie zarządzania automatycznymi zmianami tabeli krajowego planu rozdziału uprawnień do emisji | |
Funkcje udostępnione poprzez serwisy www | |
IncreaseNAPallocationReserve() | Obsługuje wnioski o zwiększenie rezerwy w tabeli krajowego planu rozdziału uprawnień o ilość uprawnień nabytą przez rejestr w drodze "uzupełnienia". |
RemoveNAPallocationReserve() | Obsługuje wnioski o usunięcie z rezerwy w tabeli krajowego planu rozdziału uprawnień ilości uprawnień nabytej przez rejestr w drodze "uzupełnienia"." |
AddNEInstallationtoNAP() | Obsługa wniosków dodania nowych instalacji nowych uczestników do tabeli krajowego planu rozdziału uprawnień do emisji |
IncreaseAllocationtoNEInstallationinNAP() | Obsługa wniosków zwiększenia przydziałów w tabeli krajowego planu rozdziału uprawnień do emisji dla istniejących instalacji, które są nowymi uczestnikami |
RemoveNAPallocationofclosingInstallation() | Obsługa wniosków usunięcia przydziałów z tabeli krajowego planu rozdziału uprawnień do emisji dla instalacji, które są zamykane |
Pozostałe funkcje | |
Nie dotyczy | |
Role | |
Niezależny dziennik transakcji Wspólnoty (dla wszystkich funkcji) i rejestr (tylko dla funkcji receiveNapManagementOutcome) |
Tabela XIa-3: Funkcja NAPTableManagementWS.AddNEInstallationtoNAP()
Zadanie | |
Ta funkcja odbiera wniosek dodania nowej instalacji nowego uczestnika do tabeli krajowego planu rozdziału uprawnień do emisji. Jeżeli nowa instalacja nowego uczestnika nie zostanie objęta rozdzielaniem, ilość uprawnień będzie miała wartość zero. Jeżeli nowa instalacja nowego uczestnika zostanie objęta rozdzielaniem, rezerwa zostanie zredukowana o równorzędną ilość. | |
Niezależny dziennik transakcji Wspólnoty uwierzytelnia rejestr inicjujący (rejestr tworzący), wywołując funkcję AuthenticateMessage() i sprawdza wersję rejestru inicjującego wywołując funkcję CheckVersion(). | |
Jeżeli kontrola uwierzytelnienia i wersji jest pozytywna, system odsyła identyfikator wyniku "1" bez kodu odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. | |
Jeżeli kontrola uwierzytelnienia i wersji jest negatywna, system odsyła identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | |
"PermitIdentifier" oznacza kod identyfikacji pozwolenia składający się z elementów opisanych w załączniku VI. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
InitiatingRegistry | Obowiązkowy |
CommitmentPeriod | Obowiązkowy |
NewValueofReserve | Obowiązkowy |
Installation(*) | Obowiązkowy |
PermitIdentifier | Obowiązkowy |
InstallationIdentifier | Obowiązkowy |
Allocation(*) | Obowiązkowy |
YearinCommitmentPeriod | Obowiązkowy |
AmountofAllowances | Obowiązkowy |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Response Code | Opcjonalny |
Użycia | |
- AuthenticateMessage - WriteToFile - CheckVersion Użył | |
Nie dotyczy (wywoływane jako serwis www) |
Tabela XIa-4: Funkcja
NAPTableManagementWS.IncreaseAllocationtoNEInstallationinNAPIncreaseallocationtoNEInstallationinNAP()
Zadanie | |
Ta funkcja odbiera wniosek zwiększenia rozdzielania dla instalacji już istniejących w tabeli krajowego planu rozdziału uprawnień do emisji, które to instalacje są uważane za nowych uczestników. Rezerwa zostanie zmniejszona o ilość równorzędną ilości rozdzielonej w tym procesie. | |
Niezależny dziennik transakcji Wspólnoty uwierzytelnia rejestr inicjujący (rejestr tworzący), wywołując funkcję AuthenticateMessage() i sprawdza wersję rejestru inicjującego wywołując funkcję CheckVersion(). | |
Jeżeli kontrola uwierzytelnienia i wersji jest pozytywna, system odsyła identyfikator wyniku "1" bez kodu odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. | |
Jeżeli kontrola uwierzytelnienia i wersji jest negatywna, system odsyła identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
InitiatingRegistry | Obowiązkowy |
CommitmentPeriod | Obowiązkowy |
NewValueofReserve | Obowiązkowy |
Installation(*) | Obowiązkowy |
InstallationIdentifier | Obowiązkowy |
Allocation(*) | Obowiązkowy |
YearinCommitmentPeriod | Obowiązkowy |
AmountofAllowances | Obowiązkowy |
Parametry wyjścia | |
ResultIdentifier | Obowiązkowy |
ResponseCode | Opcjonalny |
Użycia | |
- AuthenticateMessage - WriteToFile - CheckVersion | |
Użył | |
Nie dotyczy (wywoływane jako serwis www) |
Tabela XIa-5: Funkcja NAPTableManagementWS RemoveNAPallocationofclosingInstallation()
Zadanie | |
Ta funkcja odbiera wniosek usunięcia instalacji znajdujących się w tabeli krajowego planu rozdziału uprawnień do emisji. Uprawnienia dotąd nierozdzielone zostaną skreślone i równorzędna ilość uprawnień zostanie dodana do rezerwy. | |
Niezależny dziennik transakcji Wspólnoty uwierzytelnia rejestr inicjujący (rejestr tworzący), wywołując funkcję AuthenticateMessage() i sprawdza wersję rejestru inicjującego wywołując funkcję CheckVersion(). | |
Jeżeli kontrola uwierzytelnienia i wersji jest pozytywna, system odsyła identyfikator wyniku "1" bez kodu odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. | |
Jeżeli kontrola uwierzytelnienia i wersji jest negatywna, system odsyła identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
InitiatingRegistry | Obowiązkowy |
CommitmentPeriod | Obowiązkowy |
NewValueofReserve | Obowiązkowy |
Installation (*) | Obowiązkowy |
InstallationIdentifier | Obowiązkowy |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Response Code | Opcjonalny |
Użycie | |
- AuthenticateMessage | |
- WriteToFile | |
- CheckVersion | |
Użył | |
Nie dotyczy (wywoływane jako serwis www) |
Tabela XIa-6: Funkcja NAPTableManagementWS receiveNapManagementOutcome ()
Zadanie | |
Ta funkcja odbiera wynik operacji zarządzania NAP. | |
Rejestr inicjujący (rejestr tworzący) uwierzytelnia niezależny dziennik transakcji UNFCCC (lub niezależny dziennik transakcji Wspólnoty jeśli wszystkie procesy, o których mowa w załączniku VIII, są kierowane poprzez niezależny dziennik transakcji Wspólnoty do niezależnego dziennika transakcji UNFCCC), wywołując funkcję AuthenticateMessage() i sprawdza wersję dziennika transakcji wywołując funkcję CheckVersion(). | |
Jeżeli kontrola uwierzytelnienia i wersji jest pozytywna, system odsyła identyfikator wyniku "1" bez kodu odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. | |
Jeżeli kontrola uwierzytelnienia i wersji jest negatywna, system odsyła identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | |
Jeżeli wynik jest "0" z jakiejkolwiek innej przyczyny błędu, lista kodów odpowiedzi jest wypełniana parami (kod odpowiedzi i, o ile to możliwe, lista identyfikatorów instalacji). | |
Parametry wejścia | |
From | Obowiązkowy |
To | Obowiązkowy |
CorrelationId | Obowiązkowy |
MajorVersion | Obowiązkowy |
MinorVersion | Obowiązkowy |
Outcome | Obowiązkowy |
Response List | Opcjonalny |
Parametry wyjścia | |
Result Identifier | Obowiązkowy |
Response Code | Opcjonalny |
Użycie | |
- AuthenticateMessage | |
- WriteToFile | |
- CheckVersion | |
Użył | |
Nie dotyczy (wywoływane jako serwis www) |
Tabela XIa-6a: Funkcja NAPTableManagementWS IncreaseNAPallocationReserve ()
Zadanie | ||
Ta funkcja przyjmuje wniosek o zwiększenie rezerwy w tabeli krajowego planu rozdziału uprawnień. Rezerwa jest zwiększana o ilość, która jest równoważna ilości uprawnień nabytej przez rejestr w drodze "uzupełnienia". Niezależny dziennik transakcji Wspólnoty uwierzytelnia inicjujący rejestr (rejestr tworzący) przez wywołanie funkcji AuthenticateMessage() i kontroluje wersję inicjującego rejestru przez wywołanie funkcji CheckVersion(). Jeżeli kontrola uwierzytelnienia i wersji jest pozytywna, system odsyła identyfikator wyniku "1" bez kodu odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. Jeżeli kontrola uwierzytelnienia lub wersji jest negatywna, system odsyła identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | ||
Parametry wejścia | ||
From | Obowiązkowy | |
To | Obowiązkowy | |
CorrelationId | Obowiązkowy | |
MajorVersion | Obowiązkowy | |
MinorVersion | Obowiązkowy | |
InitiatingRegistry | Obowiązkowy | |
CommitmentPeriod | Obowiązkowy | |
NewValueofReserve | Obowiązkowy | |
Parametry wyjścia | ||
Result Identifier | Obowiązkowy | |
Response Code | Opcjonalny | |
Użycia | ||
- AuthenticateMessage - WriteToFile - CheckVersion | ||
Użył | ||
Nie dotyczy (wywoływane jako serwis WWW). |
Tabela XIa-6b: Funkcja NAPTableManagementWS RemoveNAPallocationReserve ()
Zadanie | |||
Ta funkcja służy do przyjmowania wniosku o usunięcie z rezerwy w tabeli krajowego planu rozdziału uprawnień ilości uprawnień nabytej przez rejestr w drodze "uzupełnienia". Niezależny dziennik transakcji Wspólnoty uwierzytelnia inicjujący rejestr (rejestr tworzący) przez wywołanie funkcji AuthenticateMessage() i kontroluje wersję inicjującego rejestru przez wywołanie funkcji CheckVersion(). Jeżeli kontrola uwierzytelnienia i wersji jest pozytywna, system odsyła identyfikator wyniku "1" bez kodu odpowiedzi, treść wniosku zostaje wpisana do pliku przez wywołanie funkcji WriteToFile() i wniosek zostaje umieszczony w kolejce. Jeżeli kontrola uwierzytelnienia lub wersji jest negatywna, system odsyła identyfikator wyniku "0" wraz z pojedynczym kodem odpowiedzi wskazującym przyczynę błędu. | |||
Parametry wejścia | |||
From | Obowiązkowy | ||
To | Obowiązkowy | ||
CorrelationId | Obowiązkowy | ||
MajorVersion | Obowiązkowy | ||
MinorVersion | Obowiązkowy | ||
InitiatingRegistry | Obowiązkowy | ||
CommitmentPeriod | Obowiązkowy | ||
NewValueofReserve | Obowiązkowy | ||
Parametry wyjścia | |||
Result Identifier | Obowiązkowy | ||
Response Code | Opcjonalny | ||
Użycia | |||
- AuthenticateMessage - WriteToFile - CheckVersion | |||
Użył | |||
Nie dotyczy (wywoływane jako serwis WWW). |
Tabela XIa-7: Procesy dotyczące zmian tabeli NAP
Opis procesu | Kody odpowiedzi niezależnego dziennika transakcji Wspólnoty |
NAPTableManagementWS.AddNEInstallationtoNAP | 7005, 7122, 7125, 7153, 7154, 7155, 7156, 7159, 7451, 7452, 7700, 7701, 7702, 7703, 7704 |
NAPTableManagementWS.IncreaseallocationtoNEInstallationinNAP | 7005, 7153, 7154, 7155, 7156, 7159, 7207, 7451, 7452, 7700, 7701, 7702, 7703, 7705 |
NAPTableManagementWS RemoveNAPallocationofclosingInstallation | 7005, 7153, 7154, 7155, 7156, 7159, 7207, 7451, 7700, 7706 |
IncreaseNAPallocationReserve | 7005, 7122, 7153, 7154, 7155, 7156, 7700, 7702 7453 |
RemoveNAPallocationReserve | 7005, 7122, 7153, 7154, 7155, 7156, 7700, 7702 7454 |
5. Jeżeli wszystkie kontrole zostaną przeprowadzone z pozytywnym wynikiem, niezależny dziennik transakcji Wspólnoty automatycznie dokonuje zmiany krajowego planu rozdziału uprawnień do emisji w swojej bazie danych i powiadamia o tym administratora rejestru oraz centralnego administratora.
ZAŁĄCZNIK XII
89 Lista kodów odpowiedzi dla wszystkich procesów
89 Lista kodów odpowiedzi dla wszystkich procesów
2. Każdy administrator rejestru zapewni, aby znaczenie każdego kodu odpowiedzi było zachowane podczas przedstawiania informacji dotyczących procesu według załącznika XVI upoważnionemu przedstawicielowi, który zainicjował ten proces.
Tabela XII-1: Kody odpowiedzi niezależnego dziennika transakcji Wspólnoty
Kod odpowiedzi | Opis | Równorzędny kod odpowiedzi w ramach standardów wymiany danych |
7005 | Aktualny status rejestru inicjującego (lub przekazującego) nie pozwala na zajście tego procesu. | |
7006 | Aktualny status rejestru nabywającego nie pozwala na zajście tego procesu. | |
7020 | Wyszczególniony kod identyfikacji rachunku nie istnieje w rejestrze nabywającym. | |
7021 | Wyszczególniony kod identyfikacji rachunku nie istnieje w rejestrze przekazującym. | |
7022 | Rachunek przekazujący i rachunek nabywający muszą znajdować się w tym samym rejestrze dla wszystkich transakcji, z wyjątkiem przekazów zewnętrznych. | |
7023 | Rachunek przekazujący i rachunek nabywający dla przekazów zewnętrznych muszą znajdować się w różnych rejestrach. | |
7024 | Przydziały w przypadku siły wyższej nie mogą być przekazane z rachunku posiadania Strony, o ile nie zostaną anulowane i wycofane zgodnie z art. 58. | |
7025 | Rachunek przekazujący jest zablokowany dla wszystkich przekazów przydziałów z rachunku, z wyjątkiem procesów odstąpienia i anulowania oraz wymiany stosownie do art. 52, 53, 60 i 61. | |
7027 | Jedna lub więcej jednostek w bloku seryjnym nie jest rozpoznawanych jako utrzymywane przez rachunek przekazujący. | |
7101 | Rachunek został już utworzony. | |
7102 | Rachunek musi mieć jednego i tylko jednego posiadacza rachunku. | |
7103 | Rachunek musi mieć jednego i tylko jednego głównego upoważnionego przedstawiciela. | |
7104 | Rachunek musi mieć jednego i tylko jednego drugorzędnego upoważnionego przedstawiciela. | |
7105 | Instalacja musi mieć jedną i tylko jedną osobę kontaktową. | |
7106 | Instalacja związana z tym rachunkiem jest już związana z innym rachunkiem. | |
7107 | Wszyscy upoważnieni przedstawiciele rachunku muszą być różni. | |
7108 | Identyfikator alfanumeryczny wyznaczony dla rachunku został już wyznaczony dla innego rachunku. | |
7109 | Tworzonemu typowi rachunku nie nadano poprawnego okresu zobowiązania. | |
7110 | Rachunek posiadania operatora musi mieć jedną i tylko jedną instalację związaną z tym rachunkiem. | |
7111 | Wyszczególniony rachunek nie istnieje i dlatego nie jest możliwe uaktualnienie lub zamknięcie rachunku. | |
7113 | Nie jest możliwe dokonanie zmiany posiadacza rachunku osobistego rachunku posiadania. | |
7114 | Wyszczególniony rachunek został już zamknięty i dlatego nie jest możliwe zamknięcie rachunku. | |
7115 | Wyszczególniony rachunek nadal zawiera jednostki i dlatego nie jest możliwe zamknięcie rachunku. | |
7117 | Instalacja powiązana z wyszczególnionym rachunkiem nie jest zgodna i dlatego nie jest możliwe zamknięcie rachunku. | |
7118 | Wyszczególniona instalacja nie istnieje i dlatego nie jest możliwe uaktualnienie tabeli zweryfikowanych emisji dla tej instalacji. | |
7119 | Wyszczególniony rok jest rokiem przyszłym i dlatego nie jest możliwe uaktualnienie tabeli zweryfikowanych emisji za tenże rok. | |
7120 | Osoby i ich związek z rachunkiem nie istnieją i dlatego nie jest możliwe uaktualnienie tego związku. | |
7122 | Identyfikator korelacji nie jest w ważnym formacie lub jest poza zakresem. | |
7124 | Alfanumeryczny identyfikator rachunku nie jest w ważnym formacie lub jest poza zakresem. | |
7125 | Identyfikator pozwolenia nie jest w ważnym formacie lub jest poza zakresem. | |
7126 | Nazwa instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7127 | Główna czynność instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7128 | Kraj instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7129 | Kod pocztowy instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7130 | Miejscowość instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7131 | Adres1 instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7132 | Adres2 instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7133 | Rodzima firma instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7134 | Firma filialna instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7135 | Identyfikacja EPER firmy nie jest w ważnym formacie lub jest poza zakresem. | |
7136 | Szerokość geograficzna instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7137 | Długość geograficzna instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7138 | Kod związku osób nie jest w ważnym formacie lub jest poza zakresem. | |
7139 | Identyfikator osoby nie jest w ważnym formacie lub jest poza zakresem. | |
7140 | Imiona ludzi nie są w ważnym formacie lub są poza zakresem. | |
7141 | Nazwiska ludzi nie są w ważnym formacie lub są poza zakresem. | |
7142 | Kraj ludzi nie jest w ważnym formacie lub jest poza zakresem. | |
7143 | Kod pocztowy ludzi nie jest w ważnym formacie lub jest poza zakresem. | |
7144 | Miejscowość ludzi nie jest w ważnym formacie lub jest poza zakresem. | |
7145 | Adres1 ludzi nie jest w ważnym formacie lub jest poza zakresem. | |
7146 | Adres2 ludzi nie jest w ważnym formacie lub jest poza zakresem. | |
7147 | Numer telefonu1 ludzi nie jest w ważnym formacie lub jest poza zakresem. | |
7148 | Numer telefonu2 ludzi nie jest w ważnym formacie lub jest poza zakresem. | |
(skreślony) | (skreślony) | |
7150 | Adres poczty elektronicznej ludzi nie jest w ważnym formacie lub jest poza zakresem. | |
7151 | Czynność ludzi nie jest w ważnym formacie lub jest poza zakresem. | |
7152 | Zweryfikowane emisje instalacji nie są w ważnym formacie lub są poza zakresem. | |
7153 | Element "od" nie jest w ważnym formacie lub jest poza zakresem. | |
7154 | Element "do" nie jest w ważnym formacie lub jest poza zakresem. | |
7155 | Główna wersja nie jest w ważnym formacie lub jest poza zakresem. | |
7156 | Podrzędna wersja nie jest w ważnym formacie lub jest poza zakresem. | |
7157 | Typ rachunku nie jest w ważnym formacie lub jest poza zakresem. | |
7158 | Identyfikator rachunku nie jest w ważnym formacie lub jest poza zakresem. | |
7159 | Identyfikator instalacji nie jest w ważnym formacie lub jest poza zakresem. | |
7160 | Nie jest możliwe, aby osobisty rachunek posiadania miał osobę kontaktową lub jej dane, albo instalację lub jej dane (jak wymieniono w sekcji 11.1 załącznika I do decyzji Komisji 2004/156/WE), związane z tymże rachunkiem. | |
7161 | Instalacja związana z rachunkiem posiadania operatora niewskazana jako "zamknięta" w tabeli krajowego planu rozdziału uprawnień do emisji i nie można zamknąć rachunku | |
7162 | Instalacja związana z rachunkiem posiadania operatora nie posiada wpisu w tabeli krajowego planu rozdziału uprawnień do emisji i nie można otworzyć rachunku | |
7201 | Ilość przydziałów żądana do wydania na określony okres przekracza ilość zatwierdzoną przez Komisję w planie krajowych rozdzieleń. | |
7202 | Rachunek nabywający nie jest rachunkiem posiadania Strony. | |
7203 | Tabela planu krajowego rozdzielenia nie została przedłożona Komisji i dlatego nie jest możliwe, aby nastąpiło wydanie lub rozdzielenie przydziałów na wyszczególniony okres. | |
7205 | Jednostki żądane do konwersji na przydziały muszą być jednostkami AAU, które zostały wydane na okres zobowiązania odpowiadający okresowi zobowiązania, dla którego wydawane są przydziały. | |
7206 | Wyszczególniony rachunek nabywający nie jest rachunkiem posiadania operatora, który jest związany z wyszczególnioną instalacją. | |
7207 | Instalacja nie występuje w tabeli planu krajowego rozdzielenia. | |
7208 | Wyszczególniony rok nie występuje w tabeli planu krajowego rozdzielenia. | |
7209 | Rachunek nabywający nie jest rachunkiem odstąpienia na okres 2005-2007. | |
7210 | Przydziały na okoliczność siły wyższej mogą być wydane dopiero przed 30 czerwca 2008 r. | |
7211 | Żądana ilość wydania przydziałów na okoliczność siły wyższej przekracza ilość zatwierdzoną przez Komisję na okres zobowiązania. | |
7212 | Rachunek nabywający nie jest rachunkiem anulowania na okres 2005-2007. | |
7213 | Zmniejszenie ilości przydziałów przekracza korektę NAP (planu krajowego rozdziału) zatwierdzoną przez Komisję. | |
7214 | Ilość przekazywanych przydziałów nie jest ściśle równa ilości przewidzianej w NAP dla wyszczególnionej instalacji i wyszczególnionego roku. | |
7215 | Instalacja nie istnieje. | |
7216 | Ilość przekazywanych przydziałów dla wyszczególnionej instalacji i wyszczególnionego roku przewidziana w planie krajowego rozdzielenia została już przekazana. | |
7217 | Wyszczególniony rok nie zawiera się w okresie 2005-2007. | |
7218 | Wyszczególnione jednostki AAU są przydziałami i dlatego nie jest możliwa konwersja tych jednostek AAU na jednostki ERU. | |
7219 | Jednostki żądane do wydania nie mają poprawnego kodu identyfikacji przydziału i dlatego nie jest możliwe, aby nastąpiło wydanie. | |
7220 | Jednostki żądane do wydania nie mają poprawnego kodu identyfikacji przydziału na okoliczność siły wyższej i dlatego nie jest możliwe, aby nastąpiło wydanie. | |
7221 | Rachunek nabywania lub przeniesienia nie może istnieć w rejestrze, o którym mowa w art. 63a | |
7222 | Uprawnienia do przeniesienia nie mogą mieć uzupełniającego typu jednostki 4 | |
7223 | Rachunek nabywania musi być rachunkiem anulowania za odnośny okres | |
7224 | Uprawnienia do wydania muszą mieć uzupełniający typ jednostki 4 | |
7225 | Połączone stany posiadania po transakcji dwóch rachunków posiadania Strony uczestniczących w transakcji w rejestrze, o którym mowa w art. 63a, muszą być równe połączonym stanom posiadania przed transakcją | |
7226 | Bilans rachunku posiadania Strony, który może przechowywać uprawnienia o uzupełniającym typie jednostki 1, 2 lub 3, musi być większy lub równy ilości przenoszonej z rejestru, o którym mowa w art. 63a | |
7227 | Rachunek nabywania musi być rachunkiem wycofania za bieżący okres | |
7228 | Uprawnienia muszą być uprawnieniami wydanymi na bieżący okres | |
7301 | Uwaga: stany posiadania obliczone na podstawie decyzji 18/CP.7 Konferencji Stron UNFCCC są tylko o 1 % wyższe od rezerwy na okres zobowiązania. | |
7302 | Nie ma porozumienia w sprawie wzajemnego uznania pomiędzy rejestrem przekazującym a rejestrem nabywającym, które umożliwia przekazanie przydziałów. | |
7304 | Po 30 kwietnia pierwszego roku bieżącego okresu przydziały wydane na poprzedni okres mogą być przekazane na rachunek anulowania lub na rachunek wycofania za ten okres. | |
7305 | Przydziały nie są tymi, które zostały wydane na okres 2005-2007. | |
7353 | Nie jest możliwe odstąpienie na okres 2008-2012 i następne pięcioletnie okresy przydziałów wydanych na okres 2005-2007. | |
7354 | Rachunek przekazujący nie jest rachunkiem posiadania operatora. | |
7355 | Nie jest możliwe odstąpienie na poprzedni okres przydziałów wydanych na bieżący okres. | |
7356 | Jednostki nie kwalifikują się do odstąpienia stosownie do art. 53. | |
7357 | Ilość przydziałów oraz przydziałów na okoliczność siły wyższej żądanych do przekazania na rachunek wycofania nie jest równa ilości przydziałów odstąpionych stosownie do Artykułów 52 i 54. | |
7358 | Ilość jednostek AAU żądanych do konwersji z przydziałów nie jest równa ilości przydziałów odstąpionych stosownie do art. 52. | |
7359 | Ilość jednostek żądanych do przekazania z rachunku wycofania nie jest równa ilości przydziałów odstąpionych stosownie do art. 52 i 53. | |
7360 | Rachunek (rachunki) przekazujące nie jest/są rachunkiem (rachunkami) posiadania Strony. | |
7361 | Jednostki nie kwalifikują się do wycofania stosownie do art. 58 i 59. | |
7362 | Ilość jednostek CER żądanych do przekazania na rachunek anulowania nie jest równa ilości przydziałów odstąpionych stosownie do art. 53. | |
7363 | Ilość jednostek AAU do wycofania nie jest równa ilości uprawnień przekształcanych w procesie "przekształcenie nierozdzielonych uprawnień na wycofanie" | |
7364 | Transakcja nie jest inicjowana po dniu 30 czerwca roku następującego po ostatnim roku odnośnego okresu pięciu lat | |
7365 | Jednostki do wycofania są uprawnieniami i dlatego nie można ich wycofać | |
7366 | Ilość do przekształcenia nie może przekraczać liczby wydanych, lecz nierozdzielonych uprawnień | |
7401 | Ilość jednostek AAU żądanych do konwersji na przydziały nie jest równa ilości przydziałów anulowanych. | |
7402 | Wyszczególniony typ jednostki żądany do anulowania przed wymianą nie jest przydziałem wydanym na poprzedni okres. | |
7404 | Ilość przydziałów anulowanych nie jest równa ilości przydziałów przeznaczonych do anulowania stosownie do art. 60 lit. a) i art. 61 lit. b). | |
7405 | Ilość przydziałów anulowanych z rachunku przekazującego nie jest równa ilości przydziałów przekazanych z powrotem na ten rachunek. | |
7406 | Rachunek (rachunki) przekazujące muszą być rachunkami przywołanymi w art. 11 ust. 1 i 2. | |
7407 | Rachunek (rachunki) nabywające muszą być rachunkami przywołanymi w art. 11 ust. 1 i 2. | |
7408 | Liczba anulowanych uprawnień musi być równa liczbie uprawnień do anulowania na mocy art. 63o | |
7451 | Łączna ilość uprawnień w zaktualizowanym NAP i bieżącym NAP musi być identyczna | |
7452 | Ilość przydzielana nowym uczestnikom nie może przekraczać ilości, o jaką zmniejsza się rezerwa | |
7453 | Ilość uprawnień dodanych do rezerwy musi być dodatnia. | |
7454 | Ilość uprawnień usuniętych z rezerwy nie może przekroczyć całkowitej ilości uprawnień nabytych przez rejestr w drodze "uzupełnienia". | |
7501 | Istnieje niezgodność pomiędzy rejestrem i CITL w blokach jednostek rachunku posiadania operatora. | |
7502 | Istnieje niezgodność pomiędzy rejestrem i CITL w blokach jednostek rachunku posiadania osoby. | |
7503 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w blokach jednostek rachunku posiadania operatora. | |
7504 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w blokach jednostek rachunku posiadania osoby. | |
7505 | Istnieje niezgodność pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku posiadania operatora. | |
7506 | Istnieje niezgodność pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku posiadania osoby. | |
7507 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku posiadania operatora. | |
7508 | Informacja: nie ma niezgodności pomiędzy rejestrem a CITL w ogólnych liczbach bloków jednostek rachunku posiadania osoby. | |
7509 | Istnieje niezgodność pomiędzy rejestrem i CITL w blokach jednostek rachunku posiadania Strony. | |
7510 | Istnieje niezgodność pomiędzy rejestrem i CITL w blokach jednostek rachunku wycofania. | |
7511 | Istnieje niezgodność pomiędzy rejestrem i CITL w blokach jednostek rachunku anulowania. | |
7512 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w blokach jednostek rachunku posiadania Strony. | |
7513 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w blokach jednostek rachunku wycofania. | |
7514 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w blokach jednostek rachunku anulowania. | |
7515 | Istnieje niezgodność pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku posiadania Strony. | |
7516 | Istnieje niezgodność pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku wycofania. | |
7517 | Istnieje niezgodność pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku anulowania. | |
7518 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku posiadania Strony. | |
7519 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku wycofania. | |
7520 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku anulowania. | |
7521 | Istnieje niezgodność pomiędzy rejestrem i CITL w blokach jednostek rachunku wymiany. | |
7522 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w blokach jednostek rachunku wymiany. | |
7523 | Istnieje niezgodność pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku wymiany. | |
7524 | Informacja: nie ma niezgodności pomiędzy rejestrem i CITL w ogólnych liczbach bloków jednostek rachunku wymiany. | |
7525 | Nie można poddawać korekcie liczby zweryfikowanych emisji za rok X po 30 kwietnia roku X + 1, o ile właściwy organ nie powiadomi centralnego administratora o nowym statusie zgodności dla instalacji, w przypadku których dokonuje się korekty liczby zweryfikowanych emisji | |
7601 | Przypomnienie: wyszczególnione bloki jednostek przydziałów wydanych na poprzedni okres nie zostały jeszcze anulowane stosownie do art. 60 i 61. | |
7700 | Kod okresu zobowiązania poza zakresem | |
7701 | Należy podać przydział dla wszystkich lat. | |
7702 | Nowa rezerwa musi być dodatnia lub równa zeru | |
7703 | Ilość uprawnień przeznaczona dla instalacji i na rok musi być większa lub | |
równa 0 | ||
7704 | Identyfikator pozwolenia musi istnieć i łączyć się z identyfikatorem instalacji | |
7705 | Ilość uprawnień przeznaczona dla instalacji i na rok w zaktualizowanym NAP musi być większa lub równa tej ilości w bieżącym NAP | |
7706 | Ilość uprawnień wykreślona z tabeli NAP dla instalacji musi być równa ilości, o jaką zwiększa się rezerwę | |
7901 | Rejestr inicjujący musi istnieć w tabeli rejestrów | 1501 |
7902 | Status rejestru inicjującego musi umożliwiać proponowanie transakcji. (CITL utrzyma bieżący status każdego rejestru. W tym przypadku CITL musi rozpoznać, czy rejestr jest w pełni operacyjny) | 1503 |
7903 | Status rejestru nabywającego musi umożliwiać akceptowanie transakcji. (CITL utrzyma bieżący status każdego rejestru. W tym przypadku CITL musi rozpoznać, czy rejestr jest w pełni operacyjny) | 1504 |
7904 | Status rejestru musi umożliwiać prowadzenie operacji uzgadniania. (CITL utrzyma bieżący status każdego rejestru. W tym przypadku CITL musi rozpoznać dostępność rejestru do uzgadniania) | 1510 |
7905 | ID transakcji musi się składać z ważnego kodu rejestru, po którym następują wartości liczbowe | 2001 |
7906 | Kod typu transakcji musi być ważny | 2002 |
7907 | Kod uzupełniającego typu transakcji musi być ważny | 2003 |
7908 | Kod statusu transakcji musi być ważny | 2004 |
7909 | Kod typu rachunku musi być ważny | 2006 |
7910 | Identyfikator rachunku inicjującego musi być większy od zera | 2007 |
7911 | Identyfikator rachunku nabywającego musi być większy od zera | 2008 |
7912 | Rejestr tworzący wszystkich bloków jednostki musi być ważny | 2010 |
7913 | Kod typu jednostki musi być ważny | 2011 |
7914 | Kod uzupełniającego typu jednostki musi być ważny | 2012 |
7915 | Musi istnieć początek bloku szeregowego jednostek i koniec bloku szeregowego jednostek | 2013 |
7916 | Koniec bloku szeregowego jednostek musi być większy lub równy początkowi bloku szeregowego jednostek | 2014 |
7917 | Jednostki RMU i ERU przekształcane z jednostek RMU i tCER oraz lCER muszą mieć ważny kod aktywności LULUCF | 2015 |
7918 | Jednostki AAU i ERU przekształcane z jednostek AAU i CER nie muszą mieć ważnego kodu aktywności LULUCF | 2016 |
7919 | Jednostki ERU, CER, tCER i lCER muszą mieć ważny kod projektu | 2017 |
7920 | Jednostki AAU lub RMU nie muszą mieć ważnego kodu projektu | 2018 |
7921 | Jednostki ERU muszą mieć ważny "Track Code" | 2019 |
7922 | Jednostki AAU, RMU, CER, tCER i lCERs nie muszą mieć ważnego kodu śledzenia | 2020 |
7923 | Jednostki AAU, RMU, ERU i CER nie muszą mieć daty wygaśnięcia | 2022 |
7924 | Kod transakcji dla proponowanych transakcji nie może już istnieć w CITL | 3001 |
7925 | Kod transakcji dla transakcji w toku musi już istnieć w CITL | 3002 |
7926 | Nie można ponownie zakończyć uprzednio zakończonych transakcji | 3003 |
7927 | Nie można zakończyć uprzednio odrzuconych transakcji | 3004 |
7928 | Nie można zakończyć transakcji, w których uprzednio zidentyfikowano rozbieżność CITL | 3005 |
7930 | Nie można zakończyć uprzednio przerwanych transakcji | 3007 |
7931 | Nie można zakończyć uprzednio anulowanych transakcji | 3008 |
7932 | Nie można przerwać uprzednio zaakceptowanych transakcji zewnętrznych 3009 | |
7933 | Status transakcji Accepted (zaakceptowana) lub Rejected (odrzucona) jest nieważny dla transakcji innych niż zewnętrzne | 3010 |
7934 | Status transakcji z rejestru inicjującego musi wskazywać status Proposed (proponowana), Completed (zakończona) lub Terminated (przerwana) | 3011 |
7935 | Status transakcji z rejestru nabywającego dla przeniesienia zewnętrznego musi wskazywać status Rejected (odrzucona) lub Accepted (zaakceptowana) | 3012 |
7936 | Obowiązujący okres zobowiązań musi odpowiadać bieżącemu lub następnemu okresowi zobowiązania (wraz z odnośnymi okresami poprawek) | 4001 |
7937 | Jednostki zidentyfikowane w transakcji muszą już istnieć w CITL | 4002 |
7938 | Jednostki zidentyfikowane w transakcji muszą być przechowywane w rejestrze inicjującym | 4003 |
7939 | Wszystkie atrybuty wszystkich bloków jednostek muszą być zgodne z atrybutami bloku jednostki CITL z wyjątkiem przypadku, gdy bieżąca transakcja zmienia atrybuty | 4004 |
7940 | Wszystkie bloki jednostek w transakcji muszą być na jeden obowiązujący okres zobowiązania | 4005 |
7941 | Dla wszystkich transakcji z wyjątkiem przenoszenia zewnętrznego rejestr inicjujący i nabywający muszą być takie same | 4006 |
7942 | Dla przenoszenia zewnętrznego rejestr inicjujący i nabywający muszą być różne | 4007 |
7943 | Jednostki zidentyfikowane w transakcji nie mogą zawierać niespójności zidentyfikowanych w procesie uzgadniania z CITL | 4008 |
7945 | Jednostki zidentyfikowane w transakcji nie mogą być wykorzystywane w innej transakcji | 4010 |
7946 | Jednostki anulowane nie mogą być przedmiotem kolejnych transakcji | 4011 |
7947 | Propozycja transakcji musi zawierać przynajmniej jeden blok jednostki | 4012 |
7948 | Transakcja nie może wydawać więcej niż jeden typ jednostki | 5004 |
7949 | Początkowy okres zobowiązania musi być taki sam dla wszystkich jednostek wydanych w transakcji | 5005 |
7950 | Obowiązujący okres zobowiązania musi być taki sam, jak początkowy okres zobowiązania dla wszystkich jednostek wydanych w transakcji | 5006 |
7951 | Anulowanie na rachunek anulowania nadmiernego wydania nie może mieć miejsca w rejestrze krajowym | 5152 |
7952 | Rachunek nabywający w transakcji anulowania musi być rachunkiem anulowania | 5153 |
7953 | W transakcjach anulowania należy przewidzieć identyfikatory rachunku dla rachunków nabywających | 5154 |
7954 | Bloki jednostek przeznaczonych do anulowania muszą mieć ten sam obowiązujący okres zobowiązania, jak rachunek anulowania | 5155 |
7955 | Rejestr inicjujący wycofujący jednostki musi być rejestrem krajowym lub rejestrem Wspólnoty | 5251 |
7956 | Rachunek nabywający dla transakcji wycofania musi być rachunkiem wycofania | 5252 |
7957 | W transakcjach wycofania należy przewidzieć identyfikatory rachunku dla rachunków nabywających | 5253 |
7958 | Bloki jednostek przeznaczonych do wycofania muszą mieć ten sam obowiązujący okres zobowiązania, jak rachunek wycofania | 5254 |
7959 | Rejestr inicjujący przesuwający jednostki musi być rejestrem krajowym | 5301 |
7960 | Rachunek inicjujący w transakcji przesuwania musi być rachunkiem posiadania | 5302 |
7961 | Jednostki można przesuwać tylko na kolejny bezpośredni okres zobowiązania | 5303 |
7962 | Identyfikator uzgadniania musi być większy od zera | 6201 |
7963 | Kod identyfikacyjny uzgadniania musi się składać z ważnego kodu rejestru, po którym następują wartości liczbowe | 6202 |
7964 | Status uzgadniania musi być wartością między 1 a 11 | 6203 |
7965 | Migawka uzgadniania musi być datą między dniem 1 października 2004 r. a bieżącą datą plus 30 dni | 6204 |
7966 | Typ rachunku musi być ważny | 6205 |
7969 | Kod identyfikacyjny uzgadniania musi istnieć w tabeli Reconciliation Log | 6301 |
7970 | Status uzgadniania wysłany przez rejestr musi być ważny | 6302 |
7971 | Status przychodzącego uzgadniania musi być taki sam, jak status uzgadniania zarejestrowany przez CITL | 6303 |
7972 | Migawka DateTime uzgadniania rejestru musi być zgodna z migawką DateTime uzgadniania CITL | 6304 |
ZAŁĄCZNIK XIII
90 Procedury testowania
90 Procedury testowania
a) Testy jednostek: testowane są indywidualne składniki pod względem ich specyfikacji.
b) Testy integracji: testowane są grupy składników zawierające części kompletnego systemu pod względem ich specyfikacji.
c) Testy systemu: testowany jest system jako całość pod względem jego specyfikacji.
d) Testy obciążenia: system poddawany jest szczytowym obciążeniom czynnościowym odzwierciedlającym prawdopodobne zapotrzebowania, które będą zgłaszane systemowi przez jego użytkowników.
e) Testowanie zabezpieczenia: identyfikowane są wszelkie słabości zabezpieczenia systemu.
2. Indywidualne testy dla rejestru przeprowadzane w ramach etapów testowania przedstawionych w ust. 1 prowadzone są zgodnie z określonym z góry planem, a wyniki są dokumentowane. Dokumentacja ta jest na żądanie udostępniana Centralnemu Administratorowi. Wszelkie mankamenty wykryte w rejestrze podczas etapów testowania winny zostać usunięte, zanim odbędzie się testowanie wymiany danych pomiędzy rejestrem a niezależnym dziennikiem transakcji Wspólnoty.
3. Centralny Administrator żąda, aby rejestr wykonał następujące etapy testowania:
a) Testy uwierzytelnienia: testowana jest zdolność rejestru do identyfikowania niezależnego dziennika transakcji Wspólnoty i na odwrót.
b) Testy synchronizacji czasu: testowana jest zdolność rejestru do ustanowienia swojego czasu systemowego i do zmiany swojego czasu systemowego w celu uzyskania zgodności z czasem systemowym niezależnego dziennika transakcji Wspólnoty i niezależnego dziennika transakcji UNFCCC.
c) Testy formatu danych: testowana jest zdolność rejestru do generowania komunikatów odpowiadających odpowiedniemu statusowi i etapowi procesu oraz odpowiedniemu formatowi przedstawionemu w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
d) Testy obsługi kodu programowania i bazy danych: testowana jest zdolność rejestru do przetwarzania otrzymywanych komunikatów, które odpowiadają odpowiedniemu formatowi określonemu w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC.
e) zintegrowany test procesu: testom zostaje poddana zdolność rejestru do wykonania wszystkich procesów, w tym wszystkie odnośne statusy i etapy opisane w załącznikach od VIII do XI oraz XIa, oraz możliwość prowadzenia ręcznych zabiegów na bazie danych na podstawie załącznika X.
f) Testy rejestrowania danych: testowana jest zdolność rejestru do ustanowienia i prowadzenia zapisów wymaganych stosownie do art. 73 ust. 2.
4. Centralny administrator żąda od rejestru, by udowodnił, że kody wyjściowe wymienione w załączniku VII oraz kody odpowiedzi wymienione w załącznikach od VIII do XI oraz XIa są zawarte w bazie danych rejestru oraz interpretowane i używane poprawnie w odniesieniu do procesów.
5. Etapy testowania przedstawione w ust. 3 odbywają się pomiędzy obszarem testowania rejestru a obszarem testowania niezależnego dziennika transakcji Wspólnoty, ustanowionym stosownie do art. 71.
6. Indywidualne testy przeprowadzane w ramach etapów testowania przedstawionych w ust. 3 mogą różnić się w zależności od oprogramowania i sprzętu komputerowego używanego przez rejestr.
7. Indywidualne testy przeprowadzane w ramach etapów testowania przedstawionych w ust. 3 prowadzone są zgodnie z określonym z góry planem, a wyniki są dokumentowane. Dokumentacja ta jest na żądanie udostępniana Centralnemu Administratorowi. Wszelkie mankamenty wykryte w rejestrze podczas etapów testowania określonych w ust. 3 winny zostać usunięte, zanim ustanowione zostanie łącze komunikacyjne pomiędzy tymże rejestrem i niezależnym dziennikiem transakcji Wspólnoty. Administrator rejestru wykaże, iż wszelkie takie mankamenty zostały usunięte przez pomyślne przeprowadzenie etapów testowania przedstawionych w ust. 3.
ZAŁĄCZNIK XIV
91 Procedury inicjalizacji
91 Procedury inicjalizacji
a) Nazwę, adres, miejscowość, kod pocztowy, kraj, numer telefonu, numer telefaksu oraz adres poczty elektronicznej administratora swojego rejestru.
b) Adres, miejscowość, kod pocztowy i kraj fizycznej lokalizacji rejestru.
c) URL oraz port(-y) zarówno zabezpieczonego, jak i publicznego obszaru rejestru oraz URL i port(-y) obszaru testowania.
d) Opis podstawowego i rezerwowego sprzętu i oprogramowania komputerowego używanego przez rejestr oraz sprzętu i oprogramowania komputerowego, na którym oparty jest obszar testowania stosownie do art. 68.
e) Opis systemów i procesów zabezpieczania wszystkich danych, w tym częstotliwości, z jaką wykonywana jest zapasowa kopia bazy danych, oraz systemów i procedur szybkiego odzyskiwania wszystkich danych i wznawiania wszystkich operacji na wypadek katastrofy stosownie do art. 68.
f) Opis planu zabezpieczenia rejestru ustanowionego stosownie do ogólnych wymagań zabezpieczenia według załącznika XV.
g) Opis systemu i procedur rejestru pod względem zarządzania zmianami stosownie do art. 72.
h) Informacje żądane przez Centralnego Administratora w celu umożliwienia dystrybucji cyfrowych certyfikatów stosownie do załącznika XV.
O wszelkich późniejszych zmianach należy niezwłocznie powiadomić Komisję.
2. Każde Państwo Członkowskie powiadomi Komisję o ilości przydziałów na okoliczność siły wyższej, które mają być wydane na okres 2005-2007 na podstawie upoważnienia do wydania takich przydziałów udzielonego przez Komisję stosownie do art. 29 dyrektywy 2003/87/WE.
3. Przed okresem 2008-2012 oraz przed każdym kolejnym pięcioletnim okresem każde Państwo Członkowskie przekaże Komisji następujące informacje:
a) Ogólną ilość jednostek ERU CER, jaką operatorzy mogą użyć przez każdy okres stosownie do art. 11a ust. 1 dyrektywy 2003/87/WE.
b) Rezerwa okresu zobowiązania, obliczona zgodnie z decyzją 18/CP.7 Konferencji Stron UNFCCC jako 90 % ilości przydzielonej Państwu Członkowskiemu lub 100 % pięciokrotnej wielkości jego ostatnio przeglądniętego zapasu, w zależności od tego, co jest najmniejsze.
Wymagania dotyczące tabeli planu krajowego rozdzielenia
4. Każdy plan krajowego rozdzielenia jest przedkładany zgodnie z formatami określonymi w ust. 5 i 7.
5. Format przekazywania Komisji tabeli krajowego planu rozdziału uprawnień jest następujący
a) całkowita liczba rozdzielonych uprawnień: w pojedynczej komórce - całkowita liczba uprawnień, które zostaną rozdzielone na okres objęty krajowym planem rozdziału uprawnień;
b) całkowita liczba uprawnień nierozdzielonych pomiędzy obecnie działających operatorów (rezerwa): w pojedynczej komórce - całkowita liczba uprawnień (rozdzielonych lub nabytych), które odłożono dla nowych operatorów oraz w celu sprzedaży w drodze aukcji na okres objęty krajowym planem rozdziału uprawnień;
c) lata: w pojedynczych komórkach dla każdego roku spośród lat objętych krajowym planem rozdziału uprawnień w porządku wzrastającym;
d) kod identyfikacyjny instalacji: w pojedynczych komórkach w porządku wzrastającym. wymienione instalacje obejmują instalacje jednostronnie włączone na podstawie art. 24 dyrektywy 2003/87/WE i nie obejmują jakichkolwiek instalacji wykluczonych tymczasowo na podstawie art. 27 dyrektywy 2003/87/WE;
e) przydzielone uprawnienia: uprawnienia, które mają być przydzielone na określony rok dla określonej instalacji, są wpisywane do komórki łączącej ten rok z komórką kodu identyfikacyjnego instalacji.
6. Instalacje według ust. 5 lit. d) obejmują instalacje jednostronnie ujęte w art. 24 dyrektywy 2003/87/WE i nie obejmują jakichkolwiek instalacji czasowo wykluczonych na podstawie art. 27 dyrektywy 2003/87/WE.
7. Zapisany w języku XML schemat przedstawiania Komisji tabeli krajowego planu rozdziału uprawnień do emisji jest następujący:
8. W ramach procedur inicjalizacji przedstawionych w funkcjonalnych i technicznych specyfikacjach dotyczących standardów wymiany danych dla systemów rejestrów według Protokołu z Kioto, opracowanych stosownie do decyzji 24/CP.8 Konferencji Stron UNFCCC, Komisja przekazuje Sekretariatowi UNFCCC kody identyfikacji rachunku dotyczące rachunków anulowania, rachunków wycofania i rachunków wymiany każdego rejestru.
ZAŁĄCZNIK XV
92 Normy zabezpieczenia
92 Normy zabezpieczenia
1. Jeżeli nie zostało ustanowione łącze komunikacyjne między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC, wszystkie procesy dotyczące uprawnień, automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji i rachunków są wykonywane za pomocą łącza komunikacyjnego o następujących własnościach:
a) Bezpieczna transmisja jest realizowana poprzez zastosowanie technologii SSL z szyfrowaniem minimum 128-bitowym.
b) Tożsamość każdego rejestru jest uwierzytelniana przy użyciu cyfrowych certyfikatów dla zapytań pochodzących od niezależnego dziennika transakcji Wspólnoty. Tożsamość niezależnego dziennika transakcji Wspólnoty jest uwierzytelniana przy użyciu cyfrowych certyfikatów dla każdego zapytania pochodzącego od rejestru. Tożsamość każdego rejestru jest uwierzytelniana przy użyciu nazwy użytkownika i hasła dla każdego zapytania pochodzącego od rejestru. Tożsamość niezależnego dziennika transakcji Wspólnoty jest uwierzytelniana przy użyciu nazwy użytkownika i hasła dla każdego zapytania pochodzącego od niezależnego dziennika transakcji Wspólnoty. Cyfrowe certyfikaty są rejestrowane jako ważne przez organ certyfikacyjny. Nazwy użytkowników i hasła mają długość co najmniej 10 znaków i są zgodne z podstawowym schematem uwierzytelniania protokołu HTTP (http://www.ietf.org/rfc/rfc2617.txt).
2. Po utworzeniu łącza komunikacyjnego między niezależnym dziennikiem transakcji Wspólnoty a niezależnym dziennikiem transakcji UNFCCC, wszystkie procesy dotyczące uprawnień, automatycznych zmian tabeli krajowego planu rozdziału uprawnień do emisji, zweryfikowanych emisji, rachunków i jednostek Kioto są wykonywane za pomocą łącza komunikacyjnego o własnościach opisanych w specyfikacji funkcjonalnej i technicznej standardów wymiany danych systemów rejestracji w ramach protokołu z Kioto, opracowanej na podstawie decyzji 24/CP.8 Konferencji Stron UNFCCC.
Łącze komunikacyjne pomiędzy niezależnym dziennikiem transakcji Wspólnoty i jego upoważnionymi przedstawicielami oraz każdym rejestrem i wszystkimi upoważnionymi przedstawicielami w danym rejestrze
3. Łącze komunikacyjne pomiędzy niezależnym dziennikiem transakcji Wspólnoty i jego upoważnionymi przedstawicielami oraz pomiędzy rejestrem i upoważnionymi przedstawicielami posiadaczy rachunków, weryfikatorami i administratorem rejestru, po uzyskaniu przez upoważnienionych przedstawicieli dostępu z sieci innej niż ta, która obsługuje niezależny dziennik transakcji Wspólnoty lub dany rejestr, ma następujące właściwości:
a) Bezpieczna transmisja jest realizowana poprzez zastosowanie technologii SSL z szyfrowaniem minimum 128-bitowym.
b) Tożsamość każdego upoważnionego przedstawiciela jest uwierzytelniana poprzez zastosowanie nazw użytkowników i haseł, które są rejestrowane jako ważne przez rejestr.
4. System służący do wydawania upoważnionym przedstawicielom nazw użytkowników i haseł stosownie do ust. 3 lit. b) ma następujące właściwości:
a) W dowolnym czasie każdy upoważniony przedstawiciel otrzymuje jednoznaczną nazwę użytkownika i jednoznaczne hasło.
b) Administrator rejestru utrzymuje w rejestrze wykaz wszystkich upoważnionych przedstawicieli, którym udzielono dostępu do rejestru wraz z ich prawami dostępu.
c) Liczba upoważnionych przedstawicieli Centralnego Administratora i administratora rejestru jest ograniczona do minimum, a prawa dostępu są przydzielane wyłącznie z uwagi na umożliwienie wykonywania zadań administracyjnych.
d) Wszelkie ustanowione przez dostawcę domyślne hasła dostępu z prawami dostępu Centralnego Administratora lub administratora rejestru zostają niezwłocznie zmienione po zainstalowaniu oprogramowania i sprzętu komputerowego dla niezależnego dziennika transakcji Wspólnoty lub rejestru.
e) Upoważnieni przedstawiciele są zobowiązani do zmiany wszelkich tymczasowych haseł, jakie otrzymali po wejściu po raz pierwszy do zabezpieczonego obszaru niezależnego dziennika transakcji Wspólnoty lub rejestru, a następnie zobowiązani są do zmiany swoich haseł minimum co dwa miesiące.
f) System zarządzania hasłami prowadzi wykaz poprzednich haseł upoważnionego przedstawiciela i nie dopuszcza do ponownego użycia dziesięciu ostatnich haseł tego upoważnionego przedstawiciela. Hasła mają długość minimum osiem znaków i stanowią połączenie znaków numerycznych i alfanumerycznych.
g) Hasła nie są wyświetlane na ekranie komputera podczas wpisywania ich przez upoważnionego przedstawiciela, a pliki z hasłami nie są bezpośrednio widoczne dla upoważnionego przedstawiciela Centralnego Administratora lub administratora rejestru.
Łącze komunikacyjne pomiędzy niezależnym dziennikiem transakcji Wspólnoty i ogólną społecznością oraz każdym rejestrem i ogólną społecznością
5. Publiczny obszar strony WWW niezależnego dziennika transakcji Wspólnoty oraz publiczna strona WWW rejestru nie wymagają uwierzytelniania ich użytkowników reprezentujących ogólną społeczność.
6. Publiczny obszar strony WWW niezależnego dziennika transakcji Wspólnoty oraz publiczny obszar strony WWW rejestru nie zezwalają użytkownikom reprezentującym ogólną społeczność na bezpośredni dostęp do bazy danych niezależnego dziennika transakcji Wspólnoty lub bazy danych tego rejestru. Dostęp do danych, które są publicznie dostępne zgodnie z załącznikiem XVI, jest możliwy poprzez odrębną bazę danych.
Ogólne wymagania dotyczące zabezpieczenia odnoszące się do niezależnego dziennika transakcji Wspólnoty oraz każdego rejestru
7. Poniższe ogólne wymagania dotyczące zabezpieczenia stosują się do niezależnego dziennika transakcji Wspólnoty i każdego rejestru:
a) Niezależny dziennik transakcji Wspólnoty i każdy rejestr są zabezpieczone przed Internetem za pomocą programu "firewall", który ma być skonfigurowany możliwie jak najściślej tak, aby ograniczać ruch do i od strony Internetu.
b) Niezależny dziennik transakcji Wspólnoty i każdy rejestr przeprowadzają regularne skanowanie wszystkich węzłów, stacji roboczych i serwerów w obrębie swoich sieci pod względem obecności wirusów. Oprogramowanie antywirusowe będzie regularnie uaktualniane.
c) Niezależny dziennik transakcji Wspólnoty i każdy rejestr zapewniają, aby oprogramowanie wszystkich węzłów, stacji roboczych i serwerów było prawidłowo konfigurowane i rutynowo uzupełniane wraz z pojawianiem się uaktualnień zabezpieczających i funkcjonalnych.
d) Gdy zajdzie potrzeba, niezależny dziennik transakcji Wspólnoty i każdy rejestr wprowadzą dodatkowe wymogi odnośnie do zabezpieczenia w celu zapewnienia, aby system był zdolny do reagowania na nowe zagrożenia bezpieczeństwa.
ZAŁĄCZNIK XVI
93 Wymagania składania raportów przez każdego administratora rejestru i Centralnego Administratora
93 Wymagania składania raportów przez każdego administratora rejestru i Centralnego Administratora
1. Centralny Administrator prezentuje i aktualizuje informacje podane w pkt 2-4c odnośnie do systemu rejestrów na ogólnie dostępnej stronie internetowej niezależnego dziennika transakcji Wspólnoty w określonych terminach, zaś każdy administrator rejestru prezentuje i aktualizuje informacje podane w pkt 2-4b w odniesieniu do własnego rejestru na ogólnie dostępnej stronie internetowej tego rejestru w określonych terminach.
2. Następujące informacje dotyczące każdego rachunku są wykazywane w tydzień po utworzeniu rachunku w rejestrze, a następnie są co tydzień uaktualniane:
a) nazwisko, adres, miasto, kod pocztowy, kraj, nr telefonu i adres e-mail posiadacza rachunku;
b) identyfikator alfanumeryczny: określony przez posiadacza rachunku identyfikator przypisany każdemu rachunkowi;
c) nazwisko, adres, miasto, kod pocztowy, kraj, nr telefonu, nr faksu i adres e-mail głównego i zastępczego upoważnionego przedstawiciela rachunku, określonego przez posiadacza rachunku dla tego rachunku, pod warunkiem że posiadacz rachunku zwrócił się do administratora rejestru na piśmie o prezentację wszystkich lub części informacji.
3. Następujące dodatkowe informacje dotyczące każdego rachunku posiadania operatora są wykazywane w tydzień po utworzeniu rachunku w rejestrze, a następnie co tydzień są uaktualniane:
a) punkty 1-4.1, 4.4-5.5 oraz pkt 7 (czynność 1) informacji identyfikujących instalację związaną z rachunkiem posiadania operatora, wymienione w sekcji 11.1 załącznika I do decyzji Komisji 2004/156/WE;
b) kod identyfikacji pozwolenia: kod przydzielony instalacji związanej z rachunkiem posiadania operatora, zawierający elementy przedstawione w załączniku VI;
c) kod identyfikacji instalacji: kod przydzielony instalacji związanej z rachunkiem posiadania operatora, zawierający elementy przedstawione w załączniku VI;
d) uprawnienia i wszystkie uprawnienia na okoliczność siły wyższej rozdzielone i wydane na mocy art. 11 dyrektywy 2003/87/WE oraz wszystkie korekty takich przydziałów dla instalacji związanej z rachunkiem posiadania operatora, która to instalacja znajduje się w tabeli krajowego planu rozdziału uprawnień do emisji lub jest nowym uczestnikiemł
e) data wejścia w życie pozwolenia na emisję gazów cieplarnianych oraz data otwarcia rachunku.
4. Poniższe dodatkowe informacje dotyczące każdego rachunku posiadania operatora na lata od 2005 r. będą wykazywane zgodnie z określonymi niżej terminami:
a) dane dotyczące zweryfikowanych emisji wraz z korektami dla instalacji związanej z rachunkiem posiadania operatora za rok X są prezentowane począwszy od dnia 1 kwietnia roku (X+1), lub, jeżeli dzień 1 kwietnia przypada na weekend lub święto, dane dotyczące zweryfikowanych emisji są prezentowane począwszy od pierwszego dnia roboczego następującego po dniu 1 kwietnia;
b) jednostki umorzone zgodnie z art. 52 i 53 według jednostkowego kodu identyfikacyjnego (w przypadku jednostek ERU i CER) za rok X są prezentowane począwszy od dnia 1 maja roku (X+1);
c) symbol wskazujący, czy instalacja związana z rachunkiem posiadania operatora odstąpiła niezbędną liczbę uprawnień lub nie odstąpiła uprawnień do dnia 30 kwietnia roku X zgodnie z art. 6 ust. 2 lit. e) dyrektywy 2003/87/WE, oraz jakiekolwiek kolejne zmiany tego statusu na podstawie poprawek zweryfikowanych emisji zgodnie z art. 51 ust. 4 niniejszego rozporządzenia są przedstawiane od dnia 15 maja roku (X + 1). Zależnie od liczby statusu zgodności instalacji i statusu operacyjnego rejestru podawane są następujące symbole wraz z następującymi stwierdzeniami:
Tabela XVI-1: stwierdzenia dotyczące zgodności
Liczba statusu zgodności za rok X na mocy art. 55 dnia 30 kwietnia roku (X + 1) | Symbol | Stwierdzenie |
prezentacja w CITL i rejestrach | ||
Wszystkie odstąpione uprawnienia zgodnie z art. 52, 53, 54 za okres ≥ od zweryfikowanych emisji w okresie do bieżącego roku | A | "Liczba uprawnień i jednostek Kioto większa lub równa zweryfikowanym emisjom została odstąpiona do dnia 30 kwietnia" |
Wszystkie odstąpione uprawnienia zgodnie z art. 52, 53 i 54 za okres < od zweryfikowanych emisji w okresie do bieżącego roku | B | "Liczba uprawnień i jednostek Kioto mniejsza od zweryfikowanych emisji została odstąpiona do dnia 30 kwietnia" |
C | "Nie wprowadzono zweryfikowanych emisji do dnia 30 kwietnia" | |
Zweryfikowane emisje w okresie od bieżącego roku zostały skorygowane na podstawie art. 51 | D | "Zweryfikowane emisje zostały skorygowane przez właściwy organ po dniu 30 kwietnia roku X. Właściwy organ państwa członkowskiego zadecydował, że instalacja nie jest zgodna w roku X" |
Zweryfikowane emisje w okresie od bieżącego roku zostały skorygowane na podstawie art. 51 | E | "Zweryfikowane emisje zostały skorygowane przez właściwy organ po dniu 30 kwietnia roku X. Właściwy organ państwa członkowskiego zadecydował, że instalacja jest zgodna w roku X" |
X | "Wprowadzenie zweryfikowanych emisji i/lub odstąpienie było niemożliwe do dnia 30 kwietnia z powodu procesu odstępowania uprawnień i/lub wstrzymania procesu aktualizacji zweryfikowanych emisji w rejestrze państwa członkowskiego zgodnie z art. 6 ust. 3"; " |
d) symbol wskazujący, czy rachunek instalacji jest zablokowany zgodnie z art. 27 ust. 1, jest prezentowany od dnia 31 marca w roku (X + 1).
4a. Następujące ogólne informacje będą wykazywane i uaktualniane w ciągu 7 dni roboczych od momentu wszelkich zmian, jakie zostały w nich dokonane:
a) tabela krajowego planu rozdziału uprawnień każdego państwa członkowskiego, wskazująca rozdział na instalacje oraz ilość uprawnień zarezerwowanych do późniejszego rozdzielenia lub sprzedaży, zostanie wykazana i uaktualniona zawsze wtedy, gdy nastąpi korekta do tabeli krajowego planu rozdziału uprawnień, z wyraźnym określeniem, gdzie dokonano korekt;
b) opłaty pobierane za utworzenie i roczne utrzymanie rachunków posiadania w każdym rejestrze; uaktualnienia tej informacji są zgłaszane centralnemu administratorowi przez administratora rejestru w ciągu 15 dni roboczych od jakiejkolwiek zmiany opłat;
c) typ jednostek Kioto, które mogą znajdować się na rachunkach posiadania operatora i osobistych rachunkach posiadania w rejestrach.
4c. Wykaz z identyfikatorami jednostkowymi wszystkich umorzonych uprawnień, CER i ERU jest prezentowany oraz aktualizowany co 24 godziny. W przypadku jednostek CER i ERU prezentuje się nazwę projektu, kraj pochodzenia i identyfikator projektu.
Informacje dostępne publicznie z każdego rejestru
5. Każdy administrator rejestru wykazuje i uaktualnia informacje wymienione w ust. 6-10 odnoszące się do jego rejestru w publicznym obszarze strony WWW danego rejestru zgodnie z określonym harmonogramem.
6. Następujące informacje dotyczące każdego identyfikatora projektu dla czynności projektowej realizowanej stosownie do art. 6 Protokołu z Kioto, na podstawie których Państwo Członkowskie wydało jednostki ERU, zostają wykazane w tydzień po nastąpieniu wydania:
a) nazwa projektu: jednoznaczna nazwa projektu;
b) lokalizacja projektu: Państwo Członkowskie i miasto lub region, w którym projekt jest zlokalizowany;
c) lata wydania ERU: lata, w których wydane zostały jednostki ERU w wyniku czynności projektowej realizowanej stosownie do art. 6 Protokołu z Kioto;
d) raporty: przeznaczone do pobrania elektroniczne wersje całej publicznie dostępnej dokumentacji związanej z projektem, w tym propozycji, monitoringu, weryfikacji i wydania jednostek ERU, gdy stosowne, podlegającej przepisom dotyczącym poufności zawartym w decyzji -/CMP.1 [Artykuł 6] Konferencji Stron UNFCCC służącej jako posiedzenie Stron Protokołu z Kioto.
e) jakakolwiek tabela dotycząca rezerwy sporządzona zgodnie z decyzją Komisji 2006/780/WE(1)
7. Następujące informacje dotyczące posiadania i transakcji, według kodu identyfikacyjnego zawierającego elementy przedstawione w załączniku VI, odnoszące się do danego rejestru za lata, począwszy od 2005 r., są wykazywane zgodnie z określonymi niżej terminami:
a) ogólna ilość jednostek ERU, CER, AAU i RMU utrzymywanych na każdym rachunku (posiadania osoby, posiadania operatora, posiadania Strony, anulowania, wymiany lub wycofania) na dzień 1 stycznia roku X jest wykazywana, począwszy od 15 stycznia roku (X+5);
b) ogólna ilość jednostek AAU wydanych w roku X na podstawie rozdzielonej ilości stosownie do art. 7 decyzji nr 280/2004/WE jest wykazywana, począwszy od 15 stycznia roku (X+1);
c) ogólna ilość jednostek ERU wydanych w roku X na podstawie działania projektowego realizowanego stosownie do art. 6 Protokołu z Kioto jest wykazywana, począwszy od 15 stycznia roku (X+1);
d) ogólna ilość jednostek ERU, CER, AAU i RMU nabytych z innych rejestrów w roku X oraz tożsamość przekazujących rejestrów i rachunków są wykazywane, począwszy od 15 stycznia roku (X+5);
e) ogólna ilość jednostek RMU wydanych w roku X na podstawie każdego działania według art. 3 ust. 3 i 4 Protokołu z Kioto jest wykazywana, począwszy od 15 stycznia roku (X+1);
f) ogólna ilość jednostek ERU, CER, AAU i RMU przekazanych do innego rejestru w roku X oraz tożsamość nabywających rachunków i rejestrów jest wykazywana, począwszy od 15 stycznia roku (X+5);
g) ogólna ilość jednostek ERU, CER, AAU i RMU anulowanych w roku X na podstawie działań według art. 3 ust. 3 i 4 Protokołu z Kioto jest wykazywana, począwszy od 15 stycznia roku (X+1);
h) ogólna ilość jednostek ERU, CER, AAU i RMU anulowanych w roku X po stwierdzeniu przez komitet zgodności działający na podstawie Protokołu z Kioto, że Państwo Członkowskie nie dotrzymuje swojego zobowiązania wynikającego z art. 3 ust. 1 Protokołu z Kioto, jest wykazywana, począwszy od 15 stycznia roku (X+1);
i) ogólna ilość pozostałych jednostek ERU, CER, AAU i RMU lub przydziałów anulowanych w roku X oraz przywołanie artykułu, stosownie do którego te jednostki Kioto lub przydziały były anulowane według niniejszego rozporządzenia, są wykazywane, począwszy od 15 stycznia roku (X+1);
j) ogólna ilość jednostek ERU, CER, AAU, RMU i przydziałów wycofanych w roku X jest wykazywana, począwszy od 15 stycznia roku (X+1);
k) ogólna ilość jednostek ERU, CER, AAU przeniesionych w roku X z poprzedniego okresu zobowiązania jest wykazywana, począwszy od 15 stycznia roku (X+1);
l) ogólna ilość przydziałów z poprzedniego okresu zobowiązania anulowanych i zamienionych w roku X jest wykazywana, począwszy od 15 maja roku X;
m) aktualne stany posiadania jednostek ERU, CER, AAU i RMU na każdym rachunku (posiadania osoby, posiadania operatora, posiadania Strony, anulowania lub wycofania) na dzień 31 grudnia roku X są wykazywane, począwszy od 15 stycznia roku (X+5).
8. Wykaz osób upoważnionych przez Państwo Członkowskie do utrzymywania jednostek ERU, CER, AAU i/lub RMU pod swoją odpowiedzialnością jest wykazywany w tydzień po udzieleniu takiego upoważnienia i jest uaktualniany co tydzień.
9. Ogólna ilość jednostek CER i ERU, którą operatorzy mogą użyć przez każdy okres stosownie do art. 11a ust. 1 dyrektywy 2003/87/WE, jest wykazywana zgodnie z art. 30 ust. 3 dyrektywy 2003/87/WE.
10. Rezerwa okresu zobowiązania, obliczona zgodnie z decyzją 18/CP.7 Konferencji Stron UNFCCC jako 90 % ilości przydzielonej Państwu Członkowskiemu lub 100 % pięciokrotnej wielkości jego ostatnio przejrzanego zapasu, w zależności od tego, co jest najmniejsze, oraz ilość jednostek Kioto, o którą Państwo Członkowskie przekracza rezerwę okresu zobowiązania, a tym samym przestrzega jej, jest wykazywana na żądanie.
Informacje dostępne publicznie z niezależnego dziennika transakcji Wspólnoty
11. Centralny Administrator wykazuje i uaktualnia informacje wymienione w ust. 12 odnoszące się do systemu rejestrów w publicznym obszarze strony WWW niezależnego dziennika Wspólnoty według określonego harmonogramu.
12. Następujące informacje dla każdej dokonanej transakcji dotyczącej systemu rejestrów za rok X wykazywane są, począwszy od 15 stycznia roku (X+5):
a) kod identyfikacji rachunku przekazującego: przydzielony do rachunku kod składający się z elementów przedstawionych w załączniku VI;
b) kod identyfikacji rachunku nabywającego: przydzielony do rachunku kod składający się z elementów przedstawionych w załączniku VI;
c) nazwa posiadacza rachunku przekazującego: posiadacz rachunku (osoba, operator, Komisja, Państwo Członkowskie);
d) nazwa posiadacza rachunku nabywającego: posiadacz rachunku (osoba, operator, Komisja, Państwo Członkowskie);
e) występujące w transakcji przydziały lub jednostki Kioto według kodu identyfikacji jednostki składającego się z elementów przedstawionych w załączniku VI;
f) kod identyfikacji transakcji: przydzielony do transakcji kod składający się z elementów przedstawionych w załączniku VI;
g) data i godzina przeprowadzenia transakcji (według czasu uniwersalnego);
h) typ procesu: katagoryzacja procesu składającego się z elementów przedstawionych w załączniku VII.
12a. W dniu 30 kwietnia każdego roku CITL umieszcza na swojej ogólnie dostępnej stronie internetowej następujące informacje ogólne:
– udział procentowy umorzonych uprawnień w każdym państwie członkowskim w poprzednim roku kalendarzowym, które zostały umorzone z rachunku, na który zostały przydzielone,
– suma zweryfikowanych emisji każdego państwa członkowskiego podana dla poprzedniego roku kalendarzowego jako odsetek sumy zweryfikowanych emisji roku przed rokiem poprzednim,
– udział procentowy rachunków zarządzanych przez dane państwo członkowskie w liczbie i wielkości wszystkich transakcji z udziałem uprawnień i jednostek Kioto w poprzednim roku kalendarzowym,
– udział procentowy rachunków zarządzanych przez dane państwo członkowskie w liczbie i wielkości wszystkich transakcji z udziałem uprawnień i jednostek Kioto w poprzednim roku kalendarzowym między rachunkami zarządzanymi przez różne państwa członkowskie.
Informacje udostępniane posiadaczom rachunków z każdego rejestru
13. Każdy administrator rejestru wykazuje i uaktualnia informacje wymienione w ust. 14 odnoszące się do jego rejestru w bezpiecznym obszarze strony WWW tego rejestru według określonego harmonogramu.
14. Dla każdego rachunku następujące elementy, według kodu identyfikacji jednostki zawierającego elementy przedstawione w załączniku VI, są wykazywane na żądanie posiadacza rachunku wyłącznie temu posiadaczowi rachunku:
a) aktualne stany posiadania przydziałów lub jednostek Kioto;
b) wykaz proponowanych transakcji zainicjowanych przez tego posiadacza rachunku, wyszczególniający dla każdej proponowanej transakcji elementy wymienione w ust. 12 lit. a)-f), datę i godzinę złożenia propozycji transakcji (według czasu uniwersalnego), aktualny status zaproponowanej transakcji oraz ewentualne odesłane kody wynikające ze sprawdzeń przeprowadzonych stosownie do załącznika IX;
c) wykaz przydziałów lub jednostek Kioto nabytych przez ten rachunek w wyniku przeprowadzonych transakcji, wyszczególniający dla każdej transakcji elementy wymienione w ust. 12 lit. a)-g);
d) wykaz przydziałów lub jednostek Kioto przekazanych z tego rachunku w wyniku przeprowadzonych transakcji, wyszczególniający dla każdej transakcji elementy wymienione w ust. 12 a)-g).
______
(1) Dz.U. L 316 z 16.11.2006, str. 12.
- zmieniony przez art. 78 pkt 2 rozporządzenia nr 920/2010 z dnia 7 października 2010 r. w sprawie standaryzowanego i zabezpieczonego systemu rejestrów na mocy dyrektywy 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzji nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.10.270.1) z dniem 15 października 2010 r.
- zmieniony przez art. 88 pkt 1 rozporządzenia nr 1193/2011 z dnia 18 listopada 2011 r. ustanawiającego rejestr Unii na okres rozliczeniowy rozpoczynający się dnia 1 stycznia 2013 r. oraz na kolejne okresy rozliczeniowe w ramach unijnego systemu handlu uprawnieniami do emisji gazów cieplarnianych zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady oraz zmieniającego rozporządzenia Komisji (WE) nr 2216/2004 i (UE) nr 920/2010 (Dz.U.UE.L.11.315.1) z dniem 30 listopada 2011 r.
- zmieniony przez art. 90 lit. d) rozporządzenia nr 994/2008 z dnia 8 października 2008 r. w sprawie znormalizowanego i zabezpieczonego systemu rejestrów zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.08.271.3) z dniem 12 października 2008 r.
- zmieniony przez art. 78 pkt 12 rozporządzenia nr 920/2010 z dnia 7 października 2010 r. w sprawie standaryzowanego i zabezpieczonego systemu rejestrów na mocy dyrektywy 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzji nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.10.270.1) z dniem 15 października 2010 r.
-zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 1 lutego 2008 r.
- zmieniony przez art. 90 lit. i) rozporządzenia nr 994/2008 z dnia 8 października 2008 r. w sprawie znormalizowanego i zabezpieczonego systemu rejestrów zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.08.271.3) z dniem 12 października 2008 r.
-zmieniony przez art. 78 pkt 18 rozporządzenia nr 920/2010 z dnia 7 października 2010 r. w sprawie standaryzowanego i zabezpieczonego systemu rejestrów na mocy dyrektywy 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzji nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.10.270.1) z dniem 15 października 2010 r.
- zmieniony przez art. 88 pkt 7 rozporządzenia nr 1193/2011 z dnia 18 listopada 2011 r. ustanawiającego rejestr Unii na okres rozliczeniowy rozpoczynający się dnia 1 stycznia 2013 r. oraz na kolejne okresy rozliczeniowe w ramach unijnego systemu handlu uprawnieniami do emisji gazów cieplarnianych zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady oraz zmieniającego rozporządzenia Komisji (WE) nr 2216/2004 i (UE) nr 920/2010 (Dz.U.UE.L.11.315.1) z dniem 30 listopada 2011 r.
-dodany przez art. 78 pkt 19 rozporządzenia nr 920/2010 z dnia 7 października 2010 r. w sprawie standaryzowanego i zabezpieczonego systemu rejestrów na mocy dyrektywy 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzji nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.10.270.1) z dniem 15 października 2010 r.
- zmieniony przez art. 88 pkt 8 rozporządzenia nr 1193/2011 z dnia 18 listopada 2011 r. ustanawiającego rejestr Unii na okres rozliczeniowy rozpoczynający się dnia 1 stycznia 2013 r. oraz na kolejne okresy rozliczeniowe w ramach unijnego systemu handlu uprawnieniami do emisji gazów cieplarnianych zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady oraz zmieniającego rozporządzenia Komisji (WE) nr 2216/2004 i (UE) nr 920/2010 (Dz.U.UE.L.11.315.1) z dniem 30 listopada 2011 r.
-zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 1 lutego 2008 r.
- zmieniony przez art. 90 lit. j) rozporządzenia nr 994/2008 z dnia 8 października 2008 r. w sprawie znormalizowanego i zabezpieczonego systemu rejestrów zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.08.271.3) z dniem 12 października 2008 r.
-zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 4 sierpnia 2007 r.
- zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 1 lutego 2008 r.
-zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 4 sierpnia 2007 r.
- zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 1 lutego 2008 r.
- zmieniony przez art. 90 lit. k) rozporządzenia nr 994/2008 z dnia 8 października 2008 r. w sprawie znormalizowanego i zabezpieczonego systemu rejestrów zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.08.271.3) z dniem 12 października 2008 r.
-dodany przez art. 1 pkt 32 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 1 lutego 2008 r.
- zmieniony przez art. 90 lit. l) rozporządzenia nr 994/2008 z dnia 8 października 2008 r. w sprawie znormalizowanego i zabezpieczonego systemu rejestrów zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.08.271.3) z dniem 12 października 2008 r.
- zmieniony przez art. 78 pkt 20 rozporządzenia nr 920/2010 z dnia 7 października 2010 r. w sprawie standaryzowanego i zabezpieczonego systemu rejestrów na mocy dyrektywy 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzji nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.10.270.1) z dniem 15 października 2010 r.
-zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 4 sierpnia 2007 r.
- zmieniony przez art. 90 lit. m) rozporządzenia nr 994/2008 z dnia 8 października 2008 r. w sprawie znormalizowanego i zabezpieczonego systemu rejestrów zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.08.271.3) z dniem 12 października 2008 r.
- zmieniony przez art. 78 pkt 21 rozporządzenia nr 920/2010 z dnia 7 października 2010 r. w sprawie standaryzowanego i zabezpieczonego systemu rejestrów na mocy dyrektywy 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzji nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.10.270.1) z dniem 15 października 2010 r.
-zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 1 lutego 2008 r.
- zmieniony przez art. 90 lit. n) rozporządzenia nr 994/2008 z dnia 8 października 2008 r. w sprawie znormalizowanego i zabezpieczonego systemu rejestrów zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.08.271.3) z dniem 12 października 2008 r.
-zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 1 lutego 2008 r.
- zmieniony przez art. 90 lit. o) rozporządzenia nr 994/2008 z dnia 8 października 2008 r. w sprawie znormalizowanego i zabezpieczonego systemu rejestrów zgodnie z dyrektywą 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzją nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.08.271.3) z dniem 12 października 2008 r.
- zmieniony przez art. 1 pkt 31 rozporządzenia nr 916/2007 z dnia 31 lipca 2007 r. (Dz.U.UE.L.07.200.5) zmieniającego nin. rozporządzenie z dniem 1 stycznia 2009 r.
- zmieniony przez art. 78 pkt 22 rozporządzenia nr 920/2010 z dnia 7 października 2010 r. w sprawie standaryzowanego i zabezpieczonego systemu rejestrów na mocy dyrektywy 2003/87/WE Parlamentu Europejskiego i Rady oraz decyzji nr 280/2004/WE Parlamentu Europejskiego i Rady (Dz.U.UE.L.10.270.1) z dniem 15 października 2010 r.
© Unia Europejska, http://eur-lex.europa.eu/
Za autentyczne uważa się wyłącznie dokumenty Unii Europejskiej opublikowane w Dzienniku Urzędowym Unii Europejskiej.