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.) Pinja Kimari (asialistan kohdissa 1-5) Emmi Kaivosoja Teemu Hellas Pasi Lintunen (asialistan kohdassa 3) 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 Esa Kaario Tampereen Sähköverkko Oy Arttu Lahtinen Fortum Markets Oy Monika Lindberg Fortum Markets Oy Jari Nykänen Paikallisvoima ry Vesa Mäkilä SPS Energiapalvelut Oy 1 Kokouksen avaus Puheenjohtaja avasi kokouksen klo ja esitteli kokoukseen osallistuneen Pinja Kimarin, jonka vastuualueena projektissa on tietosuoja- ja tietoturva-asiat. Puheenjohtaja kertoi, että kokoukseen toimijoiden käyttöönottosuunnitelman ohjeistuksesta tulee kertomaan Pasi Lintunen, jonka kanssa voi keskustella ohjeistukseen liittyvistä kysymyksistä. 2 Terveisiä Datahub Road Show:sta Puheenjohtaja kertoi ajankohtaisina asioina, että CGI on tekemässä CMS-tuotteeseen määrittelyjä ja ensimmäisenä vuorossa ovat asiakas-, käyttöpaikka- ja sopimustietojen sekä kytkentäpyyntöjen osalta tuotemääritysten valmistuminen. Terveisinä Datahub Road Show:sta puheenjohtaja kertoi, että esille tilaisuuksissa nousi muun muassa seuraavia kysymyksiä: Sähköinen laskutus onko asiakkaan viite mahdollista antaa? Taustasopimukset onko datahubissa huomioitu? Puheenjohtaja vastasi taustasopimuksiin liittyen, että taustasopimuskäsite ei istu datahubiin, eikä oletusmyyjä käsitettä saa lain mukaankaan käyttää. Työryhmäläiset kommentoivat, että taustasopimuksia on nykyään käytössä esim. vuokra-asunnoissa eli esim. asukkaan muuttaessa pois sopimus siirtyy asunnonomistajalle. Datahubin näkökulmasta näissäkin tapauksissa ilmoitetaan aina uusi sopimus ja menetellään määritettyjen prosessien mukaisesti. Kysymyksenä esille nousi myös osapuolen käyttöliittymä ja mitä siinä voi tehdä ja kenelle se on tarkoitettu? Puheenjohtaja kommentoi, että tammikuussa saattaisi olla mahdollista

