Prosessityöryhmän kokous

Transkriptio

1 Pöytäkirja 1 (9) Prosessityöryhmän kokous Aika klo Paikka Duetto Business Park, Läkkisepäntie 23, Helsinki nh. Kuolajärvi Läsnä Marjut Puukangas (pj.) Emmi Kaivosoja (siht.) Teemu Hellas Arttu Laine Keravan Energia Oy Emma Mäki-Kala Elenia Palvelut Oy Jari Rusanen Loiste Sähköverkko Oy Pia Aaltonen Fortum Markets Oy Satu Kortesmäki Caruna Oy Pinja Kimari (kohdat 3-4) Poissa Tiina Leppälahti Helen Sähköverkko Oy 1 Kokouksen avaus ja edellisen kokouksen muistio Puheenjohtaja avasi kokouksen klo Puheenjohtaja kävi läpi kokouksen agendan. Käytiin läpi viime kokouksen ( ) pöytäkirja. Osoiterakenneohjeesta ei ole vielä julkaistu uutta versiota. Siihen liittyvät edellisen kokouksen jälkeen esiin nousseet kommentit toimitetaan Marjut Puukankaalle. Salatun asiakkaan kuvausta tarvitsee täydentää prosessidokumenttiin: kuluttaja-asiakkaalla käytetään salattu merkintää vain turvakiellon kohdalla, lisäksi puolustusvoimien asiakkuudet merkitään salaisiksi asiakkaiksi datahubissa. Edellisen kokouksen pöytäkirjan osalta ei noussut esiin muita kommentteja ja pöytäkirja hyväksyttiin. 2 Lyhyt katsaus projektiin Järjestelmätoimittajatestaus on edennyt, järjestelmätoimittajat ovat saaneet ilmoitettua ensimmäiset käyttöpaikat ja sopimukset datahubiin. Markkinaosapuolten pilottiryhmä on käynnistymässä pian. Markkinaosapuolten omat käyttöönottosuunnitelmat on saatu markkinatoimijoilta. Yhteenvetoa käyttöönottosuunnitelmista on tulossa 4.6. ajankohtaisseminaarissa. Käyttöönottosuunnitelmasta ollaan julkaisemassa versio 1.3 pian. Tietokonversion vaiheen 1 määräaika on toukokuun lopussa. Tiedon laatu on parantunut, mutta vielä ei olla ensimmäisen vaiheen tavoitteessa. Datahub ajankohtaisseminaari pidetään 4.6. ja tapahtumasta on tulossa myös webcasting. Datahub-tukipalvelu CGI USE on otettu käyttöön sähköpostia korvaamaan.

