Prosessityöryhmän kokous

Transkriptio

1 Pöytäkirja 1 (12) Prosessityöryhmän kokous Aika klo Paikka Duetto Business Park, Läkkisepäntie 23, Helsinki nh. Kuolajärvi Läsnä Marjut Puukangas (pj.) Kerttu Korpelainen (siht.) Esa Pietarinen Pasi Aho (asialistan kohdissa 1-4) Emmi Kaivosoja (asialistan kohdissa 6-10) Teemu Hellas (asialistan kohdissa 6-10) Raimo Toivanen PKS Sähkönsiirto Oy Tiina Leppälahti Helen Sähköverkko Oy Tomi Mäkelä Elenia Oy Jari Rusanen Loiste Sähköverkko Oy Kaisa Ylipeura Energiapolar Oy Saku Ruottinen Caruna Oy (Skype) Esa Kaario Tampereen Sähköverkko Oy Monika Lindberg Fortum Markets Oy Arttu Lahtinen Fortum Markets Oy Vesa Mäkilä SPS Energiapalvelut Oy Poissa Jari Nykänen Paikallisvoima ry 1 Kokouksen avaus Puheenjohtaja avasi kokouksen klo ja kävi läpi edellisen kokouksen pöytäkirjan. Pöytäkirjaan ei tullut läpikäynnin yhteydessä kommentoitavaa ja pöytäkirja hyväksyttiin. 2 Projektin tilannekatsaus Pasi Aho kertoi työryhmäläisille projektin ajankohtaisista tapahtumista, joita käytiin läpi myös datahub-ajankohtaiswebinaarissa Aho näytti vuoden 2018 projektin keskeiset tehtävät ja kertoi järjestelmähankinta-prosessista, jossa toimittajaksi valittiin CGI Suomi Oy. Järjestelmän toimitus sisältää järjestelmän suunnittelun, toteutuksen, testauksen ja käyttöönoton. Toimitus sisältää myös markkinaosapuolten sertifioinnit sekä tuki- ja ylläpitopalvelut eli hankittiin niin sanottu avaimet käteen ratkaisu. Aho kertoi myös hankintaprosessin kulusta ja miten lopputulokseen päädyttiin. Aho avasi myös järjestelmän kokonaiskustannuksia ja niiden jakautumista, jotka löytyvät esimateriaalista pöytäkirjan liitteenä. Työryhmässä heräsi kysymys onko datahubissa kyberturvallisuus huomioitu riittävällä tasolla ja onko olemassa riski kasvavista kustannuksista. Yle uutisoi datahub lainsäädännöstä ja uutisessa lain arviointineuvosto nosti esiin muun muassa datahubin kyberturvallisuuskysymyksiä. Aho vastasi, että datahub-järjestelmähankinnassa on varauduttu varsin kattavalla vaatimustasolla kyberturvallisuuteen ja sitä kautta toteutuksen tulisi siihen vastata. Uutisen myötä tehtiin lisäselvitystä lainsäädännön perustelumuistion tueksi ja uutisen ei nähdä esimerkiksi vaikuttavan datahub-lainsäädäntömuutosten etenemisaikatauluun.

