Prosessityöryhmän kokous

Transkriptio

1 Pöytäkirja 1 (10) 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 (asialistan kohdasta 4) Emmi Kaivosoja Teemu Hellas Raimo Toivanen PKS Sähkönsiirto Oy (asialistan kohdasta 2.3) Tiina Leppälahti Helen Sähköverkko Oy (Skype) Tomi Mäkelä Elenia Oy Jari Rusanen Loiste Sähköverkko Oy Kaisa Ylipeura Energiapolar Oy Saku Ruottinen Caruna Oy Esa Kaario Tampereen Sähköverkko Oy (Skype) Monika Lindberg Fortum Markets Oy Arttu Lahtinen Fortum Markets Oy Vesa Mäkilä SPS Energiapalvelut Oy Jari Nykänen Paikallisvoima ry 1 Kokouksen avaus Puheenjohtaja avasi kokouksen klo ja kävi läpi päivän agendan sekä kertoi, että projektin kokonaissuunnitteluvaiheen aikana työryhmän kokoussykliä on tarve tihentää. Datahub-järjestelmätoimittajan kanssa prosesseja läpikäytäessä tulee vastaan kysymyksiä sekä tarkennettavia asioita nopeaan tahtiin ja myös vastaukset avoimiin asioihin tulisi saada useammin kuin kerran kuussa. Työryhmien jo sovittujen kokouspäivien lisäksi perjantaisin ehdotettiin pidettävän lyhempiä Skype-palavereita, jotta kaikki tarvittavat asiat ehditään käymään läpi työryhmässä. Sovittiin, että puheenjohtaja lähettää Skype-kutsut klo ja jatkossa perjantaisin klo seuraavaan varsinaiseen kokoukseen saakka ( ). Fingrid lisää kokouksissa käsiteltävät asiat Projectplacen käsiteltävien asioiden listalle kokouksia varten ennen kokouksia, niin pian kuin mahdollista. Mikäli kokoukselle ei olekaan tarvetta perutaan ko. kokous. Käytiin keskustelua siitä, pitäisikö CGI:n edustajan myös osallistua työryhmän kokouksiin. Puheenjohtaja kertoi, että CGI:n edustajat eivät osallistu työryhmän kokouksiin vaan asiat kommunikoidaan FG:n edustajien kautta. Puheenjohtaja 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. Puheenjohtaja kertoi datahub-lainsäädännön osalta, että lakiesitys on talousvaliokunnassa ja mikäli viivästyksiä ei tule, laki voisi tulla voimaan vuoden vaihteessa. Puheenjohtaja kertoi myös, että päivitetyt versiot prosessidokumentaatiosta (versio 1.6) on nyt julkaistu EDIELfi-portaalissa, myös englanninkielinen kieliversio tullaan julkaisemaan lähiaikoina.