2 Pöytäkirja 2 (10) demota työryhmälle järjestelmän käyttöliittymää ja aiheeseen tullaan palaamaan silloin. Osoitetiedoista saatiin myös paljon kysymyksiä sen osalta, miten asiakkaan osoitetta ylläpidetään. 3 Toimijoiden käyttöönottosuunnitelma ohjeistus Pasi Lintunen Pasi Lintunen kertoi työryhmälle käyttöönottoon liittyvistä suunnitelmista, sähkömarkkinalain velvoitteista sekä datahub-lainsäädännön tilanteen. Talousvaliokunta on antanut mietintönsä Sähkömarkkinalain muutosesitykseen, joka ei Lintusen käsityksen mukaan sisältänyt merkittäviä muutoksia. Lakiesitys on menossa lähiaikoina eduskunnan käsittelyyn. Lintunen korosti esityksensä alussa, että onnistunut käyttöönotto edellyttää hyvää suunnittelua. Käyttöönoton päätavoitteina on saada projekti kerralla maaliin, turvata vähittäismarkkinoiden, prosessien ja liiketoiminnan jatkuvuus sekä säilyttää asiakkaan kokeman palvelun laatu hyvänä. Lintunen näytti myös mitä käyttöönottosuunnitelmia datahubin käyttöönotto vaatii ja miten ne eroavat toisistaan. Lintusen esitysmateriaali löytyy pöytäkirjan liitteenä. Kaikkien markkinaosapuolten tulee tehdä tarvittavat valmistelutoimet datahubin käyttöönottamiseksi. Sähkömarkkinalain muutosesitykseen on kirjattu velvoite käyttää datahubin palveluita (vähittäismyyjät ja jakeluverkonhaltijat) sekä toteuttaa datahubin käyttöönoton edellyttämät valmistelutoimet. Fingrid on yhdessä toimialan jäsenistä koostuvan työryhmän kanssa määrittänyt mittaristoa, tehtävälistoja ja seurantatyökaluja valmistelutoimien etenemiselle. Vähittäismyyjien ja jakeluverkonhaltijoiden on laadittava oma suunnitelma datahubin käyttöönotolle kolmen kuukauden kuluessa lain voimaantulosta. Suunnitelma tulee toimittaa Energiavirastolle sekä Fingridille. Valvontatoimivalta valmistelutoimien suhteen on Energiavirastolla. Fingrid raportoi osapuolen edistymistä sekä valmiudesta EV:lle. Datahubin käyttöönottosuunnitelmasta tullaan julkaisemaan väliversio 1.2 vuoden loppuun mennessä. Versiopäivityksen yhteydessä suunnitelma päivitetään sähkömarkkinalain mukaiseksi. Suuremman remontin kokeva versio 2.0 julkaistaan datahub-projektin suunnitteluvaiheen jälkeen keväällä Fingrid on työstänyt myös yhdessä toimialan edustajista kootun työryhmän kanssa ohjeistuksen markkinaosapuolten käyttöönottosuunnitelmien laatimisen tueksi. Työryhmäläiset kommentoivat, että kysymyksiä markkinaosapuolen suunnitelman osalta tulee varmasti, kunhan suunnitelmaa aletaan tekemään, mutta tässä vaiheessa tarkentavia kysymyksiä ei herännyt. Puheenjohtaja kertoi Lintusen esityksen lopuksi, että toimialan ohjeistaminen puuttuvien henkilötunnusten keräämiseksi on nostettu Fingridin Tiedonvaihdon kehitysryhmän sekä ET:n vähittäismarkkinoiden menettelytapojen kehitysryhmän yhteiskokouksen agendalla Työryhmässä kommenttina esiin nousi Titta-palvelun käyttöönotto ja vastuurajoitukset palvelun osalta. Puheenjohtaja kommentoi, että palvelusopimukset solmitaan jokaisen palvelua käyttävän osapuolen kanssa edelleen, mutta lainsäädäntö toki määrittää vastuut. Puheenjohtaja lupasi välittää tietokonversioprojektista vastaavalle Lauri Jännekselle palautteen, että onhan Titta-palvelun palvelusopimus linjassa lainsäädännön kanssa.

