Informacje dla ZUD

Poniżej przedstawiamy odpowiedzi na najczęściej zadawane pytania.

Proszę o informację dlaczego odczyt zaczyna się od 2018-03-31 kończy dnia 2018-05-01. Rozliczenie powinno dotyczyć pełnego miesiąca czyli zaczynać dnia 2018-03-31 i kończyć 2018-04-30 lub zaczynać od 2018-04-01 i kończyć 2018-05-01.

Komunikat xml ma strukturę drzewka. Wskazane przez użytkownika daty znajdują się na poziomie 3 drzewa xml w segmencie SG6 i oznaczają maksymalny okres dla lokalizacji licznika (maksymalny okres dla wszystkich danych przekazywanych w komunikacie). Prezentowany jest okres z parametrami 163 (czas rozpoczęcia) plus data, oraz 164 (czas zakończenia) plus data w takim znaczeniu, że: „dane przekazane w poniższym komunikacie mogą dotyczy okresu od daty 201803310600+2, do 201805010600+02”.

Dokładne okresy dla przekazywanych danych pomiarowych znajdują się w innych segmentach komunikatu. Każdorazowo po danej pomiarowej przekazywana jest jednostka pomiaru i daty od i do.

Excel nie jest dobry do analizy xml, ponieważ nie pokazuje struktury komunikatu. Jest ona lepiej widoczna a aplikacji w Internet Explorer.

Czy pliki na zmianę sprzedawcy też będą umieszczane w katalogach MSCONSWS i MSCONSWR?

Tak, pliki będą publikowane w obsłudze zdarzenia zmiany sprzedawcy.

Czy dla plików na zmianę sprzedawcy też będą odpowiedniki w plikach csv?

Tak, generator csv na podstawie plików będzie ewidencjonował dane w plikach csv.

Czy pliki odczytowe ze stanami początkowymi na zmianę sprzedawcy będą miały takie nazwy jak w folderze MSCONSWS?

Nazwy będą zgodnie z nazewnictwem w folderze MSCONSWS.

Porównując pliki na zmianę sprzedawcy z pozostałymi plikami zauważyliśmy, że jest w nich mniej o trzy kolumny (czy to jest poprawne):

a. CATEGOTY,

2. CATEGORY_CODE_LIST_ID,

3. STATUS_DESCRITION_CODE.

W kolejnych komunikatach po 2 lipca 2019 r. wprowadzona została poprawka po której występują również powyższe dane w treści komunikatów.

Pracujemy nadal nad wyrównaniem struktury komunikatów z obszaru tarnowskiego w kierunku struktury komunikatów z obszaru zabrzańskiego i gdańskiego

Stwierdziliśmy, że już posiadamy dane w plikach xlsx, a nie ma ich jeszcze w plikach xml – jaki może być tego powód? – przykładowy nr PPG : PL003XXXXXXX.

Czasy tworzenia/publikacji dla wskazanego punktu PL003XXXXXXX, dla odczytu harmonogramowego z dnia 02.07.2019 r.:

Plik xml dla PL003XXXXXXX w systemie został utworzony 03.07.2019 o godz. 22:05

Plik xml dla PL003XXXXXXX na sftp został utworzony w dniu 04.07.2019 o godz. 05:31

Może pojawić się opóźnienie na początku miesiąca wynikające z kolejkowania komunikatów w trakcie przekazywania odczytów dla punktów WR.

Dane dla pliku CSV zostały wygenerowane w dniu 04.07.2019 o godz. 19:05

Zdarza się, że w plikach xml dane są, a nie ma ich równolegle w plikach csv – czy będzie pełna synchronizacja? – przykładowy nr PPG : PL003XXXXXXX.

Pliki xml są publikowane w chwili zarejestrowania odczytu w systemie. Plik csv generowany jest raz dziennie (godz. 19:00).

Zauważyliśmy, że dla PSG Tarnów do nr PPG został dodany prefiks PL004 co wymaga renumeracji nr PPG.

Prefix PL004 jest dodany tylko na potrzeby komunikacji w celu rozpoznania tarnowskiego obszaru taryfowego. W systemie billingowym PSG nie jest stosowany numer prefiksu. Numeracja PPG w systemie nie uległa zmianie.

