Prosessityöryhmän kokous

Transkriptio

1 Pöytäkirja 1 (10) Prosessityöryhmän kokous Aika Paikka Fingrid, Läkkisepäntie 21, Helsinki Nh. Sauna Läsnä Esa Kaario Ville Kauppinen Arttu Lahtinen Tiina Leppälahti Tomi Mäkelä Vesa Mäkilä Saku Ruottinen Jari Rusanen Monika Lindberg Raimo Toivanen Kaisa Ylipeura Marjut Puukangas Kerttu Korpelainen Esa Pietarinen Lauri Jännes Poissa Jari Nykänen Tampereen Sähköverkko Oy KSS Energia Oy Fortum Markets Oy Helen Oy Elenia Oy Satapirkan Sähkö Oy Caruna Oy Loiste Sähköverkko Oy Fortum Markets Oy PKS Sähkönsiirto Oy Energiapolar Oy (skype) (pj.) (siht.) Paikallisvoima ry 1 Kokouksen avaus Puheenjohtaja avasi kokouksen klo Käytiin läpi lyhyt esittelykierros, sillä Korpelainen oli mukana ryhmän kokouksessa ensimmäistä kertaa ja toimii jatkossa ryhmän sihteerinä. 2 Edellisen kokouksen muistio Teknisen edustuksen omat kokoukset pidettiin viime kokouksen välissä. Puheenjohtaja ilmoitti että käydään läpi kaikki kokousmuistiot, eli viime kokouksen muistion lisäksi myös kokousmuistiot teknisten asioiden läpikäynneistä. Pietarinen kävi läpi pöytäkirjat teknisistä läpikäynneistä ja kertoi, että Datahub-tapahtumat eli tekninen dokumentti on käynyt läpi muodon muutoksen ja on nyt muokattu helpommin luettavaan muotoon. Lisäksi on tarkastettu eroavaisuudet Sähkön vähittäismarkkinoiden liiketoimintaprosessit datahubissa eli prosessidokumentin ja teknisen dokumentin välillä sekä korjattu havaitut yksittäiset virheet. Puheenjohtaja kävi läpi viime kokouksen muistion, kommentteja muistioihin ei enää tullut.

