Regional Booking Platform Webservice szolgáltatás illeszkedési felület dokumentáció

Regional Booking Platform Webservice szolgáltatás illeszkedési felület dokumentáció 4.2 verzió

Készítette: IP Rendszerintegrátor Kft.

Tartalomjegyzék 1. A dokumentum célja................................................................................................................. 4 2. Bevezetés ................................................................................................................................. 5 3. Fogalomtár ............................................................................................................................... 6 3.1. Hálózati infrastruktúra .................................................................................................................. 6 3.2. Szereplők....................................................................................................................................... 7 4. Alapelvek ................................................................................................................................. 8 4.1. Koncepció...................................................................................................................................... 8 4.2. Műszaki informatikai megvalósításra vonatkozó alapelvek ......................................................... 9 4.2.1 Rendelkezésre állás ................................................................................................................. 9 4.2.2 A regional booking platform elérhetősége ............................................................................. 9 4.2.3 Azonosítás, tanúsítványok ...................................................................................................... 9 4.2.4 Alkalmazott protokollok, kódolás ........................................................................................... 9 4.2.5 Üzenetek érvényessége – validálás....................................................................................... 10 4.2.6 Archiválás .............................................................................................................................. 10 5. Ajánlatadás ............................................................................................................................ 11 5.1. Aukció adatok lekérdezése (getAuctions)................................................................................... 11 5.1.1 A kérést tartalmazó üzenet ................................................................................................... 12 5.1.2 A választ tartalmazó üzenet .................................................................................................. 12 5.2. Tömeges ajánlat beadás (bulkMakeBids) ................................................................................... 17 5.2.1 A kérést tartalmazó üzenet ................................................................................................... 21 5.2.2 A választ tartalmazó üzenet .................................................................................................. 22 5.3. UPTA ajánlatok törlése (bulkRemoveUptaBids) ......................................................................... 23 5.3.1 A kérést tartalmazó üzenet ................................................................................................... 26 5.3.2 A választ tartalmazó üzenet .................................................................................................. 26 6. Web service kommunikáció az RBP és a TSO Tag között ........................................................... 28 6.1. Tarifa és áradatok küldése IP-ből RBP-be ................................................................................... 28 6.2. RBP aukciók eredményeinek importja........................................................................................ 33 7. Bilaterális kapacitás átadás ..................................................................................................... 40 7.1. Bilaterális ajánlat beadás (OfferBilateralCapacity) ..................................................................... 40 7.1.1 A kérést tartalmazó üzenet ................................................................................................... 43 7.1.2 A választ tartalmazó üzenet .................................................................................................. 44 7.2. Bilaterális kapacitás átadások lekérdezése üzemeltetők számára (GetBilateralOffersByTso) ... 45

Gázipari Kommunikációs Szabvány

7.2.1 A kérést tartalmazó üzenet ................................................................................................... 46 7.2.2 A választ tartalmazó üzenet .................................................................................................. 47 7.3. Bilaterális kapacitás átadások lekérdezése az átadó számára (GetBilateralOffersBySeller) ...... 50 7.3.1 A kérést tartalmazó üzenet ................................................................................................... 51 7.3.2 A választ tartalmazó üzenet .................................................................................................. 52 7.4. Bilaterális kapacitás átadások lekérdezése az átvevő számára (GetBilateralOffersByBuyer) .... 55 7.4.1 A kérést tartalmazó üzenet ................................................................................................... 56 7.4.2 A választ tartalmazó üzenet .................................................................................................. 57 7.5. Bilaterális kapacitás átadás elutasítása üzemeltetők számára (RefuseBilateralOfferByTso) ..... 60 7.5.1 A kérést tartalmazó üzenet ................................................................................................... 63 7.5.2 A választ tartalmazó üzenet .................................................................................................. 63 7.6. Bilaterális kapacitás átadás jóváhagyása üzemeltetők számára (ApproveBilateralOfferByTso) 64 7.6.1 A kérést tartalmazó üzenet ................................................................................................... 67 7.6.2 A választ tartalmazó üzenet .................................................................................................. 67 7.7. Bilaterális kapacitás átadás visszavonása az átadó számára (RevokeBilateralOfferBySeller) .... 68 7.7.1 A kérést tartalmazó üzenet ................................................................................................... 70 7.7.2 A választ tartalmazó üzenet .................................................................................................. 70 7.8. Bilaterális kapacitás átadás visszautasítása az átvevő számára (RejectBilateralOfferByBuyer) . 71 7.8.1 A kérést tartalmazó üzenet ................................................................................................... 74 7.8.2 A választ tartalmazó üzenet .................................................................................................. 76 7.9. Bilaterális kapacitás átadás jóváhagyása átvevők számára (ApproveBilateralOfferByBuyer).... 76 7.9.1 A kérést tartalmazó üzenet ................................................................................................... 79 7.9.2 A választ tartalmazó üzenet .................................................................................................. 79 7.10. Bilaterális kapacitás átadás lezárás üzemeltetők számára (CloseBilateralOfferByTso)............ 80 7.10.1 A kérést tartalmazó üzenet ................................................................................................. 82 7.10.2 A választ tartalmazó üzenet ................................................................................................ 82


1. A DOKUMENTUM CÉLJA Jelen dokumentumnak az a célja, hogy a rendszerirányítói engedélyes (FGSZ) és együttműködő partnerei, azaz a •

RBP TSO Tagjai,

•

RBP Rendszerhasználói Tagjai

közötti, az operatív üzletmenet során alkalmazható, szerver-szerver kommunikáció alapelveit rögzítse, és üzenetformátumait definiálja.


2. BEVEZETÉS A gáziparban a gyakorlati üzletmenet során intenzív, informatikai úton folytatott kommunikáció zajlik az egyes gázipari szereplők között. Jellegzetes példaként ide sorolható a nominálás, az allokálás, a mérési adatok szolgáltatásának területe – vonatkozzon az akár földgázszállítói, akár elosztói, akár tárolói rendszerre, és legyen az abban érintett akár rendszerhasználó, akár rendszerüzemeltető. Jelenleg az üzenetváltások jelentős része E-mail-en, illetve Excel állományok cseréje révén valósul meg, amely nagyobb adatmennyiségek esetén általában mind a küldő, mind a fogadó részére kevéssé hatékony megoldásnak bizonyul. Mind a rendszerüzemeltetők, mind a rendszerhasználók számára kedvezőbb, és számottevően hatékonyabb, ha a mindennapi üzletmenet során váltott üzenetek cseréje a partnerek informatikai platformjai között közvetlenül, önműködően, és érdemi emberi közreműködést nélkülöző módon valósul meg. Ezáltal sokkal nagyobb tömegű adat konzisztens, és akár sűrűbb cseréje válik lehetővé. Jelen leírás a földgázszállítási és rendszerirányítási engedélyes és partnerei közötti, szerver-szerver alapú kommunikáció formáját hivatott meghatározni. A kommunikáció kétoldalú jellege miatt a dokumentum is kettős, az FGSZ és Partnerei közötti üzenetváltások leképezése érdekében. A további fejezetekben előbb az alapfogalmak, majd a koncepció, az általános alapelvek, végül az egyes konkrét üzenetformátumok ismertetésére kerül sor.


3. FOGALOMTÁR 3.1. HÁLÓZATI INFRASTRUKTÚRA RBP

A Regional Booking Platform olyan elektronikus kapacitás kereskedelmi platform, amely kapacitáslekötési platformként megfelel a földgázellátásról szóló 2008. évi XL törvénynek valamint a 984/2013/EU számú Bizottsági rendeletnek. Az RBP Alkalmazás és RBP Portál együttesen alkotja a Regional Booking Platformot.

Kapacitás

Valamely földgáz-szállító hálózati (akár absztakt) elem földgázáteresztő képessége, azaz azon tulajdonsága, hogy egységnyi időtartam alatt milyen mennyiségű földgáz kibocsátására képes. Alkalmazott mértékegysége a kW/h és kWh/nap. Az elszámolásra használt mértékegység a TSO Tag és Rendszerhasználó Tag által és köztük megkötött szerződésben van kikötve. A szerződés az adatokat mindkét módon kifejezve tartalmazza

Ascending Clock (ACTA) aukció

Az emelkedőáras aukció olyan aukció, amelyben a rendszerhasználó sorrendben bejelentett, meghatározott árlépcsők szerint igényel mennyiségeket.

Uniform Price (UPTA) aukció

Az egyenáras aukció során a rendszerhasználó egy egykörös ajánlattételi kör során mind mennyiségi mind árra vonatkozó ajánlatokat ad be, és minden rendszerhasználó, aki elnyer kapacitást, a legalacsonyabb sikeres ajánlat árát fizeti meg.

Large Price Step (LPS)

A nagy árlépcső olyan rögzített vagy változó összeg, amely rendszerösszekötési pontonként és szabványos kapacitástermékekként van meghatározva.

Small Price Step (SPS)

A kis árlépcső olyan rögzített vagy változó összeg, amely rendszerösszekötési pontonként és szabványos kapacitástermékenként van meghatározva, és amely kisebb, mint a nagy árlépcső.


3.2. SZEREPLŐK Szállítási rendszerüzemeltető tag (TSO Tag)

Olyan szállítási rendszerüzemeltető, aki az RBP-n keresztül allokál és köt szerződéseket kapacitásokra, valamint igénybe vesz más kínált szolgáltatásokat is. Az FGSZ Zrt. önmagában is egy RBP TSO Tag.

Rendszerhasználó Tag (NU Tag)

Az RBP-re a platformon allokált kapacitás lekötés, átruházás vagy szerződéskötés, valamint egyéb kínált szolgáltatás igénybe vételének céljából regisztrált természetes vagy jogi személy.

Regional Booking Platform Üzemeltető (RBP Üzemeltető)

A Regional Booking Platformot üzemeltető jogi szeméy, amely az FGSZ Földgázszállító Zártkörűen Működő Részvénytársaság (FGSZ).


4. ALAPELVEK 4.1. KONCEPCIÓ Jelen specifikáció két fél, mint gázipari szereplő informatikai platformja közötti kommunikáció formáját rögzíti. Mint az 1. ábra mutatja, ebből a szempontból a küldő és a fogadó szerepben levő informatikai platform közötti különbségtételre kerül sor.

1. ÁBRA: A KÜLDŐ ÉS A FOGADÓ INFORMATIKAI PLATFORM EGYÜTTMŰKÖDÉSE

Azt, hogy melyik engedélyes informatikai platformja tölti be a küldő ill. fogadó szerepet, az adott üzleti tevékenység határozza meg. Az egyes üzenetformátumok leírásánál található „Szereplők, szerepkörök” rovatban mindig egyértelműen rögzített, hogy a küldő ill. fogadó szerepét mely engedélyes informatikai rendszere tölti be. Jelen specifikáció alapkoncepciója, hogy minden esetben a küldő fél egy kérést tartalmazó üzenetet küld a másik, fogadó félnek. A fogadó fél a kapott üzenetet feldolgozza, majd annak eredményét a válaszban a küldőnek eljuttatja. Minden egyes üzleti tevékenység esetén meghatározott, hogy a kérésnek és a válasznak milyen struktúrában milyen adatokat kell tartalmaznia.

Műszaki megvalósítást tekintve a specifikáció alapkoncepcióját a 2. ábra mutatja.

2. ÁBRA: A SPECIFIKÁCIÓ MŰSZAKI INFORMATIKAI ALAPKONCEPCIÓJA

A fogadó informatikai platformnak tehát egy HTTPS-en keresztül elérendő web service-es felületet kell biztosítania. Az üzenetváltások SOAP-on keresztül, XML üzenetek formájában valósulnak meg. A fogadó a küldő számára a választ minden esetben a web service visszatérési értékében nyújtja. Mind