2 Pöytäkirja 2 (12) Aho esitteli lyhyesti CGI Oy:n. CGI:n datahub ratkaisu perustuu Central Market System (CMS) 2 nimiseen järjestelmään. Tällä hetkellä projekti etenee kokonaissuunnitteluvaiheessa, josta siirrytään tarkennettuun suunnitteluvaiheeseen marras- tammikuussa. CGI on jo saanut datahub-projekteja maaliin ja Tanskassa, Hollannissa sekä Englannissa (vesimarkkinoilla) on jo käytössä CGI:n toteuttamat datahub-järjestelmät. Näin ollen Fingridillä ollaan erittäin luottavaisia valittuun järjestelmäratkaisuun ja toimittajaan. Datahubin lainsäädäntötyö on kesken ja parhaillaan lakiesitys on oikeusministeriöllä laintarkastuksessa. Näillä näkymin lakiesitys lähtenee viikolla 38 eduskunnan käsiteltäväksi. Aho kertoi myös käyttöönottosuunnittelutyön etenemisestä, työn alla on parhaillaan ohjeistus toimijoiden käyttöönottosuunnitelmien laatimiseksi. Käyttöönottotyöryhmä on käynnistetty työ suunnitelman päivittämiseksi ja käyttöönottosuunnitelman versio 2.0 tullaan julkaisemaan vuoden loppuun mennessä. Fingrid on käynnistänyt Energiaviraston kanssa sallitun tuoton valvontamallin valmistelun ja työn pitäisi valmistua kesäkuussa Tämän myötä päästään tarkentamaan datahubin maksukomponentit ja arviot yksikköhinnoista. Kun työ saadaan tähän pisteeseen päästään myös määrittämään datahubin ja markkinaosapuolten välille solmittavien palvelusopimusten sisältöä. Aho näytti myös projektin vuosikellosta mitä loppuvuoden osalta tulee tapahtumaan ja milloin. Työryhmien kokousten lisäksi tulossa on muun muassa alueellisia datahub-seminaaritilaisuuksia eli Datahub Road Show, jossa tullaan kertomaan projektin ajankohtaisista asioista. Ilmoittautuminen tilaisuuksiin on avattu EDIELfi-portaalissa. Ahon esitysmateriaali löytyy pöytäkirjan liitteenä. 3 Prosessityöryhmän kokoonpano ja mandaatti Puheenjohtaja esitteli työryhmälle uuden kokoonpanomallin, joka olisi tarkoitus ottaa käyttöön vuoden 2019 alusta. Uuden mallin myötä pyritään tehostamaan ryhmän toimintaa ja samalla vastataan myös saatuun palautteeseen siitä, että ryhmässä on koko ajan samat edustajat. Ymmärretään myös se, että alan monien muidenkin muutosten myötä yhtiön edustajia tarvitaan muihinkin toimialan työryhmiin. Energiateollisuus ry:tä tullaan pyytämään nimeämään työryhmän seuraavassa rotaatiossa (2019) 3 verkkoyhtiön ja 3 myyntiyhtiön jäsentä. Jatkossa työryhmässä tullaan myös tekemään vuosittainen rotaatio yhden jakeluverkonhaltijan ja yhden myyjien edustajan osalta. Näin mukaan pääsee mahdollisimmat monet halukkaat tuomaan työhön omaa näkökulmaansa. Työryhmässä ei jatkossa tulla tarvitsemaan erikseen teknisiä edustajia, sillä järjestelmätoimittajista ollaan kokoamassa omaa teknistä ryhmäänsä, joka toki toimii jatkossa yhteistyössä prosessityöryhmän kanssa. Prosessityöryhmän mandaatti tulee säilymään ennallaan ja jatkossakin työryhmässä käsitellään mahdollisia prosesseihin tulevia muutostarpeita. Työryhmällä on jatkossa noin kuusi kokousta vuodessa. Ryhmäläiset näkivät suunnitellun muutoksen hyvänä ja Energiateollisuus ry:n kanssa aloitetaan keskustelu uuden ryhmän nimeämisestä. Rusanen lupasi ottaa asian esille seuraavassa ET:n vähittäismarkkinoiden menettelytapojen kehitysryhmän kokouksessa 18.9.

3 Pöytäkirja 3 (12) 4 Prosessityöryhmän jäsenten kuulumiset Osassa työryhmäläisten yhtiöissä järjestelmävaihtoprojektit ovat edenneet maaliin, mutta tietojen tarkastukset jatkuvat edelleen. Osassa jäsenten edustamissa yhtiöissä järjestelmävaihtoprojektit ovat vasta alkamassa tai parhaillaan käynnissä. Titta-palvelua on hyödynnetty ahkerasti. Parissa yhtiössä on myös aloitettu määrittelyprosessi GSRN-käyttöpaikkatunnusten käyttöönotosta. Tämän osalta toivottaisiin toimialan muiden yhtiöiden välillä keskustelua siitä, miten tunnusten muodostus aiotaan tehdä. Ideana työryhmästä nousi, että asia voisi olla esillä myös Datahub Road Show:ssa. Olisi hyvä saada verkkoyhtiöistä vinkkejä suunnitellusta toteutuksesta ja jaettua niitä toimijoiden kesken. Rusanen lupasi nostaa asian myös ET:n vähittäismarkkinoiden menettelytapojen kehitysryhmässä keskusteluun. 5 Projektin eteneminen ja asioiden käsittely työryhmän kesken Puheenjohtaja kävi läpi projektin etenemistä ja sitä kuinka prosesseihin liittyvät asiat viedään eteenpäin projektissa. Prosessityöryhmän nykyisellä kokoonpanolla työskentelyä prosessityön parissa jatketaan kokonaissuunnitteluvaiheen loppuun eli tammikuun 2019 loppuun saakka. 6 Käsiteltävien asioiden listan läpikäynti Kokoukseen liittyi mukaan Fingridiltä Teemu Hellas ja Emmi Kaivosoja käymään läpi ryhmälle käsiteltäväksi listattuja avoimia asioita. Hellas vastaa datahub-projektissa mittaukseen ja taseselvitykseen liittyvistä prosesseista ja Kaivosoja mm. asiakas- ja tuotetiedoista. Työryhmäläiset olivat kevään kokouksessa miettineet mitä nykyisin MSCONS-sanomilla toimitettavia tietoja olisi tarvetta toimittaa myös datahubin käyttöönoton jälkeen. Asiaa tiedusteltiin myös toimialalta viimeisimmän tietokonversiokyselyn yhteydessä. Keskeisinä tarpeellisina tietoina tunnistettiin Spot-hintasarjan välitys, lämpötilatiedot, kaukolämmön/jäähdytyksen tuntitiedot, hankintaan liittyvät ennusteet ja osuusvoimaloiden tiedot / tuotantotiedot. Työryhmässä nähtiin, että esim. kaukolämpöön liittyvät tiedot voitaisiin mahdollisesti tuoda vasta datahubin myöhemmissä versioissa. Todettiin myös, että mahdollinen muu tiedonvaihto osapuolten kesken voisi olla toteutettavissa muulla tavoin kuin MSCONS-sanomilla. Keskusteltiin myös siitä, että ilmatieteenlaitokselta on mahdollista saada lämpötilatietoja muussakin formaatissa, eli MSCONS-sanomia ei tarvittaisi ko. tiedon välittämisessä. Osuusvoimaloiden tuotantoennusteiden ja tietojen osalta mietittiin, voitaisiinko tietoja toimittaa yhtiöltä toiselle jossain vapaavalinnaisessa tiedostomuodossa, mikä olisi mahdollista määrittää osapuolten kesken. Työryhmässä heräsi kysymys, onko energiayhteisöjen osalta tulossa jotain uusia tiedon välitys tarpeita? Puheenjohtaja kommentoi, ettei toistaiseksi älyverkkotyöryhmän edustajien kanssa käydyssä keskustelussa ole tällaisia tarpeita noussut esiin. Jotain muutoksia on varmasti kuitenkin tarpeellista jo miettiä, esim. käyttöpaikan myyjäkäsitettä pitää pohtia eli tarvitaanko jatkossa 2 myyjää samalle käyttöpaikalle. Tarvittavat muutokset näiltä osin voidaan tarvittaessa määritellä datahubin tuleviin versioihin.

