Datahub - tietokonversiotyöryhmän kokous

Transkriptio

1 Pöytäkirja 1 (8) Datahub - tietokonversiotyöryhmän kokous Aika klo Paikka Läsnä Fingrdi Oyj, Läkkisepäntie, Helsinki Jari Jaakola Erica Lietzen Katja Repo Jaana Kortelainen Birgitta Polojärvi Hannu Santala Jukka Luoma Saila Turunen Minna Pajunen Elina Kortessalo Sari Wessman Fredrik Södö pj Jukka Rinta-Luoma Marjut Puukangas siht Pohjois-Suomen Energiatieto Oy Caruna Oy Nivos Oy Porvoon Energia Oy Loiste Sähkönmyynti Oy Fortum Markets Oy Suomen Voimatieto Oy Pohjois-Karjalan Sähkö Oy KSS Energia Oy Vattenfall Oy Jyväskylän Energia Oy Fingrid Oyj Fingrid Oyj Fingrid Oyj Poissa - 1 Kokouksen avaus Fredrik Södö avasi kokouksen. Todettiin, että Modultek ei ole enää mukana työryhmässä ja Elina Kortessalo paikkaamassa Vattenfallin osalta Vassi Kujalaa. 2 Edellisen kokouksen muistio Mittaustietojen siirtoformaatista keskusteltiin edellisellä kerralla, tietokonversiosuunnitelmaan kirjattua Saf-formaattia ei ole kyseenalaistettu, joten pitäydytään siinä. Muistioon ei muuta huomautettavaa. 3 Tietokonversiosuunnitelma ja yhteenveto kommenteista Käytiin läpi tietokonversiosuunnitelmaan saatuja kommentteja. Siihen saatiin hyvin kommentteja 15 erityyppiseltä yhtiöltä. Kommentteja tuli kattavasti niin myyjiltä, verkkoyhtiöiltä kuin järjestelmätoimittajilta. Kaikkiin kommenteissa olleisiin kysymyksiin tullaan vastaamaan ja tullaan tekemään vastaavanlainen kysymyksiä ja vastauksia dokumentti kuin prosessienkin osalta on julkaistu. Pöytäkirjaan on kirjattu ne mistä keskusteltiin kokouksessa.

2 Pöytäkirja 2 (8) Kommenttien perusteella tullaan dokumentti viimeistelemään ja virallinen versio julkaistaan mennessä. 3.1 Toimialan omat tietokonversiosuunnitelmat Fingridiltä pyydettiin mallipohjaa toimialan omiin tietokonversiosuunnitelmiin tai niiden auditointia. Todettiin, että Fingrid voi tuottaa listaa suunnitelmassa huomioitavista asioista. keskusteltiin myös siitä, voiko Fingrid suositella jotakuta yhtiötä joka voisi auditoida, Fingridillä ei ole resursseja tällaiseen. 3.2 Tietojen siivous ja rikastus Asiakas- ja osoitetietojen siivouksesta saatiin paljon kommentteja ja kysymyksiä. Keskusteltiin siitä, että kaikilla käyttöpaikoilla ei ole osoitetta Postin rekisterissä. Keskusteltiin myös siitä, kuinka näitä osoitteettomia hallitaan. Tarkastusvaiheessa voitaneen hyödyntää käyttäjäryhmäluokittelua. Mietittävä myös sitä kuinka erotetaan, ettei aina jää tarkastuksissa kiinni. 3.3 Erikoismerkit Erikoismerkeistä oli joitain kysymyksiä kommenteissa. Todettiin, että UTF8-merkistön merkit on sallittu. 3.4 Korjausraportit 3.5 Pilottivaihe Kommenteissa toivottiin tarkempaa kuvausta näihin, mutta todettiin että nämä määritellään yhdessä järjestelmätoimittajan kanssa. Pilottivaiheen etenemisestä toivottiin yleisesti lisätietoa projektin edetessä. Tietokonversiotyöryhmän kokouspöytäkirjat tullaan julkaisemaan jatkossa Fingridin datahub-kotisivuilla, joten tämä on ensimmäinen askel tähän suuntaan. Jatkossa pilottivaiheen etenemisestä tullaa informoimaan toimialaa muutoinkin. 3.6 Rekisterien hyödyntäminen Fingrid on kesän aikana käynyt keskusteluja Väestörekisterikeskuksen kanssa mahdollisuudesta täydentää heidän rekisteristä puuttuvia henkilötunnuksia toimialan järjestelmiin. Henkilötietojen luovuttaminen Fingridille tai toimialan yhtiöille vaatii lainsäädännöllisen perusteen, mitä tällä hetkellä ei ole. Joten toimialan on itse oltava aktiivisia asiakkaisiin nähden henkilötunnuksen saamisen suhteen. Tästä on informoitava toimialaa. On huomioitava, että Fingrid ei voi tehdä ohjetta siihen kuinka tieto asiakkailta kerätään. Postin rekisterin mukainen tarkistus osoitteiden osalta ei välttämättä aina toimi. Fingridin aiemmin teettämää vertailua nykyisen käyttöpaikkarekisterin osalta ei kaikilta osin voitu hyödyntää. Joitain tarkastuksia katujen nimien yhtenäistämiseen esimerkiksi voidaan tehdä. Tämän osalta on pohdittava käytetäänkö sitä.