3 Pöytäkirja 3 (10) 4 Tietosuoja datahubissa Pinja Kimari Kimari kertoi työryhmälle, miten tietosuoja on huomioitu projektissa tähän asti sekä tulevaisuudessa. Kimari kertoi tietosuoja-asetuksen lähtökohdista ja periaatteista lyhyesti. Periaatteena on, että kaikella henkilötietojen käsittelyllä on ennalta määritetty käyttötarkoitus. Kerättävän tiedon määrä minimoidaan ja sitä säilytetään vain lakisääteisen ajan. Käsittely on läpinäkyvää ja se lokitetaan, jotta voidaan osoittaa lain noudattaminen. Käsittely tapahtuu huolellisesti ja riittävät tekniset sekä organisatoriset suojaukset otetaan käyttöön, jotta henkilötieto ei tahattomasti tai laittomasti muutu, häviä tai tuhoudu. Keskustelussa huomioina esiin nousi, että datahubin palvelimet sijaitsevat Fingridin konesalissa ja että CGI:llä ei ole mahdollisuutta päivittää järjestelmään tietoa sisäisillä tunnuksillaan. Kimari kertoi myös Fingridin toimintaperiaatteista. Tuotteen ja toimittajan puolesta tietosuojaa on huomioitu monelta osin, mutta myös Fingridin tulee huolehtia prosessien tietoturvallisesta suunnittelusta. Tavat toimia ovat suunnitellut, kuten myös pääsynhallintakäytännöt ja tietosuojan toteutus validoidaan. Kimari näytti myös mitä projektin eri osa-alueiden osalta tulee huomioida tietosuojamielessä. Kaavio löytyy Kimarin esitysmateriaalista, joka löytyy pöytäkirjan liitteenä. Kimari kertoi, että tietosuojasta on tulossa oma kattava dokumenttinsa. Puheenjohtaja kommentoi, että Titan osalta tietosuojadokumentti löytyy jo EDIELfi-portaalista. Kimari näytti työryhmäläisille mitä henkilötietoa datahubissa on. Henkilötiedoksi lasketaan mikä hyvänsä tieto, joka voidaan joko suoraan tai välillisesti yhdistää henkilöön. Kimari korosti, että on äärimmäisen tärkeää, että kaikille asiakkaille on ilmoitettu henkilötunnus, sillä tällä tiedolla asiakas yksilöidään datahubissa. Tietosuojan turvaamiseksi on oleellista, että kaikki osapuolet käyttävät datahubia vain määriteltyihin markkinaprosesseihin ja niiden nimenomaisiin tarkoituksiin. Osapuolten tulee käsitellä henkilö- ja asiakastietoja huolellisesti ja luottamuksellisesti. Osapuolten tulee myös huolehtia omista järjestelmistään ja niiden ajantasaisesta tietoturvasta. Markkinaosapuolilla on vastuu riittävien turvatoimien toteuttamisesta henkilötietojen suojaamiseksi. Ylätason hahmotuksen tekeminen miten vastuut jakautuvat datahubin käyttöönoton jälkeen on aloitettu. Tarkempi sisältö vastuiden osalta tulee vielä tarkentumaan ennen datahubin palvelusopimusten laatimista. Kimarin esittämä vastuukaavio löytyy esitysmateriaalista pöytäkirjan liitteenä. Lopuksi Kimari näytti muistilistaa, mitä markkinaosapuolten tulisi tietosuojan osalta huomioida. Markkinaosapuolten tulee tarkistaa, että organisaation tietosuojaseloste / rekisteriseloste kattaa käsittelytoimet datahubin käyttöönottamisesta. Markkinaosapuolten tulee myös huolehtia tarvittavien vastuuhenkilöiden nimeämisestä (tietosuoja ja tietoturva) sekä tarkistaa informointivelvoitteet (art. 12). Osapuolten on huolehdittava tietosuojaloukkausprosessinsa tarkistamisesta sekä tarkistettava testiympäristöjen tietojenkäsittelijät & mahdollisesti tarvittavat sopimukset. Myös projektin jälkeisten tietoturva- ja tietosuojakäytäntöjen valmistelusta tulee huolehtia. Kysymyksenä työryhmässä heräsi, onko tietosuojasta tulossa esitys webinaariin? Puheenjohtaja kommentoi, että aiheesta tullaan pitämään varmasti oma datahub-webinaari. Kimari tulee tietosuojatyön edetessä kertomaan sen etenemisestä työryhmän kokouksiin