4 Pöytäkirja 4 (12) Puheenjohtaja kävi myös lyhyesti läpi viimeisimmän tietokonversiokyselyn tulokset, jotka käytiin perusteellisemmin läpi 31.8 ajankohtaiswebinaarissa. Tämän webinaarin tallenne löytyy EDIELfi-portaalista. 6.1 Sulakekoko / Sähkötehon laskenta -tarvitaanko jännitetieto? Ohjeistus, että muille kuin 400 V kohteille tulee ilmoittaa sähköteho voi jäädä verkkoyhtiöiltä huomaamatta. Tällöin laskeminen 400V:n mukaan antaa esim. 20kV nähden 50- kertaa pienemmän sähkötehon sulakekoosta laskettuna. Tällöin toimitetut mittaustiedot helposti hylätään liian suurina. Toki tällöin verkkoyhtiö voi korjata käyttöpaikan sulakekoon ja/tai sähkötehon ennen mittaustietojen uudelleentoimitusta. Varmistus asialle, että 400V kuitenkin käytetään kaikissa tapauksissa oletuksena sähkötehon laskennalle? Jos sähköteho erikseen annettu, käytetään sitä mittaustietojen validoinnissa. 400 V on oletuksena laskennalle ja muille pitää ilmoittaa sähköteho. Käytännössä yli 400 V jännitetasoilla ei ole käytössä sulakkeita, joten ongelmatilanteita ei tästä syystä juurikaan pitäisi tulla. Muutoksille tietomalliin ei ole tarvetta, kirjataan asia siis selvemmin Sähkön vähittäismarkkinoiden liiketoimintaprosessit datahubissa -dokumenttiin. Jos myöhemmin tulee esiin tarve tuoda jännite käyttöpaikkatietoihin datahubissa, palataan asiaan. 6.2 Osapuolen roolit Tulisiko osapuolen tyyppi [1] vaihtaa osapuolen rooleiksi [1..2]? Tämän hetken määritysten mukaan osapuolella/tietyllä osapuolitunnuksella voi olla vain yksi osapuolen tyyppi (myyjä, jvh tai 3.osapuoli). Tämä perustuu ajatukseen, että myyjä ja jvh osapuoli voi toimia automaattisesti myös 3.osapuolella. Voi kuitenkin tulla tarve tarkemmin eritellä ne myyjät ja jvh:t, jotka toimivat 3.osapuolena esim. tietosuojan kannalta. Tietysti samalla osapuolella ei saa olla sekä myyjän että jvh:n roolia, edes silloin, kun nämä roolit toteutuisivat pienemmässä sähköyhtiössä, koska näille rooleille tarvitaan omat osapuolitunnukset. Roolien tarkentaminen on jatkokäsittelyssä datahub-projektissa ja tilanne annettu tiedoksi prosessityöryhmälle. 6.3 Mittaustietohakujen priorisointi halutessa Palattiin huhtikuun palaverissa käytyyn keskusteluun mittaustietojen hakujen priorisointiin. ja todettiin että asia tulee ottaa huomioon datahub-toimittajan kanssa suunnitteluvaiheessa. 6.4 ebix & mittauspisteen tyyppi Sanomakuvauksissa käytetään kenttää "MeteringpointType" kahdessa eri merkityksessä. E58 sanomassa (käyttöpaikan tiedot) sillä tarkoitetaan käyttöpaikan tyyppiä [kulutus, tuotanto, tuotantoyksikön omakäyttö]. E66 mittaustietojen ilmoituksessa tämä on (kulutus, tuotanto, rajapiste). Näiden lisäksi dokumenteissa (esim. datastandardi) yleisesti mittauspisteen tyyppi on [käyttöpaikka, tuotantoyksikkö, rajapiste] ja käyttöpaikalla on nuo tyypit, jotka E58 sanomassa mainittu. Nämä olisi hyvä saada linjaan, että kaikki tietävät, mitä esim. sanomassa E66 pitää kulloinkin käyttää. Mitä esim. käytetään pientuotantokäyttöpaikalle ja mitä tuotantoyksikölle.