3 Pöytäkirja 3 (8) 3.7 Asiakastietojen yhdenmukaistaminen Kommenteista kävi ilmi huoli siitä kuinka varmistetaan että tieto tulee oikein konversiossa jos asiakas on usean myyjän myynnissä ja tiedoissa on eroja. Tämän osalta on vielä mietittävä kuinka infotaan muita osapuolia tiedon muuttumisesta ja mikä tieto sitten on oikea. Nyt on mietitty, että sen tieto kenellä on viimeisin sopimus, otetaan. Tämä ei ole välttämättä paras vaihtoehto, koska uudempi asiakastieto voi sisältää vähemmän tietoa kuin aikaisempi. Samassa yhteydessä keskusteltiin kuinka hoidetaan asiakkaat, joilla ei ole hetua ja samassa järj. myynti ja verkko, kenen osapuolen tunnus laitetaan. Keskusteltiin myös siitä miten toimitaan, jos useampi asiakas on yhdellä asiakasnumerolla, eikä kenelläkään ole hetua. Säännön mukaan näille tulisi sama tunnus. Näihin on mietittävä vielä ratkaisut. Todettiin tässä yhteydessä, että osoitetiedon attribuuttijärjestys on datastandardissa aakkosissa, muutetaan loogiseen järjestykseen esimerkkitiedostoihin. 3.8 Yhdistysrekisterin käyttö Suunnitelmasta puuttui tarkastus myös yhdistysrekisteristä. Tarkistus tuo mukanaan monimutkaisuutta, koska yrityksiä ja yhdistyksiä ei eroteta siirtotiedostoissa. Voi tuoda mukanaan suorituskykyhaasteita. Y-tunnuksen ja yhdistystunnuksen perusteella voi hakea tietoja YTJ:stä. Ja nimen perusteella voi hakea y-tunnuksia. 3.9 Ohjeistukset Ohjeistuksiin liittyen saatiin paljon kommentteja. Viesti alalta on, että ohjeita tarvitaan ja odotetaan mahdollisimman aikaisin. Siirtotiedostojen esimerkkitiedostoja toivottiin ja ne ovat tulossa jo syksyllä Tietokonversiojärjestelmän valmius pilottivaiheen alkaessa Keskusteltiin siitä, mikä on järjestelmän valmius pilottivaiheen alkaessa. Asiakastieto tulee voida vastaanottaa, muut toteutetaan pilottivaiheen edetessä. Keskusteltiin myös siitä kuinka paljon sitouttaa pilottiyhtiöitä. Aluksi toimitetaan vain tarvittava tieto, jonka avulla voidaan konfiguroida tarkastussäännöt. Pilottivaiheessa tärkein asia on kuitenkin rakentaa luotettava ja toimiva järjestelmä Mistä tieto tuodaan tietokonversiojärjestelmään Kommenteissa oli kysymyksiä siitä missä vaiheessa tieto tuodaan tietokonversiossa testiympäristöstä ja missä vaiheessa tuotantoympäristöstä. Keskusteltiin siitä, että on tärkeää, että lähtödata tulee samalta ajalta. Mikäli tieto haetaan suoraan tuotantokannasta, on huomioitava, että sitä on luultavasti tarve muokata tarkastuksen jälkeen. Lisäksi tietojen haut voivat olla raskaita ja häiritä muuta tuotantokäyttöä. Keskusteltiin siitäkin, että testikantaa ei voida pitää koskemattomana iteraatiokierrosten väliaikana. Kun siirrytään seuraavaan iteraatioon, toimitetaan silloin myös edellisen iteraatiokierroksen tiedot uudelleen, näin molemmat tiedot ovat samalta ajalta.