4 Pöytäkirja 4 (10) myös jatkossa. Keskustelussa esille nousi huomio, että aggrekoitu tieto, jota tullaan datahubista tuottamaan, tullaan vielä käymään läpi datahub-projektissa. 5 Valtuutukset datahubissa / muut keskeneräiset asiat 5.1 Salaisen asiakkaan käsittely Salaisen asiakkaan käsittelystä keskusteltiin myös Energiateollisuus ry:n vähittäismarkkinoiden kehitysryhmässä. Asian osalta menettelyohjeeseen (11.3.) on kirjattu: Salassa pidettävien asiakkaiden määrä on ollut kasvussa. Tietojen salassa pito on varmistettava koko prosessin ajan ja luonnollisesti myös sen jälkeen. Tällaisen turva-asiakkaan ollessa kyseessä, tulee ennen normaalin sanomaprosessin käynnistämistä lähettää sähköpostilla tieto kyseisen asiakkaan tietojen salassa pidosta. Tähän sähköpostiin on pyydettävä kuittaus. Sähköposti tulee lähettää jo ennen sanomaa, jotta varmistutaan prosessin oikeasta käsittelyjärjestyksestä siten, etteivät asiakkaan tiedot jää salaamatta sanoman ja sähköpostin käsittelyn väliseksi ajaksi. Tieto salassa pidosta on hyvä lähettää myös salatulla sähköpostilla, jonka avain lähetetään erikseen esimerkiksi tekstiviestillä. Nykyinen malli (sähköposti) takaa salaisen asiakkaan tietosuojan PRODAT-sanomien näkökulmasta. Sähköpostikäsittely on kuitenkin jo vanhanaikainen toimintatapa, ja datahub tulee varmistamaan salaisen asiakkaan käsittelyn automaattisin prosessein. Alalle tarvitaan myös ohjeistusta, miten markkinaosapuolten tulee käsitellä salattuja asiakkaita. Datahub ei tule ottamaan kantaa, onko salattu asiakas turvakieltoasiakas vai muusta syystä salaiseksi merkitty asiakas. Sovittiin tarkennettavaksi ohjeistusta, miten markkinaosapuolen tulee salaisen asiakkaan tietoja käsitellä. Maistraatin sivuilta löytyy ohje turvakieltoasiakkaan käsittelystä. Datahubissa turvakieltoasiakas tulee merkata salaiseksi, datahub ei tietoa tarkista vaan vastuu tiedon ilmoittamisesta on markkinaosapuolilla. Muita asiakkaita käsitellään datahubissa GDPR:n mukaisesti. Salaisella asiakkaalla tarkoitetaan siis turvakieltoasiakasta (kuluttaja) myös yhtiö voidaan poikkeustapauksissa määrittää salaiseksi asiakkaaksi. ET:n vähittäismarkkinoiden kehitysryhmään voidaan nostaa keskusteluun, tarvitaanko maistraatin ohjeen lisäksi vielä tarkempaa ohjeistusta asiasta. 5.2 Valtuutusten ilmoitus Myös työryhmässä aiemmin käsittelyssä ollutta valtuutusten käsittelyä on käyty läpi Energiateollisuus ry:n vähittäismarkkinoiden kehitysryhmässä. Aiemmin prosessityöryhmässä käydyn mukaisesti muiden kuin kuluttaja-asiakkaiden kanssa on mahdollista käyttää edelleen valtuutuksen ilmoitukseen myyjän lähettämää DH-810 tapahtumaa. Jos myyjä on ilmoittanut sopimuksen datahubiin, pitäisi ET:n työryhmän näkemyksen mukaan myyjän voida ilmoittaa DH-810 tapahtumalla myös kuluttajan valtuutus datahubille kulutushistoriatietojen hakemista varten. ET:n työryhmän mukaan tämä pitää nostaa vielä uudelleen käsiteltäväksi. Puheenjohtaja lupasi nostaa asian uudelleen keskusteluun myös Fingridin lakiosaston kanssa, sillä tämä on tunnistettu lain tulkinnan kannalta haasteellisena Fingridin näkökulmasta. Jos asiakkaan valtuutuksen ilmoittaa kolmas osapuoli (palveluntarjoaja) vaadittaisiin toki asiakkaan ilmoittama valtuutus suoraan datahubiin. Ehdotuksina valtuutuksen antamiskanavina esille nousivat yhtiöiden Online-palvelut sekä tekstiviesti, mutta tekstiviesti ei kuitenkaan täytä vahvan tunnistautumisen kriteerejä. Valtuutusten ilmoitus nostetaan seuraavaan kokouksen agendalle