5 Pöytäkirja 5 (12) Todettiin, että asia tulee ottaa huomioon suunnitteluvaiheessa datahub-toimittajan kanssa. 6.5 Mittausaikasarjan tunnuksen pakollisuus Mittaustietosanomaan on määritetty pakolliseksi mittausaikasarjan tunnus, jonka on tarkoitus olla lähettäjän käyttämä tunnus. Tätä on tarkoitus käyttää erilaisissa häiriö- ja selvitystilanteissa. Voisiko tulevaisuudessa olla mahdollista, että lähettävällä järjestelmällä ei ole käytössä ko. kenttää, jota käyttää ilmoituksessa? Tulisiko tämän kentän olla vapaaehtoinen? On myös ollut puhetta, että aikasarjan tunnus voi muuttua useastikin, joten se on pelkästään ilmoituskohtainen tunnus. Pidetään tunnus edelleen pakollisena ko. sanomassa. 6.6 Asiakkaan "osapuolen omatunnus" Jos henkilöasiakkaalla ei ole henkilötunnusta, tulee myyjän antaa asiakkaalle osapuolen omatunnus (myyjätunnus_asiakasnumero). Tarkistus, että on ymmärretty, että jakeluverkonhaltija ei luo omaa "osapuolen omatunnusta" vaan käyttää myyjän määrittämää tunnusta? Tarkennetaan dokumentaatioon, että myyjän antama tunnus menee sopimusprosessissa myös verkolle. Tietokonversiovaiheessa toimitaan toisin, kun myyjän oma asiakastunnus ei ole verkolla tiedossa. 6.7 Laskutusosoitteiden haku sanomarajapinnasta Laskutusosoitteita ei voi nykymäärityksillä erikseen hakea millään DH-tapahtumalla. Nämä tiedot luonnollisesti kuitenkin välitetään sopimustietojen luonnin ja päivitysten yhteydessä. Tiedot tulevat olemaan myös saatavilla ns. tietorajapinnasta. Varmistus, että laskutusosoitteita ei tarvita palauttaa esim. DH-130 asiakas- ja käyttöpaikkatietojen hauissa, joissa kuitenkin tulee muita sopimustietoja? Lisätään laskutusosoite ja yhteyshenkilö(t) palautettaviin tietoihin nykyisen myyjän ja jakeluverkonhaltijan tapahtumiin. Palautetaan molemmille sekä myyntisopimuksen että verkkosopimuksen laskutusosoitteet. FG selvittää vielä, onko estettä sille, että uusi myyjä tai uusi verkonhaltija voisi saada laskutusosoitteen ja yhteyshenkilön haettua datahubista, kun haku tehdään joka tapauksessa asiakkaan valtuutuksella. 6.8 Häviöiden tasevirhe Tasevirheiden laskennan yhteydessä lasketaan myös ns. häviöiden tasevirhe. Eli tämä on muutos häviöissä, joka aiheutuu käyttöpaikkojen tasevirheiden korjauksista, joissa toiseksi osapuoleksi joutuu JVH. Määritettiin alun perin näin, sillä ei ollut tarkoitus, että häviöt voisi missään muussa prosessissa muuttua. Nyt kuitenkin on mahdollisuus korjata myös rajapisteiden ja tuotantoyksiköiden mittaustietoja jälkikäteen. Nämäkin voivat muuttaa häviöitä, mutta näitä ei nykymäärityksillä lasketa tasevirheiden laskennan yhteydessä laskettuihin häviöiden tasevirheisiin. Onko täten tasevirheiden laskennan yhteydessä lasketut häviöiden tasevirheet lainkaan tarpeellisia?