Prosimy o wyjaśnienie, czy dla PPG z obszaru Tarnów nr PPG (Id) w plikach xml będą poprzedzone prefiksem PL004, czy tego prefiksu nie będzie. Zauważyliśmy, że w plikach csv tego prefiksu nie ma. Poniżej podajemy przykład takiego PPG:

EDI_TASPPL004XXXXXXXXXXXX_PSGD20190719123100000000222494_TASP.xml – jest nr PPG jako PL0040091XXXXX,

TASP-TA-201907181900 201907191900.csv – jest nr PPG jako 0091XXXXX.

Od dnia 19.09.2019 dla obszaru taryfowego Tarnów w plikach CSV zostały ujednolicone nr ID PoD z numerem ID PoD z pliku XML. Dla pozostałych obszarów taryfowych Poznań, Warszawa i Wrocław obecnie stosowany format danych pomiarowo-odczytowych dla punktów wyjścia typu WS umieszczanych na sftp.psgaz.pl pozostaje bez zmian.

Czy pliki na sftp są archiwizowane?

Pliki będą archiwizowane zgodnie z zasadami opisanymi w dokumencie - „Instrukcja obsługi SFTP w zakresie danych odczytowych punktów wyjścia typu WS”.

Odnośnie pola ASSOCCODE – w testowanych plikach w tym polu wpisana jest wersja „1.0” jednak w specyfikacji dokumentu (w pliku Excel) zadeklarowana jest wartość „1.1”. Która z nich będzie właściwa na etapie wdrożenia produkcyjnego?

Wersja 1.1 będzie kolejną wersją produkcyjną.

Segment NAD – Pod danymi dla MS (nadawcy komunikatu) w specyfikacji Excel dokumentu MSCONS pojawia się sekcja zawierająca dane osoby przysyłającej dokument. Blok ten nie pojawia się w przykładowych XML, czy będzie wykorzystywany w docelowym rozwiązaniu?

Dane kontaktowe do przedstawiciela wysyłającego komunikat są danymi opcjonalnymi i mogą być przesłane w celu jednoznacznego wskazania osoby do kontaktu. Podczas testów komunikacji będzie można zweryfikować wykorzystanie tego pola.

Segment NAD2 – W przykładowych XML element/tag oznaczony jest jako NAD2, ale w opisie w Excel jest to NAD, czy docelowa nazwa elementu to NAD2?

Oznaczenie NAD2 w xml odnosi się do lokalizacji POD. W opisie w Excel pozostaje bez zmian.

Odnośnie podsekcji LOC w ramach NAD2 – Sekcja w opisie w Excel posiada nast. pola (zachowana kolejność):

PLACE_QUALIFIER

CODE_LIST_RESPONSIBLE_AGENCY_1

PLACE_ID

Jednak w XML są to w niektórych przypadkach nast. pola (dla dużych odbiorców, czyli WR):

PLACE_QUALIFIER

CODE_LIST_RESPONSIBLE_AGENCY_1

PLACE (bez „_ID”)

lub (w części przykładów dot. małych odbiorców WS):

PLACE_QUALIFIER

PLACE_ID

CODE_LIST_RESPONSIBLE_AGENCY_1 (inna kolejność).

Jaka jest docelowa kolejność i nazwy tagów, które będą wykorzystywane produkcyjnie?

W komunikatach dla WS, które ze względu na ilość komunikatów przeważają:

PLACE_QUALIFIER

PLACE_ID

CODE_LIST_RESPONSIBLE_AGENCY_1 (inna kolejność).

Dla WR używane jest pole PLACE, a docelowo zostanie zmienione na PLACE_ID.

Pliki XSD opisują większą liczbę pól w XMLach niż te, które zmapowano w opisach dokumentów zamieszczonych w formie arkuszy Excel (kolumna Pole XML). Czy można to tak interpretować, że elementy nie zmapowane w pliku Excel nie będą wykorzystywane?

Elementy nie zmapowane w pliku Excel nie będą wykorzystywane w obecnej wersji, ale nie wyklucza to możliwości użycia w przyszłości.

Proszę o informację w sprawie dostępności odczytów na serwerze SFTP. W moich folderach z obszarów taryfowych Zabrze, Gdańsk, Tarnów nie ma żadnych odczytów.