2 Pöytäkirja 2 (9) Prosessidokumentaatiosta on julkaistu ediel-portaaliin versio 1.8. Julkaisu sisältää vaiheiden 1 ja 2 prosesseihin liittyvät muutokset. Jatkossa ediel-portaaliin tullaan julkaisemaan myös epävirallisia kuvauksia tulossa olevista muutoksista ennakkoon, jotta toimijat voivat valmistautua tuleviin muutoksiin. 3 Rekisteröidyn oikeuksien prosessi Käytiin läpi Pinjan johdolla dokumenttiluonnos rekisteröidyn oikeuksien prosessista. Tarvitsee vielä kuvata mikä taho vastaa minkäkin tiedon oikeellisuudesta. Prosessidokumentissa on tätä jo kuvattu, joten sinne voinee linkittää. Graafinen yhteenveto voisi olla toimiva. Tarvitsee vielä kuvata mitkä tiedot tarkemmin tulisi sisällyttää siirtotiedostoon, jonka asiakas voi saada asiakasportaalista itselleen tai toimitettavaksi eteenpäin. Ilman henkilötunnusta kuluttaja-asiakas ei pääse käyttämään datahubin asiakasportaalia, koska asiakasta ei voida luotettavasti tunnistaa. Tällöin asiakas ei pääse katselemaan itsestään datahubissa olevia tietoja. Tietopyynnöt asiakkailta, jotka eivät pääse omiin tietoihinsa portaalin kautta, ohjataan datahubin tukipalveluun. Asiakkaan tunnistukseen käytetään todennäköisesti henkilötodistuksen kopiota, jonka asiakas toimittaa sähköisesti. Asiakkaalle näytettävässä tietojen käsittelylokissa ei työntekijöiden suojaamiseksi yksilöidä tietoja käsitellyttä käyttäjää henkilötasolla, sen sijaan näytetään tietoja käsitellyt organisaatio, esimerkiksi markkinaosapuoli. Jos asiakas lähettää tietojen oikaisupyynnön datahubiin, pyyntö välitetään viimeiseksi asiakkaan kanssa sopimuksen tehneelle myyjälle, joka päivittää tiedot DH-111 prosessin kautta. Toivottavaa olisi, että oikaisuprosessissa se taho, johon asiakas ottaa yhteyttä hoitaisi asiakaskontaktin loppuun asti, on sekavaa asiakkaalle jos yhteydenottoja oikaisupyyntöön liittyen tulee useilta eri tahoilta. Ainoa tilanne, jossa henkilötietojen poisto datahubissa on relevantti, on tilanne jossa asiakas, joka ei ole vielä datahubissa, tekee myyntisopimuksen, jonka peruu ennen sen voimaantuloa. Tällöin asiakas voidaan poistaa datahubista pyydettäessä. Muutoin asiakkaaseen liittyviin tietoihin pätee 6 vuoden säilytysvelvoite eikä tietoja poisteta datahubista. 4 Asiakaskäyttöliittymän tarvekartoitusta Käytiin läpi alustavasti suunniteltuja tietokokonaisuuksia, joita asiakkaalle näytettäisiin asiakasportaalissa ja mietittiin mitä tietoja asiakkaalle olisi hyödyllistä esittää käyttöliittymässä. Työryhmäläisille jäi kotitehtäväksi miettiä vielä omien taustaryhmiensä kanssa, mitä tietoja asiakkaalle olisi hyvä esittää portaalissa ja mitkä saadakseen asiakkaan pitäisi tehdä erillinen tietopyyntö. Asiaan palataan seuraavassa kokouksessa. 4.1 Asiakastiedot Oletuksena asiakkaalle näytetään voimassaolevat tiedot. Käsittelylokin asiakastiedoista saisi sitä erikseen pyytämällä, sitä ei esitettäisi suoraan asiakasportaalissa. Asiakas voi muuttaa tietojensa salattu statusta portaalissa, josta tieto päivittyy suoraan datahubiin. Ehdotettiin, että asiakas voisi korjata itse portaalissa myös nimeään, osoitetietojaan ja