2 Pöytäkirja 2 (10) 2 Kotitehtävien läpikäynti 2.1 Mittaustietojen toimitusten aikarajat Työryhmäläisillä oli kotitehtävänä miettiä Mittaustietojen toimitusten aikarajajoja datahubissa JVH:lle (nykyinen määrittely D+11 20:00). Asiaa on käyty läpi myös varttitaseen referenssiryhmässä ja ehdotuksena mittaustietojen toimituksesta on: JVH:t toimittavat tiedot datahubille D+11 23:59 ja datahub edelleen esett:lle D+12 23:59 (esett laskennat D+13 12:00). Muut kuin datahubin kautta toimivat verkkoyhtiöt (DSO rooli) ilmoittavat omat summatietonsa kuten tähänkin asti D+11 23:59 esett:lle. Kotitehtävä koskien mittaustietojen toimitusten aikarajaa on kommentoitu myös Energiateollisuus ry:n vähittäismarkkinoiden kehitysryhmän toimesta. ET:n kehitysryhmän ehdottama malli D+12 klo nähtiin myös prosessityöryhmässä hyvänä ja työryhmä yhtyi ET:n kehitysryhmän näkemykseen. 2.2 Tuotantolajit Tilastokeskus on yhdessä ET:n ja muiden sidosryhmiensä kanssa käynyt läpi datahubiin määriteltyjä tuotantolajeja. Uudessa ehdotuksessa yhdistyy teknologia ja energialähde, mutta luokat eivät ole keskenään päällekkäisiä. Polttokenno on lisätty uutena teknologiana mukaan, mutta ei ole vielä tässä vaiheessa relevantti. Työryhmäläisiä pyydettiin kommentoimaan kotitehtävänä ollutta Tilastokeskuksen laatimaa listausehdotusta tuotantolajeista, joka löytyy esitysmateriaalista pöytäkirjan liitteenä. Työryhmän keskustelussa esille nousi, miten toimitaan niiden käyttöpaikkojen osalta, joissa on useaa tuotantoa samalla käyttöpaikalla eli mikä tuotantolaji tulisi ilmoittaa (esim. jos yli 75% tiettyä tuotantolajia valitaanko silloin ko. vaihtoehto). Mietittiin myös onko listaus tehty pelkästään pienkohteita ajatellen ja onko tuotantolajit tarkoitus harmonisoida myös esettin suuntaan. Puheenjohtaja lupasi selvittää Tilastokeskuksen kanssa vielä listausta ja kommentoi, että tuotantolaji on datahubin näkökulmasta attribuutti, johon voi lisätä arvoja tarvittaessa. 2.3 Verkkosopimuksen virheellisen vahvistuksen peruutus Lisäksi työryhmälle jäi pohdittavaksi yksi kohta käsiteltävien asioiden Excelistä. Viime kokouksessa keskusteltiin verkkosopimuksen virheellisen vahvistuksen peruutuksesta. Sen osalta tuli miettiä, onko tapauksia, joissa peruutuksen syy olisi verkonhaltijan peruutus. Tapahtuma on kuvattu prosessidokumentissa niin, 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? Tarkoitus oli miettiä tilanteita, jotka nyt aiheuttavat verkkoyhtiölle manuaalista selvitystyötä. Työryhmäläiset kommentoivat, että on paljon tilanteita, joissa useampi myyjä ilmoittautuu jakeluverkonhaltijalle, joka aiheuttaa verkkoyhtiölle paljon selvitystyötä. Huomioitava datahubissa on, että järjestelmästä tulee myyjälle tarpeeksi tarkka syykoodi hylkäyksessä, sillä nyt myyjä on saanut tiedon verkkoyhtiöltä. Nähtiin, että datahubin tulisi hylätä jälkimmäinen sopimus ja myyjällä lähetettäisiin syykoodi hylkäyksestä. Kommenttina esiin nousi myös, että käsittelysääntöjen tulisi olla asiakkaan tahdon huomioivia. Todettiin, että

3 Pöytäkirja 3 (10) vaikka datahub hylkäisi viimeisimmän sopimuksen, niin asiakkaan tahto tulee huomioiduksi, sillä asiakkaan kanssa selvitetään tilanne, kenen myyjän kanssa hän sopimuksen haluaa solmia. Eli Myyjän tulee saada datahubista selvä informaatio, miksei sopimus voi alkaa ja myyjä selvittää asian asiakkaan kanssa. Muuttojen osalta esiin nostettiin, että muutoissa aiheutuu paljon manuaalityötä tilanteissa, joissa asiakas peruu muuton, koska haluaa peruuttaa uuden myyntisopimuksen, jolloin palautuu poismuuttaneen myyjälle. Työryhmässä nousi esiin huoli siitä, pystyisivätkö myyjät selvittämään epäselvät tilanteet keskenään, sillä työryhmäläisten mukaan myyjät eivät välttämättä halua peruuttaa sopimuksia vaikka se olisikin asiakkaan tahto. Mietittiin myös miten viimeisin myyjä saa tiedon toisesta myyjästä selvittelyä varten eli voisiko asiakas esim. valtuuttaa oikeuden tietoon datahubissa, jotta selvitystyö myyjien välillä olisi mahdollista. Mikäli puolestaan asiakkaan tulisi vahvistaa haluttu sopimus, miten se toteutettaisiin. Päätettiin ottaa aihe pidettävän ET:n vähittäismarkkinoiden kehitysryhmän ja Fingridin tiedonvaihdon kehitysryhmien yhteiskokouksen agendalle niin saadaan muodostettua kattavampi kuva asian osalta. Yhteenvetona, että manuaalista selvitystyötä nykyisin aiheuttavat sopimusten alkamis- ja päättymispäivän muutokset, virheellisesti tehtyjen sopimusten korjaukset, sopimusten perumiset sekä se että verkko- ja myyntisopimukset ovat eri asiakkaiden nimissä. Toisinaan ongelmia aiheuttaa myös se, ettei asiakas tiedä uutta osoitettaan tarkasti, johon on muuttamassa. Datahub tuo suurimpaan osaan listatuista apua. Esimerkiksi muuttotapahtuman pystyy perumaan datahubissa, jolloin datahub palauttaa aiemman tilanteen ja ilmoittaa asiasta ko. osapuolille. Sopimusten alkamis- ja päättymispäivän muutoksien osalta datahub lähettää myyjälle syykoodin milloin myyjänvaihto on tehtävissä, eikä syy jää enää avoimeksi. Datahubissa uusille sopimuksille tulee samat asiakkaat myynti- ja verkkosopimukselle mikä osaltaan myös tulee vähentämään manuaalisia tarkastuksia. 3 Risteävien prosessien läpikäynti Työryhmässä aloitettiin viime kokouksessa risteävien sopimusprosessien läpikäynti, jota jatkettiin kotitehtävän merkeissä. Työryhmällä oli tehtävänä läpikäydä taulukko, jossa oli eri variaatioita risteävien prosessien osalta ja miettiä miten asia datahubissa tulisi käsitellä. Kommenttina taulukon luettavuuden osalta nousi, että välillä oli vaikea hahmottaa onko kyseessä tilanne jossa sama myyjä on A sekä B myyjä vai ovatko myyjät eri myyjiä. Puheenjohtaja kertoi, ettei risteävien prosessien läpikäyntiä ole vielä aloitettu toimittajan kanssa vaan aihe tullaan ottamaan käsittelyyn marraskuussa, näin ollen tarvittaessa aiheeseen voidaan vielä palata niin Skype-kokouksissa kuin myös seuraavassa työryhmän kokouksessa, mutta on hyvä jos periaatteet saataisiin tässä kokouksessa jo keskusteltua.