Dane pomiarowe na serwerze SFTP udostępniane są dla wszystkich obszarów taryfowych PSG. Dane pomiarowe dla obszarów taryfowych poznańskiego, warszawskiego oraz wrocławskiego udostępniane są w dotychczasowych formatach w folderach odpowiednio: POZNAN, WARSZAWA, WROCLAW. Dane pomiarowe dla obszarów taryfowych gdańskiego, tarnowskiego, zabrzańskiego udostępniane są w folderze OUTPUT->CSV-WS w postaci plików CSV oraz OUTPUT->MSCONSWS w postaci plików MSCONS zgodnych ze specyfikacją standardu EDIFACT i dotyczą punktów wyjścia typu WS. W folderze OUTPUT->MSCONSWR znajdują się dane pomiarowe z punktów wyjścia typu WR w postaci plików MSCONS.

Kiedy będą dostępne dane odczytowe dla pozostałych oddziałów PSG na serwerze SFTP?

Uprzejmie informuję, iż na serwerze SFTP dostępne są dane dla wszystkich punktów wyjścia typu WS. Nadmieniam, iż dla obszarów taryfowych poznańskiego, warszawskiego, wrocławskiego dane udostępniane są w dotychczasowych formatach na lokalnych serwerach FTP oraz dane dla obszaru taryfowego gdańskiego, tarnowskiego, zabrzańskiego w jednolitym formacie w postaci plików MSCONS (XML) oraz plików CSV.

W nawiązaniu do komunikatu o przejściu wyłącznie na komunikację za pośrednictwem usługi SFTP proszę o informację czy komunikat dotyczy wyłącznie danych pomiarowych dla punktów typu WS czy również dla punktów typu WR?

W przedmiotowej sprawie uprzejmie informuję, iż przekazany do Państwa komunikat dotyczy wyłącznie punktów WS.

Jaki jest termin przejścia na nowe kody PPG dla wszystkich Oddziałów?

Uruchomienie kolejnych obszarów taryfowych (Oddziałów) poprzedzone migracją i nadaniem punktom wyjścia typu WS nowych nr ID (POD), będzie komunikowane wszystkim ZUD z odpowiednim wyprzedzeniem.

Jak odczytywać nazwy plików w katalogach MSCONSXX (co oznaczają poszczególne części nazwy plików?

Nazwa pliku składa się kolejno z:

a) Wartość stała: "EDI_"

b) 4 znakowego kodu partnera

c) prefixu numeru POD

d) wartości z elementu MSCONS \ DTM \ DATUM zawartej w odczytywanym pliku XML

e) wartości z elementu MSCONS \ BGM \ DOCUMENTNUMBER

Zauważyliśmy, że niektóre plik są puste. Czym to jest spowodowane i w jakim celu?

Uprzejmie informuję, iż puste pliki bez danych pomiarowo-rozliczeniowych wynikają z powodu braku odczytów w tym okresie. Pliki CSV umieszczane są na serwerze SFTP raz dziennie i zawierają odczyty wprowadzone do systemu do godziny 19:00 w danym dniu roboczym. Puste pliki oznaczają, iż w danym dniu nie zaimplementowano na SFTP odczytów dla dedykowanego ZUD (w tym dniu nie wykonano odczytu wskazań układu pomiarowego).

Niniejszym informujemy, iż nie mamy narzędzia do odczytywania Państwa plików w zakresie SFTP. Prosimy zatem nadal o przesyłanie plików XSLX jak do tej pory.

W przedmiotowej sprawie informujemy, iż w okresie przejściowym dane pomiarowo-odczytowe dla punktów WS z grup taryfowych W1-W4 będą nadal przekazywane na obecnych zasadach tj. za pomocą plików xlsx przesyłanych drogą mailową oraz równolegle za pomocą serwera SFTP.

Proszę o informację o pojawieniu się nowych podkatalogów w katalogu Zabrze (czy to oznacza że dane dla punktów WS i WR w niedługim czasie będą pojawiać się na serwerze SFTP).

Uprzejmie informuję, iż obecnie pliki z danymi pomiarowymi dla zabrzańskiego obszaru taryfowego znajdują się w katalogu OUTPUT->MSCONSWS (pliki XML) oraz katalogu OUTPUT->CSV-WS (pliki MSCONS przekonwertowane do postaci CSV).