6 Pöytäkirja 6 (12) Asia tiedoksi työryhmälle, toistaiseksi ei ole tarvetta toimenpiteille asian osalta. 6.9 Myyjällä tulee olla tasevastaava Myyjän summatietojen toimittaminen esettille edellyttää, että myyjällä on voimassaoleva tasevastaava (kulutukselle ja tuotannolle omansa) määritetty Basseen. Tämä ns. RBRtieto tulee olla Bassessa 14 vuorokautta ennen sen voimaantuloa. Tulisiko datahubissa estää myyjien uudet sopimukset sellaisille mittausalueille, joilla heillä ei ole sopimuksen koko ajalle määritetty RBR-tietoa Basseen? Datahubin tulisi estää sopimukset mittausalueille joille myyjällä ei ole tasevastaavaa Saman rajapistesumman ilmoitus esett:lle datahubin ja toisen verkkoyhtiön toimesta. esett:n säännöt sallivat kahden verkkoyhtiön ilmoittaa samaa rajapistesummaa. Jos verkkoyhtiöiden summat eroavat toisistaan, muodostetaan näistä viralliseen laskentaan uudet arvot ennalta määritettyjen sääntöjen mukaisesti (esett Handbook, luku ). Datahubissa tulee olemaan rajapistesummia, joissa toinen verkkoyhtiöosapuoli ei ole mukana datahubin suorittamissa taseselvityslaskennoissa (esim. voimalaitos-, alue-, teollisuusverkkoja). Ei liene mahdollista (eikä ehkä järkevääkään) kieltää näitä verkkoyhtiöitä lähettämästä rajapistesummatietoja erikseen esett:lle? Jos tätä ei kielletä, miten tämä pitäisi huomioida datahubissa? Ehdotus on, että tuodaan datahubiin Bassesta myös "virallinen/lopullinen" rajapistesummatieto (sanomalla "NEG Confirmation of Aggregated Data per Neighbouring Grid for Settlement Responsible") mittausaluekohtaisesti, mistä mahdolliset erot ilmoitetuissa rajapistesummissa näkyvät. Yleisesti rajapistesumma tulee varmasti vastaamaan datahubin laskemaa ja esett:lle ilmoittamaa rajapistesummaa, mutta varmasti poikkeustilanteitakin tulee olemaan. Datahubiin tuodaan Bassesta virallinen rajapistesummatieto Sähkövarastotyyppien listaus Toistaiseksi ei ole vielä määritetty listaa eri varastolaitteiden tyypeistä. Alla alustava ehdotus listaukseksi: (kiinteä) sähköakku sähköauton akku (tai lataus) power 2 gas vesipumppuvarasto ilmapumppuvarasto (tällaisia löytyy esim. Saksassa) vetylaitos vauhtipyörä Tiedon olisi syytä olla joustavasti päivittyvä, että voidaan konfiguroimalla lisätä, kun tarvetta tulee. Sähkövarastotyypeistä ei ole vielä tarkkaa tietoa eli käytetään tätä listaa alustavasti Virtuaalinen tuotantoyksikkö kenttä Toistaiseksi ei ole määritetty datastandardiin erityistä tietokenttää, josta selviää mikä tuotantoyksikkö on virtuaalinen ja mikä tavallinen. Tämä tieto tulee toki olla datahubissa,

7 Pöytäkirja 7 (12) jotta esimerkiksi esett:lle voidaan ilmoittaa tuotantoyksikön tiedot oikein. Onko syytä viedä tällaista tietoa itse datastandardiin, oletettavasti? Tasemallin muutos voi vielä vaikuttaa asiaan ja muuttaa tarvetta. Ei lisätä datastandardiin Tuotantotaseessa käsiteltävät varastolaitteet (tiedoksi) Tiedoksi työryhmälle: Taseselvityssääntöjen mukaan yli 1 MW varastolaitteet tulee käsitellä tuotantotaseessa. Tästä syystä kaikki yli 1 MW sähkövarastot tulee verkkoon syötön osalta määrittää tuotantoyksiköksi datahubissa. Tämä vastaa jo nykyistä käytäntöä esett:llä Virallisen taseselvitystiedon ja taseikkunan ulkopuolella korjatun tiedon haku Taseselvitystietojen hakuun annetaan tieto siitä, haetaanko virallisia taseselvitystietoja vai taseikkunan ulkopuolelta laskettuja päivitettyjä tietoja. Palauttaako näistä molemmat tietoja taseikkunan sisäpuolelta (käytännössä täysin samat tiedot riippumatta valinnasta) vai pitäisikö toisessa haussa rajata tietojen palautuksesta selkeyden vuoksi pois taseikkunan avoinna oleva osuus? Molemmat tulisi palauttaa taseikkunan sisällä samaa Tuotantoyksikön mittaustiedot osana taseselvitystietosanomaa Datahubin taseselvitystietosanoma sisältää aggregoidun tiedon lisäksi tuotantoyksiköiden mittaustietoa. Sanomassa on myös tuotantoyksiköistä aggregoitua summatietoa. Sanomassa ei kuitenkaan ilmoiteta rajapisteiden mittaustietoa, vaan pelkästään rajapistesummatietoa. Onko edelleen perusteltua, että tuotantoyksiköiden mittaustiedot tulevat osana muuten aggregoidun tiedon sanomaa? (Nykymäärityksillä myyjille ja verkonhaltijoille lähetettävät DH-514 ja DH-515 sanomat eivät myös täsmää esett:n käyttämään E31-sanomaan kaikilta osin. "Virallisella" E31-sanomalla ei voi ilmoittaa rajapistesummatietoja eikä tuotantotietoja.) Joka tapauksessa teknisen dokumentin kuvausta taseselvitystietojen E31-sanomaa tulee tarkentaa. Siellä on pakollisena tietona mittauspisteen tyyppi (kulutus, tuotanto, rajapiste). esett:n E31-sanomalla ilmoitetaan kulutustaseen tietoja ja tämä kenttä on aina "consumption". Datahubin osalta tämän kentän käyttö tulisi tarkentaa, koska se sisältää taseselvityslaji-kentän kanssa päällekkäistä tietoa. E31 sanomasta puuttuu myös tuotantolaji. Otetaan sanomasta pois tuotantoyksikön mittaustiedot Kiinteä toimitus myyjän määritelmässä Prosessidokumentin "Myyjä"-määritelmässä puhutaan kiinteistä toimituksista, joita ei käytännössä vähittäismarkkinoilla voida tehdä, ainakaan datahubissa. Ehdotetaan koko virke poistettavaksi. Ei tehdä muutoksia.