4 Pöytäkirja 4 (10) Jälkimmäinen tapahtuma (B) ilmoitetaan myöhemmin ja aiemmalle päivälle kuin mille aiempi tapahtuma on ilmoitettu (A) Käytiin aluksi läpi kohdat, joihin Fingrid oli listannut vaihtoehtoiset ratkaisut, miten tilanne datahubissa käsiteltäisiin. Ulosmuutot Sopimuksen irtisanominen: Sopimuksen A päättyminen aikaistuu ilmoituksen B päättymispäivämäärälle VAI Hylätään ilmoitus B ja myyjän tulee peruuttaa ensin ilmoitus A? Työryhmän näkemys oli, että ko. tilanteessa sopimuksen A päättyminen aikaistuu ilmoituksen B päättymispäivämäärälle. Ulosmuuttotilanteessa sopimuksen A päättyminen aikaistuu ilmoituksen B päättymispäivämäärälle. Sopimusta purettaessa sopimuksen A päättyminen aikaistuu ilmoituksen B päättymispäivämäärälle. Sopimuksen purkaminen (myyjä) Sopimuksen irtisanominen: Sopimuksen A päättyminen aikaistuu ilmoituksen B päättymispäivämäärälle VAI Hylätään ilmoitus B ja myyjän tulee peruuttaa ensin ilmoitus A? Osa työryhmäläisistä näki, että ko. tilanteessa toimitaan samalla logiikalla kuin ulosmuutoissa eli sopimuksen A päättyminen aikaistuu ilmoituksen B päättymispäivämäärälle. Osa työryhmästä oli kuitenkin miettinyt asiaa sopimuksen purkamista verkon näkökulmasta ja päätynyt jälkimmäiseen vaihtoehtoon. Lisättiin sopimuksen purkamiselle toinenkin sarake Exceliin, jossa verkkoyhtiön näkökulma. Todettiin myös että järjestelmän automatiikan rakentamisen kannalta logiikan kannattaa olla yhtenäinen ja prosessi on myös markkinaosapuolia ajatellen helpompi muistaa. Taulukon läpikäynnin yhteydessä järkevänä logiikkana nähtiin, että datahub peruu automaattisesti saman myyjän aiemman ilmoituksen, mikäli myyjä ei itse tee peruutusta. Keskusteltiin siitä, että risteävien prosessienkin käsittelyssä on datahubin päättelysäännöissä huomioitava irtisanomisen ja uuden sopimuksen teon aikarajat ja kaikki muut päättelysäännöt mitä on aiemmin sopimusprosessien käsittelyihin määritelty. Huomiona esille nousi, että välillä asiakkaat ilmoittavat ulosmuuton halutessaan irti määräaikaisesta myyntisopimuksesta. Edelliselle myyjälle tulisi lähteä tieto, mikäli asiakas on ilmoittanut ulosmuuton ja uudelle myyjälle sisäänmuuton. Näin nykyinen myyjä pystyy reagoimaan asiaan ja esimerkiksi vaatimaan asiakkaalta mahdollista sopimussakkoa.