5 Pöytäkirja 5 (10) 5.3 Työryhmästä esille nousseiden kysymysten läpikäynti DH-333: Verkkosopimusten päättäminen tehdään lähes aina takautuvasti, koska se kohdistetaan siihen päivään, jolloin mittari on haettu pois asiakkaalta. Poiston ilmoittamisessa voi olla viivettä. Nyt aikarajoiksi on määritetty kuluvä päivä 90 vuorokautta Kyllä, tämän hetken määritysten mukaan päättämiset tulisi ilmoittaa aikaisintaan tapahtumapäivänä. Meneekö sisäänmuuton peruuttaaminen samalla tavalla kuin myyjänvaihdossa. Eroaako tilanne jos vanha myyjä on ilmoittanut ulosmuuton? Tarjotaanko sopimusta takaisin missä tilanteessa? Sopimuksen peruutuksen tekee se osapuoli joka sopimuksen on ilmoittanut. Peruutus ei eroa sen osalta onko ilmoitus kirjattu syytiedolla muutto tai myyjän vaihto. Jos vanha myyjä on ilmoittanut ulosmuuton ennen peruutettavaa sisäänmuuttoa ja sisäänmuutto perutaan, ulosmuutto jää voimaan Erillinen ulosmuuttoilmoitus osana asiakkaan sisäänmuuttoa: Miten hoituu; Jakeluverkonhaltija voi ottaa yhteyttä asiakkaaseen, jos sisäänmuutto kohteen myyjä ei ole ilmoittanut kaikkia sopimuksen asiakkaita. Jatkossa sisäänmuuttotilanteessa syntyneen myyntisopimuksen perusteella määräytyy asiakkaat verkkosopimukselle. Nähdäkseni ei ole tilannetta, jolloin verkolla olisi tarvetta lisätä asiakkaita sopimukselle. Mikäli näin on, on myyntisopimus tehtävä uusiksi. Voiko ulosmuutto kohteen jättää tällä ilmoituksella voimaan niille asiakkaille joiden yhteystietoja ei ilmoiteta? Ei, mikäli asiakkaat muuttuvat sopimuksella tarvitaan aina uusi sopimuksen ilmoitus. Voiko ulosmuuttokohteen jättää tälle ilmoituksella voimaan niille asiakkaille joiden yhteystietoja ei ilmoiteta? Eikö tieto pitäisi mennä vanhalle myyjälle ja hän selvittää jäävät käyttöpaikalle? Ei mikäli asiakkaat muuttavat sopimuksella tarvitaan aina uusi sopimuksen ilmoitus. Vanha myyjä saa tiedon sopimuksen päättymisestä. Työryhmä kommentoi, että nykyinen määrittely ei ehkä ole riittävä, sovittiin että palataan aiheeseen tarvittaessa seuraavassa työryhmän kokouksessa. DH Ilmoitus myyntisopimuksen päättymisestä: Tietokonversioiden jälkeen verkko- ja myyntisopimukset voivat olla erihenkilön nimissä. Dokumentin mukaan sanomassa ei mene asiakkaan nimeä. Miten datahub osaa käsitellä tilanteen, jossa verkkosopimuksella oleva henkilö on jo tehnyt sopimuksen uuden (toisen) myyjän kanssa kuin käyttöpaikan vanha myyntisopimus ilmoitetaan päätettäväksi. Päättämisessä ilmoitetaan syytieto. Jos päättäminen tehdään syyllä irtisanominen, jää jo aiemmin ilmoitettu myyntisopimus voimaan. Vanha sopimus päättyy. Keskustelussa esille nousi, että konversiossa näitä tilanteita tulee vastaan ja käyttöönoton jälkeenkin vielä. Mikäli myyntisopimus on päättymässä verkkoyhtiö saa kyllä tiedon tästä. Missä tilanteessa datahub toimittaa negatiivisen kuittauksen? Esimerkiksi ulosmuutoissa aina kun sanoma ei mene validoinneista läpi. Tämän tapahtu-