3 Pöytäkirja 3 (9) yhteystietojaan. Tällöin osapuolen tulisi voida nähdä, että päivitys tulee asiakkaalta itseltään. Päätettiin, että mieluiten rajataan asiakkaan suoraan tekemät päivitykset yhteystietoihin ja osoitteeseen sekä salattu tietoon. Nimien päivitystä suoraan asiakasportaalista ei mahdollisteta, vaan nimenmuutoksen tekee asiakkaan myyjä. Myöskään asiakkaan asiointikieltä ei voi muuttaa suoraan portaalissa, vaan osapuolen kautta. Asiakasportaalissa tarvitsee tehdä selväksi, että asiakkaan postiosoitteen muuttaminen asiakasportaalissa ei vaikuta asiakkaan sopimusten laskutusosoitteisiin, vaan niiden muuttaminen tapahtuu sopimukseen liittyvän markkinaosapuolen kautta. 4.2 Käyttöpaikkatiedot Oletuksena asiakkaalle näytetään käyttöliittymässä niitä käyttöpaikkoja, joille asiakkaalla on voimassa oleva sopimus. Käyttöpaikasta näytetään voimassa olevia tietoja. Erillisen pyynnön kautta voisi olla mahdollista nähdä vanhojen käyttöpaikkojen tietoja. Käyttöpaikan kautta pitäisi päästä navigoimaan siihen liittyvään sopimus-, mittaus- ja valtuutustietoon. Jos asiakkaalla on tulevaisuudessa alkava sopimus jo datahubiin ilmoitettuna, mutta ei vielä voimassa, voidaan asiakkaalle näyttää kyseisestä käyttöpaikasta osoite. Käyttöpaikkatiedoissa ei katsottu tarpeelliseksi näyttää käyttöpaikkoja, joille asiakas on vain antanut valtuutuksen (DH-133 tapahtumaa varten), joille asiakkaalla ei ole vielä sopimusta datahubissa. Asiakkaalle ei käyttöliittymässä haluta näyttää käyttöpaikan kytkentätilaa sekaannuksen välttämiseksi. Käyttöpaikkojen käsittelyhistoria olisi saatavilla vain erillisellä pyynnöllä, ei käyttöliittymässä. Alustavasti arveltiin, että asiakkaalle esitettäviä tietoja käyttöpaikasta olisivat mittarinumero, vuosikäyttöarviot, sulakekoko, käyttöpaikkatunnus, käyttöpaikan tyyppi ja käyttöpaikan osoitteet. 4.3 Mittaustiedot Mittaustiedot liittyvät tiettyyn käyttöpaikkaan, joten oletettavasti niihin siirrytään käyttöpaikan kautta. Mittaustiedoille tulisi olla jokin oletusaikaväli, jolta tietoja esitetään käyttöliittymässä, esimerkiksi viimeisimmältä viikolta. Asiakkaalle esitetään vain asiakkaan sopimuksen aikaista mittaustietoa. Asiakkaan voisi olla mahdollista valita useamman (max 4) käyttöpaikan mittaustiedot tarkasteltavaksi yhtä aikaa. Tähän liittyen todettiin, että yhteen käyttöpaikkaan saattaa datahubissa liittyä 3 aikasarjaa (pätöenergia tuotannon tai kulutuksen osalta sekä loisenergian otto ja anto). Kovin montaa aikasarjaa ei kannata esittää graafisesti yhtä aikaa. Oletuksena asiakkaalle näytetään pätöenergiaa, loisenergiat voisi olla mahdollista saada näkyviin erillisellä valinnalla jos ne on käyttöpaikalle raportoitu. Pohdittava vielä onko käyttöliittymässä tarvetta näyttää asiakkaalle vertailevaa kulutustietoa, vai riittäisikö esimerkiksi linkki vertailutietoihin. 4.4 Sopimustiedot Oletuksena asiakkaalle näytetään kaikki asiakkaan voimassaolevat ja tulevat sopimukset. Menneet sopimukset näytetään käyttöliittymässä erillisen valinnan kautta. Olisi hyvä voida näyttää asiakkaalle, jos asiakkaan sopimuksella on muitakin sopimuskumppaneita (useita asiakkaita), esimerkiksi näiden muiden asiakkaiden nimet. Selvitettäväksi jäi, onko tämä tietosuojan puolesta mahdollista.