8 Pöytäkirja 8 (12) 6.17 Käyttöpaikan poistaminen virheellisesti luoduille käyttöpaikoille Prosessidokumentissa: "Virheellisesti datahubiin luodut käyttöpaikat pitää poistaa datahubista. Mikäli virhe huomataan ennen kuin käyttöpaikalle on tehty muita tapahtumia, voidaan käyttöpaikan luonti perua yleisellä peruutustapahtumalla, joka palauttaa tilanteen sellaiseksi, kun se oli ennen virheellisen käyttöpaikan luontia. Mikäli käyttöpaikalle on ehditty tehdä tapahtumia ennen virheen havaitsemista, tulee nämä tapahtumat perua ensin, jonka jälkeen käyttöpaikka tulee asettaa tilaan poistettu käytöstä, jolloin ko. käyttöpaikkatunnusta ei voida enää käyttää uudelleen." Onko yllä oleva teksti jäänyt päivittämättä? Prosessien määrittelyn myöhemmässä vaiheessa tuotiin omaksi tapahtumaksi DH-123 Käyttöpaikan poisto. Voidaanko luonti siis peruuttaa sekä peruutustapahtumalla että kyseisellä tapahtumalla? Kyseisen tapahtuman DH-123 tarkoitus myös oli, että tällöin käyttöpaikkatunnus voitaisiin käyttää uudelleen. Tulisiko olla siten, että jos käyttöpaikalle ei ole ilmoitettu mitään tapahtumia --> käytetään DH-123. Jos käyttöpaikalle on jo tehty tapahtumia --> osapuolet peruuttavat ko. tapahtumat ja päivitetään käyttöpaikan tilaksi poistettu käytöstä (eikä tunnusta voida täten uudestaan käyttää)? Vai käytetäänkö jälkeisemmässäkin tilanteessa DH-123, joka sitten poistaa pysyvästi aiemmin ilmoitetut "virheelliset" muut tapahtumat? Poistaminen (peruutussanoma/dh-123) on mahdollista vain, jos ei ole tullut ollenkaan sopimustapahtumia käyttöpaikalle. Suunnitteluvaiheessa päätettävä peruutustapahtuman ja poistosanoman käytöstä, luultavasti kannattaa luopua erillisestä tapahtumasta, niin ei tarvitse rakentaa ylimääräistä rajapintaa. Jos on jo tullut tapahtumia, vain operaattorin tulisi voida poistaa / muuten käsitellä käyttöpaikan tietoja, jos käyttöpaikkatunnus on pakko saada takaisin käyttöön Väärälle rajapisteen suunnalle ilmoittaminen 6.19 Tasevirhe Tarkoitushan oli, että rajapisteillä väärään suuntaan ilmoitettua mittaustietoa ei suoraan hylätä DH-211 mittaustietoilmoituksessa? Ei hylätä mutta jotenkin ilmoitetaan verkolle virheestä. Teknisessä dokumentissa tasevirheellä on rekisteröintipäivä, prosessidokumentissa laskenta-ajon tunnus. Oletettavasti molemmat ovat tarkoitettu tasevirheen tunnisteeksi. Mikä muotoinen (esim. päivämäärä, aikaleima) tämän pitäisi olla ja miten nimetä? Mahdollista myös, että laskentapäivä on eri kuin se hetki, jonka mukaisilla tiedoilla laskenta tehdään. Lisätään tieto siitä, minkä hetken tiedoilla on laskettu, minä päivänä on laskettu ja laskenta-ajon tunnus Tuotteen validointi sopimusilmoituksissa Datahubin validointisäännöistä puuttuu tarkastus, että uudessa sopimuksessa tai sopimuspäivityksessä ilmoitettava tuote on olemassa datahubissa ja lisäksi voimassa silloin kun sopimus alkaa. Lisäksi ehkä se, että tuote kuuluu sopimusta ilmoittavalle osapuolelle.