az idevágó szabványokat, mind a web service-ek leírását, mind az alkalmazandó XML üzenetstruktúrákat jelen dokumentum rögzíti.

4.2. MŰSZAKI INFORMATIKAI MEGVALÓSÍTÁSRA VONATKOZÓ ALAPELVEK 4.2.1 RENDELKEZÉSRE ÁLLÁS Valamennyi engedélyesnek 7x24 órás rendelkezésre állású szervert kell üzemeltetnie a kölcsönös kommunikáció folytatása érdekében. Ezen a szerveren kell elérhetőnek lennie azon webszolgáltatásnak, amely a kommunikációt lehetővé teszi.

4.2.2 A REGIONAL BOOKING PLATFORM ELÉRHETŐSÉGE A szolgáltatás igénybevételének alapfeltétele, hogy az engedélyes megküldje a rendszerirányítónak azon kiszolgálója címét, amelyen a rendszerirányító által elvárt SOAP interfész elérhető. A teszt szerver SOAP interfészének elérhetősége: https://rbp.test.fgsz.hu/RBP/services/ Itt található minden elérhető szolgáltatás. A szolgáltatások leírása a kívánt szolgáltatás kiválasztásával érhető el. Az éles – produktív – szerver SOAP interfészének elérhetősége: https://rbp.fgsz.hu/services/ Itt található minden elérhető szolgáltatás. A szolgáltatások leírása a kívánt szolgáltatás kiválasztásával érhető el. Amennyiben az éles környezet a fenti címen nem elérhető, mert az RBP a tartalék környezetben üzemel, akkor a következő címen érhető el: https://rbp.standby.fgsz.hu/services/ Itt található minden elérhető szolgáltatás. A szolgáltatások leírása a kívánt szolgáltatás kiválasztásával érhető el. A web service elkészítését követően javasoljuk a kliens oldali program elkészítését úgy, hogy paraméterezhetően, vagy akár automatikusan át tudjon állni a tartalék RBP (rbp.standby.fgsz.hu) hívására, ha az éles környezet (eip.fgsz.hu) nem elérhető.

4.2.3 AZONOSÍTÁS, TANÚSÍTVÁNYOK A web service-ek alkalmazása során tanúsítvány-alapú azonosítás történik, azaz: •

az FGSZ informatikai platformjára minden partner csak az azon alkalmazott tanúsítvánnyal küldhet üzenetet

4.2.4 ALKALMAZOTT PROTOKOLLOK, KÓDOLÁS • • •