4 Pöytäkirja 4 (9) 4.5 Valtuutukset 4.6 Lokitiedot Valtuutustietojen näyttämisen lisäksi käyttöliittymässä asiakkaan tulee voida antaa uusi ja päättää olemassa oleva valtuutus omiin tietoihinsa. Tarvitaan selvät kuvaukset asiakkaalle eri valtuutustyyppien käytöstä, jotta tämä tietää minkä valitsee. Pohdittiin missä halutaan esittää tietoa siitä, mikä taho on käsitellyt asiakkaan tietoja, missä tarkoituksessa ja milloin. Todettiin, että käyttöliittymän kautta voisi olla mielekästä saada näkyviin tietojen muokkaushistoria. Tietojen katselujen lokit voisivat olla erillisellä tietopyynnöllä saatavaa tietoa. Esimerkiksi taselaskentaa varten haetaan käyttöpaikkatietoja, tämän näkeminen käsittelylokeissa voi olla asiakkaalle hämmentävää. Asiakkaalle on kuvattava, että osapuolet, joiden kanssa asiakkaalla on sopimus, oletusarvoisesti pääsevät katsomaan asiakkaan tietoja. 5 ET:n asiakaskeskeinen vähittäismarkkinamalli ja yhteislaskutus raportti ET:n raportti on käyty datahubiin liittyvien asioiden osalta läpi Energiateollisuuden edustajien kanssa. Samalla raporttiin tehtiin muutamia tarkennuksia. Yhteislaskutukseen liittyen tullaan lisäämään ohjeistusta osapuolille, miten tietoja datahubiin tulee ilmoittaa. Datahubin tarkastussäännöt eivät 1.0 versiossa pysty varmistamaan kaikkia tähän liittyviä toimintatapoja, vaan ohjeiden noudattaminen jää osapuolten vastuulle. Myöhemmässä datahub versiossa harkitaan laskutustavan muutoksen irrottamista erilliseksi tapahtumakseen, jolloin voitaisiin varmistaa, että tämä tieto päivittyy aina sekä myynti- että verkkosopimuksessa samalla käyttöpaikalla. Nykyiset sopimuksen päivitystapahtumat eivät tätä varmistusta mahdollista. Vakuuksien hallintajärjestelmään liittyen jäädään odottamaan TEM:in päätöstä, ei ole vielä tiedossa tarvitaanko datahubista jonkinlaista rajapintaa sellaiseen. 6 Osapuolten käyttöliittymän käyttö markkinaprosesseissa Ehdotettiin, että markkinaosapuolille sallittaisiin datahubin markkinaprosessien käyttö sekä käyttöliittymän että sanomarajapinnan kautta. Tämä helpottaisi osapuolten toimintaa virhetilanteissa, esimerkkinä käyttöpaikan poisto datahubista, jos käyttöpaikkaa ei ole tarkoitus poistaa verkon omasta järjestelmästä. Käyttäjäoikeuksien kautta osapuolet voisivat rajoittaa käyttöliittymän käyttöä markkinaprosesseihin, niin että kaikilla käyttäjillä ei ole niihin pääsyä. Huolena on, että jos osapuoli voi suorittaa markkinaprosesseja sekä rajapinnan että käyttöliittymän kautta, osapuolen oman järjestelmän ja datahubin tiedot voivat poiketa toisistaan. Käyttäjäoikeuksia käyttöliittymässä rajaamalla riskiä voidaan pienentää. Asian pohdinta jää työryhmäläisille kotitehtäväksi ja siihen palataan myöhemmässä kokouksessa. 7 Käsiteltävien asioiden listan läpikäynti Läpikäytiin käsiteltävien asioiden Excel-listan avoimet kohdat.