9 Pöytäkirja 9 (12) Lisätään validointisäännöt, verkkosopimukselle aina ja myyntisopimukselle silloin kun myyntituote ilmoitetaan Sopimukseen liitetyn tuotteen päättyminen Jos jollakin sopimuksella käytetyn tuotteen loppuaika tulee, tuote ei ole enää voimassa, mutta saattaa olla yhä datahubissa sopimuksen tuotteena. Kuinka suuri ongelma on se, että datahubissa olisi sopimuksella tuote, joka ei ole enää voimassa? Yksi ratkaisumahdollisuus: Lisätään sekä tuotetietojen, uuden sopimuksen että sopimuspäivityksen ilmoitukseen validointeja. Tuotetietojen päivityksessä tarkastettaisiin, että jos asetetaan tuotteelle loppuaika, tuote ei saa olla millään sopimuksella, jossa sopimus ei lopu tai tuote sopimukselta poistu ennen asetettavaa loppuaikaa. Uuden sopimuksen ja sopimuspäivityksen kohdalla tarkastettaisiin, että tuotteella joko ei ole loppuaikaa tai vaihtoehtoisesti sopimus päättyy ennen tuotteen loppuaikaa. Viimeinen saattaa jossakin määrin olla rajoittava sopimusten ilmoitusten kannalta. Ei muutoksia validointeihin, kukin osapuoli vastaa omista tuotetiedoistaan. Datahubissa saattaa olla vanhentuneita tuotteita sopimuksilla. Validoinnit rajoittaisivat yhtiöiden toimintatapoja tuotteiden hallinnassa Asiakkaan syöttämän valtuutuksen validointi Kun asiakas syöttää asiakasportaalissa valtuutuksen, tiedoille on varmaan syytä tehdä kaikki samat validoinnit mitä tehdään DH-810 tapahtumassa annettaville tiedoille. Puuttuu kuvauksista. Lisätään validointi kuvaukseen Verkkosopimuksen virheellisen vahvistuksen peruutus Verkkosopimuksen peruutustapahtuman DH-342 kuvauksessa lukee, että tapahtumaa käytetään myös silloin, kun verkkoyhtiö peruuttaa virheellisesti tehdyn verkkosopimuksen vahvistuksen. Tulisiko peruutuksen syy -kentän yhdeksi vaihtoehdoksi lisätä "jakeluverkonhaltijan peruutus" nykyisten "asiakkaan/myyjän peruutuksen" lisäksi? Tapahtuman DH-342 luokkakaaviosta puuttuu myös kenttä "peruutuksen syy" vaikka listaus syistä on kuvaajassa annettu. Lisätään DH-342:n peruutuksen syy -kenttä. Työryhmälle jää mietittäväksi onko tapauksia, joissa peruutuksen syy olisi verkonhaltijan peruutus. Teknisessä dokumentissa tällainen syy löytyy, päivitetään prosessidokumentti vastaamaan teknistä dokumenttia Käyttöpaikan poistolle oma sanoma? Tulisiko käyttöpaikan poistolle oma sanoma? Jos käyttöpaikan poistoon käytetään samaa sanomaa, kun käyttöpaikkatietojen ilmoitukselle/päivitykselle, tulee sanomatyypille E58 määrittää kaikki ne kentät vapaaehtoisiksi, joita käyttöpaikan poistossa ei tarvita. Näitä kenttiä on paljon. Jos sanoman skeemassa on paljon vapaavalintaisia tietoja, tulee enemmän validointeja tehdä prosessitasolla, joka on hitaampaa kuin skeemavalidointi (pakollisten kenttien tarkistus).

10 Pöytäkirja 10 (12) Todennäköisesti tehdään oma sanomatyyppi, käydään läpi vielä suunnittelun aikana datahub-toimittajan kanssa Uuden sopimuksen ilmoitussääntö Tarkoitetaanko prosessidokumentin luvun säännöllä 7 sisäänmuuttoa eli sitä, että kaikki asiakkaat muuttuvat? Eikä sitä, että vain osa asiakkaista muuttuu. Tulisiko tarkentaa? Sovittiin käsiteltäväksi risteävien tapahtumien yhteydessä. 7 Dokumenttien uusien versioiden kommenttien läpikäynti Puheenjohtaja kertoi, että Sähkön vähittäismarkkinoiden liiketoimintaprosessit datahubissa versio 1.6. dokumentti on työryhmäläisten kommentoitavana Projectplacessa. Nyt vietyihin muutoksiin ei tullut kommentteja, joten dokumentaation uusi versio julkaistaan syyskuun aikana. Dokumentaatiolle on myöhemmin tulossa vielä uusia muutostarpeita, esimerkiksi datahub lainsäädännön voimaan tullessa täytyy tarkentaa lainsäädännöstä tulevia termejä ja mitä se ko. dokumentissa tarkoittaa. Termejä tullaan näiltä osin tarkentamaan ja ne yhtenäistetään kaikkien projektin julkaisemien dokumenttien kanssa. Datahub rooleja tullaan tarkentamaan ebix roolien mukaisesti esim. missä roolissa jakeluverkonhaltija toimii. Tapahtumakuvaukset tullaan myöhemmin viemään omaksi dokumentikseen luettavuuden helpottamiseksi. Tietokonversiosuunnitelmaa on myös muutettu ja dokumentti on päivitetty vastaamaan tämän hetkistä tilannetta tietokonversiossa. Tietokonversiotiimi oli pyytänyt kommentteja myös prosessityöryhmältä. Tietokonversiosuunnitelmaan työryhmäläisiltä saadut kommentit luvattiin välittää tietokonversiotiimille. 8 Risteävien prosessien läpikäynti Tulevia datahub-järjestelmän määrittelyjä varten on tarkennettava sopimustapahtumiin liittyviä ilmoituksia ja sitä, kuinka toinen mahdollinen samalle käyttöpaikalle ns. risteävästi eli päällekkäin ilmoitettu prosessi vaikuttaa jo ilmoitettuun tapahtumaan. Tarkoitus on varmistua aiemmin määritettyjen sääntöjen oikeellisuudesta sekä tarkentaa sääntöjä tarvittavin osin. Risteäviä tapahtumia tullaan käymään läpi datahub-toimittajan kanssa suunnitteluvaiheessa, joten on tärkeää käydä eri skenaarioita läpi ensin prosessityöryhmän kanssa. Datahubiin tulee määrittää käsittelysäännöt, jotta epäselvyyksiä syntyisi mahdollisimman vähän risteävien tapahtumien osalta. Toki tilanteilta, joissa selvittelyä tarvitaan ei voida täysin välttyä. Tärkeää on, että asiakkaan tahto toteutuu ja löydetään skenaarioista se todennäköisin, joka automatiikalla voidaan ratkaista. Risteävissä tapahtumissa on tunnistettava vaikutukset ilmoitusten ajankohdasta riippuen, koska ilmoitus on vastaanotettu ja mitä ajankohtaa uusi ilmoitus koskee, eli miten eri tilanteissa datahubin näkökulmasta tulisi menetellä. Dokumentaation sopimusten ilmoituksiin ja päättämisiin liittyviä sääntöjä on näiltä osin tarkennettava.