6 Pöytäkirja 6 (10) man validointisäännöt löytyvät prosessidokumentista (Sähkön vähittäismarkkinoiden liiketoimintaprosessit datahubissa) DH Toimituksen kytkentäpyyntö: Sanomassa ei ole mahdollista ilmoittaa erillistä numero kytkentäturvallisuuden varmistamista varten, koska puhelin numero otetaan asiakastiedoista. Nykyään puhelin numero löytyy sähköpostilla toimitettavasta kytkentä pyynnössä. Olisi hyvä saada sanomaan. On määritelty version 1.6. dokumentteihin. DH Ilmoitus toimituksen kytkennästä: Onko varttitaseella vaikutusta, tuleeko ilmoittaa vartin tarkkuudella? Osa tunnissa osa vartissa? Kytkentätapahtuma ilmoitetaan varttimaailmassa vartin tarkkuudella. DH Ilmoitus kytkennän viivästymisestä: Jos asiakas ei vastaa kytkentäturvallisuustekstiviestiin, niin miten JVH voi arvioida mahdollisen kytkentäajankohdan? Pitäisikö toimialaa ohjeistaa joihinkin perustapauksiin ohjeellisia viivästysaikoja. Mikäli JVH ei voi arvioida mahdollista kytkentäaikaa ei tätä ole pakko ilmoittaa. Voidaan nostaa keskusteluun myös ET:n vähittäismarkkinoiden kehitysryhmässä. DH Ilmoitus katkaisun viivästymisestä: Jos katkaisu viivästyy, niin meneekö energia myyjän vai verkon häviöihin? Jos katkaisu viivästyy, menee kulutus myyjän pyytämän katkaisupäivän jälkeen verkon häviöihin. Jos menee häviöihin, niin lähettääkö datahub sanoman (Huom prosessi kaavioissa nuoli on vaan JVH:ltä datahubiin.) Sanoma mainittu DH-311:n yhteydessä myös Tämä lasketaan automaattisesti verkon häviöihin. Tämän osalta on CGI:n kanssa vielä kesken selvitys siitä miten loppujen lopuksi toteutetaan tämän raportointi DH Tuotetiedon päivitys: Pitääkö alueverkon kohteille välittää tuotetietoja? Ei, alueverkon osalta datahubiin tuodaan vain rajapistetietoja ja nekin vain siltä osin kuin koskevat liityntää jakeluverkkoon. Alueverkon osalta datahubiin täytynee viedä ainoasta häviöiden laskennan kannalta oleellinen tieto. Kyllä. Tuotantokohteiden sopimusprosessin tulisi voida lähteä liikkeelle verkosta ilman että kukaan ostaa tuotettua sähköä Pientuotannon kohteilla on aina oltava myyjä, mikäli tähän tulee muutos niin sen jälkeen voidaan miettiä tätä uudelleen, muutoin menee kuin myyntisopimuksen prosessi. Verkkoyhtiö voi tarvittaessa ylläpitää tietoja pientuotantokohteesta myös muulla tavoin ilman sopimuksia. Kommenttina esiin nousi, että sopimusprosessi lähtee aina liikkeelle myyjältä. Negatiiviset kuittaukset täytyy tarkentaa joka paikkaan prosesseja. Onko muuta kuin teknistä tarkastusta vai tarkastetaanko sanomasisältöjä tms?

7 Pöytäkirja 7 (10) Validointisäännöt on kuvattu prosessidokumenttiin sekä tapahtumat dokumenttiin ja negatiivisiin kuittauksiin pyritään saamaan mahdollisimman kuvaavasti se syy miksi sanoma ei ole mennyt validoinnissa läpi. Tarkemmat tekniset kuittaukset tullaan kuvaamaan projektin edetessä 6 Käsiteltävien asioiden listan läpikäynti Läpikäytiin käsiteltävien asioiden Excel-listan avoimet kohdat. Listattuja avoimia asioita käytiin läpi myös ja pidetyissä Skype-kokouksissa. Skype-kokouksissa käsitellyt kohdat löytyvät pöytäkirjan liitteestä Eri mittausresoluutiot Miten menetellään jos käyttöpaikan mittausjakso on esim. 5min ja taseselvitys tehdään vartissa. Mitä tietoa ilmoitetaan hubiin? Onko käyttöpaikan mittausresoluutio mittauksen vai taseselvityksen? Mitä näytetään asiakkaalle verkkoyhtiön ja datahubin asiakasportaaleista? Toimitetaan varttia tai tuntia taseselvitysjakson mukaan. 6.2 Eri mittausresoluutiot, pätö/lois Onko mahdollista, että pätö- ja loismittauksilla olisi eri mittausresoluutio? Teoreettisesti mahdollista, ei keksitty todellisia tapauksia. TMTSTR:n lisättäväksi suosituksiin että näillä on aina sama resoluutio. Sovittiin kysymys vietäväksi myös markkinaosapuolten järjestelmätoimittajien keskusteluun perustetussa Slack-foorumissa. 6.3 Rinnakkaiset käyttöpaikat uuden sopimuksen teossa Pitäisikö sisäänmuuton yhteydessä peruuttaa paitsi kyseisen käyttöpaikan, myös rinnakkaisten käyttöpaikkojen muiden kuin sisään muuttavien asiakkaiden tulevaisuudessa alkavat sopimukset? Ei ilmoiteta mitään. 6.4 Käyttöpaikan mittauksen resoluutio Varttimittauksen takia käyttöpaikalle tarvitaan tieto käyttöpaikan mittauksen resoluutiosta (1h/15min). Ehdotus, että käyttöpaikan ominaisuuksiin lisätään resoluutio -attribuutti. Samalla mittaustapa "tuntimittaus" muutettaisiin "jatkuva mittaus". Huomio työryhmältä: Verkkoyhtiöissä suunnitteilla ja osin jo käytössä tarkempaa resoluutiota mittauksissa kuin varttia. Tällöin verkkojen omissa järjestelmissä resoluutio olisi eri kuin datahubissa. Mennään näillä näkymin ebix standardin mukaan, käyttöpaikan ominaisuuksiin lisätään resoluutio -attribuutti. Samalla mittaustapa "tuntimittaus" muutettaisiin "jatkuva mittaus". FG saattaa konsultoida vielä järjestelmäntoimittajafoorumia aiheesta. Toteutetaan kaksi erillistä attribuuttia.