5 Pöytäkirja 5 (9) 7.1 Tuotantokäyttöpaikkojen mittaustapa Tuntimittaussuositus toteaa: "Tuotantokohteet, joista sähköä siirtyy myös yleiseen jakeluverkkoon, tulee varustaa tuntimittauksella." Datahubissa ei ole tällä hetkellä validointisääntöä tälle. Tuotantokäyttöpaikoille tulisi sallia ainoastaan mittaustapa 'jatkuva mittaus'. Koskee tapahtumia DH-121 ja DH-122. Lisätään validointisääntö: tuotantokäyttöpaikan mittaustapa on oltava 'jatkuva mittaus'. 7.2 Toimitusvelvollisuuden raportointi datahubista Meillä on ollut keskustelua CGI:n kanssa datahubin tekemistä raporteista. Yksi datahuin tuottama raportti JVH:n puolesta tulee olemaan toimitusvelvollisuuden piirissä olevien käyttöpaikkojen vuosiennusteiden raportointi toimitusvelvolliselle myyjälle. Toimitusvelvollisuus= Vähittäismyyjän, jolla on huomattava markkinavoima jakeluverkonhaltijan vastuualueella, on toimitettava vastuualueella sähköä kohtuulliseen hintaan kuluttajille sekä muille loppukäyttäjille, joiden käyttöpaikka on varustettu enintään 3 x 63 ampeerin pääsulakkeilla tai joiden sähkönkäyttöpaikkaan ostetaan sähköä enintään kilowattituntia vuodessa. Kuinka huomioidaan raportoinnissa ne käyttöpaikat mihin ei ole ilmoitettu pääsulaketta? Sähköteholle määritetään laskennallinen raja, joka vastaa 3x63A. 7.3 Kuluttaja-asiakkaat ilman hetua Kuinka toimitaan tilanteissa, jos kuluttaja-asiakkaalle ei saada hetua eikä syntymäaikaa selvitettyä ennen tietokonversiota? Tällä hetkellä on määritetty, että jos ilmoittaa asiakkaalle muun tunnuksen hetun sijaan, on annettava syntymäaika. Asia nostettu esiin ET:n ja FG:n tiedonvaihdon kehitysryhmien yhteiskokouksessa. Tällä hetkellä tietokonversiossa näitä tapauksia on todella paljon. Ehdostus, että lisätään jokin tekaistu päivämäärä ( ?), jota mahdollisesti voitaisiin käyttää syntymäaikana näissä mitä ei todellakaan ole mahdollista asiakkaalta saada. Toistaiseksi tähän ei tehdä muutosta, koska pyritään kannustamaan yhtiöitä täydentämään tiedot tietokonversioon. Työryhmä oli sitä mieltä, että tällaisen poikkeustavan käyttö ei saa olla liian helppoa, jotta osapuolet eivät hyödynnä sitä tiedonlaadun parantamistyön kustannuksella. Keskusteltiin tässä yhteydessä myös siitä, että sopimuksen ilmoitukselle voisi tehdä vertailun löytyykö hubista jo samaa asiakasta ilman hetua. 7.4 Katkaisupyynnön peruutus kytkentäpyynnöllä Järjestelmätoimittajien testiskenario workshopissa tuli kysymys siitä, miksi ei aina peruuteta katkaisupyyntöä kytkentäpyynnöllä ja päinvastoin.

6 Pöytäkirja 6 (9) Ei muuteta peruutussääntöjä. Voi aiheuttaa sekaannusta osapuolten järjestelmissä ja tällä on vaikutusta taseselvitystietoihin. Käytetään peruutustapahtumia. 7.5 Katkaisupyynnön peruutus viivästyksen jälkeen Kuinka tulee toimia tilanteessa, joissa myyjä on ilmoittanut katkaisupyynnön ja verkko on toimittanut tähän viivästysilmoituksen, jos myyjä haluaa perua katkaisupyynnön? Eli asiakas maksaa laskunsa pyydetyn katkaisupäivän jälkeen, mutta verkko ei ole katkaissut sähköjä vaan on ilmoittanut tähän viivästymisilmoituksen. Taseissa tämä siirtyy pyydetyn katkaisupäivän jälkeen verkon häviöihin. Mitä tapahtuu jos katkaisupyyntö tässä tapauksessa perutaan? Käytetään kytkentäpyyntöä. Taseiden näkökulmasta pyydetyn katkaisupäivän jälkeinen aika ennen peruutusta menee verkon häviöihin. 7.6 Mittaustieto uudelle myyjälle - takautuva sopimus Tilanteessa jossa tehdään takautuva sopimus, voiko myyjä itse hakea mittaustiedot sopimuksen alun osalta vai pitäisikö Datahubin lähettää mittaustiedot myyjälle? Myyjä voi hakea hakutapahtumalla mittaustiedot takautuvalta ajalta. 7.7 "Kytkentätila" rajapisteille ja tuotantoyksiköille Rajapisteille ja tuotantoyksiköille ollaan ottamassa "kytkentätila" käyttöön datahubissa. Tila tietoa tullaan ylläpitämään käyttöliittymän kautta. Missä kytkentätiloissa datahubin tulisi lähettää muistutus puuttuvasta mittaustiedosta? Kaikissa paitsi poistettu käytöstä? Kytkentätilan lisääminen ok. Käytetään samoja validointisääntöjä kuin käyttöpaikoilla. 7.8 Mittaus-/tasetietojen haun pysäyttäminen Datahub-operaattorilla ei tule olemaan mahdollisuutta pysäyttää asynkronista hakua. Tulisiko hakuihin määrittää rajoituksia tilanteissa joissa osapuoli "turhaan" kuormittaa järjestelmän suorituskykyä suurilla hauilla? Jonkinnäköinen rajoitus olisi hyvä olla. Datahub ehdottaa rajaa. 7.9 Häviöiden nollaus Läpikäynnissä CGI:n kanssa nousi esiin kysymys takautuvan sopimuksen yhteydessä lähetettävästä "häviöiden nollaus" nolla-aikasarjasta. Tämän toteuttaminen ei ole täysin yksinkertaista, sillä Datahub ei lähtökohtaisesti määritä itse arvoja aika-sarjoihin, eikä käyttöpaikalla ole, datahubin näkökulmasta, nolla-aikasarjaa. Keskusteltava tapahtuman tarpeellisuudesta ja/tai mahdollisista muista tavoista toteuttaa tämä. DH tapahtuma poistetaan. Verkko voi hakea tiedot häviöistään DH-514 tapahtumalla.