2 Pöytäkirja 2 (10) 3 Tietokonversiotyön eteneminen / Jännes Jännes esittäytyi ryhmälle ja kertoi tiekonversioprojektin etenemisestä, aloittaen tietokonversion tavoitteista. Tietokonversio on avainasemassa datahubin käyttöönoton onnistumisen kannalta, muiden maiden kokemuksista on otettu oppia ja tietokonversioon tullaa todella panostamaan. Haasteita tietokonversiotyöhön tuo 200 hyvin erilasta osapuolta niin valmiuksiltaan kuin tietojärjestelmiltään. Tietokonversiopalvelun hankinta on käynnissä parhaillaan eikä toimittajaa ole vielä valittu. Alan valmistautumisen tueksi sekä seuraamiseksi toteutetaan kolme seurantakyselyä, joista jo 2 on toteutettu ja kolmas lähetetään alalle myöhemmin kevään aikana. Jännes muistutti myös henkilötunnusten keräämisen tärkeydestä, kaikkien yhtiöiden tulee täydentää itsenäisesti hetuja lainsäädäntöä odotellessa (lainsäädännön toteutuminen ei ole varmaa). Jännes kävi läpi tietokonversioprojektin rakenteen ja tässä yhteydessä käytiin myös läpi projektin alustava aikataulu, joka löytyy muistion liitteenä olevasta esitysmateriaalista. Tuotannollisen koekäytön myötä, tietokonversiopalvelu tullaan avaamaan alan käyttöön (menee lomittain datahubin käyttöönoton kanssa). Jokaisessa iteraatiovaiheessa vaatimukset datan laadun suhteen tiukentuvat ja kolmannessa iteraatiossa otetaan käyttöön GS1-tunnukset. Myyjien ja verkkojen tärkein tehtävä on toimittaa tiedot konversiopalveluun ja korjata lähdetietoja palvelusta saatujen raporttien perusteella, jotta datan laatu saadaan riittävän hyvälle tasolle. Lopuksi ennen datahubin käyttöönottoa toimitetaan myös mittaustiedot. Kaikki tietokonversion ohjeet ja dokumentaatio, kuten tietokonversiosuunnitelma löytyy EDIELfi-portaalista. Tietokonversiosuunnitelma kattaa koko tietokonversioprojektin ja sen tueksi on tehty myös lyhennetty ohje. Konversiopalvelun käyttö ohjeistetaan myöhemmin, kunhan palvelun toimittaja varmistuu. Tällä hetkellä vastauksia seurantakyselyistä on saatu kahdesta ensimmäisestä kyselystä. Suurin osa yhtiöistä on valmistautunut hyvin tai kohtuullisesti, mutta löytyy myös yhtiöitä jotka eivät ole vielä tehneet mitään. Tuloksista on myös käynyt ilmi, että tietomalleissa ja datastandardin yhteensopivuudessa on suurehkoja eroja. Tiedot on määritelty kolmeen kriittisyysluokkaan, joista luokan kolme tiedot ovat vähiten kriittisiä (näissä on eniten myös puutteita). Ryhmäläisiltä tuli kommentteja, että kyselyjen kautta on tullut tarkasteltua omia järjestelmiä ja ne on koettu tarpeellisiksi. Mäkelä kertoi esimerkin kriittisyysluokan pakollisiksi määritellyistä tiedoista esim. käyttöpaikan lisäosoitteet, jotka ovat luokiteltu kriittisyysluokkaan 1., Mäkelä kommentoi, että verkkoyhtiön näkökulmasta lisäosoitteet eivät välttämättä ole erittäin kriittisiä. Lopuksi Jännes kertoi tietokonversiotyöryhmän toiminnasta. Ryhmäläiset kaipasivat lisää tietoa tietokonversioaikataulusta, milloin aikataulu tarkentuu ja missä kuussa mikäkin tiedosto tulee lähettää? Resursointi on todella haasteellista ennen aikataulun tarkentumista (esim. henkilöstöresurssit pitää yhtiöissä varata hyvissä ajoin). Jännes kommentoi, että julkinen hankinta on käynnissä, eikä ennen palvelun toimittajan valintaa voida aikataulua tarkentaa.

3 Pöytäkirja 3 (10) Myös datahubin käyttöönoton aikataulu herätti kiivasta keskustelua, sillä aikataulu on järjestelmäuudistusten kannalta erittäin tärkeä tieto. Puheenjohtaja kertoi, että tällä hetkellä ei ole tukea mahdolliselle uudelle aikatauluarviolle. Ryhmäläiset kommentoivat, että kuukausitason arvio auttaisi jo paljon. Puheenjohtaja vie viestiä projektin johdolle, aikataulun tarkentumisen odottelun tuska on ymmärretty. 4 Projektin tilanne / Puukangas Käyttöönottosuunnitelma Käyttöönottosuunnitelman tekeminen on käynnistynyt keväällä ja ensimmäinen luonnos käyttöönottosuunnitelmasta tullaan julkaisemaan alan kommentoitavaksi loppusyksystä. Datahubin käyttöönottotyöryhmän tekemä suunnitelma on tarkoitettu koko alan tueksi ja tämän lisäksi jokaisen yhtiön tulee tehdä oma käyttöönottosuunnitelmansa. Energiateollisuus ry nimesi jäsenet käyttöönottotyöryhmään ja ET:ltä ryhmän jäsenenä toimii Riina Heinimäki. Pöyryn konsulttipalveluja hyödynnetään työryhmän fasilitointi apuna ja työryhmä tekee yhteistyötä myös muiden datahub-projektin työryhmien kanssa. Käyttöönottotyöryhmän tarkempi kokoonpano sekä kaikki työryhmän pöytäkirjat löytyvät EDIELfi-portaalista. Lakiasiat Työ- ja elinkeinoministeriön Arto Rajala, joka vastaa datahub lainsäädännön valmistelusta TEM:in energiaosastolla, ilmoitti että tulevana kesänä luonnos hallituksen esitykseksi on menossa lausuntakierrokselle. Rajalan blogi: Lainsäädännöstä haetaan myös tukea henkilötunnusten saamiseksi. Lainsäädännön etenemistä odotellessa henkilötunnusten aktiivinen keräys on tärkeää. Puukangas kertoi seurantaryhmän kautta esille nousseesta esimerkistä, jolla yhtiö oli saanut hyvin kerättyä hetuja. Yhtiön kampanjassa asiakastietojen päivityksen osalta oli ollut porkkanana matkalahjakortti, ja saatekirjeessä annettiin muutama kanava jolla tiedot pystyi ilmoittamaan (tietoja ilmoitettiin näin hyvin myös kirjeitse). Lopuksi Puukangas kertoi, että Datahub hankinta on käynnissä ja vie tällä hetkellä valtaosan projektin resursseista. Datahub webinaari-koulutussarja etenee ja ryhmä antoi palautetta, että webinaarit ovat vastanneet hyvin odotuksia tullaan vielä järjestämään ylimääräinen webinaari, jossa käsitellään eniten kysymyksiä saaneita aiheita ja mahdollisia prosesseihin tulleita muutoksia. 5 Prosessiryhmän jäsenten kuulumiset Puheenjohtaja avasi keskustelun, onko hubin rooli selvillä yhtiöissä ja mitä käyttöönotto käytännössä tarkoittaa? Ovatko osapuolten vastuut ja velvollisuudet selvät?

