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

Átírás

1 Regional Booking Platform Webservice szolgáltatás illeszkedési felület dokumentáció 4.2 verzió Készítette: IP Rendszerintegrátor Kft.

2 Tartalomjegyzék 1. A dokumentum célja Bevezetés Fogalomtár Hálózati infrastruktúra Szereplők Alapelvek Koncepció Műszaki informatikai megvalósításra vonatkozó alapelvek Rendelkezésre állás A regional booking platform elérhetősége Azonosítás, tanúsítványok Alkalmazott protokollok, kódolás Üzenetek érvényessége validálás Archiválás Ajánlatadás Aukció adatok lekérdezése (getauctions) A kérést tartalmazó üzenet A választ tartalmazó üzenet Tömeges ajánlat beadás (bulkmakebids) A kérést tartalmazó üzenet A választ tartalmazó üzenet UPTA ajánlatok törlése (bulkremoveuptabids) A kérést tartalmazó üzenet A választ tartalmazó üzenet Web service kommunikáció az RBP és a TSO Tag között Tarifa és áradatok küldése IP-ből RBP-be RBP aukciók eredményeinek importja Bilaterális kapacitás átadás Bilaterális ajánlat beadás (OfferBilateralCapacity) A kérést tartalmazó üzenet A választ tartalmazó üzenet Bilaterális kapacitás átadások lekérdezése üzemeltetők számára (GetBilateralOffersByTso)... 45

3 7.2.1 A kérést tartalmazó üzenet A választ tartalmazó üzenet Bilaterális kapacitás átadások lekérdezése az átadó számára (GetBilateralOffersBySeller) A kérést tartalmazó üzenet A választ tartalmazó üzenet Bilaterális kapacitás átadások lekérdezése az átvevő számára (GetBilateralOffersByBuyer) A kérést tartalmazó üzenet A választ tartalmazó üzenet Bilaterális kapacitás átadás elutasítása üzemeltetők számára (RefuseBilateralOfferByTso) A kérést tartalmazó üzenet A választ tartalmazó üzenet Bilaterális kapacitás átadás jóváhagyása üzemeltetők számára (ApproveBilateralOfferByTso) A kérést tartalmazó üzenet A választ tartalmazó üzenet Bilaterális kapacitás átadás visszavonása az átadó számára (RevokeBilateralOfferBySeller) A kérést tartalmazó üzenet A választ tartalmazó üzenet Bilaterális kapacitás átadás visszautasítása az átvevő számára (RejectBilateralOfferByBuyer) A kérést tartalmazó üzenet A választ tartalmazó üzenet Bilaterális kapacitás átadás jóváhagyása átvevők számára (ApproveBilateralOfferByBuyer) A kérést tartalmazó üzenet A választ tartalmazó üzenet Bilaterális kapacitás átadás lezárás üzemeltetők számára (CloseBilateralOfferByTso) A kérést tartalmazó üzenet A választ tartalmazó üzenet... 82

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

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

6 3. FOGALOMTÁR 3.1. HÁLÓZATI INFRASTRUKTÚRA RBP Kapacitás Ascending Clock (ACTA) aukció 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ó é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. 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 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) Small Price Step (SPS) 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. 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ő.

7 3.2. SZEREPLŐK Szállítási rendszerüzemeltető tag (TSO Tag) Rendszerhasználó Tag (NU Tag) Regional Booking Platform Üzemeltető (RBP Üzemeltető) 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 önmagában is egy RBP TSO 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. 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).

8 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