7 Pöytäkirja 7 (9) 7.10 Muutoksia mittaustiedon muistutus tapahtumaan DH-212 Mittaustiedon muistutus tapahtuma DH-212 ollaan jakamassa neljäksi eri tapahtumaksi: DH data missing, DH insufficient status, DH Non-zero values (disconnected metering point), DH Invalid direction (exchange point). Muistutus sanomaan lisätään in/out area, jolla voidaan tunnistaa rajapisteiden osalta suunta. Jaetaan eri tapahtumiksi. Kysymys alalta: Saisiko muistutukseen tarkastelu ajahetken? Datahub selvittää CGI:ltä 7.11 Taseselvitystiedot tilanteessa, jossa esett hylkää sanoman Miten Datahubin tulisi toimia taseselvityslaskentojen tulosten osalta tilanteessa, jossa esett hylkää esimerkiksi yhden myyjä/mittausalue -relaation osalta sanoman, eikä sitä saada operaattorin toimesta korjattua. Tulisiko Datahubin tässä tilanteessa kuitenkin välittää laskentojen tulos ko. osapuolille, vaikka se ei ole ollut mukana virallisessa taseselvityksessä vai pitäisikö edellinen "onnistunut" taseselvityslaskenta "jättää voimaan"? Viimeisin onnistunut laskenta jätetään voimaan. Osapuolille ei välitetä esett:n hylkäämien laskentojen tuloksia. Jos operaattori ei pysty korjaamaan virhettä lähetetään verkolle korjauspyyntö sähköpostilla DH-520, 3 vuoden taselaskenta - haku, tietojen poisto Datahub laskee epävirallista taselaskentaa 3 vuotta takautuvasti kerran kuussa. Voidaanko aiempien laskentojen tulokset poistaa? Vanhempien laskentojen tuloksia ei voi hakea DH-52x tapahtumilla. Jos osapuoli hakee "taseikkunan ulkopuolella korjattuja tietoja", palautetaan taseikkunen sulkeutumisen ja laskennan suoritusajanhetken osalta viimeisimmässä virallisessa taselaskennassa laskettu tieto. Jos osapuoli pyytää erikseen korjauslaskentaa "vapaasti määritellylle" ajalle, palautetaanko tämän laskennan tulos vai edellisen koko aikavälin laskennan tulos myöhemmissä hauissa, ennen kuin uusi laskenta suoritetaan ko. aikavälille? Säilytetään kahden viimeisimmän laskennan tulokset. Vanhemmat voidaan poistaa. Haulla palautetaan viimeisimmän laskennan tulos ko. aikaväliltä, vaikka hakuväli sisältäisi "erikseen laskettuja" tietoja. Käyttöliittymän kautta nähdään mitä on laskettu ja milloin DH-520, 3 vuoden taselaskenta laskenta Laskentaanko 3 vuotta takautuvasti kaikki prosessidokumentin kuvassa 39 (versiossa 1.8) kuvatut laskennat vai riittääkö virallisesssa taseselvityksessä käytettävien aikasarjojen laskenta? Lasketaan kaikki kuvassa 39 (versiossa 1.8) olevat laskennat Mittauspisteen tyyppiin muutos E66 ja F08 sanomissa käytettävä mittauspisteen tyypin attribuutteja muutetaan lisäämällä F01 = käyttöpaikka ja poistamalla E17 = kulutus. E18 = tuotantoyksikkö ja E20 = rajapiste säilyvät ennallaan.