4 Pöytäkirja 4 (10) Käytiin läpi lyhyt kierros ryhmäläisten kesken yhtiöiden kuulumisista. Kriittistä keskustelua syntyi mm. aikataulusta, järjestelmäkehityksestä ja kustannuksista sekä niiden jakautumisesta. Kun uuden järjestelmän hankinta (markkinaosapuolten omien tietojärjestelmien osalta) on käynnissä, epätietoisuus aikataulusta on liiankin usein esillä. Resursointi aiheuttaa haasteita monille. Tietokonversiotyöryhmän pilottiyhtiöiden edustajat (prosessityöryhmän edustajista) kokivat, että työ etenee omalla painollaan. Yritysjohdon koetaan olevan ajan tasalla. Rusanen vinkkasi että voitaisiin vielä toteuttaa erikseen yhtiöiden johdolle suunnattu webinaari. Järjestelmätoimittajien tarjouksien hintojen sekä maksujen todettiin olevan kovia, eikä niitä saada katettua muilla säästöillä. Loppuasiakkaalle olisi saatava kustannushyötyjä, mutta kustannushyötyjä ei nähdä realistisina kun datahubin aiheuttamat kustannukset ovat niin suuret. Kokonaiskustannukset huolestuttivat ryhmäläisiä ja keskustelua herätti järjestelmätoimittajien painostus sitoutumiseen jo tässä vaiheessa. Järjestelmätoimittajat eivät välttämättä edes tarjoa muutostöitä, sillä resurssit ovat varattu käynnissä oleviin tai jo myytyihin projekteihin. Ryhmä nosti esiin huolen, voiko järjestelmätoimittajien resurssit riittää kaikille osapuolille suunnitellussa datahubin käyttöönottoaikataulussa ja ala olla valmiina ajoissa. Puheenjohtaja huomautti että datahub tarjoaa uudenlaisen alustan ja mahdollisuuden uudenlaisiin tulevaisuuden ratkaisuihin eikä tarjoa vastausta kaikkiin ongelmiin heti. Datansiivous on nyt erityisen tärkeää ja että tehdään kaikki, mitä tällä hetkellä voidaan hubiin valmistautumiseksi. Yhteenvetona, että tarkkaa aikataulua kaivataan ja vasta sen myötä pystytään tekemään investointipäätöksiä yhtiöissä. Viedään projektin johdolle viestiä keskustelussa esille nousseista huolenaiheista. 6 Dokumenttien uudet versiot / Pietarinen Sähkön vähittäismarkkinoiden liiketoimintaprosessit datahubissa versio 1.2 Datahub-tapahtumat versio 1.1 Datastandardi versio 1.3 Puheenjohtaja toi esille, että vaikka dokumenttien uudet versiot luvattiin alun perin julkaista huhtikuussa, haluttiin projektissa ja webinaareissa esiin nousseet kysymykset prosessityöryhmän käsittelyyn vielä ennen uusien versioiden julkistamista. Mm. Asiakastiedoista tullaan poistamaan webinaarien palautteiden perusteella asiakkaan asiointitapa ja tullaan siirtämään se osaksi sopimustietoja. Prosessidokumentin kolmos- ja neloslukujen ristiriitoja on korjattu. Datastandardista on korjattu virheitä, muita merkittäviä muutoksia ei tehty. Pietarinen