9 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 MŰSZAKI INFORMATIKAI MEGVALÓSÍTÁSRA VONATKOZÓ ALAPELVEK 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 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: 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: 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: 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ő 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 ALKALMAZOTT PROTOKOLLOK, KÓDOLÁS A kommunikáció HTTPS protokollon zajlik, melyen keresztül XML (1.0 ötödik kiadás, ü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:

10 o o o UTF-8 : HTTPS: SOAP: XML Séma leírók elérhetősége o xmlns:soapenv=" o xmlns:xsd= o xmlns:xsi= Ü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 ARCHIVÁLÁS Az RBP Üzemeltető 5 évre archiválja a web service üzeneteket.

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

12 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 <getauctions> <request/> </getauctions> 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

13 o o o o LPS SPS Aktuális árlépcső százalékban 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

14 MEZŐK Megnevezés Leírás XML címkenév Formátum / típus Aukció név Egy 8 jegyú karaktersorozat, ami az aukció egyértelmű azonosítására szolgál. auctionname String Hálózati pont A hálózati pont neve capacitypointname String neve Hálózati pont EIC kódja A hálózati pont EIC kódja eic String Termék típus Éves, negyedéves, havi, napi, napon belüli, STRIP prodcttype YEARLY, QUARTERLY MONTHLY, DAILY, WITHINDAY, STRIP Termék név Vonatkozási időszak productname String Megszakíthatóság Megszakítható, nem productquality FIRM, INTERRUPTIBLE megszakítható 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, szezonális standard STANDARD, NON_STANDARD, NON_STANDARD- SEASONAL 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

15 Megnevezés Leírás XML címkenév Formátum / típus Aktuális árlépcső százalék (ACTA) A kiinduló árhoz viszonyított százalék pricestep Integer Igényelt mennyiség (ACTA) Az ajánlatban igényelt mennyiség quantity Integer Ajánlott (UPTA) ár Az egységár amennyit az igényelt mennyiségért fizet price Integer Igényelt mennyiség (UPTA) Az ajánlatban igényelt mennyiség bidquantity Integer Minimum mennyiség (UPTA) Az amennyiség, amennyinél kevesebbet már nem szeretne vásárolni az ajánlattevő minquantity Integer PÉLDA <getauctionsresponse> <return> <actabids> <bid> <auctionname> </auctionname> <capacitypointname>érsekvadkert</capacitypointname> <eic>39zveersekv11gni</eic> <producttype>monthly</producttype> <productname> </productname> <productquality>firm</productquality> <capacitytype>unbundled</capacitytype> <direction>direct</direction> <gasflow>physical</gasflow> <standard>standard</standard> <reserveprice> HUF</reservePrice> <capacityoffered>10000</capacityoffered> <lps>0</lps> <sps>0</sps> <pricestep>0</pricestep> <quantity>9700</quantity> </bid> <bid>

16 <auctionname> </auctionname> <capacitypointname>érsekvadkert</capacitypointname> <eic>39zveersekv11gni</eic> <producttype>monthly</producttype> <productname> </productname> <productquality>firm</productquality> <capacitytype>unbundled</capacitytype> <direction>direct</direction> <gasflow>physical</gasflow> <standard>standard</standard> <reserveprice> HUF</reservePrice> <capacityoffered>10000</capacityoffered> <lps>1</lps> <sps>0</sps> <pricestep>10</pricestep> <quantity>6000</quantity> </bid> <bid> <auctionname> </auctionname> <capacitypointname>érsekvadkert</capacitypointname> <eic>39zveersekv11gni</eic> <producttype>monthly</producttype> <productname> </productname> <productquality>firm</productquality> <capacitytype>unbundled</capacitytype> <direction>direct</direction> <gasflow>physical</gasflow> <standard>standard</standard> <reserveprice> HUF</reservePrice> <capacityoffered>10000</capacityoffered> <lps>2</lps> <sps>0</sps> <pricestep>20</pricestep> <quantity>5000</quantity> </bid> </actabids> <uptabids> <bid> <auctionname> </auctionname> <capacitypointname>fót</capacitypointname> <eic>39zvefot00011gnm</eic> <producttype>daily</producttype> <productname> </productname>

17 <productquality>firm</productquality> <capacitytype>unbundled</capacitytype> <direction>direct</direction> <gasflow>physical</gasflow> <standard>standard</standard> <reserveprice> HUF</reservePrice> <capacityoffered>10000</capacityoffered> <price>5000</pricestep> <bidquantity>1000</bidquantity> <minquantity>800</minquantity> </bid> <bid> <auctionname> </auctionname> <capacitypointname>gyál</capacitypointname> <eic>39zvegyal0011gnp</eic> <producttype>daily</producttype> <productname> </productname> <productquality>firm</productquality> <capacitytype>unbundled</capacitytype> <direction>direct</direction> <gasflow>physical</gasflow> <standard>standard</standard> <reserveprice> HUF</reservePrice> <capacityoffered>10000</capacityoffered> <price>5000</pricestep> <bidquantity>1000</bidquantity> <minquantity>800</minquantity> </bid> </uptabids> </return> </getauctionsresponse> 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

18 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:

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

20 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 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_ 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

21 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 XML címkenév Formátum / típus Aukció név Egy 8 jegyű karaktersorozat, ami az aukció egyértelmű azonosítására szolgál. auctionname 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 kiinduló ár százalékában (%) kifejezve. price Integer Igényelt mennyiség (UPTA) Igényelt mennyiség UPTA esetében. bidquantity Integer Minimum mennyiség (UPTA) Minimum vásárolni kívánt mennyiség UPTA esetében. minquantity Integer

22 22/83 PÉLDA <bulkmakebids> <request> <actabids> <bid> <auctionname> </auctionname> <lps>0</lps> <sps>0</sps> <quantity>9000</quantity> </bid> </actabids> <uptabids> <bid> <auctionname> </auctionname> <price>5000</price> <bidquantity>1000</bidquantity> <minquantity>800</minquantity> </bid> </uptabids> </request> </bulkmakebids> 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 XML címkenév Formátum / típus Aukció név Egy 8 jegyű karaktersorozat, ami az aukció egyértelmű azonosítására szolgál. auctionname String Hibakód Hibakód error String

23 23/83 PÉLDA <soap:body> <soap:fault> <faultcode>soap:server</faultcode> <faultstring>invalid_request<faultstring> <detail> <BulkMakeBidsFault> <faultinfo> <error> <auctionname> </auctionname> <error>bid_quantity_greater_previous_bid_quantity</error> </error> </faultinfo> </BulkMakeBidsFault> </detail> </soap:fault> </soap:body> 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.

24 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:

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

26 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 Formátum / típus Aukció név Egy 8 jegyű karaktersorozat, ami az aukció egyértelmű azonosítására szolgál. auctionname String PÉLDA <bulkremoveuptabids> <request> <AuctionNames> <auctionname> </auctionname> <auctionname> </auctionname> </AuctionNames> </request> </bulkmakebids> 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 27/83 o o Aukciónév Hibakód MEZŐK Megnevezés Leírás XML címkenév Formátum / típus Aukció név Egy 8 jegyű karaktersorozat, ami az aukció egyértelmű azonosítására szolgál. auctionname String Hibakód Hibakód error String PÉLDA <soap:body> <soap:fault> <faultcode>soap:server</faultcode> <faultstring>invalid_request<faultstring> <detail> <BulkRemoveUptaBidsFault> <faultinfo> <error> <auctionname> </auctionname> <error>bidding_not_allowed</error> </error> </faultinfo> </BulkRemoveUptaBidsFault> </detail> </soap:fault> </soap:body>

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

29 29/83 MEZŐK 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) 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 publikálásának napja gasday String Hálózati pont EIC kódja A hálózati pont EIC kódja eiccode String Hálózati neve pont A hálózati pont neve capacitypointname String Kapacitás adatok A kapacitás adatok a termék típus, megszakíthatóság, áramlási irány és hálózati pontok szerint vannak elküldve. Ezen kívül napi és órai adatok is biztosítva lesznek. capacitybynetworkpoints YEARLY, QUARTERLY MONTHLY, DAILY, WITHINDAY, STRIP Megszakíthatóság Megszakítható, megszakítható nem productquality FIRM, INTERRUPTIBLE Hálózati iránya pont Direkt, vissza direction DIRECT, REVERSE Áramlási irány Fizikai, Backhaul gasflow PHYSICAL, BACKHAUL