8 Pöytäkirja 8 (9) Muutos ok Taseista vastaavan myyjän pääsy mittaustietoihin Tilanteessa jossa taseista vastaa eri myyjä kuin myyntisopimuksella on, pitäisikö tasemyyjällä olla pääsy ko. ajalta mittaustietoihin? Myös taseista vastaavalla myyjällä pitää olla pääsy mittaustietoihin Negatiivisten häviöiden käsittely esett:ssä Voidaanko negatiivisiä häviöitä varten luodulle tuotantoyksikölle ilmoittaa nollaa aikasarjaa ajalle, jolloin negatiivista häviötä ei ole? Negatiivisten häviöiden tuotantoyksikölle voidaan raportoida nolla aikasarjaa, kun negatiivisia häviöitä ei ole Energiaraportointi valtuutus ja mittaustietojen välitys Mittaustietojen välitys valtuutetulle osapuolelle energiaraportointivaltuutuksen päätyttyä. Jos mittaustiedon välitys päättyy valtuutuksen päättyessä, ongelma syntyy ulosmuuttotilanteissa. Tällöin valtuutetulta 3.osapuolelta jää aina viimeisten päivien mittaustiedot puuttumaan, koska valtuutus päättyy ja tietoja (jotka toimitetaan jälkikäteen) ei enää välitetä. Toisaalta jos päätetään, että välitetään aina esim. 11 päivää valtuutuksen päättymisen jälkeen vielä mittaustietoa asiakas ei voi heti päättää valtuutusta niin että tietoa ei enää siirtyisi. Käytännön selittäminen asiakkaalle voi myös olla vaikeaa. Myös jos valtuutus onkin käytännön kannalta voimassa 2 vuotta + 11 päivää kun datahubiin ilmoitetaan voimassaoloajaksi 2 vuotta, tämä on ongelma tietosuoja-asetuksen kannalta. Tilanteeseen ei keksitty hyvää ratkaisua. Työryhmä oli sitä mieltä, että datahub projekti voi ratkaista tämän CGI:n kanssa Tuotantokäyttöpaikan katkaisu Tuotantokäyttöpaikkoja ei yleensä katkaista osapuolten järjestelmissä. Miten saadaan tuotantokäyttöpaikka katkaistu tilaan kun kulutuskäyttöpaikka katkaistaan? Mitä tietoa myyjät haluavat tuotantokäyttöpaikasta? Mitä mittaustietoa ilmoitetaan tuotantokäyttöpaikoille, jos niitä ei siirretä katkaistu tilaan? Jos on tarve muuttaa tuotantokäyttöpaikan kytkentätilaa datahubissa, tarvitaan erillinen kytkentä/katkaisusanoma näille käyttöpaikoille, jotta tila muuttuu datahubissa ja välittyy käyttöpaikan myyjälle. Tämä tarvitsee kuvata tarkemmin prosessidokumentaatioon, mutta mitään muutosta ei kuitenkaan tarvita prosesseihin. 8 Kokouksen päätös ja seuraavat kokoukset Sovittiin skypekokous vielä perjantaille klo Puheenjohtaja päätti kokouksen klo Työryhmän seuraava kokous paikan päällä Duetto Business Parkissa on

9 Pöytäkirja 9 (9) Liite Esitysmateriaali Jakelu Prosessityöryhmä Pinja Kimari