5 Pöytäkirja 5 (10) kyseli ryhmäläisiltä halutaanko kaikki korjatut virheet saada ensin ryhmäläisille nähtäväksi, mutta todettiin että korjatut virheet näkyvät dokumentin muutosmerkinnöistä ja riittää, että ryhmäläiset voivat sitä kautta käydä läpi korjaukset. Muutettavat asiat on joka tapauksessa käyty ryhmän kanssa läpi. 7 GS1-ohjeistus GS1-ohjeistus oli alan kommentoitavana maaliskuun ajan, mutta kommentteja tuli todella vähäisesti. Yksi tullut toive oli, että kaikki 18 merkkiä olisivat vapaasti käytettävissä, mutta tämä ei tule olemaan mahdollista. Lisää viestintää ja ohjeistusta kaivataan sen osalta, mihin kaikkiin järjestelmiin muutos tulee tehdä. Toivottiin myös että Fingrid tekee seurantaa yhtiöiden edistymisestä asian suhteen, tietokonversiokyselyissä tullaan ottamaan mukaan kysymys liittyen GS1- tunnuksiin siirtymisen valmistautumisesta. ET:ltä on tulossa ohje miten asiakkaan suuntaan tulee viestiä muutoksesta. 8 Osoiterakenne-ohjeen luonnos / Pietarinen Datastandardin määritykset on laadittu Energiateollisuus ry:n osoiterakenne-ohjeen perusteella. Pietarinen kävi datahubin osoiterakenne-ohjeen läpi, joka on laadittu muokkaamalla ET:n ohjetta. Esille nousi, että ohjeessa olevat standardit tulee tarkastaa ja se että taustalta löytyy todenmukainen lähdetieto. Tarkentavat ohjeet katuosoitteelle ovat ohjeessa mukana. Tietokenttien formaatit on vielä käytävä erikseen läpi. Ulkomaalaiset osoitteet ja niiden ohjeistus lisättävä ohjeeseen esimerkkien kera sekä mitä erikoismerkkejä saa käyttää (universal post union internet-sivuja käytetään apuna). Nimirakenne-ohjeet halutaan sisällyttää ohjeeseen. Puheenjohtaja sanoi, että ohje koostetaan valmiiksi ja pyritään julkaisemaan samaan aikaan projektidokumenttien uusien versioiden kanssa. 9 Keskeneräisten asioiden lista / kaikki Asiakkaiden vertailutiedot Laista tulee velvollisuus esittää asiakkaalle kulutuksen vertailutietoa, jota on myös tarkoitus näyttää asiakasportaalissa. ET on laatinut asiasta ohjeen. Datahubiin tulee määrittää, miten ET:n ohjetta datahubissa sovelletaan. Lämpötilakorjaukset eivät välttämättä ole järkeviä tehdä datahubissa. Onko järkevintä päivittää vertailutiedot "käsin"? Toteutetaan yksinkertainen nykymallin mukainen pdf-muotoinen vertailutieto. Esimerkkinä käytetään ET:n ohjeen Sähkönmyyjän raportti asiakkaan energiankäytöstä liitteen 1 mukaista perusmallia (yksiaikainen tuote) -> saatavilla: raportti_2010.html Myyjät voivat halutessaan toteuttaa parempaa palvelua.