30 Megnevezés Leírás XML címkenév Formátum / típus 30/83 Szabványos kapacitástermék Szabványos, szabványos, szezonális nem standard STANDARD, NON_STANDARD, NON_STANDARD- SEASONAL Kiinduló ár A kiinduló ár devizával együtt, termék típus, megszakíthatóság, áramlási irány és hálózati pontok szerint reserveprice 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=" xmlns:ser=" <soapenv:header/> <soapenv:body> <ser:uploadcapacityandtariff> <capacityandtariffdata> <tsoeiccode>21x-ro-a-a0a0a-s</tsoeiccode> <gasday> </gasday> <capacitylist> <capacitybynetworkpoints> <eiccode>21z q</eiccode> <capacitypointname>csanádpalota (HU>RO)</capacityPointName> <direction>direct</direction> <capacitydatarows> <yearlycapacity> <firmdailycapacity>2</firmdailycapacity> <firmhourlycapacity>50</firmhourlycapacity> <interruptibledailycapacity>960</interruptibledailycapacity> <interruptiblehourlycapacity>40</interruptiblehourlycapacity> <backhauldailycapacity>600</backhauldailycapacity> <backhaulhourlycapacity>25</backhaulhourlycapacity> </yearlycapacity> <quarterlycapacity> <firmdailycapacity>480</firmdailycapacity>