A kommunikáció HTTPS protokollon zajlik, melyen keresztül XML (1.0 – ötödik kiadás, http://www.w3.org/TR/xml/) üzenetek cseréjére kerül sor A web szolgáltatások hívása minden esetben szinkron módon történik Szabványok:


•

o UTF-8 : http://www.ietf.org/rfc/rfc2279.txt o HTTPS: http://tools.ietf.org/html/rfc2818 o SOAP: http://tools.ietf.org/html/rfc3288 XML Séma leírók elérhetősége o xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" o xmlns:xsd=”http://www.w3.org/2001/XMLSchema” o xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

4.2.5 ÜZENETEK ÉRVÉNYESSÉGE – VALIDÁLÁS Egy üzenet minden esetben akkor, és csak akkor minősül érvényesnek, ha a jelen specifikációban rögzített formai és tartalmi követelményeknek eleget tesz. (Amennyiben tehát egy üzenet nem felel meg a formai és tartalmi követelményeknek, a fogadó visszautasítja azt.) Formai követelmény pl., hogy a tárgy gáznap formátum az xsd:DateTime-nak feleljen meg. Ez azt jelenti, hogy az engedélyesek informatikai platformjai kölcsönösen akkor és csak akkor fogadják el a tárgy gáznapot tartalmazó mezőket (és ily módon üzeneteket), ha ennek a formátumnak eleget tesznek. Tartalmi követelményt tekintve bizonyos mezők csak bizonyos értékeket vehetnek fel. Jellegzetesen a gázmennyiségek meghatározásánál jelen specifikáció csak a kWh-ban megadott mennyiségeket tartja elfogadottnak – más mértékegység használata jelenleg tehát nem értelmezett. Megjegyzendő, hogy az ilyen jellegű tartalmi megkötések a jelen specifikációhoz tartozó XML sémákban is megjelennek, amelyeknek az üzeneteknek eleget kell tenniük.

4.2.6 ARCHIVÁLÁS Az RBP Üzemeltető 5 évre archiválja a web service üzeneteket.


5. AJÁNLATADÁS 5.1. AUKCIÓ ADATOK LEKÉRDEZÉSE (GETAUCTIONS) ÜZLETI CÉL, KÖRNYEZET Ez a szolgáltatás azon felhasználók által használható, amelyeknek joguk van ajánlatokat beadni. Ennek a szolgáltatásnak a segítségével az összes futó aukció lekérdezhető, de csak érvényes tanúsítvánnyal vehető igénybe. A válaszüzenetben a Rendszerhasználó Tag beadhat ajánlatot az ACTA és UPTA aukciókra. Ha még nincs beadott ajánlat, akkor egy üres ajánlat jelenik meg azért, hogy a Rendszerhasználó Tag láthassa az aukció paramétereit. LEÍRÁS Annak érdekében, hogy ajánlatot tudjon beadni, a Rendszerhasználó tagnak rendelkeznie kell az összes információval az aukciókról, amikben részt vesz. A szolgáltatás válaszüzenetében minden olyan információ rendelkezésre áll, aminek segítségével érvényes ajánlatot lehet beadni. A szolgáltatás csak érvényes tanúsítvánnyal vehető igénybe és a tanúsítvány tulajdonosának rendelkeznie kell ajánlattételi joggal. Ezek hiányában a szolgáltatáshoz való hozzáférés megtagadásra kerül. A válaszüzenetnek csak azon aukciók és ajánlatok lesznek a részei, melyekben a felhasználó részt vesz, és amelyek már elindultak, de még nem zárultak le és nincsenek két ajánlattételi kör között. Az aukciókat aukció névvel azonosítjuk. SZEREPLŐK, SZEREPKÖRÖK • • • •

A kérés küldője: Rendszerhasználó Tag A kérés fogadója: RBP Üzemeltető A válasz küldője: RBP Üzemeltető (FGSZ) A válasz fogadója: Rendszerhasználó Tag

ÜTEMEZÉS, HATÁRIDŐK A határidők az aukcióban definiált szabályok szerint alakulnak. A válaszüzenet kizárólag azokat az aukciókat tartalmazza, amelyek nyitva állnak az ajánlatok befogadására. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK A web service kizárólag érvényes tanúsítvánnyal vehető igénybe. A tanúsítvány tulajdonosának rendelkeznie kell ajánlatbeadó jogosultsággal. Ezek hiányában a hozzáférés megtagadásra kerül.


5.1.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS getAuctions STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt. MEZŐK A kérés nem tartalmaz információt, mivel a tanúsítvány alapján azonosítunk. PÉLDA <request/>

5.1.2 A VÁLASZT TARTALMAZÓ ÜZENET LEÍRÁS A válaszüzenet tartalmaz minden nyitott aukciót, és a Rendszerhasználó által korábban beadott összes ajánlatot. LOGIKAI SZERKEZET A válaszüzenet logikai felépítése az alábbi: •

•

Hibaüzenet-sorok az alábbiak szerint: o Hibakód o Hibaüzenet ACTA ajánlatok o Aukció név o Hálózati pont neve o Hálózati pont EIC kódja o Termék típus (éves, negyedéves, havi, napi, napon belüli, STRIP) o Termék név (vonatkozási időszak) o Megszakíthatóság (megszakítható, nem megszakítható) o Kapacitás típus (kapcsolt, nem kapcsolt) o Aukció iránya (direkt, vissza) o Áramlási irány (fizikai, backhaul) o Szabványos kapacitástermék (szabványos, nem szabványos, szezonális) o Kiinduló ár (devizával együtt) o Felajánlott kapacitás


•

o LPS o SPS o Aktuális árlépcső százalékban o Igényelt mennyiség UPTA ajánlatok o Aukció név o Hálózati pont neve o Hálózati pont EIC kódja o Termék típus (éves, negyedéves, havi, napi, napon belüli, STRIP) o Termék név (vonatkozási időszak) o Megszakíthatóság (megszakítható, nem megszakítható) o Kapacitás típus (kapcsolt, nem kapcsolt) o Aukció iránya (direkt, vissza) o Áramlási irány (fizikai, backhaul) o Szabványos kapacitástermék (szabványos, nem szabványos, szezonális) o Kiinduló ár (devizával együtt) o Felajánlott kapacitás o Ajánlott ár o Igényelt mennyiség o Igényelt minimum mennyiség


MEZŐK Megnevezés

Leírás

Aukció név

Egy 8 jegyú karaktersorozat, auctionName ami az aukció egyértelmű azonosítására szolgál.

Hálózati neve

XML címkenév

pont A hálózati pont neve

Formátum / típus String

capacityPointName String

Hálózati pont EIC A hálózati pont EIC kódja kódja

eic

String

Termék típus

Éves, negyedéves, havi, napi, prodctType napon belüli, STRIP

YEARLY, QUARTERLY MONTHLY, DAILY, WITHINDAY, STRIP

Termék név

Vonatkozási időszak

String

Megszakíthatóság Megszakítható, megszakítható

productName nem productQuality

FIRM, INTERRUPTIBLE

Kapacitás típus

Kapcsolt, nem kapcsolt

capacityType

BUNDLED, UNBUNDLED

Aukció iránya

Direkt, vissza

direction

DIRECT, REVERSE

Áramlási irány

Fizikai, Backhaul

gasFlow

PHYSICAL, BACKHAUL

Szabványos kapacitástermék

Szabványos, nem szabványos, standard szezonális

STANDARD, NON_STANDARD, NON_STANDARDSEASONAL

Kiinduló ár

A kiinduló ár devizával együtt

reservePrice

String

Felajánlott kapacitás

Az aukción felajánlott kapacitás

capacityOffered

Integer

Aktuális (ACTA)

LPS Aktuális nagy árlépcső

lps

Integer

Aktuális (ACTA)

SPS Aktuális kis árlépcső

sps

Integer


Megnevezés

Leírás

XML címkenév

Formátum / típus

Aktuális árlépcső A kiinduló árhoz viszonyított priceStep százalék (ACTA) százalék

Integer

Igényelt mennyiség (ACTA)

Integer

Ajánlott (UPTA)

Az ajánlatban mennyiség

igényelt quantity

ár Az egységár amennyit igényelt mennyiségért fizet

az price

Integer

Igényelt mennyiség (UPTA)

Az ajánlatban mennyiség

igényelt bidQuantity

Integer

Minimum mennyiség (UPTA)

Az amennyiség, amennyinél minQuantity kevesebbet már nem szeretne vásárolni az ajánlattevő

Integer

PÉLDA 00001016 Érsekvadkert <eic>39ZVEERSEKV11GNI <productType>MONTHLY <productName>2015.06 <productQuality>FIRM UNBUNDLED DIRECT PHYSICAL <standard>STANDARD 100.0000 HUF 10000 0 <sps>0 <priceStep>0 9700 Gázipari Kommunikációs Szabvány

00001016 Érsekvadkert <eic>39ZVEERSEKV11GNI <productType>MONTHLY <productName>2015.06 <productQuality>FIRM UNBUNDLED DIRECT PHYSICAL <standard>STANDARD 100.0000 HUF 10000 1 <sps>0 <priceStep>10 6000 00001016 Érsekvadkert <eic>39ZVEERSEKV11GNI <productType>MONTHLY <productName>2015.06 <productQuality>FIRM UNBUNDLED DIRECT PHYSICAL <standard>STANDARD 100.0000 HUF 10000 2 <sps>0 <priceStep>20 5000 00001017 Fót <eic>39ZVEFOT00011GNM <productType>DAILY <productName>2015.06.01


<productQuality>FIRM UNBUNDLED DIRECT PHYSICAL <standard>STANDARD 100.0000 HUF 10000 <price>5000 1000 <minQuantity>800 00001018 Gyál <eic>39ZVEGYAL0011GNP <productType>DAILY <productName>2015.06.01 <productQuality>FIRM UNBUNDLED DIRECT PHYSICAL <standard>STANDARD 100.0000 HUF 10000 <price>5000 1000 <minQuantity>800

5.2. TÖMEGES AJÁNLAT BEADÁS (BULKMAKEBIDS) ÜZLETI CÉL, KÖRNYEZET A szolgáltatás segítségével a meghatalmazott felhasználók ajánlatokat adhatnak be. LEÍRÁS A felhasználó ajánlatot tud tenni egy, vagy több futó aukció aktuális körében. A szolgáltatás célja egyrészt, hogy a manuális módszernél gyorsabban lehessen ajánlatot beadni, másrészt az ember által elkövethető hibák minimalizálása Gázipari Kommunikációs Szabvány

SZEREPLŐK, SZEREPKÖRÖK • • • •

A kérés küldője: Rendszerhasználó Tag A kérés fogadója: RBP Üzemeltető A válasz küldője: RBP Üzemeltető A válasz fogadója: Rendszerhasználó Tag

ÜTEMEZÉS, HATÁRIDŐK A határidők az aukcióban definiált szabályok szerint alakulnak. Ajánlatokat kizárólag abban az időintervallumban fogadunk be, amikor az aukció nyitva áll az ajánlatok befogadására. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK A webszeríz kizárólag érvényes tanúsítvánnyal vehető igénybe.. A tanúsítvány tulajdonosának rendelkeznie kell ajánlatadó jogosultsággal. Ezek hiányában a hozzáférés megtagadásra kerül. Ezen kívül csak olyan aukcióra fogadunk be ajánlatot, amire a felhasználó által helyettesített Rendszerhasználó Tag meghívást kapott, és az aukció nyitva áll az aukciózásra. Egy hívással több ascending clock és uniform price típusú aukcióra is lehet ajánlatokat adni. Az ajánlatok befogadásakor külön kezeljük az ACTA és az UPTA típusú aukciókat. Ha bármelyik ACTA aukcióra adott ajánlatban hiba van, akkor egyetlen a kérésben szereplő ACTA ajánlatot sem fogad be a rendszer. Emellett ha az UPTA ajánlatok helyesek, akkor az UPTA ajánlatokat befogadjuk. Mindez fordítva is igaz. Az ajánlatadás rendszerét a CAM NC szabályozza. Ennek megfelelően a következő hiba ellenőrzéseket végezzük:


Ellenőrzés Csak akkor lehet ajánlatot beadni, ha nyitva van az aukció SPS ajánlati körre ajánlatot csak az első aluljegyzés után lehet beadni Az aktuálisnál kisebb LPS körre nem lehet ajánlatot beadni. Az aktuálisnál kisebb SPS körre nem lehet ajánlatot beadni. Két LPS kör között nem lehet ajánlatot beadni SPS körre Az igényelt kapacitás nem lehet nagyobb, mit a felajánlott kapacitás Csak pozitív egész ajánlatokat lehet beadni A beadott ajánlatoknak körönként egyenlőnek, vagy kisebbnek kell lennie, mint az előző.

Hibaüzenet azonosítója BIDDING_NOT_ALLOWED SMALL_STEP_BID_PRICE_NOT_BETWEEN_RELEVANT_LARGE_STEP_PRICES LARGE_STEP_SMALLER_THAN_ACTUAL SMALL_STEP_SMALLER_THAN_ACTUAL SMALL_STEP_BID_NOT_BETWEEN_LARGE_STEP_PRICES BID_QUANTITY_GREATER_THAN_CAP_OFFERED NEGATIVE_VALUE BID_QUANTITY_GREATER_PREVIOUS_BID_QUANTITY

A beadott ajánlatoknak körönként egyenlőnek, vagy nagyobbnak kell BID_QUANTITY_SMALLER_NEXT_BID_QUANTITY lennie, mint a következő. SPS körre nem lehet ajánlatot beadni úgy, hogy LPS kör nem zárult le SMALL_STEP_PHASE_MUST_NOT_BE_STARTED_WITHOUT_LPS_BIDS aluljegyzéssel Az SPS körre beadott ajánlatoknak körönként nagyobbnak kell lennie, SPS_BID_QUANTITY_GREATER_PREVIOUS_LPS_BID_QUANTITY mint az előző LPS körre beadott ajánlat. Az SPS körre beadott ajánlatoknak kisebbnek kell lennie, mint az SPS_BID_QUANTITY_SMALLER_NEXT_LPS_BID_QUANTITY következő LPS körre beadott ajánlat. A felajánlottnál több kapacitást nem lehet igényelni. QUANTITY_OVER_CAPACITY_OFFERED Csak létező aukcióra lehet ajánlatot beadni INVALID_AUCTION A kis árlépcső ajánlatainak a megfelelő nagy árlépcső értékei között kell SMALL_STEP_BID_PRICE_NOT_BETWEEN_RELEVANT_LARGE_STEP_PRICES lennie

Készítette: IP Rendszerintegrátor Kft.

20/83 Az ajánlott mennyiségnek nagyobbnak kell lennie következő lépcsős mennyiségnél A kiadásoldali pénzügyi limitet nem lehet túllépni A betáplálásoldali pénzügyi limitet nem lehet túllépni A pénzügyi limitet nem lehet túllépni A rendszerhasználó erre az aukcióra nem adhat be ajánlatot A rendszerhasználónak minden érintett zónában letétbe kell helyeznie pénzügyi fedezetet Az ajánlott mennyiség nem lehet több, mint 999999999 Az ajánlott mennyiség nem haladhatja meg az előző lépcsőben megadott mennyiséget SPS- nél Az ajánlott mennyiség nem lehet 0 vagy negatív Ugyanarra az árlépcsőre csak egy ajánlat menthető Az ajánlat értéke nem lehet kisebb, mint a következő ajánlat LPS- nél A beadott ajánlat összértéke nem lehet nagyobb, mint a rendszerhasználó pénzügyi kerete Az ajánlat értéke nem lehet kisebb, mint a következő ajánlat SPS- nél Érvénytelen kis árlépcső Kis árlépcsőre nem adhat be ajánlatot korábbi nagy árlépcsőre adott ajánlat nélkül Maximum 10 ajánlatot adhat be UPTA aukcióra UPTA aukcióra nem adhat be több ajánlatot ugyanazon az áron UPTA aukciónál a minimum mennyiségnek kevesebbnek kell lennie az igényelt mennyiségnél UPTA ajánlat mennyisége nem lehet 0 UPTA ajánlatnál a minimum mennyiség nem lehet negatív UPTA ajánlatnál az igényelt mennyiség nem lehet negatív UPTA ajánlatnál az ár nem lehet negatív


BID_QUANTITY_SMALLER_NEXT_BID_QUANTITY FINANCIAL_OUT_LIMIT_EXCEEDED FINANCIAL_IN_LIMIT_EXCEEDED FINANCIAL_LIMIT_EXCEEDED NETWORK_USER_CANNOT_BID_ON_GIVEN_AUCTION DEPOSIT_IS_MISSING BID_QUANTITY_MUST_BE_LESS_THAN_999999999 SPS_BID_QUANTITY_GREATER_PREVIOUS_SPS_BID_QUANTITY BID_QUANTITY_EQUALS_OR_LESS_THAN_ZERO NEW_BID_ON_SAME_PRICE_STEP BID_QUANTITY_SMALLER_PREVIOUS_BID_QUANTITY FINANCIAL_LIMIT_TOO_SMAL SPS_BID_QUANTITY_SMALLER_PREVIOUS_SPS_BID_QUANTITY INVALID_SMALL_PRICE_STEP SMALL_STEP_PHASE_MUST_NOT_BE_STARTED_WITHOUT_LPS_BIDS TOO_MANY_BIDS SAME_BID_PRICE MIN_QUANTITY_GREATER_THAN_BID_QUANTITY QUANTITY_ZERO NEGATIVE_MIN_QUANTITY NEGATIVE_QUANTITY NEGATIVE_PRICE

FGSZ Zrt.

5.2.1 A KÉRÉST TARTALMAZÓ ÜZENET

METÓDUS bulkMakeBids STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • •

Fejrész Tartalom o ACTA ajánlatok Ajánlat o UPTA ajánlatok Ajánlat A fejrész nem tartalmaz üzleti információt. MEZŐK Megnevezés

Leírás

Aukció név

Egy 8 jegyű karaktersorozat, auctionName ami az aukció egyértelmű azonosítására szolgál.

String

LPS (ACTA)

Aktuális nagy árlépcső

lps

Integer

SPS (ACTA)

Aktuális kis árlépcső

sps

Integer

Mennyiség (ACTA)

Az igényelt mennyiség

quantity

Integer

Ár (UPTA)

Ajánlott ár UPTA esetében. A price kiinduló ár százalékában (%) kifejezve.

Integer

Igényelt mennyiség (UPTA)

Igényelt mennyiség esetében.

UPTA bidQuantity

Integer

Minimum mennyiség (UPTA)

Minimum vásárolni kívánt minQuantity mennyiség UPTA esetében.

Integer


XML címkenév

Formátum / típus

22/83 PÉLDA <request> 00001016 0 <sps>0 9000 00001016 <price>5000 1000 <minQuantity>800

5.2.2 A VÁLASZT TARTALMAZÓ ÜZENET LEÍRÁS A válasz üzenetben hiba esetén az aukcióhoz tartozó hibakódokat adjuk vissza. LOGIKAI SZERKEZET Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel: •

Hibaüzenet-sorok az alábbiak szerint: o Aukciónév o Hibakód

MEZŐK Megnevezés

Leírás

Aukció név


String

Hibakód

Hibakód

String


XML címkenév

error

Formátum / típus

FGSZ Zrt.

23/83

PÉLDA <soap:Body> <soap:Fault> soap:Server INVALID_REQUEST <detail> <BulkMakeBidsFault> <error> 00001016 <error>BID_QUANTITY_GREATER_PREVIOUS_BID_QUANTITY

5.3. UPTA AJÁNLATOK TÖRLÉSE (BULKREMOVEUPTABIDS) ÜZLETI CÉL, KÖRNYEZET A szolgáltatás segítségével a meghatalmazott felhasználók eltávolíthatnak UPTA ajánlatokat. (E módszer mellett akármelyik ajánlat eltávolítható az adott aukcióra való 0 ajánlat beadásával). LEÍRÁS Egy vagy több ajánlat eltávolítható egy vagy több aukcióból. A szolgáltatás célja egyrészt, hogy a manuális módszernél gyorsabban lehessen ajánlatot törölni, másrészt az ember által elkövethető hibák minimalizálása. SZEREPLŐK, SZEREPKÖRÖK • • • •

A kérés küldője: Rendszerhasználó Tag A kérés fogadója: RBP Üzemeltető A válasz küldője: RBP Üzemeltető A válasz fogadója: Rendszerhasználó Tag

ÜTEMEZÉS, HATÁRIDŐK A határidők az aukcióban definiált szabályok szerint alakulnak. Törlést kizárólag abban az időintervallumban fogadunk be, amikor az aukció nyitva áll az ajánlatok befogadására.


FGSZ Zrt.

24/83 ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK A webservice kizárólag érvényes tanúsítvánnyal vehető igénybe. A tanúsítvány tulajdonosának rendelkeznie kell ajánlatbeadó jogosultsággal. Ezek hiányában a hozzáférés megtagadásra kerül. Ezen kívül csak olyan aukcióra fogadunk be törlés parancsot, amire a felhasználó által helyettesített rendszerhasználó meghívást kapott, és az aukció nyitva áll az aukciózásra. Az ajánlatadás rendszerét a CAM NC szabályozza. Ennek megfelelően a következő hiba ellenőrzéseket végezzük:


FGSZ Zrt.

25/83

Ellenőrzés Csak akkor lehet ajánlatot törölni, ha nyitva van az aukció Az aktuális aukciós státuszban nem lehet ajánlatot törölni Ehhez az azonosítóhoz tartozó ajánlatot már törölték Nem létező aukció névre nem lehet ajánlatot beadni. Ajánlat csak akkor törölhető, ha a rendszerhasználó részt vesz az aukcióban


Hibaüzenet azonosítója AUCTION_NOT_ACTIVE UPTA_BID_REMOVE_NOT_ALLOWED UPTA_BID_HAS_ALREADY_REMOVED INVALID_AUCTION NETWORK_USER_CANNOT_BID_ON_GIVEN_AUCTION

FGSZ Zrt.

5.3.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS bulkRemoveUptaBids STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. •

Fejrész

•

Tartalom o

UPTA ajánlatok Aukció név

A fejrész nem tartalmaz üzleti információt. MEZŐK Megnevezés

Leírás

XML címkenév

Aukció név


Formátum / típus String

PÉLDA <request> 00001016 00001017

5.3.2 A VÁLASZT TARTALMAZÓ ÜZENET LEÍRÁS A válasz üzenetben hiba esetén az aukcióhoz tartozó hibakódokat adjuk vissza. LOGIKAI SZERKEZET A válaszüzenet logikai felépítése az alábbi: •

Hibaüzenet-sorok az alábbiak szerint:


27/83 o

Aukciónév

o

Hibakód

MEZŐK Megnevezés

Leírás

XML címkenév

Aukció név


String

Hibakód

Hibakód

String

error

Formátum / típus

PÉLDA <soap:Body> <soap:Fault> soap:Server INVALID_REQUEST <detail> <BulkRemoveUptaBidsFault> <error> 00001016 <error>BIDDING_NOT_ALLOWED


FGSZ Zrt.

28/83

6. WEB SERVICE KOMMUNIKÁCIÓ AZ RBP ÉS A TSO TAG KÖZÖTT 6.1. TARIFA ÉS ÁRADATOK KÜLDÉSE IP-BŐL RBP-BE ÜZLETI CÉL, KÖRNYEZET Ez a szolgáltatás biztosítja a megfelelő kommunikációt az RBP és a TSO IP (back-end rendszer) között annak érdekében, hogy hozzájusson a hálózati pontok legfrissebb kapacitás, tarifa és árlépcső adataihoz. Az adatokat a TSO IP-ből az RBP-be küldik. LEÍRÁS Amennyiben RBP-ben aukció került kiírásra, ennek felparaméterezéséhez szükségesek az IP-ben tárolt kapacitás- és áradatok annak érdekében, hogy azok feltöltése után a ’Setting’ státuszú aukció ’Set’ státuszba léphessen. A szolgáltatás kizárólag érvényes tanúsítvánnyal vehető igénybe és a tanúsítvány tulajdonosának megfelelő jogokkal (Kapacitás adatok WebService) kell rendelkezni, hogy futtathassa a szolgáltatást. Ezen feltételek hiányában a szolgáltatáshoz való hozzáférés megtagadásra kerül. SZEREPLŐK, SZEREPKÖRÖK • • • •

A kérés küldője: TSO IP A kérés fogadója: RBP A válasz küldője: RBP A válasz fogadója: TSO IP

ÜTEMEZÉS, HATÁRIDŐK A web service működése szempontjából fontos job lefuttatásának beállítására az IP Management modulban nyílik ütemezési lehetőség. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehetséges a web service használata. A tanúsítvány tulajdonosának engedéllyel kell rendelkezni, hogy futtathassa a szolgáltatást. Ezek hiányában a hozzáférés megtagadásra kerül.

6.1.1. A KÉRÉST TARTALMAZÓ ÜZENET LEÍRÁS A kérés üzenetben küldünk minden olyan adatot, melyre az RBP-nek szüksége van. STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel.


FGSZ Zrt.

29/83 • •

Fejrész (nem tartalmaz üzleti információt) Tartalom o TSO Tag EIC kódja o Gáznap (adatok küldésének idejét közli) o Hálózati pont EIC kódja o Hálózati pont neve o Hálózati pont iránya o Kapacitás adatok termék o Megszakíthatóság o Áramlási irány o Kiinduló ár o Nagy árlépcső (LPS) o Kis árlépcső (SPS)

MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

TSO Tag EIC kódja

A releváns TSO Tag EIC kódja

tsoEicCode

String

Gáznap

A gáznap az adatok gasday publikálásának napja

String


eicCode

String

Hálózati neve

capacityPointName

String


Kapacitás adatok

A kapacitás adatok a termék capacityByNetworkPoints YEARLY, QUARTERLY típus, megszakíthatóság, MONTHLY, DAILY, áramlási irány és hálózati WITHINDAY, STRIP pontok szerint vannak elküldve. Ezen kívül napi és órai adatok is biztosítva lesznek.

Megszakíthatóság Megszakítható, megszakítható Hálózati iránya

pont Direkt, vissza

Áramlási irány

Fizikai, Backhaul


nem productQuality

FIRM, INTERRUPTIBLE

direction

DIRECT, REVERSE

gasFlow

PHYSICAL, BACKHAUL

FGSZ Zrt.

30/83 Megnevezés

Leírás

XML címkenév

Formátum / típus


Szabványos, nem standard szabványos, szezonális


Kiinduló ár

A kiinduló ár devizával reservePrice együtt, termék típus, megszakíthatóság, áramlási irány és hálózati pontok szerint

String

Rögzített LPS

Tényleges nagy árlépcső

lps

Integer

Rögzített SPS

Tényleges kis árlépcső

sps

Integer

PÉLDA <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://service.web.rbp.ipsystems.hu"> <soapenv:Header/> <soapenv:Body> <ser:uploadCapacityAndTariff> 21X-RO-A-A0A0A-S 2015-01-01 <eicCode>21Z000000000236Q Csanádpalota (HU>RO) DIRECT 2 50 960 40 600 25 480


FGSZ Zrt.

31/83 2 96 4 2400000000 10 480 20 96 4 2400000001 10 <monthlyCapacity> 12000 500 2400 100 7200 300 720 30 240 10 1200 50 <eicCode>21Z000000000236Q Csanádpalota (HU>RO) DIRECT <productType>YEARLY 661


FGSZ Zrt.

32/83 8000.123456 666 <seasonalCapacityPrice>1000 10 <sps>1 <productType>QUARTERLY 20000 7000.123456 1900 18 <sps>9 <monthlyReservePrice> <productType>MONTHLY 30000 12345678 3000 16 <sps>4 <productType>DAILY 40000 999.123456 6000 15 <sps>1

6.1.2. A VÁLASZT TARTALMAZÓ ÜZENET


FGSZ Zrt.

33/83 LEÍRÁS A válasz üzenet visszajelzést tartalmaz arról, hogy az elküldött adatok sikeresen megérkeztek és mentésre kerültek az RBP-ben. MEZŐK A válasz nem tartalmaz üzleti információt. PÉLDA <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:uploadCapacityAndTariffResponse xmlns:ns2="http://service.web.rbp.ipsystems.hu"/>

6.2. RBP AUKCIÓK EREDMÉNYEINEK IMPORTJA ÜZLETI CÉL, KÖRNYEZET Ez a szolgáltatás lehetővé teszi, hogy az RBP elküldje a lezárt aukciók szerződéses adatait (TRADE-ek) a TSO Tagnak és a Rendszerhasználó Tagnak. LEÍRÁS A lezárt aukciók sikeres ajánlatai (TRADE-ek) a megfelelő hozzáférési jogok szerint elküldésre kerülnek az igénylő félhez. A szolgáltatás kizárólag érvényes tanúsítvánnyal vehető igénybe és a tanúsítvány tulajdonosának megfelelő jogokkal (Aukció eredmények WebService export-érintett TSO Tag) kell rendelkezni, hogy futtathassa a szolgáltatást. Ezek hiányában a szolgáltatáshoz való hozzáférés megtagadásra kerül. SZEREPLŐK, SZEREPKÖRÖK • • • •

A kérés küldője: TSO Tag A kérés fogadója: RBP A válasz küldője: RBP A válasz fogadója: TSO Tag

ÜTEMEZÉS, HATÁRIDŐK A web service működése szempontjából fontos job lefuttatásának beállítására az IP Management modulban nyílik ütemezési lehetőség. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK A szolgáltatás kizárólag érvényes tanúsítvánnyal vehető igénybe. A tanúsítvány tulajdonosának engedéllyel kell rendelkezni, hogy futtathassa a szolgáltatást. Gázipari Kommunikációs Szabvány

FGSZ Zrt.

34/83 Ezek hiányában a hozzáférés megtagadásra kerül.

6.2.1. A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS getTrades STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • •

Fejrész (nem tartalmaz üzleti információt) Tartalom o TSO Tag EIC kódja o Időintervallum (from – to)

MEZŐK Megnevezés

Leírás

TSO Tag EIC A releváns TSO Tag EIC kódja kódja Időintervallum (from – to)

XML címkenév

Formátum / típus

tsoEicCode

String

Az a tól ig időszak, melyek gasday között a TRADE-k lekérdezésre kerülnek

String

PÉLDA <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:getTrades xmlns:ns2="http://service.web.rbp.ipsystems.hu"> <request> 21X-HU-A-A0A0A-8 2015-05-13T14:32:00.000Z 2015-05-14T14:32:08.000Z

6.2.2. A VÁLASZT TARTALMAZÓ ÜZENET


FGSZ Zrt.

35/83 LEÍRÁS A választ tartalmazó üzenetben küldésre kerül az összes, a megadott intervallumba eső időszak alatt generálódott minden TRADE. STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • •

Fejrész (nem tartalmaz üzleti információt) Tartalom o Trade azonosító o Aukció név o Rendszerhasználó EIC kódja o Rendszerhasználókódja o Rendszerhasználó neve o Hálózati pont EIC kódja o Hálózati pont neve o Hálózati pont IP kódja (nomination ID) o Terméktípus (éves, negyedéves, havi, napi, STRIP) o Instrument (gázév, gáznegyedév, gázhónap, gáznap, STRIP) o Érvényesség kezdete o Érvényesség vége o Kapacitás típus (kapcsolt, nem kapcsolt) o Minőség (megszakítható, nem megszakítható) o Irány (fizikai, backhaul) o Szabványos (szabványos, nem szabványos) o Allokált mennyiség o Kiinduló ár o Elszámoló ár o Aukciós felár o Ügyletazonosító

MEZŐK Megnevezés

Leírás

Trade azonosító

A Trade azonosítására tradeID szolgáló szám

String

Aukció név

Egy 8 jegyű auctionName karaktersorozat, ami az aukció egyértelmű azonosítására szolgál.

String

Rendszerhasználó

A

String

rendszerhasználó


XML címkenév

EIC netwokrUSerEic

Formátum / típus

FGSZ Zrt.

36/83 EIC kódja

kódja

Rendszerhasználó Operátor kódja

A rendszerhasználó networkUserCode operátori kódja

String

Rendszerhasználó neve

A rendszerhasználó neve

netwokrUserName

String


networkPointEic

String

Hálózati neve

networkPointName

String


Hálózati pont IP A releváns hálózati pont IP networkPointNominationID String kódja kódja (nomination ID) (nomination ID) Termék típus

Éves, negyedéves, havi, prodctType napi, napon belüli, STRIP


Instrument

Vonatkozási időszak

String

Érvényesség kezdete

Az érvényesség dátuma

Érvényesség vége

Az érvényesség végét jelző validityEnd dátum

String

Kapacitás típus


BUNDLED, UNBUNDLED


instrument kezdő validityStart

capacityType

nem capacityQuality

FIRM, INTERRUPTIBLE

Áramlási irány

Fizikai, Backhaul


Szabványos, nem standard szabványos, szezonális


Allokált mennyiség

Az érintett allocatedCapacity rendszerhasználónak

String


gasFlow

String

PHYSICAL, BACKHAUL

FGSZ Zrt.

37/83 allokált mennyiség Kiinduló ár

A kiinduló ár devizával reservePrice együtt

String

Elszámoló ár

Aukciós felárral kiinduló ár

String

Aukciós felár

Elnyert kapacitásért, a clearingPremium kiinduló ár mellett fizetendő felár

String

Ügyletazonosító

Ügylet azonosítására egyedi ID

String

növelt clearingPrice

pontos confirmatonID szolgáló

PÉLDA <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:getTradesResponse xmlns:ns2="http://service.web.rbp.ipsystems.hu"> 150 00000299 2015-0514T09:54:28.808Z 15X-GDF-SUEZ--2 GDFSUEZ GDF SUEZ Energia Magyarország Zrt. 39WSIFORRASFSEN2 Egyesített Kitárolás SIFORRASFSEN <productType>YEARLY 2015 GASYEAR 2015.10.01 2016.09.30


FGSZ Zrt.

38/83 UNBUNDLED FIRM PHYSICAL <standard>STANDARD 9000000 418.29 418.29 0 21X-HU-A-A0A0A-8/15X-GDF-SUEZ--2/00000299 <priceDecimals>4 151 00000228 2015-0514T09:54:28.808Z 15X-GDF-SUEZ--2 GDFSUEZ GDF SUEZ Energia Magyarország Zrt. 39WKETELJCS58EN1 MOL betáplálási pontja (2/S)

Nyrt

KTD

összevont

KETELJCS58EN <productType>YEARLY 2015 GASYEAR 2015.10.01 2016.09.30 UNBUNDLED FIRM PHYSICAL <standard>STANDARD 1000 1 194.08 1 194.08 0 21X-HU-A-A0A0A-8/15X-GDF-SUEZ--2/00000228 <priceDecimals>4


FGSZ Zrt.

39/83 152 00000298 2015-0514T09:54:28.808Z 15X-GDF-SUEZ--2 GDFSUEZ GDF SUEZ Energia Magyarország Zrt. 39ZSIFGTAROLSENX Egyesített Letárolás SIFGTAROLSEN <productType>YEARLY 2015 GASYEAR 2015.10.01 2016.09.30 UNBUNDLED FIRM PHYSICAL <standard>STANDARD 8000000 0 0 0 21X-HU-A-A0A0A-8/15X-GDF-SUEZ--2/00000298 <priceDecimals>4


FGSZ Zrt.

40/83

7. BILATERÁLIS KAPACITÁS ÁTADÁS 7.1. BILATERÁLIS AJÁNLAT BEADÁS (OFFERBILATERALCAPACITY) ÜZLETI CÉL, KÖRNYEZET A szolgáltatás célja, hogy a megfelelő jogosultsággal rendelkező rendszerhasználók általuk birtokolt kapacitást ajánlhatnak fel más rendszerhasználók számára. LEÍRÁS Az ajánlat beküldésekor formai ellenőrzések után rögzítjük a rendszerben az ajánlatot. Azt, hogy rendelkezésre áll e a kapacitás a rendszerüzemeltetők ellenőrzik. Ha minden szereplő jóváhagyja a bilatot, a kapacitást csak akkor szabad átvezetni. A kapacitás átadás nem jár szerződés módosítással. Kapacitást átadni egy adott órától bármelyik gáznap végéig lehet, kivéve napon belüli átadás esetében, olyankor csak az adott gáznap vége választható. SZEREPLŐK, SZEREPKÖRÖK • • • •

A kérés küldője: Rendszerhasználó Tag (átadó) A kérés fogadója: RBP Üzemeltető A válasz küldője: RBP Üzemeltető A válasz fogadója: Rendszerhasználó Tag (átadó)

ÜTEMEZÉS, HATÁRIDŐK Az vonatkozási időszaknak legalább a beadás időpontjától kezdve 4 óra múlva kell kezdődnie. A bilat érvényességének legalább a vonatkozási időszak kezdete előtt 3 órával kell végződnie. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet bilaterális kapacitás átadást beküldeni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilaterális kapacitás átadást jogosultsággal. Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést. Az átadás kezdetét UTC szerint órás pontossággal kell megadni. A beadott időpontnál csak az órát vesszük figyelembe, a percet, másodpercet, stb levágjuk. Beadott átadás Átkonvertált kezdete (UTC) kezdete (UTC)

átadás Átadás magyar (CET)

kezdete Megjegyzés idő szerint

2015.08.06 13:14:22.589

2015.08.06 13:00:00.000

2015.08.06 15:00

Nyári időszámítás

2015.10.25

2015.10.25 04:00:00.000

2015.10.25 05:00

Téli időszámítás


FGSZ Zrt.

41/83 04:59:59.999 2015.11.05 23:59:59.999

2015.11.05 23:00:00.000

2015.11.06 00:00


Az átadás végét nap pontossággal kell megadni. Az időpontot mindig a téli és nyári időszámítás szerint az adott naptári napra eső gáznap végéhez igazítjuk UTC szerint. Beadott átadás vége Átkonvertált átadás vége Átadás vége magyar Megjegyzés (UTC) (UTC) idő szerint (CET) 2015.08.07 15:14:22.589

2015.08.07 03:59:59.999

2015.08.07 05:59


2015.10.25 01:59:59.999

2015.10.25 04:59:59.999

2015.10.25 05:59


2015.08.06 23:59:59.999

2015.08.06 03:59:59.999

2015.08.06 05:59


Az érvényességet ezredmásodperc pontossággal rögzíti a rendszer, nem konvertáljuk.


FGSZ Zrt.

42/83 Ellenőrzés Hibaüzenet azonosítója Az vonatkozási időszak kezdetének korábbinak kell lennie, mint a OFFER_BILATERAL_CAPACITY_START_DATE_GREATER végének. Az vonatkozási időszak kezdetének a 4 órás eltoláson kívülre kell esnie OFFER_BILATERAL_CAPACITY_START_DATE_BEFORE_REFERENCE Az érvényesség végének legalább 3 órával a vonatkozási időszak kezdete elé kell esnie A vonatkozási időszaknak gáznap végéig kell tartania. Napon belüli esetben az adott gáznap végéig. Az átvevőnek a kiválasztott zónában szerződött rendszerhasználónak kell lennie. Nem lehet ugyanaz az átadó és az átvevő A kiválasztott zónák csak a ponthoz kapcsolódó zónák lehetnek. Csak a rendszerben létező zónát lehet megadni. Az átadónak a kiválasztott zónában szerződött rendszerhasználónak kell lennie. A kiválasztott rendszerhasználónak léteznie kell a rendszerben. A kiválasztott rendszerhasználónak érvényesnek kell lennie a start dátum időpontjában.

OFFER_BILATERAL_CAPACITY_VALIDITY_AFTER_REFERENCE OFFER_BILATERAL_CAPACITY_INVALID_END_DATE OFFER_BILATERAL_CAPACITY_PARTNER_MISSING_FROM_ZONE OFFER_BILATERAL_CAPACITY_PARTNER_AND_SELLER_ARE_THE_SAME OFFER_BILATERAL_CAPACITY_ZONES_MUST_BELONG_TO_THE_CAPACITY_POINT OFFER_BILATERAL_CAPACITY_ZONES_MUST_EXIST OFFER_BILATERAL_CAPACITY_SELLER_MUST_BE_ASSIGNED_TO_THE_ZONE OFFER_BILATERAL_CAPACITY_NETWORK_USER_NOT_EXISTS OFFER_BILATERAL_CAPACITY_NETWORK_USER_NOT_VALID

A kiválasztott hálózati pontnak léteznie kell a rendszerben. OFFER_BILATERAL_CAPACITY_CAPACITY_POINT_NOT_EXISTS A kiválasztott hálózati pontnak érvényesnek kell lennie a start dátum OFFER_BILATERAL_CAPACITY_CAPACITY_POINT_NOT_VALID időpontjában. Backhaul kapacitás csak megszakítható lehet. Szezonális kapacitás csak nem megszakítható lehet. Szezonális kapacitás csak éves lehet. Nem szabványos kapacitás csak STRIP típusú lehet. Az iránynak meg kell egyeznie a hálózati ponton értelmezett irányokkal. STRIP termék csak nem megszakítható lehet Az érvényesség vége a nem lehet a múltban Gázipari Kommunikációs Szabvány

OFFER_BILATERAL_CAPACITY_BACKHAUL_FIRM OFFER_BILATERAL_CAPACITY_SEASONAL_INTERRUPTIBLE OFFER_BILATERAL_CAPACITY_SEASONAL_NOT_YEARLY OFFER_BILATERAL_CAPACITY_PRODUCT_TYPE_NOT_STRIP OFFER_BILATERAL_CAPACITY_DIRECTION_IS_INVALID OFFER_BILATERAL_CAPACITY_STRIP_MUST_BE_FIRM OFFER_BILATERAL_CAPACITY_VALIDITY_IN_THE_PAST FGSZ Zrt.

43/83

7.1.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS OfferBilateralCapacity STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • •

Fejrész Tartalom o Bilaterális ajánlat A fejrész nem tartalmaz üzleti információt. MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Átvevő EIC kódja

Az átvevő rendszerhasználó PartnerNetworkUserEic String EIC kódja


CapacityPointEicCode

String

Kapacitás típus


CapacityType

BUNDLED, UNBUNDLED

Átadás iránya

Direkt, vissza

Direction

DIRECT, REVERSE

Áramlási irány

Fizikai, Backhaul

GasFlow

PHYSICAL, BACKHAUL

Termék típus

Éves, negyedéves, havi, napi, ProdctType napon belüli, STRIP


nem ProductQuality

YEARLY, QUARTERLY MONTHLY, DAILY, WITHINDAY, STRIP FIRM, INTERRUPTIBLE


Szabványos, nem szabványos, Standard szezonális


Zónák

Zóna lista

String

Zones

Átadás kezdő Az átadás vonatkozási StartDate időpontja időszakának kezdete

Date

Átadás időpontja

Date

záró Az átadás vonatkozási EndDate időszakának vége

Órai mennyiség

Az átadásra kínált kapacitás HourlyQuantity mennyiség kWh/h mértékegységben

Érvényesség vége Az az időpont, ameddig Validity időpont minden résztvevő jóváhagyásának rá kell Gázipari Kommunikációs Szabvány

Integer

Date

44/83 kerülnie Megjegyzés

Az átadó által hozzáfűzött Note megjegyzés

String

PÉLDA <PartnerNetworkUserEic>39X50TIGKER00003 21Z000000000236Q BUNDLED DIRECT PHYSICAL YEARLY FIRM <Standard>STANDARD HUN ROU <StartDate>2015-05-30T09:00:00 <EndDate>2015-09-15T05:59:59 .999 1100 2015-05-29T09:00:00 …

7.1.2 A VÁLASZT TARTALMAZÓ ÜZENET LEÍRÁS A válasz üzenet a rögzítés sikeressége estén üres, vagy az esetleges hibakódok kerülnek bele. LOGIKAI SZERKEZET A válaszüzenet logikai felépítése az alábbi: •

Hibaüzenet-sorok az alábbiak szerint: o Hibakód

MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Hibakód

Hibakód

error

String

PÉLDA <soap:Body> <soap:Fault> Gázipari Kommunikációs Szabvány

FGSZ Zrt.

45/83 soap:Server INVALID_BILATERAL_OFFER <detail> <ns1:BilateralOfferWebServiceFault xmlns:ns1="http://rbp.hu"> <error>OFFER_BILATERAL_CAPACITY_INVALID_END_DATE

7.2. BILATERÁLIS KAPACITÁS ÁTADÁSOK LEKÉRDEZÉSE ÜZEMELTETŐK SZÁMÁRA (GETBILATERALOFFERSBYTSO) ÜZLETI CÉL, KÖRNYEZET A megfelelő jogosultsággal rendelkező üzemeltetők lekérdezhetik azokat a bilaterális kapacitás felajánlásokat, amelyekben érintettek és éppen folyamatban vannak. LEÍRÁS A szolgáltatás visszaadja azokat a felajánlásokat, amelyek épp folyamatban vannak és az üzemeltetőnek teendője van vele. A következő státuszok lehetnek: •

•

•

•

WAITING_FOR_TSO: Az üzemeltetőnek ellenőriznie kell, hogy rendelkezésre áll e a kapacitás, és biztosítani, hogy ha minden résztvevő jóváhagyja az érvényesség lejárta előtt, akkor át lehessen adni a kapacitást. Ha ez megtörtént, akkor vissza kell szólnia az RBP- nek, hogy jóváhagyja a kapacitásátadást. (ApproveBilateralOfferByTso) Ha nem áll rendelkezésre a kapacitás, akkor el kell utasítani az átadást. (RefuseBilateralOfferByTso) REVOKED_BY_SELLER: Az átadó visszavonta az ajánlatot. Ha az üzemeltető már jóváhagyta az átadást és zárolta a kapacitást, akkor fel kell oldani azt, és jeleznie kell az RBP felé, hogy részéről lezártnak tekinthető az ügylet. (CloseBilateralOfferByTso) REFUSED_BY_TSO: BUNDLED kapacitás esetén a kapcsolódó zóna üzemeltetője elutasította az átadást. Ha az üzemeltető már jóváhagyta az átadást és zárolta a kapacitást, akkor fel kell oldani azt, és jeleznie kell az RBP felé, hogy részéről lezártnak tekinthető az ügylet. (CloseBilateralOfferByTso) REJECTED_BY_BUYER: Az átvevő visszautasította az ajánlatot. Ha az üzemeltető már jóváhagyta az átadást és zárolta a kapacitást, akkor fel kell oldani azt, és jeleznie kell az RBP felé, hogy részéről lezártnak tekinthető az ügylet. (CloseBilateralOfferByTso)


FGSZ Zrt.

46/83 •

•

APPROVED: Minden résztvevő jóváhagyta az átadást. Az üzemeltetőnek át kell vezetnie a kapacitás,t és jeleznie kell az RBP felé, hogy részéről lezártnak tekinthető az ügylet. (CloseBilateralOfferByTso) EXPIRED: Az ügylet érvényessége lejárt. Ha az üzemeltető zárolta a kapacitást, akkor fel kell oldani azt, és jeleznie kell az RBP felé, hogy részéről lezártnak tekinthető az ügylet. (CloseBilateralOfferByTso)


A kérés küldője: TSO Tag A kérés fogadója: RBP Üzemeltető A válasz küldője: RBP Üzemeltető A válasz fogadója: TSO Tag

ÜTEMEZÉS, HATÁRIDŐK A bilat érvényességi idejéig el kell jutni a következő státuszok valamelyikébe: REFUSED_BY_TSO, REVOKED_BY_SELLER, REJECTED_BY_BUYER, APPROVED. Amennyiben ez nem valósul meg, EXPIRED státuszba kerül a bilat. A bilatokat mindaddig vissza fogja adni a szolgáltatás, amíg CLOSED státuszba nem kerülnek. A CLOSED státuszúakat már nem adja vissza a szolgáltatás. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet az ügyleteket lekérdezni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilat jóváhagyó jogosultsággal. Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést.

7.2.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS GetBilateralOffersByTso STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt. MEZŐK A kérés nem tartalmaz információt, mivel a tanúsítvány alapján azonosítunk. PÉLDA


FGSZ Zrt.

47/83

7.2.2 A VÁLASZT TARTALMAZÓ ÜZENET LEÍRÁS A válasz üzenetben vissza adunk minden olyan ügyletet, amellyel az üzemeltetőnek van valami teendője. LOGIKAI SZERKEZET A válaszüzenet logikai felépítése az alábbi: • •

Hibaüzenet-sorok az alábbiak szerint: o Hibakód Bilaterális ajánlatok o Bilat azonosító o Érintett nominálási azonosítók o Átadó EIC kódja o Átvevő EIC kódja o Hálózati pont EIC kódja o Kapacitás típus o Átadás iránya o Áramlási irány o Termék típus o Megszakíthatóság o Szabványos kapacitástermék o Zónák o Átadás kezdő időpontja o Átadás záró időpontja o Órai mennyiség o Érvényesség vége időpont o Megjegyzés o Státusz o Záró státusz o Elutasítás oka

MEZŐK Megnevezés

Leírás

Bilat azonosító

A bilaterális azonosítója

Érintett nominálási azonosítók

A bilatnál használt NominationIds nominálási azonosító. Csak azt a nominálási azonosítót adjuk vissza, amelyik az adott TSO Tag zónájára vonatkozik.

String

Átadó EIC kódja

Az átadó rendszerhasználó SellerNetworkUserEic

String


XML címkenév ajánlat Id

Formátum / típus Long

FGSZ Zrt.

48/83 Megnevezés

Leírás EIC kódja

XML címkenév

Formátum / típus

Átvevő EIC kódja




String

Kapacitás típus


CapacityType

BUNDLED, UNBUNDLED

Átadás iránya

Direkt, vissza

Direction

DIRECT, REVERSE

Áramlási irány

Fizikai, Backhaul

GasFlow

PHYSICAL, BACKHAUL

Termék típus




nem ProductQuality

FIRM, INTERRUPTIBLE


Szabványos, szabványos, szezonális

nem Standard


Zónák

Csak azt a zónát adjuk vissza, Zones amelyik az adott TSO Tag zónájára vonatkozik.

String


Date

Átadás időpontja

Date


Órai mennyiség


Integer

Érvényesség vége Az az időpont, ameddig Validity időpont minden résztvevő jóváhagyásának rá kell kerülnie

Date

Megjegyzés


String

Státusz

A bilat aktuális státusza

WAITING_FOR_TSO, REFUSED_BY_TSO, REVOKED_BY_SELLER, WAITING_FOR_BUYER, REJECTED_BY_BUYER, APPROVED,


Status

FGSZ Zrt.

49/83 Megnevezés

Leírás

XML címkenév

Formátum / típus CLOSED, EXPIRED

Záró státusz

A CLOSED státusz utolsó státusz

előtti FinalStatus

Elutasítás oka

A TSO, az átadó, vagy az RefuseComment átvevő tölti ki abban az esetben, ha elutasítja, visszavonja, vagy visszautasítja a bilatot.

REFUSED_BY_TSO, REVOKED_BY_SELLER, REJECTED_BY_BUYER, APPROVED, EXPIRED String

PÉLDA <ns2:GetBilateralOffersByTsoResponse xmlns:ns2="http://rbp.hu"> 150 KECSANAD1HBN <SellerNetworkUserEic>39X50EONTRADE00B <PartnerNetworkUserEic>39X50SHELL00001Y 21Z000000000236Q BUNDLED DIRECT PHYSICAL YEARLY FIRM <Standard>STANDARD HUN <StartDate>2015-08-27Z <EndDate>2015-09-15Z 1000 2015-08-27Z Offer cpacity to SHELL <Status>WAITING_FOR_TSO 151 Gázipari Kommunikációs Szabvány

FGSZ Zrt.

50/83 KAABA00011GN <SellerNetworkUserEic>39X50EONTRADE00B <PartnerNetworkUserEic>39X50TIGKER00003 39ZKAABA00011GNE UNBUNDLED DIRECT PHYSICAL DAILY FIRM <Standard>STANDARD HUN <StartDate>2015-09-21Z <EndDate>2015-09-24Z 200 2015-09-08Z Offer capacity to TIGAZ. <Status>APPROVED

7.3. BILATERÁLIS KAPACITÁS ÁTADÁSOK LEKÉRDEZÉSE AZ ÁTADÓ SZÁMÁRA (GETBILATERALOFFERSBYSELLER) ÜZLETI CÉL, KÖRNYEZET A megfelelő jogosultsággal rendelkező rendszerhasználók lekérdezhetik azokat a bilaterális kapacitás felajánlásokat, amelyeket ők hoztak létre és az átadás kezdete időpont a jövőben van. LEÍRÁS A szolgáltatás visszaadja azokat a felajánlásokat, amelyek épp folyamatban vannak, vagy már lezáródtak, de még nem jött el az átadás időpontja. A következő státuszok lehetnek: • • • •

WAITING_FOR_TSO: Az átadó visszavonhatja a felajánlást. REVOKED_BY_SELLER: Az átadó visszavonta az ajánlatot. REFUSED_BY_TSO: A TSO Tag elutasította az átadást. A RefusedComment mezőből kiolvasható az elutasítás oka. WAITING_FOR_BUYER: A TSO Tag jóváhagyta a bilatot. Az átadó visszavonhatja a felajánlást.


FGSZ Zrt.

51/83 • • • •

REJECTED_BY_BUYER: Az átvevő visszautasította az ajánlatot. A RefusedComment mezőből kiolvasható az elutasítás oka. APPROVED: Minden résztvevő jóváhagyta az átadást. EXPIRED: Az ügylet érvényessége lejárt. CLOSED: A TSO Tagok nyugtázták a bilat vég státuszát. A FinalStatus mezőből kiolvasható, hogy hogyan záródott a bilat.

SZEREPLŐK, SZEREPKÖRÖK

• • • •


ÜTEMEZÉS, HATÁRIDŐK A bilat érvényességi idejéig el kell jutni a következő státuszok valamelyikéig: REFUSED_BY_TSO, REVOKED_BY_SELLER, REJECTED_BY_BUYER, APPROVED. Amennyiben ez nem valósul meg, EXPIRED státuszba kerül a bilat. A bilatokat mindaddig vissza fogja adni a szolgáltatás, amíg CLOSED státuszba nem kerülnek. A CLOSED státuszúakat az átadás időpontjáig adja vissza, utána nem. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet az ügyleteket lekérdezni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilat ajánlat jogosultsággal. Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést.

7.3.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS GetBilateralOffersBySeller STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt. MEZŐK A kérés nem tartalmaz információt, mivel a tanúsítvány alapján azonosítunk. PÉLDA


FGSZ Zrt.

52/83

7.3.2 A VÁLASZT TARTALMAZÓ ÜZENET LEÍRÁS A válasz üzenetben vissza adunk minden olyan ügyletet, amelyet a rendszerhasználó hozott létre, nem CLOSED státuszú, vagy ha CLOSED státuszú, akkor még nem jött el az átadás időpontja. LOGIKAI SZERKEZET A válaszüzenet logikai felépítése az alábbi: • •


MEZŐK Megnevezés

Leírás

Bilat azonosító



A bilatnál használt NominationIds nominálási azonosító lista. UNBUNDLED esetben csak egy elemű, BUNDLED esetben a zónáknak megfelelő sorrendben adjuk


XML címkenév ajánlat Id

Formátum / típus Long String

FGSZ Zrt.

53/83 vissza Átadó EIC kódja

Az átadó rendszerhasználó SellerNetworkUserEic EIC kódja

String

Átvevő EIC kódja




String

Kapacitás típus


CapacityType

BUNDLED, UNBUNDLED

Átadás iránya

Direkt, vissza

Direction

DIRECT, REVERSE

Áramlási irány

Fizikai, Backhaul

GasFlow

PHYSICAL, BACKHAUL

Termék típus




nem ProductQuality

FIRM, INTERRUPTIBLE



nem Standard


Zónák

Az érintett zónák listája. Zones BUNDLED esetben a pont tulajdonságainak megfelelő sorrendben adjuk őket vissza. UNBUNDLED esetben egy elemű a lista.

String


Date

Átadás időpontja

Date


Órai mennyiség


Integer


Date

Megjegyzés


String

Státusz


WAITING_FOR_TSO, REFUSED_BY_TSO,


Status

FGSZ Zrt.

54/83 REVOKED_BY_SELLER, WAITING_FOR_BUYER, REJECTED_BY_BUYER, APPROVED, CLOSED, EXPIRED Záró státusz


előtti FinalStatus

Elutasítás oka

A TSO Tag, az átadó, vagy az RefuseComment átvevő tölti ki abban az esetben, ha elutasítja, visszavonja, vagy visszautasítja a bilatot.


PÉLDA <ns2:GetBilateralOffersBySellerResponse xmlns:ns2="http://rbp.hu"> 150 KECSANAD1HBN ROUKECSANAD1HBN <SellerNetworkUserEic>39X50EONTRADE00B <PartnerNetworkUserEic>39X50SHELL00001Y 21Z000000000236Q BUNDLED DIRECT PHYSICAL YEARLY FIRM <Standard>STANDARD HUN ROU <StartDate>2015-08-27Z <EndDate>2015-09-15Z 1000 2015-08-27Z Gázipari Kommunikációs Szabvány

FGSZ Zrt.

55/83 Offer cpacity to SHELL <Status>WAITING_FOR_TSO 151 KAABA00011GN <SellerNetworkUserEic>39X50EONTRADE00B <PartnerNetworkUserEic>39X50TIGKER00003 39ZKAABA00011GNE UNBUNDLED DIRECT PHYSICAL DAILY FIRM <Standard>STANDARD HUN <StartDate>2015-09-21Z <EndDate>2015-09-24Z 200 2015-09-08Z Offer capacity to TIGAZ. <Status>CLOSED APPROVED

7.4. BILATERÁLIS KAPACITÁS ÁTADÁSOK LEKÉRDEZÉSE AZ ÁTVEVŐ SZÁMÁRA (GETBILATERALOFFERSBYBUYER) ÜZLETI CÉL, KÖRNYEZET A megfelelő jogosultsággal rendelkező rendszerhasználók lekérdezhetik azokat a bilaterális kapacitás felajánlásokat, amelyekben átvevőként vannak megjelölve és az átadás kezdete időpont a jövőben van. LEÍRÁS A szolgáltatás visszaadja azokat a felajánlásokat, amelyek épp folyamatban vannak, vagy már lezáródtak, de még nem jött el az átadás időpontja. A következő státuszok lehetnek: Gázipari Kommunikációs Szabvány

FGSZ Zrt.

56/83 • • • • • • • •

WAITING_FOR_TSO: Az átvevő visszautasíthatja a felajánlást. REVOKED_BY_SELLER: Az átadó visszavonta az ajánlatot. REFUSED_BY_TSO: A TSO Tag elutasította az átadást. A RefusedComment mezőből kiolvasható az elutasítás oka. WAITING_FOR_BUYER: A TSO Tag jóváhagyta a bilatot. Az átvevő visszautasíthatja, vagy elfogadhatja a felajánlást. REJECTED_BY_BUYER: Az átvevő visszautasította az ajánlatot. A RefusedComment mezőből kiolvasható az elutasítás oka. APPROVED: Minden résztvevő jóváhagyta az átadást. EXPIRED: Az ügylet érvényessége lejárt. CLOSED: A TSO Tagok nyugtázták a bilat vég státuszát. A FinalStatus mezőből kiolvasható, hogy hogyan záródott a bilat.


A kérés küldője: Rendszerhasználó Tag (átvevő) A kérés fogadója: RBP Üzemeltető A válasz küldője: RBP Üzemeltető A válasz fogadója: Rendszerhasználó Tag (átvevő)

ÜTEMEZÉS, HATÁRIDŐK A bilat érvényességi idejéig el kell jutni a következő státuszok valamelyikéig: REFUSED_BY_TSO, REVOKED_BY_SELLER, REJECTED_BY_BUYER, APPROVED. Amennyiben ez nem valósul meg, EXPIRED státuszba kerül a bilat. A bilatokat mindaddig vissza fogja adni a szolgáltatás, amíg CLOSED státuszba nem kerülnek. A CLOSED státuszúakat az átadás időpontjáig adja vissza, utána nem. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet az ügyleteket lekérdezni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilat ajánlat jogosultsággal. Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést.

7.4.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS GetBilateralOffersByBuyer STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt.


FGSZ Zrt.

57/83 MEZŐK A kérés nem tartalmaz információt, mivel a tanúsítvány alapján azonosítunk. PÉLDA

7.4.2 A VÁLASZT TARTALMAZÓ ÜZENET LEÍRÁS A válasz üzenetben vissza adunk minden olyan ügyletet, amelyben a rendszerhasználó a kedvezményezett, nem CLOSED státuszú, vagy ha CLOSED státuszú, akkor még nem jött el az átadás időpontja. LOGIKAI SZERKEZET A válaszüzenet logikai felépítése az alábbi: • •



FGSZ Zrt.

58/83 MEZŐK Megnevezés

Leírás

XML címkenév

Bilat azonosító



A bilatnál használt NominationIds nominálási azonosító lista. UNBUNDLED esetben csak egy elemű, BUNDLED esetben a zónáknak megfelelő sorrendben adjuk vissza

String

Átadó EIC kódja

Az átadó rendszerhasználó SellerNetworkUserEic EIC kódja

String

Átvevő EIC kódja


ajánlat Id

Formátum / típus Long



String

Kapacitás típus


CapacityType

BUNDLED, UNBUNDLED

Átadás iránya

Direkt, vissza

Direction

DIRECT, REVERSE

Áramlási irány

Fizikai, Backhaul

GasFlow

PHYSICAL, BACKHAUL

Termék típus




nem ProductQuality

FIRM, INTERRUPTIBLE



nem Standard


Zónák

Az érintett zónák listája. Zones BUNDLED esetben a pont tulajdonságainak megfelelő sorrendben adjuk őket vissza. UNBUNDLED esetben egy elemű a lista.

String


Date

Átadás időpontja

Date


Órai mennyiség

Az átadásra kínált kapacitás HourlyQuantity


Integer

FGSZ Zrt.

59/83 Megnevezés

Leírás mennyiség mértékegységben

XML címkenév

Formátum / típus

kWh/h


Date

Megjegyzés


String

Státusz


WAITING_FOR_TSO, REFUSED_BY_TSO, REVOKED_BY_SELLER, WAITING_FOR_BUYER, REJECTED_BY_BUYER, APPROVED, CLOSED, EXPIRED

Záró státusz


Elutasítás oka

A TSO Tag, az átadó, vagy az RefuseComment átvevő tölti ki abban az esetben, ha elutasítja, visszavonja, vagy visszautasítja a bilatot.

Status

előtti FinalStatus


PÉLDA <ns2:GetBilateralOffersByBuyerResponse xmlns:ns2="http://rbp.hu"> 150 KECSANAD1HBN ROUKECSANAD1HBN <SellerNetworkUserEic>39X50EONTRADE00B <PartnerNetworkUserEic>39X50SHELL00001Y 21Z000000000236Q BUNDLED


FGSZ Zrt.

60/83 DIRECT PHYSICAL YEARLY FIRM <Standard>STANDARD HUN ROU <StartDate>2015-08-27Z <EndDate>2015-09-15Z 1000 2015-08-27Z Offer cpacity to SHELL <Status>WAITING_FOR_TSO

7.5. BILATERÁLIS KAPACITÁS ÁTADÁS ELUTASÍTÁSA ÜZEMELTETŐK SZÁMÁRA (REFUSEBILATERALOFFERBYTSO) ÜZLETI CÉL, KÖRNYEZET A megfelelő jogosultsággal rendelkező üzemeltetők elutasíthatják azokat a bilaterális kapacitás felajánlásokat, amelyekben érintettek és éppen folyamatban vannak. LEÍRÁS A szolgáltatás kizárólag WAITING_FOR_TSO státuszban lévő ajánlatok esetében hívható meg SZEREPLŐK, SZEREPKÖRÖK • • • •


ÜTEMEZÉS, HATÁRIDŐK A bilat érvényességi idejéig lehet a szolgáltatást meghívni. Amennyiben ez nem valósul meg, EXPIRED státuszba kerül a bilat.


FGSZ Zrt.

61/83 ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet a szolgáltatást meghívni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilat jóváhagyó jogosultsággal. Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést.


FGSZ Zrt.

62/83 Ellenőrzés Csak létező bilaterális kapacitás átadást lehet elutasítani.

Hibaüzenet azonosítója BILATERAL_OFFER_IS_NOT_EXISTS

Csak olyan bilaterális kapacitás átadást lehet elutasítani, BILATERAL_OFFER_OPERATOR_IS_NOT_ASSIGNED_TO_THE_OFFER amelyiknél a TSO Tag operátora egy érintett zónának. Csak olyan bilaterális kapacitás átadást lehet elutasítani, BILATERAL_OFFER_IT_HAS_BEEN_ALREADY_APPROVED amelyiket még nem hagyta jóvá az adott TSO Tag. Csak olyan bilaterális kapacitás átadást lehet jóváhagyni, amelyik BILATERAL_OFFER_INVALID_OPERATION WAITING_FOR_TSO státuszban van.


FGSZ Zrt.

7.5.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS RefuseBilateralOfferByTso STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt. MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Bilat azonosító

A bilaterális ajánlat azonosítója

Id

Long

Elutasítás oka

A TSO Tagnak indokolnia kell, Comment hogy miért utasította el az átadást.

String

PÉLDA 999 Not enough capacity. Only 100kWh/h is available for the selected period and type.



MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Hibakód

Hibakód

error

String


64/83 PÉLDA <soap:Body> <soap:Fault> soap:Server INVALID_REFUSE <detail> <ns1:BilateralOfferWebServiceFault xmlns:ns1="http://rbp.hu"> <error>BILATERAL_OFFER_IS_NOT_EXISTS

7.6. BILATERÁLIS KAPACITÁS ÁTADÁS JÓVÁHAGYÁSA ÜZEMELTETŐK SZÁMÁRA (APPROVEBILATERALOFFERBYTSO) ÜZLETI CÉL, KÖRNYEZET A megfelelő jogosultsággal rendelkező üzemeltetők jóváhagyhatják azokat a bilaterális kapacitás felajánlásokat, amelyekben érintettek és éppen folyamatban vannak. LEÍRÁS A szolgáltatás kizárólag WAITING_FOR_TSO státuszban lévő ajánlatok esetében hívható meg SZEREPLŐK, SZEREPKÖRÖK • • • •


ÜTEMEZÉS, HATÁRIDŐK A bilat érvényességi idejéig lehet a szolgáltatást meghívni. Amennyiben ez nem valósul meg, EXPIRED státuszba kerül a bilat. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet a szolgáltatást meghívni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilat TSO Tag jóváhagyó jogosultsággal.


FGSZ Zrt.

65/83 Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést.


FGSZ Zrt.

66/83 Ellenőrzés Csak létező bilaterális kapacitás átadást lehet jóváhagyni.


Csak olyan bilaterális kapacitás átadást lehet jóváhagyni, BILATERAL_OFFER_OPERATOR_IS_NOT_ASSIGNED_TO_THE_OFFER amelyiknél a TSO Tag operátora egy érintett zónának. Csak olyan bilaterális kapacitás átadást lehet jóváhagyni, BILATERAL_OFFER_IT_HAS_BEEN_ALREADY_APPROVED amelyiket még nem hagyta jóvá az adott TSO Tag. Csak olyan bilaterális kapacitás átadást lehet jóváhagyni, amelyik BILATERAL_OFFER_INVALID_OPERATION WAITING_FOR_TSO státuszban van.


FGSZ Zrt.

7.6.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS ApproveBilateralOfferByTso STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt. MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Bilat azonosító


Id

Long

PÉLDA <ApproveBilateralOfferByTsoRequest> 999



MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Hibakód

Hibakód

error

String

PÉLDA <soap:Body> <soap:Fault> soap:Server INVALID_APPROVAL Gázipari Kommunikációs Szabvány

68/83 <detail> <ns1:BilateralOfferWebServiceFault xmlns:ns1="http://rbp.hu"> <error>BILATERAL_OFFER_IS_NOT_EXISTS

7.7. BILATERÁLIS KAPACITÁS ÁTADÁS VISSZAVONÁSA AZ ÁTADÓ SZÁMÁRA (REVOKEBILATERALOFFERBYSELLER) ÜZLETI CÉL, KÖRNYEZET A megfelelő jogosultsággal rendelkező rendszerhasználók visszavonhatják azokat a bilaterális kapacitás felajánlásokat, amelyeket ők hoztak létre. LEÍRÁS A szolgáltatás kizárólag WAITING_FOR_TSO és WAITING_FOR_BUYER státuszban lévő ajánlatok esetében hívható meg SZEREPLŐK, SZEREPKÖRÖK • • • •


ÜTEMEZÉS, HATÁRIDŐK A bilat érvényességi idejéig lehet a szolgáltatást meghívni. Amennyiben ez nem valósul meg, EXPIRED státuszba kerül a bilat. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet a szolgáltatást meghívni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilaterális kapacitás átadás jogosultsággal. Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést.


FGSZ Zrt.

69/83 Ellenőrzés Csak létező bilaterális kapacitás átadást lehet visszavonni.


Csak olyan bilaterális kapacitás átadást lehet visszavonni, OFFER_BILATERAL_REVOKE_BY_SELLER_INVALID_NU amelyiknél a rendszerhasználó az átadó. Csak olyan bilaterális kapacitás átadást lehet visszavonni, amelyik BILATERAL_OFFER_INVALID_OPERATION WAITING_FOR_TSO vagy WAITING_FOR_BUYER státuszban van.


FGSZ Zrt.

7.7.1 A KÉRÉST TARTALMAZÓ ÜZENET

METÓDUS RevokeBilateralOfferBySeller STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt. MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Bilat azonosító


Id

Long

Visszavonás oka

Az átadónak indokolnia kell, Comment hogy miért vonta vissza el az átadást.

String

PÉLDA 999 I have changed my mind.



MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Hibakód

Hibakód

error

String


71/83 PÉLDA <soap:Body> <soap:Fault> soap:Server INVALID_REVOKE <detail> <ns1:BilateralOfferWebServiceFault xmlns:ns1="http://rbp.hu"> <error>BILATERAL_OFFER_IS_NOT_EXISTS

7.8. BILATERÁLIS KAPACITÁS ÁTADÁS VISSZAUTASÍTÁSA AZ ÁTVEVŐ SZÁMÁRA (REJECTBILATERALOFFERBYBUYER) ÜZLETI CÉL, KÖRNYEZET A megfelelő jogosultsággal rendelkező rendszerhasználók visszautasíthatják azokat a bilaterális kapacitás felajánlásokat, amelyekben ők a kedvezményezettek. LEÍRÁS A szolgáltatás kizárólag WAITING_FOR_TSO és WAITING_FOR_BUYER státuszban lévő ajánlatok esetében hívható meg SZEREPLŐK, SZEREPKÖRÖK • • • •


ÜTEMEZÉS, HATÁRIDŐK A bilat érvényességi idejéig lehet a szolgáltatást meghívni. Amennyiben ez nem valósul meg, EXPIRED státuszba kerül a bilat. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet a szolgáltatást meghívni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilaterális kapacitás jóváhagyás jogosultsággal.


FGSZ Zrt.

72/83 Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést.


FGSZ Zrt.

73/83 Ellenőrzés Csak létező bilaterális kapacitás átadást lehet visszautasítani.


Csak olyan bilaterális kapacitás átadást lehet visszautasítani, NU_IS_NOT_THE_SELECTED_PARTNER amelyiknél a rendszerhasználó a kedvezményezett. Csak olyan bilaterális kapacitás átadást lehet visszavonni, amelyik BILATERAL_OFFER_INVALID_OPERATION WAITING_FOR_TSO vagy WAITING_FOR_BUYER státuszban van.


FGSZ Zrt.

7.8.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS RejectBilateralOfferByBuyer STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt. MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Bilat azonosító


Id

Long

Visszautasítás oka

Az átvevőnek indokolnia kell, Comment hogy miért utasította vissza az átadást.

PÉLDA 999 I don’t need the capacity.


String

75/83 Ellenőrzés Csak létező bilaterális kapacitás átadást lehet visszautasítani.


Csak olyan bilaterális kapacitás átadást lehet visszautasítani, NU_IS_NOT_THE_SELECTED_PARTNER amelyiknél a rendszerhasználó a kedvezményezett. Csak olyan bilaterális kapacitás átadást lehet visszavonni, amelyik BILATERAL_OFFER_INVALID_OPERATION WAITING_FOR_TSO vagy WAITING_FOR_BUYER státuszban van.


FGSZ Zrt.



MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Hibakód

Hibakód

error

String

PÉLDA <soap:Body> <soap:Fault> soap:Server INVALID_REJECT <detail> <ns1:BilateralOfferWebServiceFault xmlns:ns1="http://rbp.hu"> <error>BILATERAL_OFFER_IS_NOT_EXISTS

7.9. BILATERÁLIS KAPACITÁS ÁTADÁS JÓVÁHAGYÁSA ÁTVEVŐK SZÁMÁRA (APPROVEBILATERALOFFERBYBUYER) ÜZLETI CÉL, KÖRNYEZET A megfelelő jogosultsággal rendelkező rendszerhasználók jóváhagyhatják azokat a bilaterális kapacitás felajánlásokat, amelyekben érintettek és éppen folyamatban vannak. LEÍRÁS A szolgáltatás kizárólag WAITING_FOR_TSO státuszban lévő ajánlatok esetében hívható meg Gázipari Kommunikációs Szabvány

77/83 SZEREPLŐK, SZEREPKÖRÖK • • • •


ÜTEMEZÉS, HATÁRIDŐK A bilat érvényességi idejéig lehet a szolgáltatást meghívni. Amennyiben ez nem valósul meg, EXPIRED státuszba kerül a bilat. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet a szolgáltatást meghívni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilat jóváhagyó jogosultsággal. Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést.


FGSZ Zrt.

78/83 Ellenőrzés Csak létező bilaterális kapacitás átadást lehet jóváhagyni.


Csak olyan bilaterális kapacitás átadást lehet jóváhagyni, NU_IS_NOT_THE_SELECTED_PARTNER amelyiknél a rendszerhasználó a kedvezményezett. Csak olyan bilaterális kapacitás átadást lehet jóváhagyni, amelyik BILATERAL_OFFER_INVALID_OPERATION WAITING_FOR_BUYER státuszban van.


FGSZ Zrt.

7.9.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS ApproveBilateralOfferByBuyer STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt. MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Bilat azonosító


Id

Long

PÉLDA <ApproveBilateralOfferByBuyerRequest> 999



MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Hibakód

Hibakód

error

String

PÉLDA <soap:Body> <soap:Fault> soap:Server INVALID_APPROVAL



7.10. BILATERÁLIS KAPACITÁS ÁTADÁS LEZÁRÁS ÜZEMELTETŐK SZÁMÁRA (CLOSEBILATERALOFFERBYTSO) ÜZLETI CÉL, KÖRNYEZET A megfelelő jogosultsággal rendelkező üzemeltetők lezárhatják azokat a bilaterális kapacitás felajánlásokat, amelyekben érintettek. LEÍRÁS A szolgáltatás kizárólag REFUSED_BY_TSO, REVOKED_BY_SELLER, REJECTED_BY_BUYER, APPROVED vagy EXPIRED státuszokban lévő ajánlatok esetében hívható meg SZEREPLŐK, SZEREPKÖRÖK • • • •


ÜTEMEZÉS, HATÁRIDŐK A szolgáltatást bármikor meg lehet hívni, a lejárati idő előtt és után is. ÜZLETI FELTÉTELRENDSZER, MEGSZORÍTÁSOK Kizárólag érvényes tanúsítvánnyal lehet a szolgáltatást meghívni. Ezen kívül a tanúsítvány tulajdonosának rendelkeznie kell bilat TSO Tag jóváhagyó jogosultsággal. Amennyiben ezek nem teljesülnek, megtagadjuk a hozzáférést.


FGSZ Zrt.

81/83 Ellenőrzés Csak létező bilaterális kapacitás átadást lehet lezárni.


Csak olyan bilaterális kapacitás átadást lehet lezárni, amelyiknél a BILATERAL_OFFER_OPERATOR_IS_NOT_ASSIGNED_TO_THE_OFFER TSO operátora egy érintett zónának. Csak olyan bilaterális kapacitás átadást lehet lezárni, amelyik BILATERAL_OFFER_INVALID_OPERATION REFUSED_BY_TSO, REVOKED_BY_SELLER, REJECTED_BY_BUYER, APPROVED vagy EXPIRED státuszban van.


FGSZ Zrt.

7.10.1 A KÉRÉST TARTALMAZÓ ÜZENET METÓDUS CloseBilateralOfferByTso STRUKTÚRA, CÍMKÉK LEÍRÁSA Az XML üzenet logikai szerkezete az alábbi struktúra szerint épül fel. • Fejrész • Tartalom A fejrész nem tartalmaz üzleti információt. MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Bilat azonosító


Id

Long

PÉLDA 999



MEZŐK Megnevezés

Leírás

XML címkenév

Formátum / típus

Hibakód

Hibakód

error

String

PÉLDA <soap:Body> <soap:Fault> soap:Server INVALID_CLOSE




FGSZ Zrt.

Regional Booking Platform Webservice szolgáltatás illeszkedési felület dokumentáció

Recommend Documents