4 Pöytäkirja 4 (8) 3.12 Datahub järjestelmän käyttöönottovaihe Käyttöönottovaihe kuvattu tietokonversiosuunnitelmassa sen vuoksi, että saadaan määriteltyä suorituskykyvaatimuksia. Tavoite on saada tilanne markkinoilla stabiloitua. Tässä vaiheessa ei vielä voida tarkkaan määritellä sitä, kuinka monta päivää käyttöönottoon menee aikaa. Varsinainen käyttöönottosuunnitelma tullaan tekemään yhdessä datahub-järjestelmän toimittajan kanssa. Keskeneräisten tilanteiden käsittely mietittävä tarkkaan tässä yhteydessä Tietokonversioprosessi Tietokonversioprosessin kuvaa on muokattu jo ennen kommentteja. Siihen on tarkennettu osapuolikohtaiset tietojen tarkistukset. Raportit tullaan määrittelemään myös datahubista, eli nähdään koko ketju; mitä tietoja on lähetetty ja mitä tietoja on tallennettu datahubiin Valtuutustietojen käsittely Kolmansien osapuolien selvitys kyselyssä hieman epäonnistui, ei saatu tarkkaa listaa kaikilta siitä ketä osapuolia on tällä hetkellä tiedossa. Joitain kymmeniä on nyt tiedossa ja heidän kanssaan käydään vielä läpi valtuutusten toimitusprosessi ja tarpeet sille. Valtuutustietoja ei ole tällä hetkellä ylläpidetty markkinaosapuolten järjestelmissä. Keskusteltiin siitä, millä tavalla tarkistetaan osapuolen oikeudet Uudet sopimukset Täsmennetään suunnitelmaan, että uusia sopimuksia ilmoitetaan vain jos sopimus alkaa 3 kk sisään sanomaliikennemääritysten mukaan. Toive oli, että vietäisiin prosessityöryhmään keskusteluun tulisiko tuota 3 kuukautta laajentaa pidemmälle Verkkosopimuskäsittelyt Jos verkkosopimus uusitaan järjestelmäteknisistä syistä, käsitellään ne tietokonversiossa kuten uudet sopimukset. Keskusteltiin siitä kuinka viite-eheys säilyy mittaustietojen osalta. Jos on käsitelty uutena sopimuksena, niin tasekäsittelykin menee sen mukaan. Eli mittaustiedot tuodaan vain uuden sopimuksen voimassaoloajalta. Keskusteltiin siitäkin, että voidaanko mittaustietoa tuoda 6 vuotta siitä huolimatta, ettei ole voimassaolevaa sopimusta. Mittaustieto tällöin turha datahubissa, kun kenelläkään ei ole siihen oikeuksia Siirtotiedoston formaatti Kommenteissa kyseenalaistettiin sitä, onko -xlsx formaatti paras vaihtoehto. Kaikki eivät voi tuottaa tietoja tässä muodossa. Kommenteissa oli ehdotettu myös csvtiedostomuotoa. Xlsx-muotoa puoltaa se että csv:n tuottamisessa voi myös olla ongelmia. Xlsx-muoto olisi määrämuotoisempaa, voidaan määritellä tarkemmin tietotyyppejä ja se on laajempi formaatti. Harkitaan voiko csv olla rinnakkaisena vaihtoehtona. Jos se otetaan, niin csv:n