31 31/83 <firmhourlycapacity>2</firmhourlycapacity> <interruptibledailycapacity>96</interruptibledailycapacity> <interruptiblehourlycapacity>4</interruptiblehourlycapacity> <backhauldailycapacity> </backhauldailycapacity> <backhaulhourlycapacity>10</backhaulhourlycapacity> </quarterlycapacity> <quarterlycapacity> <firmdailycapacity>480</firmdailycapacity> <firmhourlycapacity>20</firmhourlycapacity> <interruptibledailycapacity>96</interruptibledailycapacity> <interruptiblehourlycapacity>4</interruptiblehourlycapacity> <backhauldailycapacity> </backhauldailycapacity> <backhaulhourlycapacity>10</backhaulhourlycapacity> </quarterlycapacity> <monthlycapacity> <firmdailycapacity>12000</firmdailycapacity> <firmhourlycapacity>500</firmhourlycapacity> <interruptibledailycapacity>2400</interruptibledailycapacity> <interruptiblehourlycapacity>100</interruptiblehourlycapacity> <backhauldailycapacity>7200</backhauldailycapacity> <backhaulhourlycapacity>300</backhaulhourlycapacity> </monthlycapacity> <dailycapacity> <firmdailycapacity>720</firmdailycapacity> <firmhourlycapacity>30</firmhourlycapacity> <interruptibledailycapacity>240</interruptibledailycapacity> <interruptiblehourlycapacity>10</interruptiblehourlycapacity> <backhauldailycapacity>1200</backhauldailycapacity> <backhaulhourlycapacity>50</backhaulhourlycapacity> </dailycapacity> </capacitydatarows> </capacitybynetworkpoints> </capacitylist> <reservepricelist> <reservepricebynetworkpoints> <eiccode>21z q</eiccode> <capacitypointname>csanádpalota (HU>RO)</capacityPointName> <direction>direct</direction> <reservepricedatarows> <yearlyreserveprice> <producttype>yearly</producttype> <firmcapacityprice>661</firmcapacityprice>

32 32/83 <interruptiblecapacityprice> </interruptiblecapacityprice> <backhaulcapacityprice>666</backhaulcapacityprice> <seasonalcapacityprice>1000</seasonalcapacityprice> <lps>10</lps> <sps>1</sps> </yearlyreserveprice> <quarterlyreserveprice> <producttype>quarterly</producttype> <firmcapacityprice>20000</firmcapacityprice> <interruptiblecapacityprice> </interruptiblecapacityprice> <backhaulcapacityprice>1900</backhaulcapacityprice> <lps>18</lps> <sps>9</sps> </quarterlyreserveprice> <monthlyreserveprice> <producttype>monthly</producttype> <firmcapacityprice>30000</firmcapacityprice> <interruptiblecapacityprice> </interruptiblecapacityprice> <backhaulcapacityprice>3000</backhaulcapacityprice> <lps>16</lps> <sps>4</sps> </monthlyreserveprice> <dailyreserveprice> <producttype>daily</producttype> <firmcapacityprice>40000</firmcapacityprice> <interruptiblecapacityprice> </interruptiblecapacityprice> <backhaulcapacityprice>6000</backhaulcapacityprice> <lps>15</lps> <sps>1</sps> </dailyreserveprice> </reservepricedatarows> </reservepricebynetworkpoints> </reservepricelist> </capacityandtariffdata> </ser:uploadcapacityandtariff> </soapenv:body> </soapenv:envelope> A VÁLASZT TARTALMAZÓ ÜZENET

33 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=" <soap:body> <ns2:uploadcapacityandtariffresponse xmlns:ns2=" </soap:body> </soap:envelope> 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.