6 Pöytäkirja 6 (10) Ilmoitetaanko kaikki vai muuttuneet tiedot? "Vähintään muuttuneet tiedot ilmoitetaan käyttöpaikkaan liittyville muille osapuolille huomioiden osapuolten oikeudet tietoihin. "Yleinen periaate on ollut, että aina ilmoitetaan kaikki tiedot. Poistetaan vähintään sana ja korjataan dokumenttiin. Sähköntoimitussopimus vain toimitusvelvolliselle myyjälle, lisätään validointi DH-311 uuden sopimuksen ilmoitukseen lisätään, että vain mittausalueen toimitusvelvollinen myyjä saa tehdä sähköntoimitussopimuksen. Tuotteille ruotsinkieliset nimet Nyt tuotteilla ja tuotekomponenteilla voi olla vain nimiä yhdellä kielellä. Ohjeistetaanko tekemään erilliset tuotteet eri kielisille mutta samoille tuotteille vai lisätäänkö kielikoodit? Toteutetaan kielikoodi tuotteisiin. Lisätään tarkennus tietomalliin. Asiakaan kielikoodi ohjaa tuotteen haun. Rajapisteiden ja tuotantoyksiköiden rakenteellisten tietojen haku Lisätään maininta dokumenttiin, että nämä rajapisteiden ja tuotantoyksiköiden rakenteelliset tiedot voi hakea esim. exceliin käyttöliittymästä? Toteutetaan raportti Exceliin, kaikki omat tiedot voi hakea. Ulkomaiset osoitteet Laitetaanko ulkomaisiin maatunnus eteen omaan kenttäänsä: SE-12345, NO Voidaan hyväksyä datahubiin, mutta ei edellytetä pakollisena? Tehdään kuvatusti. Validointi toteutetaan niin, että suomalaisissa osoitteissa FI:tä ei saa syöttää, mutta ulkomaalaisissa osoitteissa maatunnuksen saa ilmoittaa. Tasevastaava vähittäismarkkinoilla Muissa Pohjoismaissa (tai ainakin jossain Euroopassa) on ilmeisesti mahdollista myyjille kilpailuttaa tasevastaava käyttöpaikkakohtaisesti. Tätä varten esim. ebix:ssä on määritelty käyttöpaikalle "tasevastaavan vaihto" markkinaprosessi. Onko tämä prosessi tuttu projektiryhmän jäsenille? Onko nähtävillä, että Suomessa olisi halukkuutta tai tarvetta tällaisen prosessin käyttöön otolle? Voidaanko tähän ajautua jonkin markkinaharmonisoinnin johdosta? Varautumista ei ainakaan toistaiseksi nähty tarpeelliseksi. Verkkosopimuksen kohtalo mittausalueiden muutoksissa Miten käsitellään verkkosopimuksen kanssa, kun mittausalue jakaantuu tai yhdistyy toisen kanssa ja käyttöpaikan verkonhaltija vaihtuu? Pitää ottaa teknisessä toteutuksessa huomioon, hubin pitää mahdollistaa: Datahubissa on toiminto, jolla operaattori voi vaihtaa kaikki vanhan verkkoyhtiön sopimukset uuden verkkoyhtiön nimiin. Datahubissa on toiminto, jolla operaattori voi päättää kaikki olemassa