8 Pöytäkirja 8 (10) 6.5 Osoiterakenneohje Osoiterakenne ohjeessa postilokeron merkkien pituus on 10 ja datastandardissa 15. Korjataan osoiterakenneohjetta tältä osin. Osoiterakenneohjeessa olemme ohjeistaneet että asunto lyhennetään niin suomeksi kuin ruotsiksi pisteen kera, eli as. ja bst. Posti ja VRK eivät JHS 106 ohjeistuksen mukaisesti kuitenkaan käytä pistettä. Korjataan osoiterakenneohjeeseen, että voidaan käyttää pisteellä tai ilman. Korjataan osoiterakenneohje datastandardin mukaiseksi postilokeron merkkimäärän suhteen. Korjataan osoiterakenneohjeeseen as ja bst lyhenteisiin liittyen, että voidaan käyttää pisteellä tai ilman, pienillä kirjaimilla. 6.6 Määräaikaisen sopimuksen käsittelystä Jos käyttöpaikalla on määräaikainen sopimus joka on vielä voimassa, pitäisikö saman myyjän pystyä ilmoittamaan silti uusi sopimus jossa on ainakin osin samat asiakkaat käyttöpaikalle? Myyjälle pieni mutkistus jos tarvitsee erikseen ensin sopimuspäivityksellä aikaistaa sopimuksen määräaikaisuuden päättymispäivää ennen kuin voi ilmoittaa uuden sopimuksen. Tuleeko jotain ongelmia, jos tämä oikopolku sallitaan? Ei tarvita oikopolkua, tehdään erikseen määräaikaisuuden päättäminen ja sitten uuden sopimuksen ilmoitus. 6.7 Asiakkaan yhteystiedot Miten datahub toimii, jos uuden sopimuksen ilmoituksessa DH asiakkaalle ei ilmoiteta puhelinnumero tai/eikä sähköpostiosoitetta, mutta tällaiset datahubin asiakastiedoista kuitenkin löytyisi ennestään. Poistetaan vai ei? Onko tarvetta poistaa tällaista tietoa sopimusilmoituksessa? Asiakastiedon päivityksessä jompi kumpi yhteystieto on pakko ilmoittaa, mutta uuden sopimuksen ilmoituksessa ei ole tällaista sääntöä. Uuden sopimuksen ilmoituksessa tyhjä puhelinnumero ja/tai sähköposti ei poista asiakkaan tiedoista näitä, mutta ilmoitettu numero/osoite korvaa edellisen. Jos halutaan poistaa asiakkaalta yhteystieto, se tehdään erillisellä asiakastiedon päivityksellä. 6.8 Kieltäytyminen myyntisopimuksen palautuksesta peruutustilanteessa DH-343 Kieltäytyminen myyntisopimuksen palautuksesta peruutustilanteessa: Mitä tapahtuu, jos voimaan palautettava määräaikainen myyntisopimus on sellainen, jossa määräaikaisuus päättyy 1-14 päivää perutun myyntisopimuksen aloituksen jälkeen (sisäänmuutto). Saako myyjä esimerkiksi päättää sopimuksen määräaikasuuden päättymishetkeen? Hyväksytään aikaisempi päättäminen datahubissa määräaikaisuuden päättymispäivälle. 6.9 Sopimuksen päättämisestä Onko tarvetta myyjän voida signaloida datahubiin, että haluaa sopimuksen päättyvän, sellaisessa tilanteessa jossa sopimuksen on laitettu päättymään jo uuden sopimuksen ilmoituksen perusteella? Jos on, miten? Relevantti esimerkiksi jos on tarve ennalta varmistaa, että peruutustilanteessa ei palauteta tällaista sopimusta voimaan, koska myyjäkin