34 34/83 Ezek hiányában a hozzáférés megtagadásra kerül 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 XML címkenév Formátum / típus TSO Tag EIC kódja A releváns TSO Tag EIC kódja tsoeiccode String Időintervallum (from to) Az a tól ig időszak, melyek között a TRADE-k lekérdezésre kerülnek gasday String PÉLDA <soap:envelope xmlns:soap=" <soap:body> <ns2:gettrades xmlns:ns2=" <request> <tsoeiccode>21x-hu-a-a0a0a-8</tsoeiccode> <from> t14:32:00.000z</from> <to> t14:32:08.000z</to> </request> </ns2:gettrades> </soap:body> </soap:envelope> A VÁLASZT TARTALMAZÓ ÜZENET

35 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. MEZŐK 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ó Megnevezés Leírás XML címkenév Formátum / típus Trade azonosító A Trade azonosítására szolgáló szám tradeid String Aukció név Egy 8 jegyű karaktersorozat, ami az aukció egyértelmű azonosítására szolgál. auctionname String Rendszerhasználó A rendszerhasználó EIC netwokrusereic String

36 36/83 EIC kódja kódja Rendszerhasználó Operátor kódja A rendszerhasználó operátori kódja networkusercode String Rendszerhasználó neve Hálózati pont EIC kódja A rendszerhasználó neve netwokrusername String A hálózati pont EIC kódja networkpointeic String Hálózati neve pont A hálózati pont neve networkpointname String Hálózati pont IP kódja (nomination ID) A releváns hálózati pont IP kódja (nomination ID) networkpointnominationid String Termék típus Éves, negyedéves, havi, napi, napon belüli, STRIP prodcttype YEARLY, QUARTERLY MONTHLY, DAILY, WITHINDAY, STRIP Instrument Vonatkozási időszak instrument String Érvényesség kezdete Az érvényesség kezdő dátuma validitystart String Érvényesség vége Az érvényesség végét jelző dátum validityend String Kapacitás típus Kapcsolt, nem kapcsolt capacitytype BUNDLED, UNBUNDLED Megszakíthatóság Megszakítható, megszakítható nem capacityquality FIRM, INTERRUPTIBLE Áramlási irány Fizikai, Backhaul gasflow PHYSICAL, BACKHAUL Szabványos kapacitástermék Szabványos, nem szabványos, szezonális standard STANDARD, NON_STANDARD, NON_STANDARD- SEASONAL Allokált mennyiség Az érintett rendszerhasználónak allocatedcapacity String

37 37/83 allokált mennyiség Kiinduló ár A kiinduló ár devizával együtt reserveprice String Elszámoló ár Aukciós felárral növelt kiinduló ár clearingprice String Aukciós felár Elnyert kapacitásért, a kiinduló ár mellett fizetendő felár clearingpremium String Ügyletazonosító Ügylet pontos azonosítására szolgáló egyedi ID confirmatonid String PÉLDA <soap:envelope xmlns:soap=" <soap:body> <ns2:gettradesresponse xmlns:ns2=" <return> <trades> <trade> <tradeid>150</tradeid> <auctionname> </auctionname> <auctionstart> T09:54:28.808Z</auctionStart> <networkusereic>15x-gdf-suez--- 2</networkUserEic> <networkusercode>gdfsuez</networkusercode> <networkusername>gdf SUEZ Energia Magyarország Zrt.</networkUserName> <networkpointeic>39wsiforrasfsen2</networkpointeic> <networkpointname>egyesített Kitárolás</networkPointName> <networkpointnominationid>siforrasfsen</networkpointnominationid> <producttype>yearly</producttype> <instrument>2015 GASYEAR</instrument> <validitystart> </validitystart> <validityend> </validityend>

38 --2/ </confirmationId> 14T09:54:28.808Z</auctionStart> 2</networkUserEic> Magyarország Zrt.</networkUserName> 38/83 <capacitytype>unbundled</capacitytype> <capacityquality>firm</capacityquality> <gasflow>physical</gasflow> <standard>standard</standard> <allocatedcapacity> </allocatedcapacity> <reserveprice>418.29</reserveprice> <clearingprice>418.29</clearingprice> <clearingpremium>0</clearingpremium> <confirmationid>21x-hu-a-a0a0a-8/15x-gdf-suez- <pricedecimals>4</pricedecimals> </trade> <trade> <tradeid>151</tradeid> <auctionname> </auctionname> <auctionstart> <networkusereic>15x-gdf-suez--- <networkusercode>gdfsuez</networkusercode> <networkusername>gdf SUEZ Energia <networkpointeic>39wketeljcs58en1</networkpointeic> <networkpointname>mol Nyrt KTD összevont betáplálási pontja (2/S)</networkPointName> <networkpointnominationid>keteljcs58en</networkpointnominationid> <producttype>yearly</producttype> <instrument>2015 GASYEAR</instrument> <validitystart> </validitystart> <validityend> </validityend> <capacitytype>unbundled</capacitytype> <capacityquality>firm</capacityquality> <gasflow>physical</gasflow> <standard>standard</standard> <allocatedcapacity>1000</allocatedcapacity> <reserveprice> </reservePrice> <clearingprice> </clearingPrice> <clearingpremium>0</clearingpremium> <confirmationid>21x-hu-a-a0a0a-8/15x-gdf-suez- --2/ </confirmationId> <pricedecimals>4</pricedecimals>