7 Pöytäkirja 7 (10) olevat verkkoyhtiöt sekä markkinaprosessi, jolla uusi verkkoyhtiö voi ilmoittaa uudet sopimustiedot datahubiin. Tämä markkinaprosessi voisi käytännössä olla sama kuin nyt määritelty verkkosopimuksen vahvistaminen. 3. osapuolelle mahdollisuus pyytää asiakastietojen päivitystä 3.osapuoli ei voi pyytää asiakastietojen päivitystä - kommentti koskee esimerkiksi tilannetta, jossa palveluntarjoajalla on asiakkaan valtuutus ja asiakaspalvelutilanteessa havaitaan datahubissa olevan virheelliset tiedot. Pitäisikö mahdollistaa, että 3.osapuoli voi pyytää asiakastietojen päivitystä samoin kuin jakeluverkonhaltija? Käyttöpaikka- sekä asiakastietojen päivityspyyntömahdollisuus lisätään 3.osapuolelle. Mittaustiedon hakuun käyttöpaikan tyyppi DH-220:ssa tarvitaanko käyttöpaikan tyyppiä hakukriteeriksi? Esimerkiksi jos haluaa hakea vain tuotantokäyttöpaikkojen mittaustietoja. Lisätään hakuun käyttöpaikan tyyppi. Mittaustiedon deltakysely Pitäisikö olla mahdollista antaa mittaustietojen haussa päivämäärä, ja datahub palauttaisi vastauksena annetun päivämäärän jälkeen uudet ja muuttuneet tiedot? Lisätään datahub v2.0 listalle ehdotukseksi. Valtuutuksen päättäminen Pitäisi varmaan olla joku rajapinnan kautta tapahtuva tapa osapuolen päättää valtuutus. Voisiko toteuttaa valtuutusta päivittämällä? Päättämisilmoitus mahdollistettava. Itella-ID Käyttöpaikkatunnuksen kysely osoitteen perusteella epäilyttää. Nykyään osalla osapuolista käytössä Itella-ID, joka on uniikki tunniste osoitteelle. Itella-ID:n tuominen datahubiin kuitenkin edellyttäisi integraatiota Postin rekisteriin. Ei voida olettaa, että kaikki jakeluverkonhaltijat ylläpitäisivät Itella-ID:tä osana käyttöpaikan osoitetietoja. Otetaan muistilistalle, palataan asiaan tarvittaessa. Käyttöpaikan osoite Käyttöpaikan osoitteen vapaa tekstikentän nimi muutetaan vastaamaan asiakkaan osoitteessa olevaa osoitteen tarkennetta, eli molemmissa jatkossa tämä on osoitteen tarkenne. Laskutuskanavaan uusi valintamahdollisuus koodilistaan Laskutuskanaviin tuli toimialalta pyyntö, että lisätään Online lasku. Tarkoittaa että asiakas saa laskun yhtiön omista online-palveluista ainoastaan. Ei vaikutusta tietomalliin. Lisätään yksi poikkeaville laskutuskanaville tarkoitettu tyyppi Muu.