W dniu 31.05.2019 r. Polska Spółka Gazownictwa sp. z o.o. opublikowała aktualizację standardu EDIFACT, aktualna wersja standardu dostępna jest pod adresem: www.psgaz.pl/edi.

Rozpoczęcie publikacji danych pomiarowo-odczytowych dla punktów WR będzie komunikowane wszystkim ZUD z odpowiednim wyprzedzeniem.

W jaki sposób należy uzyskać dostęp do SFTP?

Uprzejmie informujemy, iż należy postępować zgodnie z załączoną Instrukcją. Wygenerowany klucz publiczny należy przesłać na adres: edifact@psgaz.pl, Osoba, która przesyła plik powinna widnieć w załączniku nr 4 lub 5 do Umowy Dystrybucyjnej. Nazwa użytkownika nadana przez PSG zostanie przesłana w informacji zwrotnej po weryfikacji osoby zgłaszającej przez służby IT PSG.

W plikach na serwerze (dotyczy obszaru tarnowskiego) numery zostały pozbawione zer na początku – nowy nr PP to 2308040. Czy nastąpiła zmiana numeracji, czy to błąd powstały podczas konwersji danych?

I czy ścieżka na serwerze jest docelowa, czy będą przeniesione w inne miejsce?

W przedmiotowej sprawie uprzejmie informujemy, iż konwersja danych spowodowała usunięcie dwóch pierwszych zer dla obszaru tarnowskiego. Nie było zmiany numeracji. Jednocześnie nadmieniam, iż aktualna ścieżka dostępu do serwera SFTP jest docelowa.

W odniesieniu do informacji o udostępnieniu danych pomiarowych na SFTP chcielibyśmy zwrócić uwagę na dwie rzeczy: dotychczasowe pomiary udostępniane były z dokładnością co do godziny, aktualnie godziny nie są już udostępniane. Czy mogą Państwo nadal podawać pomiar wraz z datą oraz godziną? W plikach XML podawany jest pełny numer punktu poboru natomiast w CSV są skrócone. Prosimy o stosowanie w obu przypadkach pełnych numerów.

Uprzejmie informuję, iż pomiary z dokładnością co do godziny są udostępniane dla punktów WR, natomiast w plikach pomiarowo-odczytowych, dotyczących punktów WS zdefiniowana jest data odczytu w formacie dd.mm.rrrr. Konwersja danych spowodowała usunięcie dwóch pierwszych zer z obszaru Tarnów. Nie było zmiany numeracji.

Co do udostępniania danych pomiarowych na SFTP możemy się zgodzić tylko dla odczytów WS, które są udostępniane. Jeżeli chodzi o dane odczytowe WR, proszę o dalsze przesyłanie ich drogą mailową, gdyż w dalszym ciągu nie otrzymaliśmy odpowiedzi od zespołu zajmującego się standardem EDIFACT i nie możemy kontynuować rozwoju implementacji danych w tym standardzie. Chcielibyśmy również zacząć pracę przynajmniej w zakresie wymiany danych pomiarowych, w oparciu o serwer SFTP.

Potwierdzamy informację, iż udostępnienie danych pomiarowych na serwerze SFTP, dotyczy wyłącznie punktów WS. Przejście na komunikację za pośrednictwem usługi SFTP dla punktów WR, będzie możliwe dopiero po pozytywnym zakończeniu wdrożenia procesu dla punktów WS.

Brak OBIS – wg nas kod OBIS powinien zawsze znajdować się w danych lub jeśli będą występować pliki bez kodu OBIS to czy na sztywno zapisywać dane jako m3 gazu.

W komunikacie brakuje kodu OBIS, który powinien być zawarty w brakującej linii 7-B:3.0.0 . W tym przypadku jest to kod właściwy dla stanu gazomierza wyrażony w m3 w warunkach rzeczywistych.

Błąd zostanie przeanalizowany i poprawiony.

Założenie licznika bez taryfy – wg nas taryfa jest zawsze wymagana do założenia Mdm i powinna być w pliku

Z załączonego przykładu wynika, że komunikat został wysłany z obszaru tarnowskiego  i dotyczy PoD typu WS.