5 Pöytäkirja 5 (10) Fingrid käy kokouksessa olleen keskustelun ja kommenttien pohjalta taulukkoa läpi ja päivittää uuden version taulukosta työryhmälle ja asiaan palataan viimeistään pidettävässä työryhmän kokouksessa. 4 Roolien tarkennus Puheenjohtaja kertoi, että Fingrid on käynyt ebix:n (European forum for energy business Information exchange) roolimalleja läpi sisäisesti sekä datahub-toimittajan kanssa. Nykyinen rooliajattelu datahubissa on hyvin ylätasolla ja jotta voidaan jatkossa hyödyntää rooleja paremmin, tulee niitä tarkentaa. Tarkemman roolijaottelun hyötyjä ovat selkeämpi jaottelu yksittäisten tehtävien toimeksiantoihin: esim. yhdelle roolille voidaan niputtaa useampia tapahtumia, tarkempi jaottelu osapuolten rooleissa datahubissa mahdollistaa käyttöoikeuksien määrittämisen tietyn tarvekokonaisuuden mukaan, roolimalliin voidaan kytkeä oikeudet tiettyyn tietoon. Jaottelun hyötyinä ovat myös se, että markkinaosapuolten sertifiointi datahubia vasten voidaan jaotella roolien mukaisesti ja jaottelu tukee myös järjestelmän määrittelyä. Lista tarkennetuista rooleista löytyy esitysmateriaalista pöytäkirjan liitteenä. Datahubissa rooleja tulee olemaan kolmella tasolla. Markkinatoimijarooleja ovat esim. myynti- ja verkkoyhtiöt ja tarkemmalla tasolla roolien alla on myös prosessirooleja ja liiketoimintarooleja. Käytiin ebixin mukaisten prosessiroolien kuvaukset ja nimet läpi työryhmässä ja sovittiin, että tarkemmat suomenkieliset kuvaukset viedään Sähkön vähittäismarkkinoiden liiketoimintaprosessit datahubissa dokumenttiin. Roolit nykyisten prosessien näkökulmasta on käyty projektissa läpi tarkemmalla tasolla ja työryhmän läpikäynnin pohjalta päästää käymään rooleja läpi myös datahub-toimittajan kanssa. Kyseessä on roolien tarkennus datahub järjestelmään eli jo aiemmin määritellyt roolit ovat datahubiin tulossa. Fingrid päivittää roolien kuvauksen Sähkön vähittäismarkkinoiden liiketoimintaprosessit datahubissa dokumenttiin (luku 1.3 Liiketoiminta datahub-ympäristössä). Työryhmälle jaetussa ennakkomateriaalissa oli myös kysymys: 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. Käytiin kysymys läpi ja todettiin, että tarkentuu uusien roolien ja rooleille määriteltävien oikeuksien myötä. 5 Käsiteltävien asioiden listan läpikäynti Käytiin työryhmässä läpi käsiteltävien asioiden Excel-listan avoimet kohdat.