39 14T09:54:28.808Z</auctionStart> 2</networkUserEic> Magyarország Zrt.</networkUserName> </trade> <trade> <tradeid>152</tradeid> <auctionname> </auctionname> <auctionstart> <networkusereic>15x-gdf-suez--- 39/83 <networkusercode>gdfsuez</networkusercode> <networkusername>gdf SUEZ Energia <networkpointeic>39zsifgtarolsenx</networkpointeic> <networkpointname>egyesített Letárolás</networkPointName> <networkpointnominationid>sifgtarolsen</networkpointnominationid> <producttype>yearly</producttype> <instrument>2015 GASYEAR</instrument> <validitystart> </validitystart> <validityend> </validityend> <capacitytype>unbundled</capacitytype> <capacityquality>firm</capacityquality> <gasflow>physical</gasflow> <standard>standard</standard> <allocatedcapacity> </allocatedcapacity> <reserveprice>0</reserveprice> <clearingprice>0</clearingprice> <clearingpremium>0</clearingpremium> <confirmationid>21x-hu-a-a0a0a-8/15x-gdf-suez- --2/ </confirmationId> <pricedecimals>4</pricedecimals> </trade>

40 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 kezdete (UTC) :14: átadás Átkonvertált kezdete (UTC) átadás Átadás kezdete magyar idő szerint (CET) Megjegyzés :00: :00 Nyári időszámítás :00: :00 Téli időszámítás

41 41/83 04:59: :59: :00: :00 Téli időszámítás 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 (UTC) :14: :59: :59: Átkonvertált átadás vége (UTC) Átadás vége magyar idő szerint (CET) Megjegyzés :59: :59 Nyári időszámítás :59: :59 Téli időszámítás :59: :59 Nyári időszámítás Az érvényességet ezredmásodperc pontossággal rögzíti a rendszer, nem konvertáljuk.

42 42/83 Ellenőrzés Az vonatkozási időszak kezdetének korábbinak kell lennie, mint a végének. Az vonatkozási időszak kezdetének a 4 órás eltoláson kívülre kell esnie Hibaüzenet azonosítója OFFER_BILATERAL_CAPACITY_START_DATE_GREATER 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. A kiválasztott hálózati pontnak léteznie kell a rendszerben. A kiválasztott hálózati pontnak é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 OFFER_BILATERAL_CAPACITY_CAPACITY_POINT_NOT_EXISTS OFFER_BILATERAL_CAPACITY_CAPACITY_POINT_NOT_VALID Backhaul kapacitás csak megszakítható lehet. OFFER_BILATERAL_CAPACITY_BACKHAUL_FIRM Szezonális kapacitás csak nem megszakítható lehet. OFFER_BILATERAL_CAPACITY_SEASONAL_INTERRUPTIBLE Szezonális kapacitás csak éves lehet. OFFER_BILATERAL_CAPACITY_SEASONAL_NOT_YEARLY Nem szabványos kapacitás csak STRIP típusú lehet. OFFER_BILATERAL_CAPACITY_PRODUCT_TYPE_NOT_STRIP Az iránynak meg kell egyeznie a hálózati ponton értelmezett irányokkal. OFFER_BILATERAL_CAPACITY_DIRECTION_IS_INVALID STRIP termék csak nem megszakítható lehet OFFER_BILATERAL_CAPACITY_STRIP_MUST_BE_FIRM Az érvényesség vége a nem lehet a múltban OFFER_BILATERAL_CAPACITY_VALIDITY_IN_THE_PAST