Nie jest to komunikat związany z montażem gazomierza, a z identyfikatorów COS_SMV_MMR wynika, że stan początkowy gazomierza został odczytany przez PSG z gazomierza przy zmianie sprzedawcy lub uruchomieniu dostaw bez wcześniejszego demontażu gazomierza.

 

Grupa taryfowa może być wskazana w komunikacie MSCONS:

 

SG10 STS

Status informacji / taryfy

Powinno(1)

Powinno (1)

 

SG10 STS 9015

6 - Umowa

 

X

(1) Pod warunkiem, że status i informacje o taryfie są dostępne

SG10 STS 4405

108 - Plan taryf

 

X

 

SG10 STS 1131

W-1.1
W-1.2
W-2.2
W-3.6
W-3.9
W-4

 

X

(1) Kiedy SG10-STS+6 i taryfa jest określona

 

W przypadku montażu gazomierza (nie dotyczy wymiany gazomierza)  identyfikatory w komunikacie MSCONS opisałyby charakter odczytu następująco: IOM_SMV_MMR.

Kiedy PSG zamierza rozpocząć testy komunikacji EDIFACT i w jaki sposób ZUD zostaną o tym poinformowane?

Testy komunikacji Edifakt odbywać się będą zgodnie z załączonym poniżej harmonogramem.

PSG, zgodnie z odpowiedzią na kolejne pytanie, planuje organizować cykliczne spotkania z ZUD, dodatkowo wszelkie informacje, w tym instrukcje techniczne, zamieszczane będą na stronie internetowej PSG.

 

L.p.

Rodzaj zadania

Opis zdania

Data rozpoczęcia

1.

Testy ZUD - Obsługa PZD i rozliczanie usługi dystrybucyjnej – I tura testów

Realizacja testów w obszarze rozliczania usługi dystrybucyjnej z ZUD zgłoszonymi do testów w I turze testów

Styczeń 2019

2.

Testy ZUD– Dane pomiarowe II tura testów

Realizacja testów w obszarze danych pomiarowych z ZUD zgłoszonymi do testów w II turze testów

Luty 2019

3.

Testy ZUD– Obsługa PZD i rozliczanie usługi dystrybucyjnej – II tura testów

Realizacja testów w obszarze rozliczania usługi dystrybucyjnej z ZUD zgłoszonymi do testów w II turze testów

Luty 2019

4.

Testy ZUD– Dane pomiarowe III tura testów

Realizacja testów w obszarze danych pomiarowych z ZUD zgłoszonymi do testów w III turze testów

Marzec 2019

5.

Testy ZUD– Obsługa PZD i rozliczanie usługi dystrybucyjnej – III tura testów

Realizacja testów w obszarze rozliczania usługi dystrybucyjnej z ZUD zgłoszonymi do testów w III turze testów

Marzec 2019

6.

Opis standardu wymiany danych drogą elektroniczną pomiędzy PSG a innymi uczestnikami rynku

Opis specyfikacji technicznej standardu Edifact

Kwiecień 2019

7.

Standaryzacja wersji Edifact w systemach billingowych

Wdrożenie rozbudowy komunikatów w systemach billingowych PSG

Maj 2019

8.

Testy końcowe

Końcowe testy zatwierdzające wdrożone rozwiązania rozbudowy i integracji standardu Edifact

Lipiec 2019

9.

Start produkcyjny

Uruchomienie produkcyjne komunikacji w zaktualizowanym standardzie Edifact z ZUD, które zrealizowały testy i potwierdziły gotowość uruchomienia produkcyjnego

Wrzesień 2019

Czy PSG planuje kolejne spotkania z ZUD dotyczące elektronicznej wymiany danych i informacji i czy przewiduje udział w nim wykonawców systemów IT po stronie ZUD?

PSG sp. z o.o. planuje cykliczne spotkania z ZUD. Spotkania odbywać się będą zgodnie z postępem prac, ale nie rzadziej niż co sześć miesięcy. Spotkania wykonawców systemów IT po stronie PSG i ZUD odbywać się będą z uwzględnieniem potrzeb.