6 Pöytäkirja 6 (10) 5.1 Kytkentäpyynnöstä kieltäytyminen Jos myyjä ilmoittaa kytkentäpyynnön mutta verkko ei halua kytkeä käyttöpaikkaa (esim. vielä asiakkaalta laskut verkolle maksamatta) niin miten verkko vastaa kytkentäpyyntöön? Ehdotus käyttää viivästymisilmoitusta (DH-413). Toinen tarkennus viivästymisilmoitukseen - jos verkko ei voi kytkeä viivästymisilmoituksessa ilmoitettuna päivänä, lähetetään uusi viivästymisilmoitus. Sovittiin käytettäväksi viivästymisilmoitusta kytkentäpyynnöstä kieltäytymiseen. Muutetaan "aikaisintaan" päivämäärä vapaaehtoiseksi. Toistuvia viivästyksiä voidaan ilmoittaa. 5.2 Käyttöpaikan poisto Onko tarvetta käyttää uudelleen virheellisesti ilmoitettu ja poisto-tapahtumalla poistettu käyttöpaikkatunnus? Nyt määritelty näin prosesseihin: 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. Ei ole tarpeellista uudelleenkäyttää käyttöpaikkatunnuksia datahubissa. 5.3 Oikeudet tietoon päivityksissä Käyttöpaikkatietojen päivitys - jos ilmoitetaan muutos tulevaisuuteen ja muutosajanhetkelle tiedetään jo olevan tulossa voimaan uusi myyntisopimus, ilmoitetaanko muutos uudelle myyjälle, entä ilmoitetaanko lainkaan nykyiselle myyjälle? Vanha myyjä: Ei mitään tietoja jos voimaantulo kun sopimus on jo päättynyt. Uusi myyjä: Perustietomuutokset heti muutoshetkellä, sopimuksen voimaantullessa saa loput tiedot tietoonsa. Näin jos ei ole asiakkaan valtuutusta, jos on valtuutus niin saa kaikki tiedot heti. 5.4 Käyttöpaikkatiedon päivitys Kuinka todennäköistä on tilanne, jolloin JVH ilmoittaa käyttöpaikkatietojen päivityksen vaikka tosiasiassa mitkään tiedoista ei muutu. Pystyykö vastaanottava myyjä käsittelemään tällaisen tilanteen omassa järjestelmässään? Entä mitä tapahtuu verkon puolella jos datahub aina hylkää ilmoituksen missä mikään ei muutu? Jos ei ole muutoksia niin datahub hylkää sanoman, syykoodissa tieto hylkäyssyystä jotta verkko osaa käsitellä. 5.5 Käyttöpaikan tilanmuutos Käyttöpaikkatiedon päivitys - tämän hetken määritysten mukaan käyttöpaikan tilatieto voidaan päivittää sekä käyttöpaikan päivitystapahtumalla, että kytky/katko-tapahtumilla. Voi aiheuttaa ristiriitaa näin. Muutetaan kuvaukseen, että tilanmuutos kytketystä tilasta kat-

7 Pöytäkirja 7 (10) kaistuun ja päinvastoin voi hoitaa vain katko/kytkytapahtumissa. Käyttöpaikan päivitystapahtumalla tilaa voidaan muuttaa ainoastaan rakenteilla ja poistettu käytöstä tilaan. Luonnissa voi tulla mihin tilaan vain. Päivitettävä prosessidokumenttiin. Ohjeistetaan, että jos purun yhteydessä halutaan ilmoittaa katkaisu, niin se pitää ilmoittaa ennen purkua. Kytketty ja katkaistu -tilaan päivitys tulee tehdä kytky/katkotapahtumalla. Käyttöpaikan päivityssanomalla voidaan päivittää ainoastaan rakenteilla tai poistettu käytöstä -tilaan. 5.6 Tapahtumien voimaantuloajat 5.7 Muistutus Tarkennus - Voimaantuloajat tapahtumille, jotka ilmoitetaan päivän tarkkuudelle ovat tapahtuman voimaantulopäivänä klo 00:00. Esim. käyttöpaikkatiedon ilmoitus, päivitys. Sopimusten voimaantulo myös alkaa klo 00:00 (inclusive) ja päättyy päättymispäivänä klo 00:00 (exclusive). Tiedoksi työryhmälle. Mikäli verkko ei vahvista verkkosopimusta, tulee datahubin lähettää muistutus verkolle. Vastaavasti kuin käyttöpaikkatietojen päivityspyyntöön liittyvä muistutus. Odotetaan kaksi päivää kuten muissakin? Muistutuksista lähtee datahub-tapahtuma. Mitä tietoja tarvitaan tästä muistutukseen? Sama 2 päivää muistutuksen alkuun myös verkkosopimuksen vahvistukselle. Sisältö sama kuin alkuperäisessä, jollakin (esim sanomatyyppi) merkitään että kyseessä on muistutus aiemmasta. 5.8 Verkkosopimusvahvistus Kuinka kytketään verkkosopimusvahvistus siihen liittyvään myyntisopimukseen, onko käyttöpaikkatunnus riittävä tieto? Kuinka käsitellään jos samaan käyttöpaikkaan tulisi useampia sopimuksia joihin liittyy uusi verkkosopimus? Miten varmistutaan että vahvistetaan oikea verkkosopimus? Tähän liittyy myös se, että järjestelmässä tullaan luomaan vahvistamattomalle sopimukselle sopimustunnus (järj.sisäinen) joka muutetaan verkkoyhtiön omaksi sopimustunnukseksi sitten kun verkko lähettää vahvistuksen. Käytetään sanomassa transaction ID:tä, joka on sama kuin datahubin lähettämässä vahvistamattoman sopimuksen sanomassa (mahdollisesti myös alkuperäisessä myyntisopimussanomassa) yhdistämään tapahtumat. 5.9 Aikasarjojen välitys kokonaisina päivinä Osapuolten ei tarvitse raportoida täysiä päiviä (24 tuntia), mutta datahub välittää tiedot täysinä päivinä eteenpäin. Onko täysien päivien välitys tarpeen? Voidaanko välittää tiedot sen mukaan mitä jakeluverkonhaltija ilmoittaa datahubiin? Eli se mikä tulee datahubiin, välitetään sellaisenaan eteenpäin. Välitettävien sanomien koko voi olla suuri, jos osapuolen raportoimat yksittäiset arvot välitetään eteenpäin koko päivän tuntisarjana ja "lisäkäsittely" hidastaa mittaustietojen käsittelyä.