9 Pöytäkirja 9 (10) on sen halunnut päättää. Ei nähty tarvetta tällaiselle ilmoitukselle Tuotteen päivitys Tuotteen päivittäminen: jos päivityksessä ei ilmoiteta hinta-aikasarjaa (vapaaehtoinen tieto) se poistetaan, varmistus että näin voidaan tehdä? Työryhmän näkemyksen mukaan tehdään kuvatusti Sopimuksen peruuttaminen Onko tilanteita, joissa olisi tarpeen voida peruuttaa sopimus joka on jo päättynyt? Oletettavasti harvinainen tilanne, mutta tulee eteen silloin tällöin. Jos on helppo toteuttaa, niin sallitaan normaalina peruutuksena, mutta ainakin pitäisi olla mahdollista operaattorin manuaalisena toimenpiteenä. 7 Seuraava kokous ja kokouksen päätös Työryhmästä nousi esiin kysymys, miten muutosten hallinta tapahtuu suunnitteluvaiheen jälkeen? Puheenjohtaja kommentoi, että suunnitteluvaiheen jälkeen muutostarpeita arvioidaan todella kriittisesti. Jatkossa muutostarpeita tullaan käsittelemään myös uudessa järjestelmätoimittajien työryhmässä. Kysymys heräsi myös uuden prosessityöryhmän kokoamisesta, ja siitä että varmistetaanhan se, että eri järjestelmätoimittajien järjestelmät ovat edustettuina uuden työryhmän edustajilla? Puheenjohtaja kertoi, että Energiateollisuus ry nimeää työryhmän jäsenet ja heitä on pyydetty huomioimaan myös tämä näkökulma. Työryhmän keskuudessa heräsi myös huoli varsinkin tulevaisuuden muutostarpeiden osalta datahub versioon 2.0, että osallistetaanhan toimialaa laajemmin päätöksentekoon, ettei päätöksiä tehdä ainoastaan rotaation jälkeen pienenevässä prosessiryhmässä. Puheenjohtaja vastasi, että uuden prosessityöryhmän tehtävänä on varmistaa, että päästään tuotantoon datahub versiolla 1.0. Työryhmässä kirjataan toki ylös jo tunnistettuja kehitystarpeita datahub versioon 2.0, mutta päätöksentekoon tullaan osallistumaan toimialaa laajemminkin ja hyödyntämään eri foorumeita niin kuin nytkin. Työryhmässä tunnistetaan ne asiat, joissa päätöksen tekoon tarvitaan laajempaa keskustelua toimialan kanssa. Lopuksi heräsi myös kysymys mitä loppuasiakkaat Suomi.fi-portaalissa pystyvät tekemään ja miten tämä tulisi huomioida yhtiöiden Online-palveluissa. Puheenjohtaja kommentoi, että tarkemmat määrittelyt Suomi.fi-portaalin toiminnallisuuksien osalta aloitetaan datahub-lainsäädännön voimaan astumisen jälkeen Väestörekisterikeskuksen kanssa. Suomi.fi portaalin toiminnallisuuksia tullaan näin ollen käymään läpi tarkemmin ensi vuonna. Puheenjohtaja päätti kokouksen klo Seuraava Skype-kokous on klo Vuoden 2019 ensimmäinen kokous paikan päällä pidetään klo

10 Pöytäkirja 10 (10) Liitteet Liite1 Esitysmateriaali Liite 2 Avointen asioiden listalta käsitellyt kohdat ja Skype-kokouksissa Jakelu Prosessityöryhmä Teemu Hellas Emmi Kaivosoja Pinja Kimari Pasi Lintunen