Czy PSG udostępni dwa kanały informacji dla ZUD, tj, EDIFACT i e-BOK (dot. obsługi PZD), szczególnie na potrzeby nieprzerwanej obsługi PZD w przypadku awarii kanału EDIFACT?

Obsługa PZD będzie miała zabezpieczony alternatywny sposób komunikacji z ZUD w przypadku awarii kanału EDIFACT. Dotyczy to szczególnie komunikatów związanych z przekazywaniem danych odczytowych (komunikat MSCONS). W przypadku serwisu e-BOK, do czasu pełnej konsolidacji systemów po stronie PSG, system ten będzie obsługiwał część obszarów taryfowych, obsługiwanych przez PSG.

Czy PSG planuje przełączyć komunikaty edig@s dot. nominacji na bezpieczny protokół transmisji AS4?

PSG sp. z o.o. dopuszcza wymianę komunikatów z ZUD alternatywnie, za pomocą protokołów: AS4 i SSL (TLS 1.2).

Jakie różnice wystąpią pomiędzy standardem EDIFACT 1.0 i EDIFACT 1.1, oraz czy zostanie zachowana kompatybilność tych standardów?

Kompatybilność standardów zostanie zachowana. Różnice wynikają głownie z uzupełnienia standardu o komunikat INVOIC oraz o informacje uzupełniające w sposób jednoznaczny interpretację protokołu.

Czy testami protokołu EDIFAKT będą objęte wszystkie komunikaty (MSCONS, UTILMD, INVOIC), czy też PSG rozpocznie testowanie od komunikatu MSCONS – dane odczytowo-pomiarowe?

Zakres i harmonogram testów poszczególnych przypadków użycia, ze względu na udział w testach kilku ZUD, będzie omawiany i uzgadniany na spotkaniu z ZUD (FAQ1 i FAQ 2).

Jak długo przechowywana jest historia operatywnych danych pomiarowych?

Użytkownik posiada dostęp do historycznych danych pomiarowych za ostatni miesiąc.

Czy PSG pracuje nad poprawą jakości danych „śróddziennych”, szczególnie dot. to operatywnych danych pomiarowych?

PSG od momentu wdrożenia centralnego systemu rozliczenia odbiorców WR prowadzi działania mające na celu poprawę jakości oraz dostępności danych operatywnych. Poprawiono wydajność systemu oraz zwiększono częstotliwość prezentowania danych. Obecnie dane dostępne są za ok. 4 godziny wstecz. Informacje na temat błędów lub problemów z portalem eBOK przekazywane przez użytkowników są poddawane analizie i na jej podstawie wdrażane są działania zaradcze. Analizowane są również inne sposoby udostępniania danych, które uzależnione są od możliwości technicznych systemów IT wykorzystywanych w PSG jak i planów rozwoju tych systemów.

Czy odbiorcy końcowi mogą wnioskować o dostęp do historycznych danych operatywnych?

Tak, o dostęp do danych operatywnych mogą wnioskować odbiorcy z grup taryfowych typu WR. Odbiorcy końcowi mogą wnioskować o dostęp do operatywnych danych pomiarowych na podstawie "Regulaminu zdalnego udostępniania danych pomiarowych" dostępnego na stronie internetowej PSG.

Czy wykonana analiza porównawcza metody temperaturowej i SLP w zakresie szacowania usługi dystrybucyjnej wykazała, że w określonych miesiącach zastosowanie SLP jest niekorzystne w porównaniu do dotychczas stosowanej metody szacowania?

W porównywanym okresie 2017 roku, nie zaobserwowano takich wyników porównania. Przeprowadzona przez PSG symulacja rozliczenia usługi dystrybucyjnej punktów WS dla zabrzańskiego obszaru taryfowego na całym 2017 r. (1,3 mln odbiorców) wykazuje poprawę dokładności szacowania z uwagi na zmniejszenie wielkości rocznej różnicy bilansowej o 0,5 punktu procentowego. Zmniejszeniu, w stosunku do obecnie stosowanej metody temperaturowej, ulega też wielkość różnicy bilansowej - straty lub superaty - w poszczególnych okresach miesięcznych roku 2017. Jeżeli chodzi o stratę, to zmiany są rzędu od 1 do 5 punktów procentowych w okresie zimowym, w przypadku superaty występującej okresie letnim zmiany są od 0,5 do 10 punktów procentowych. Powoduje to, że przy zastosowaniu metody SLP zmniejszeniu powinien ulec wolumen gazu rozliczanego w ramach bilansowania handlowego systemu dystrybucyjnego pomiędzy ZUD i PSG w poszczególnych miesiącach oraz zmniejszeniu powinno ulec saldo tych rozliczeń (gaz przekazany minus gaz odebrany ) w okresie całego roku. Metoda szacowania oparta o profile SLP jest w większym stopniu oparta o dobowe rzeczywiste wartości temperatur, w szacowaniu jest uwzględniany również wpływ dni tygodnia i dni wolnych od pracy. Powoduje to, że metoda szacowania SLP lepiej oddaje rzeczywiste zużycie odbiorcy.