8 Pöytäkirja 8 (10) Ei tarvitse täydentää ulos lähetettävään sanomaan täysiksi vuorokausiksi vaan voi välittää sen mikä ilmoitettiin Aikasarjatietojen välitys Tällä hetkellä vaadittu, että uudet ja muuttuneet aikasarjatiedot välitetään osapuolille eteenpäin. Toisin sanoen nykymäärityksillä datahub ei välittäisi JVH:n datahubiin ilmoittamia muuttumattomia mittaustietoja. CGI ehdottaa, että verkonhaltijan ilmoittamat aikasarjatiedot välitetään sellaisenaan aina eteenpäin, vaikka niissä ei olisi uusia tai muuttuneita arvoja, jotta prosessista saataisiin yksinkertaisempi (vähemmän altis virheille) sekä tehokkaampi. Datahub välittää eteenpäin samat mittaustiedot mitkä on datahubiin ilmoitettu, ei tarvitse suodattaa mitkä ovat muuttuneet ja mitkä eivät Toimeksiannot ja muistutukset Jos mittaustietojen raportointi on toimeksiannettu toiselle osapuolelle, kenelle muistutus mittaustietojen raportoinnista pitäisi mennä? DSO:lle? Toimeksiannetulle mittaustietojen raportoijalle? Molemmille? Muistutus lähetetään mittaustietoja raportoivalle osapuolelle. Ei alkuperäiselle toimeksiantajalle. Verkko ja palveluntuottaja hoitavat tarvittaessa tiedon edelleentoimittamisen toimeksiantajalle keskenään min aikasarjoihin valmistautuminen Tämän hetkinen aikasarja-arvon rajoitus ei riitä yhden käyttöpaikan yhden vuoden aikasarjatietojen hakemiseen 15min aika-askeleella. Rajan tulisi olla esim arvoa, jotta koko vuoden tiedot voitaisiin hakea yhdelle käyttöpaikalle. Tulisiko täten arvojen lukumäärää sanomassa nostaa vai lyhentää yksittäisellä haulla haettavissa olevan aikavälin pituutta? Vuosi pitää voida hakea kerrallaan, myös vartissa Aikasarjan tunnus Miten E66 mittausaikasarjasanomassa ilmoitettavaa verkkoyhtiön käyttämää aikasarjan tunnusta tulisi hyödyntää? Aikasarjan tunnusta ei käytetä sisäisesti datahubissa, mutta tulisiko se raportoida osana hylkäyssanoman syytä, aikasarjan hylkäyksen yhteydessä? Pidetään kenttä, laitetaan mukaan hylkäysviestiin Taseselvityssanomien formaatti esett/osapuolet Tulisiko osapuolille lähetettävissä taseselvityssanomissa käyttää samaa tiedostoformaattia kuin esett:n sanomissa? Etuna olisi se, että nämä sanomat on jo nykyisissä järjestelmissä käytössä. Datahubin suunnitellussa sanomassa kuitenkin menee kaikki tiedot samassa sanomassa. esettin käyttämissä sanomissa myyjien summatiedot menee omassa sanomassa ja rajapisteiden väliset siirrot omassa ja lasketut tasepoikkeamat vielä omassa sarjassaan.