5 Pöytäkirja 5 (8) käyttöön tehtävä tarvittavat rajoitteet (sarakkeiden erottelumerkki ei voi esiintyä tiedoissa) Mittaustietojen tarkastus Kommenteista kävi ilmi, että on riski jos mittaustietoja ei tarkisteta. Todettiin, että mittaustietojen tuonti tietokonversiojärjestelmään aiheuttaa omalta osaltaan riskin suorituskyvyn osalta. Tämä vaatisi paljon tietokonversiojärjestelmältä ja tämän vuoksi on jätetty vasta datahubin tarkastettavaksi. Keskusteltiin myös tasevirheiden korjauksista, miksi ei niitä tuoda tietokonversiossa. Datahubin taseselvitysvastuun alkamisajankohta on ensin määriteltävä, tasetietoa kerätään käyttöönoton myötä, mutta kaikkia laskentoja ei voida alusta alkaen voida tehdä. Tässä yhteydessä keskusteltiin siitä, kuinka tieto saadaan verkolta myyjälle tasekorjauksissa kun sopimus päättynyt alle 6 vkoa. Todettiin, että tämä hoidetaan sähköpostiviesteillä Suorituskyky Käyttäjämääriä täsmennetään suorituskyvyn osalta suunnitelmaan POC - tuloksista Keskusteltiin osoitetiedoista ja isojen ja pienten kirjainten merkityksestä postilokeron kirjoituksessa, ei voi olla mikään este prosessissa. Sopimusten päättymispäivän käsittelyä tarkennetaan. 4 Esitietokysely Käytiin läpi kyselyn tilanne ja yleiskuva vastauksista. Vastauksia saatu 75 yhtiöltä (osa vastannut sekä myyjän ja verkon puolesta yhdellä kyselyllä), vastaamatta olleisiin ollaan yhteydessä. Yhteenvetona kyselystä: Markkinaosapuolien käyttämien tietojärjestelmien kirjo on laaja Kolmansista osapuolista ei saatu kyselyn avulla kunnon listaa Monimutkaiset konsernirakenteet ja palvelukuviot voivat aiheuttaa epäselvyyksiä Tiedonvaihdon yhteystietolistalla on myyjiä, jotka eivät käytännössä toimi vähittäismyyjinä Tarkastetaan - sopimus/asiakastiedot - ovatko kaikki saman järjestelmän omaavat vastanneet samalla tavalla.