Czy harmonogram wdrożenia komunikatu EDIFACT jest zatwierdzony?

Tak, został opublikowany w FAQ w pytaniu: Kiedy PSG zamierza rozpocząć testy komunikacji EDIFACT i w jaki sposób ZUD zostaną o tym poinformowane?

Czy jest możliwość zmiany/przyspieszenia ww. harmonogramu?

Jak będzie taka możliwość, to poinformujemy o tym.

Na ile dane przekazywane przez EDIFACT są wiarygodne?

Dane są pobierane z tego samego źródła, dlatego też powinny być tożsame z danymi pozyskiwanymi przy wykorzystaniu innych metod.

Dlaczego nastąpiła zmiana harmonogramu wdrożenia komunikatu EDIFACT deklarowanego przez IT na ostatnim spotkaniu?

Zmiana wynika z potrzeby wypracowania wspólnego harmonogramu z ZUD-ami, ze względu na zakres. Wypracowany wspólny harmonogram poprzedzony będzie ankietą skierowaną do ZUD.

Jak rozumieć/ interpretować wartość ciepła spalania w strukturze komunikatu MSCONS (przypisana wartość do konkretnej daty)?

a) W przypadku odbiorców z grupy WS współczynnik konwersji odnosi się do okresu rozliczeniowego wskazanego w komunikacie. Okres rozliczeniowy określony jest w komunikacie datą początkowa oraz data końcową. b) W przypadku odbiorców z grupy WR, mimo przypisania współczynnika konwersji do konkretnej godziny, należy przyjąć, że odnosi się on do całego okresu rozliczeniowego.

Prośba o wskazanie adresu, na który należy zgłaszać zainteresowanie testami SFTP.

edifact@psgaz.pl

Czy po uruchomieniu SFTP, dane odczytowe będą również przekazywane drogą mailową (dot. obszaru taryfowego Gdańsk, Tarnów i Zabrze)?

Tylko w okresie przejściowym, o którym PSG poinformuje w odrębnym trybie. Docelowo dane te będą udostępniane tylko na SFTP lub przekazywane w formie komunikatu MSCONS pomiędzy systemami PSG i ZUD.

Czy odbiorcy zakwalifikowani do 4. grupy taryfowej przejdą do WR?

Odbiorcy zakwalifikowani do 4. grupy taryfowej nie będą kwalifikowani jako WR.

Czy jest możliwość informowania w eBOKu o brakujących danych?

Ze względu na dużą ilość źródeł danych (tysiące urządzeń pomiarowych), w wyniku codziennej eksploatacji nie jesteśmy w stanie zagwarantować ich 100% dostępności (bezawaryjnej pracy). Podjęliśmy działania zmierzające do wypracowania procedury pozwalającej przesłać do ZUD oczekiwane informacje.

Z czego wynikają rozbieżności pomiędzy ciągiem rozliczeniowym a pkt. poboru?

Rozbieżność pomiędzy PoD punktu poboru, a PoD ciągu rozliczeniowego wynika z przyjętego w PSG rozwiązania systemowego. W przypadku układów wielociągowych lub punktów, w których zawierane są umowy krótkookresowe PSG tworzy na potrzeby obsługi takich punktów PoD, w ramach których prowadzone są rozliczenia. Dane operatywne dostępne są z poziomu poszczególnych ciągów dlatego w eBOK prezentowane są obok PoD punktu poboru, PoD poszczególnych ciągów pomiarowych.