11 Pöytäkirja 11 (12) Työryhmän kanssa käytiin valmisteltujen esimerkkien avulla läpi risteäviä tapahtumia ja sitä, miten datahubissa tapahtuma käsiteltäisiin. Läpikäynnissä tilanteita mietittiin ensimmäistä kertaa, joten asiaa on tarve käsitellä uudemman kerran, kunhan työryhmäläiset ovat ehtineet perehtyä paremmin esimerkkeihin. Risteävät prosessit nostetaan uudelleen käsittelyyn seuraavassa työryhmän kokouksessa. hylätäänkö myyjän vaihto? Ensimmäisessä esimerkissä mietittiin, käsitelläänkö kaikkia uuden sopimuksen ilmoituksia samalla vahvuudella mikäli ne risteävät keskenään, eli muutto, myyjän vaihto, sopimuksen vaihto? Sekä sitä, onko myyjänvaihto vahvempi kuin sopimuksen vaihto vai samanarvoinen? Esimerkiksi peruuttaako myyjän vaihto (ilmoitus B) tulevan sopimuksen vaihdon (ilmoitus A) automaattisesti vai 9 Muut asiat Kuvatussa tilanteessa todettiin, että uusi sopimus voi tulla voimaan vain siksi ajaksi ennen kuin jo aiemmin solmittu tuleva sopimus astuu voimaan. Sopimusten määräaikaisuustieto toki tulee näissäkin huomioida. Sisäänmuuttoilmoituksen todettiin olevan ensisijainen verraten muihin ilmoituksiin. Kuvattu on myös linjassa prosessidokumentaation kanssa, eikä näin ollen aiheuta muutoksia dokumentaation osalta. Työryhmässä käsiteltiin vastaavalla tavalla useita eri tyyppisiä tapahtumia ja mietittiin miten datahubin olisi käsiteltävä ilmoitukset missäkin tilanteessa. Mietittiin myös tilanteita siitä näkökulmasta, tuleeko ilmoitus samalta myyjältä tai uudelta myyjältä ja onko ilmoitus samalle vai uudelle asiakkaalle. Kaikkia ennakkoon lähetettyjä esimerkkejä ei ehditty kokouksessa käydä läpi ja sovittiin, että FG:n valmistelema Excel-taulukko risteävistä tapahtumista jaetaan työryhmäläisille ja käsitellään seuraavassa kokouksessa Muina asioina puheenjohtaja kertoi, että käydään seuraavassa työryhmän kokouksessa läpi Fingridin päivittämät yksinkertaistetut prosessikuvat, sillä niitä ei ehditty tässä kokouksessa käsitellä. Puheenjohtaja pyysi ryhmäläisiä myös käymään päivitetyt prosessikuvat läpi ennen seuraavaa kokousta. Käsittelemättä jäi myös mittaustietojen toimituksen aikarajat, joita oli käyty läpi varttitaseen referenssiryhmässä. Puheenjohtaja lähettää sähköpostitse kotitehtävän tästä työryhmälle. Käsittelemättä jäi myös pientuotantokäyttöpaikkojen tuotantolajien täsmentäminen. Tästä on myös tulossa kotitehtävä käsiteltäväksi seuraavassa kokouksessa. 10 Seuraava kokous ja kokouksen päätös Puheenjohtaja päätti kokouksen klo Seuraava kokous pidetään Duetossa klo Liitteet Esitysmateriaali

12 Pöytäkirja 12 (12) Jakelu Prosessityöryhmä Teemu Hellas Emmi Kaivosoja Pasi Aho