8 Pöytäkirja 8 (10) Asiakkaan asiointitapa Saadun kommentin mukaan asiointitapa ei saisi olla asiakkaan tiedoissa ylläpidetty tieto. Verkko ei saa hyödyntää suoraan asiakkaan asiointitapaa verkkosopimusvahvistuksen lähettämiseen mikäli asiakas on myyjän kanssa sopinut sähköisestä asiointitavasta. Yritetään muuttaa sopimustiedoksi, Fingrid vie asiaa eteenpäin. Mittausalueiden hallinta Tulisiko mittausalueiden lisääminen ja poistaminen sekä mittausalueiden yhdentymiset ja jakaantumiset käsitellä aina datahub-operaattorin toimesta? Nämä muutokset ovat harvinaisia ja niillä voi olla merkittäviä vaikutuksia taseselvitykseen. Voisi olla varmempaa, että operaattori päivittää nämä, koska voi olla parempi "tuntuma" käyttöliittymään ja ns. näpikset voisi jäädä paremmin pois. Koskee kaikkia mittausalueen päivityksiä (esim. tunnus, tyyppi,markkinatasealue). Muutokset operaattorin tehtäväksi. GSRN-tunnusten sovellustunnus viivakoodeille Pitäisikö GSRN-tunnukseen sisällyttää myös ns. sovellustunnus viivakoodikäyttöä varten. GSRN:llä sovellustunnus on 8018 ja tämä tulisi jokaisen GSRN-tunnuksen alkuun. Tällöin datahubin tunnuksen perusteella voitaisiin suoraan luoda viivakoodi ja esim. mittarin kyljestä luettu viivakoodi on suoraan käyttökelpoinen esim. käyttöpaikkatietojen haussa. Lisätieto Puheenjohtaja lupasi että Fingrid selvittää, onko 8018-tunnuksen lisääminen tarkoituksen mukaista. Kokonaismerkkimäärän kasvattaminen 22:teen nähdään haasteellisena, jo 18 merkkiä koetaan pitkänä (esim. asiakasviestinnässä). Palataan tähän kysymykseen syyskuun kokouksessa ja otetaan myös ET mukaan keskusteluun. Ilmoitus sopimuksen peruuttamisesta ulosmuuton perusteella Sopimuksen päättämiseen liittyvä sääntö koskien ulosmuuttoilmoituksen vuoksi peruutettavaa uutta myyntisopimusta (tulevaisuudessa esiintyvien myyjänvaihtojen osalta). Prosessidokumentissa, eikä myöskään teknisessä dokumentissa ole kuvattu tapaa millä datahub ilmoittaa uuden sopimuksen tehneelle myyjälle sopimuksen peruuttamisesta. Lisätään kuvaus tapahtumasta. Osapuolten väliset valtuutukset Tarkennetaan dokumenttiin, että osapuolten välisiä valtuutuksia ei voi välittää eteenpäin enää kolmannelle osapuolelle. Eli valtuutettu osapuoli ei voi enää valtuuttaa uutta osapuolta samaan asiaan mihin tämä on itse valtuutuksen saanut. Osapuolen käyttöliittymän käyttö Tarkennetaan dokumenttiin se, että osapuoli voi hoitaa markkinaprosessit joko rajapinnan kautta tai sitten käyttöliittymän kautta. Ei voi olla molempia käytössä samaan aikaan. (Huom mittaustietoja voi ilmoittaa ainoastaan rajapinnan kautta)

9 Pöytäkirja 9 (10) Tasevirheiden käsittely sopimusten käsittelyssä Onko 6 viikon sääntö tasevirheiden korjauksessa myyjäkohtainen vai sopimuskohtainen? Myyjällähän voi olla samalle käyttöpaikalle peräkkäisiä sopimuksia, joissa on aivan eri asiakkaita. Ei liene tarkoitus, että myyjä korjaa laskutuksen tällöin niille asiakkaille, joiden sopimus on päättynyt yli 6 viikkoa sitten? Tehdään selventävä kuva. Asiakkuuden ja myyjän kanssa pitäisi mennä. "Yksikin asiakas sama" -periaatteella eli tarkistetaan peräkkäiset sopimukset, joissa myyjä on aina sama ja vähintään yksi asiakas on sama. Nykyisen myyjän aikaraja sopimusten käsittelyyn Voiko nykyinen myyjä tehdä sopimusmuutoksia omiin sopimuksiin ilman 14 vrk:n aikarajaa? Dokumentissa on nyt ristiriita tältä osin. Nykyinen myyjä voi tehdä sopimuksen vaihdon kuluvalle päivälle. Useampi järjestelmä, joilla osapuoli kommunikoi datahubin kanssa Toistaiseksi ei ole tarkasti määritelty, miten yksittäinen osapuoli voi käyttää useampaa järjestelmää datahubin kanssa kommunikoitaessa. Esim. jos verkkoyhtiö haluaisi välittää datahubin kautta mittaustietokannastaan mittaustietoja omalle toiselle järjestelmälle, joka suorittaa laskutuksen. Tulisiko tähän liittyen osapuolen pystyä määrittämään tapahtumakohtaisesti omia muita tietojärjestelmiä, joihin datahubiin ilmoitetut tiedot välitetään sen lisäksi että nämä tiedot välitetään muille tietoon oikeutetuille osapuolille? Mahdollistetaan, että JVH voi myös välittää itselleen tietoja (tarkistaa myyjät, 3.osapuolet). Lisätään dokumenttiin tarkennus. Mittaustietojen korjaukset ja asiakkaan korjauslaskutus "jakeluverkonhaltijan tulee tiedottaa sähköpostitse kutakin myyjää, jolla on velvollisuus korjata asiakkaan laskutusta. ". Onko yllä oleva lause enää relevantti, kun 6 viikon sääntö lasketaan siitä hetkestä kun mittaustiedot korjataan datahubiin ja välitetään myyjille? Myyjät voi täten itse tarkistaa, onko heillä käyttöpaikalla 6 viikon sisällä voimassaolleita sopimuksia. "sopuun pääsy hetkestä" 6 viikkoa ja samalla ilmoitettava datahubiin. tasevirheiden korjaus toimii kuten on jo kuvattu. Sähköautojen latauspaikkojen osoite Miten voidaan erottaa kaksi kulutuskäyttöpaikkaa, joilla on täysin sama osoite? Koskee esim. omakotitalon taloussähkön käyttöpaikkaan ja saman osoitteen sähköauton latauksen käyttöpaikkaa. Käytetään osoitteen tarkenne kenttää. Vapaa teksti -> Osoitteen tarkenne Käyttöpaikan osoitteilla on kenttä "vapaa teksti" ja muilla osoitteilla "osoitteen tarkenne". Näiden käyttötarkoitus on kuitenkin sama. Muutetaan vapaa teksti osoitteen tarkenteeksi.