6 Pöytäkirja 6 (8) Myyjille ja jakeluverkonhaltijoille tullaan jatkossa laittamaan kohdennettuja kyselyitä, kun on saatu yhtiöiltä oikeat yhteyshenkilöt. 5 Tietokonversiojärjestelmän hankinnan tilanne Tietokonversiojärjestelmä hankitaan palveluna, ohjelmistopalvelua varten tehdään omat vaatimusmäärittelyt ja tätä varten hankittu ulkopuolista apua. Tämä toteutetaan julkisena hankintana. Tarkkaa aikataulua ei voida laatia, ennen kuin on toimittaja valittu tietokonversiojärjestelmälle. 6 Yleisistä ohjeistuksista Käytiin läpi EDI käyttäjäpäiviltä tulleita kysymyksiä ja ohjetarpeita. Fredrik esitteli ehdotuksen ohjeistusasiaan ja omaan "sivustoon" ja keskusteltiin kuinka voitaisiin ottaa käyttöön. Datahub kotisivuja tullaan aluksi käyttämään ohjeiden jakamisessa. Tullaan julkaisemaan kysymyksistä ja vastauksista oma dokumentti, ennenkuin saadaan muuta työkalua niille. 7 Siirtotiedosto-ohjeet Ohjeistuksessa on siirtotiedostojen toimitusjärjestystä korostettu enemmän verrattuna tietokonversiosuunnitelmaan. Ohjeistukseen lisätään roolit ja selkeä taulukko siitä kuka toimittaa mitä tietoa. Lisäksi käytiin läpi monia tarkennuksia ohjeeseen: Osapuolitietoina toimitetaan vain omat tiedot. Avataan dokumenttiin tarkemmin. Siirtotiedoston revisio - pitää avata ohjeeseen. Poistetaan yritysasiakastiedon turha määritelmä Lisätään ohjeistukseen kuinka tuodaan jos esim. asiakkaalla useita puhelinnumeroita. Nimenkirjoitusasusta ET lähettänyt tiedotteen viime marraskuussa. Kuolinpesän käsittelyä täsmennetään. Varmistettava, että eri tulosteissa tulee tämä oikein. Toimii eri tavalla riippuen käyttääkö tarkennetta tai ei. Nykyinen sanomaliikenne rikkoo tälläkin hetkellä asiakastietojen oikeellisuutta, kun toimijoilla erilainen käsittelytapa omissa järjestelmissään. Datastandardissa puhelinnumerossa on eroja siirtotiedostoon verrattuna. Puhelinnumero tulee olla yhdessä pötkössä. Asiakastietojen siirtotiedostoesimerkkiin olisi hyvä laittaa useita eri variaatioita.

7 Pöytäkirja 7 (8) Henkilötunnus, syntymäaika - tarkennettava Ruotsinkielisyyden käsittelyä mietittävä asiakkaan tietojen osalta. Ohjeistetaan kuinka tuodaan jos asiakas on ilmoittanut sekä suomenkielisen että ruotsinkielisen osoitteen. Kielikoodilistan standardi otetaan käyttöön. Kuinka käsitellään jos osapuoli yrittää laittaa osoitteen kaikki samaan kenttään? kadunnimi ja talonumero on pakollisia ja jos näitä ei ole niin postilokero. Tarkennetaan ohjeeseen Tuotetiedot, kuinka alv-käsittely? Ilmoitetaanko onko alvillinen vai alviton? Siirtotuotteen perusmaksu jos sulakekokoon riippuvainen, tuotava joka hinta omana rivinään. Myyntituote ei ole pakollinen. Keskusteltiin siitä myös kuinka käsitellään eri hinnastolla olevat hinnat. Nämä käydään läpi vielä Fingridin toimesta ja viedään prosessityöryhmän käsiteltäväksi. Käyttöpaikkatunnukset, tämän tietosisältö GS1:sen osalta riippuu siitä, kuinka GS1 käyttöönotto päätetään toteuttaa. Avataan tätä dokumenttiin. Käyttöpaikkojen osoitteisiin variaatioita. Käyttöpaikan lisäosoitteisiin Ruotsinkielinen osoite lisäosoitteena, jos tarve tai jos pääosoite ruotsinkielinen niin suomenkielinen lisäosoitteena. Täsmennetään tekstissä olevaa viittausta verkkolaskuosoitteeseen. Rajapistetiedot - ilmoittaako vain otto- tai antoalueen verkonhaltijat vai molemmat Kuinka virtuaalituotantolaitokset tuodaan Jhv:n ilmoitus myyntisopimuksesta, tarkistetaan että myyntisopimuksen voimassaolo vastaa myyjän ilmoittamia tietoja. Tulee eri tiedostoon ja omat esimerkit. Valtuutustietojen osalta mietittävä miten verifioidaan että on oikeita. 8 Tietokonversio Tanskan hubi projektissa Fredrik esitteli kuinka tanskalaiset hoitivat oman tietokonversioprosessinsa. 9 Jatkotoimenpiteet Seuraava kokous Fingridillä. Ohjeistusten kommentointi hoidetaan sähköpostitse, uudet versiot laitetaan kommenteille parin viikon sisään ja lopulliseen kuntoon vko 37. Marjut Puukangas

8 Pöytäkirja 8 (8) Liitteet Jakelu ei liitteitä osallistujat