9 Pöytäkirja 9 (10) Käytetään esett-sanomia, ei tarvetta pakata kaikkea yhteen sanomaan Mittaustiedon haun validointi Jos osapuoli hakee mittauspistekohtaisesti mittaustietoa, johon tällä ei ole oikeutta, tulisiko koko haku hylätä, jos osapuolella ei ole oikeutta yhteen tai useampaan haettuun mittauspisteeseen? Palauttaa niiden tiedot mihin on oikeudet, kertoo ne pyydetyt mittauspisteet joihin hakijalla ei ole oikeuksia Ilmoitettujen mittaustietojen käsittely tuntitiedoille 15 minuutin taseselvitysaikana Datahubin käyttöönotosta lähtien taseselvitys tullaan tekemään 15 minuutin resoluutiolla. Kun datahubiin ilmoitetaan tuntitietoa mittaustiedoille, ehdotamme että mittaustiedot välitetään tällöin myös tuntitietoina eteenpäin ja laskennat tehdään 15 minuutin tarkkuudella. Tulisiko myyjien ja 3.osapuolien kuitenkin voida hakea tuntimitattujen mittaustietojen osalta rajapinnasta mittaustietoa 15 minuutin resoluutiolla? Jos kyllä, missä tapauksissa/mihin tarkoitukseen? Riittäisikö esimerkiksi 15 minuutin tietojen saanti summatasolla? Asiasta on aiemmin keväällä käyty ryhmässä keskustelua, mutta asia on tällöin vielä jäänyt auki. Mittauspisteellä tulee olla tieto millä aikaresoluutiolla sitä mitataan. Mittaustiedot välitetään sillä aikaresoluutiolla millä ne on ilmoitettu. Mittaustiedot tulee voida kuitenkin hakea myös varttiresoluutiolla, vaikka ne olisi mitattu tunnissa Asiakkaan nimi Asiakkaan nimikentän pituuden lisääminen - Titta palvelun käytön kautta on tullut esiin tapauksia joissa asiakas-tiedon toimitus jää virheeseen liian lyhyen kentän vuoksi. Kasvatetaan kentän pituutta Uuden sopimuksen ilmoitussääntö Tarkoitetaanko kohdan säännöllä sisäänmuuttoa eli sitä että kaikki asiakkaat muuttuvat? Eikä sitä, että vain osa asiakkaista muuttuu (tarkennettava). Korjataan sisäänmuutoksi, kaikki asiakkaat muuttuvat Peruutuksen aikaraja Onko yleisellä peruutussanomalla E67 jokin aikaraja, jonka kuluessa perutettavasta sanomasta se tulee lähettää? Päivityspyyntöjen peruutus: tarvitaanko aikaraja, päivityspyynnön peruutus tulee välittää päivityspyynnön vastaanottajalle. Kuvaus puuttuu dokumenteista. Fingrid tekee ehdotuksen alalle kommentoitavaksi tapahtumakohtaisesti.

10 Pöytäkirja 10 (10) 5.20 Käyttöpaikkatiedon haku Pitäisikö olla mahdollista hakea käyttöpaikkatietoja niin, että tosiaan haetaan vain käyttöpaikkatietoja, ei asiakas- tai sopimustietoja? Esimerkiksi mittaustietoja toimittava palveluntarjoaja. Sanoma F21 mahdollistaisi tämän, mutta luultavasti tarvittaisiin erillinen DHtapahtuma. Kyselytapahtuman F03 tietoja ja niiden pakollisuuksia voi olla tarve muokata. Esimerkiksi haku mittausalueen perusteella voisi olla tällöin tarpeellinen? Nykyiset pakollisuudet Tapahtumat-dokumentin luvussa eivät liene ihan oikein, tarvitsee muokata. Tietorajapinta oletetaan riittäväksi, jakeluverkonhaltijan toimeksiannon perusteella. Puheenjohtaja koostaa kesken jääneistä asioista, joita kokouksen aikana ei ehditty läpikäymään, listan ja lähettää työryhmäläisille sähköpostitse. Jatketaan listan läpikäyntiä perjantain Skype-kokouksessa. 6 Seuraava kokous ja kokouksen päätös Puheenjohtaja päätti kokouksen klo Seuraava kokous sovittiin pidettäväksi (Skype-kokous) klo ja seuraava kokopäivän kokous on klo Liitteet Esitysmateriaali Jakelu Prosessityöryhmä Teemu Hellas Emmi Kaivosoja