10 Pöytäkirja 10 (10) 10 Muut asiat - 11 Seuraava kokous Verkonhaltijan verkkoluvan tyyppi Alalta on tullut kysymyksiä, pitäisikö olla verkonhaltijan tyyppi datahubissa. Tähän on otettu kanta, että tämä tieto on jo mittausalueella mittausalueen tyyppinä (esim. alueverkko tai kantaverkko). Tietysti voisi olla datahubissa tieto siitä, että millainen verkkolupa on verkonhaltijalle myönnetty. Tämä kertoo osittain verkonhaltijan tyypistä (kantaverkon verkkolupa, suljetun verkon verkkolupa). Voisiko tällaiselle tiedolle olla mitään tarvetta vaihtaa. Vai saako sitä edes välittää muille? Ei lisätä jakeluverkonhaltijan tyyppiä. Tuotetiedot Jakeluverkonhaltijalle on määritelty pakolliseksi ilmoittaa tuotetiedot datahubiin. Myyjät saavat haettua tuotetiedot hakutapahtumalla. Nyt on kuitenkin määritelty, että jakeluverkonhaltija valtuuttaa myyjät yksitellen näkemään omat hintatietonsa. Ei tarvitse valtuutusta, korjataan määrittely tältä osin prosessidokumenttiin. Asiakkaan valtuutus osapuolen ilmoittamana Asiakkaan valtuutusten ilmoittamisten osalta olemme määritelleet, että asiakkaan antaman valtuutuksen voi osapuoli ilmoittaa datahubiin ja ilmoitettaviksi tiedoiksi on sovittu asiakkaan tunniste sekä käyttöpaikkatunnus. Tätä on tarkasteltu nyt useiden eri keskusteluiden pohjalta uudelleen. Varmistaaksemme sen, ettei väärinkäytöksiä tämän osalta pääse syntymään, tulisi tätä muuttaa niin, että asiakas aina hyväksyy osapuolen ilmoittaman valtuutuksen, ennen valtuutustiedon tallennusta datahubiin. Puheenjohtaja näytti prosessista erillisen esityksen mitä käytiin läpi. Asian käsittely jäi kesken kun kokouksen aikataulu tuli vastaan. Otetaan Skype-palaveri vielä, jossa käydään läpi uudelleen. Puheenjohtaja lähettää kutsun skype-kokoukseen, niin saadaan läpi käytyä koko ryhmän kanssa keskeneräisten asioiden lista loppuun siltä osin mitä ei ehditty nyt kokouksessa käsitellä. Seuraava varsinainen kokous on klo Puheenjohtaja päätti kokouksen klo Jakelu Liitteet Prosessityöryhmä Lauri Jännes Esitysmateriaali