Tietokonversio - Kysymykset ja vastaukset

Transkriptio

1

2 2 (29) Sisällysluettelo 1 Johdanto Siirrettävät tiedot Yleiset kysymykset... 9 Missä ja kuka määrittelee miltä aikajaksolta siirrettävät tiedot ovat?... 9 Miksi siirtotiedostoissa tulee käyttää UTC-aikaa?... 9 Missä vaiheessa päätetään, mikä tieto tallennetaan datahubiin? Asiakastiedot Onko alalle mahdollista saada oikeutta hankkia puuttuvia tietoja suoraan Väestörekisterikeskuksen tai muun tahon kautta? Missä vaiheessa tarkastellaan kumman asiakastieto, myyjän vai verkon, on oikea? Säännöt eivät ota kantaa miten verkonhaltijan toimittamat tiedot käsitellään. Onko myyjä aina vahvempi? Miksi jakeluverkonhaltijan on toimitettava tiedot yhtä suuressa laajuudessa datahubiin, jos niitä ei käytetä? Jos myyjällä ja verkolla on yhteiset asiakastiedot, siirtävätkö molemmat? Onko mietitty tarkistukseen sääntöjä, joilla myyjälle/verkonhaltijalle palautetaan esim. tieto toisella osapuolella samalla käyttöpaikalla olevan asiakkaan tiedoista (hetu/nimi)? Voisiko tietokonversiojärjestelmä kontaktoida asiakkaita keskitetysti? Mitä tunnusta tulee käyttää jos asiakkaalta puuttuu henkilötunnus? Sama yritys on perustettu moneen kertaan samalla y-tunnuksella, miten hallitaan? Osapuolitiedot GS1 GLN osapuolitunnuksen käyttö, voi olla ylimääräinen haaste konversio vaiheessa? Käyttöpaikkatiedot Voiko osoitteissa olla tarkenteita postin osoitteeseen verrattuna?... 12

3 3 (29) Vapaa-ajanasunnoista isolle osalle ei ole postin jakelua. Mitä tietoa vasten osoitteet tarkastettaisiin? Voisiko pelastusviranomaisten osoiterekisteristä saada apua käyttöpaikan osoitteen tarkastusta varten? Sallitaanko erikoismerkkejä käyttöpaikkojen nimessä? Voidaanko tarkistaa myös myyjällä käytössä olevien käyttöpaikkojen osoitetiedot? Valtuutustiedot Saattaa olla hankalaa kolmannelle osapuolelle toimittaa valtuutustietoja. Eikö olisi parempi, että verkonhaltija ja myyjä toimittaisivat ne? Kuka tarkistaa 3. osapuolen valtuutukset? Tuotetiedot Samalla tuotteella ja tuotekomponentilla voi olla samaan aikaan eri hintoja eri hinnastoissa sekä sopimuskohtaisia hintoja Sopimustiedot Tuodaanko sopimustiedot riittävän pitkältä aikaväliltä? Miksi päivämäärässä pitää olla kellonaika? Huomioidaanko mitenkään mahdollisia tuotannon ostosopimuksia, jos siinä on eri myyjäyhtiö kuin toimituksella (myyntisopimus)? Mittaustiedot Samalla asiakkaalla on voinut olla useita peräkkäisiä verkkosopimuksia. Poimitaanko vain viimeisimmän verkkosopimuksen voimassaolon verran (jos ollut yli 6 vko voimassa)? Jos on vaihtunut monesti muu-tunti-muu-tunti, niin poimitaanko vain viimeisimmän tuntimittauksen ajalta? Onko mittaustietojen tuonti ainoastaan datahubiin riskin paikka? Tietokonversioprojekti Yleiset Millainen on järjestelmätoimittajien ohjaava rooli? Miten paljon järjestelmätoimittaja pystyy tukemaan meitä Datahub-asioissa?... 15

4 4 (29) 3.2 Markkinaosapuolen oma tietokonversiosuunnitelma Voisiko FG toimittaa tähän valmiin pohjan, koska kaikilla toimijoilla suunnitelma on mitä ilmeisemmin hyvin samansuuntainen? Tuleeko Fingrid auditoimaan suunnitelmia? Tuleeko markkinaosapuolen rikastuttaa tiedot itse, jos esim. käyttöpaikoilla otetaan käyttöön uudet GS1-tunnukset? Tehtävät ja vastuut Miten Fingrid huomioi loppuasiakastiedottamisen? Järjestelmätoimittajille ohjeistus puuttuu Tietokonversiojärjestelmän määrittely puuttuu Onko tietokonversiokumppani tietokonversiojärjestelmän toimittaja? Mikä taho hankki luvan integraatioon VRK:n henkilötietopalveluun? Aikataulu Onko tietokonversiojärjestelmä on valmis ottamaan vastaan ja analysoimaan pilottidataa ennen 12/2016? Kaksi kuukautta ei tule riittämään missään nimessään testaamiseen Kakkoskierroksen aikataulua kannattaa vielä säätää joko ennen lomia tai sitten jälkeen Tuottavatko markkinaosapuolet aineiston samalta ajanhetkeltä? Pilottivaihe Saadaanko pilottivaiheen kokemuksia yleisesti markkinaosapuolten käyttöön? Vakavuustason 1 ja 2 poikkeamat on korjattu tietokonversiojärjestelmässä. Tarkoittaako, että poikkeamat on korjattu ennen pilottivaihetta 1 vai sen jälkeen? Milloin pilottiyritykset valittiin ja miten voi osoittaa kiinnostusta ryhmään jäseneksi? Onko pilottiyritysten valinnassa huomioitu, että yrityksillä on riittävästi käyttöpaikkoja, joilla on eri pilottiosapuolia myyjänä/verkonhaltijana, jotta voidaan testien kautta määrittää riittävät tarkistukset markkinatason tarkastusvaiheeseen? Testiympäristön päivitysajankohta täytyy olla ilmoitettuna hyvissä ajoin Miten käsitellään puuttuvat tiedot?... 19

5 5 (29) Miksi mittaustietoja ei tarkasteta pilottivaiheessa? Mittaustietoja on kuitenkin tarkoitus toimittaa jo pilottivaiheessa, joten onko niille aikomus tehdä jonkinlaisia tarkastuksia ennen datahubiin siirtämistä? Tarkastussäännöistä pitää saada tiedot, joita vasten omia tietoja voi tarkastaa Datahubin toteutusvaihe Onko jossain määritelty miten pitkään lähdeaineiston poiminta saa kestää? Miksi tietokonversioon liittyvä ohjeistus pitää olla valmiina vasta tarkistuspisteessä T0? Miksi tarvitaan niin monta iteraatiovaihetta? Iteraatiomäärä on pelkän migraation kannalta varsin suuri ja aiheuttaa kustannuksia Voidaanko tietojen yhdenmukaisuustarkastusta aikaistaa? Miksi mittaustietoja ei validoida tietokonversion iteraatiovaiheessa 1? Otetaanko tiedot markkinaosapuolten tuotantojärjestelmistä vai pitääkö testijärjestelmät tuoreuttaa tuotantoympäristöistä ennen iteraatiokierrosta? Miten tarkastussäännöissä voi olla poikkeamia? Käyttöönotto Riittääkö kolme päivää tietoliikennekatkoon valmistautumiseen? Saisiko käyttöönottoaikaa lyhennettyä? Miten taataan suorituskyky? Onko käyttöönotolla varasuunnitelma? Katkon aikainen ohjeistus on tultava toimialalta ja sovittava tarkemmat aikataulut yhtiökohtaisesti esim. lataukselle Mitä tarkoittaa että "tapahtumat kertyvät jonoon"? Koko tietokonversioprosessin läpiviemiseen käytettävä aika määriteltävä harkitusti huomioiden isojen yhtiöiden laajat aineistot Tietokonversiojärjestelmä Komponentit ja rajapinnat Miksi siirtotiedostojen muodoksi on valittu xlsx?... 23

6 6 (29) Mikä on siirtotietokannan rooli? Onko siirtokannasta lukeminen välttämätöntä? Tiedostojen tuonti Onko oletuksena, että tiedostot käsitellään rivikohtaisesti eli puutteelliset/virheelliset rivit eivät keskeytä tuontia? Tuotujen rivien määrän lisäksi pitäisi näyttää mahdolliset hylätyt rivit ja näiden tunnistaminen (rivinumero) Tietojen tarkastus Miten prosessissa on ajateltu toteuttaa esim. jakeluverkonhaltijan tietojen täydentäminen muiden myyjäyhtiöiden tuottamalla datalla? Millainen rooli kullakin valitulla rekisterillä vertailussa tai mahdollisessa tiedon rikastamisessa on? Tarkistetaanko, että Y-tunnus ja yrityksen nimi vastaavat toisiaan? Tullaanko väestörekisteriä käyttämään kuitenkin tietojen tarkastamiseen? Onko käynnissä selvitys, että markkinaosapuolet voisivat hyödyntää väestörekisteriä omassa tietojen siivouksessaan datahub-hanketta varten? Tehdäänkö markkinatason sääntöjen tarkistus prosessin vaiheessa 3? Miksi varaudutaan kytkemään joitakin tarkastuksia pois päältä? Raportointi Poistetaanko iteraatiovaiheiden jälkeen siirtotiedostojen tietojen lisäksi myös raportit? Datahub-järjestelmään tehtävien pistokokeiden laajuus on määriteltävä tarkemmin Miten korjausehdotusdokumentti linkitetään tietoihin, joita on tarkoitus massakorjata? Miten toimitaan vielä konversion jälkeenkin jääneiden kriittisten virheiden osalta? Eikös käyttöönoton laatuvaatimusten pitäisi olla 100% Kaikki datahubiin ladatut omat tiedot pitäisi olla mahdollista hakea esimerkiksi csv/excel -muodossa omia eheystarkasteluja varten? Tietokonversion loppuraportti. Kuka raportoi ja kenelle? Kenelle markkinaosapuolten pitää raportoida pistokokeiden tuloksista ja miten?... 27

7 7 (29) Korjaako konversiojärjestelmän toimittaja tietokonversiojärjestelmän ja datahubin välistä yhteyttä? Kenelle tietokonversioraportit tehdään, kuka niitä lukee ja mitä tiedoilla tehdään? Tietojen julkaisu Julkaistaanko tiedot datahubiin ensimmäisen kerran vasta iteraatiovaiheen 3 jälkeen? Tietojen siirtäminen datahubiin Kenellä on vastuu tiedon oikeellisuudesta, tai siitä että kaikki tiedot siirtyvät? Suorituskykyvaatimukset Ladattavan / käsiteltävän tiedon määrä on epäselvä Seuranta Jos yhdenmukaisuustarkastuksessa huomataan virheitä, miten niistä ilmoitetaan? Onko datastandardissa myös kenttä, johon tuonnin virheet merkitään? Arkkitehtuuri Onko ylläpitotoimintojen käyttöliittymä tarkoitettu FG:lle vai markkinaosapuolille vai molemmille eri toimintojen osalta? Saako markkinaosapuoli määritellä tarkastussääntöjä? Onko työkalun käyttöön liittyen mahdollista pitää Skype-koulutuksia tms. ellei työkalu ole todella helppo käyttää perusohjeiden avulla Käyttöönottovaiheessa järjestelmälle on vaadittava 24/7 käyttövaatimus

8 8 (29) Muutoshistoria Päivämäärä Versio Muutokset 1.0 Ensimmäinen versio

9 9 (29) 1 Johdanto Fingrid pyysi tietokonversiosuunnitelmaan toimialalta kommentteja kesän 2016 aikana ja vastauksia saatiin kiitettävä määrä. Tähän dokumenttiin on kerätty kommenttikierroksella ja muiden yhteydenottojen yhteydessä esiin nousseita kysymyksiä ja niihin vastauksia. Dokumentissa on pyritty antamaan vastaus kaikkiin tietokonversiota koskeneisiin kysymyksiin. Samoja aiheita koskevia kysymyksiä tuli useita ja niitä on kerätty yhteen samojen vastausten alle. Kysymykset on jaettu aihealueittain pääotsikoiden alle, jotta lukijan olisi helpompi löytää etsimänsä. Kysymykset on kirjoitettu punaisella ja niiden alla on tavallisena tekstinä kysymyksen tai kommentin tarkenne. Vastaus on kirjoitettu lihavoituna. 2 Siirrettävät tiedot 2.1 Yleiset kysymykset Missä ja kuka määrittelee miltä aikajaksolta siirrettävät tiedot ovat? Esimerkiksi jos lataukset tehdään testikannasta, kuinka vanhoja ne voivat olla? Tuleeko eri yhtiöiden tiedot olla samalta ajanjaksolta, jotta esimeriksi myyjän ja verkon sopimustiedot täsmäävät? Vastaus: Tarkat ajankohdat sovitaan tietokonversiotyöryhmässä hyvissä ajoin ennen tietokonversiotyön alkua. Varsinkin tietokonversion iteraatiovaiheesta kolme eteenpäin on tärkeää, että tiedot ovat peräisin mahdollisimman samasta markkinatilanteesta. Miksi siirtotiedostoissa tulee käyttää UTC-aikaa? Käytettävä rannekelloaikaa. UTC on huono koska, päivämäärät eivät täsmää sopimuksissa oleviin. Vastaus: Halutaan välttää tilanteita, joissa eri markkinaosapuolet lähettävät aikaleimatiedot eri aikaympäristössä. Tietokonversiojärjestelmän ei tarvitse huomioida kesäaikasiirtymää, kun aikaleimat annetaan UTC-ajassa. Pysytään siinä. Missä vaiheessa päätetään, mikä tieto tallennetaan datahubiin? Tietokonversiojärjestelmässä, julkaisualueella vai vasta datahubissa? Vastaus: Tietokonversiojärjestelmässä. Tietokonversiojärjestelmä toimittaa yksiselitteiset tiedot datahubiin, ei siis useita versioita esim. saman asiakkaan tiedoista.

10 10 (29) 2.2 Asiakastiedot Onko alalle mahdollista saada oikeutta hankkia puuttuvia tietoja suoraan Väestörekisterikeskuksen tai muun tahon kautta? Vastaus: Fingrid on selvittänyt asiaa. Ei ole mahdollista nykyisen lainsäädännön nojalla. Missä vaiheessa tarkastellaan kumman asiakastieto, myyjän vai verkon, on oikea? Esimerkiksi siirto- ja myyntisopimukset ovat eri nimellä? Vastaus: Tarkastus tehdään ns. yhdenmukaisuustarkastuksessa, koska se edellyttää että kaikki osapuolet ovat toimittaneet tiedot. Tietokonversiojärjestelmä ei pysty päättelemään kumman tieto on oikea, tietojen siivousohjeeseen määritellään tämän osalta oma manuaalinen prosessinsa. Säännöt eivät ota kantaa miten verkonhaltijan toimittamat tiedot käsitellään. Onko myyjä aina vahvempi? Jos Myyjä A:lla on sopimus vuodesta 2005 lähtien ja Myyjällä B on sopimus, joka astuu voimaan 1 viikon päästä -> käytetään myyjän A toimittamia asiakastietoja. Myyjä B:n toimittamat asiakastiedot eivät päivity järjestelmään. Toimiiko näin? Vastaus: Säännöstö on muutettu. säännöstö perustuu verkonhaltijan tietoihin, eli datahubiin tallennetaan ensisijaisesti verkonhaltijan toimittamia asiakastietoja. Jos yksilöidyn asiakkaan tiedot löytyvät useamman verkonhaltijan järjestelmästä tallennetaan tiedot tuoreimman sopimuksen perusteella. Eri markkinaosapuolten asiakastiedoissa olevia eroavaisuuksia kirjataan tarkastusraporttiin ja markkinaosapuolten tulee selvittää oikea tieto keskenään siten, että myyjät selvittävät verkonhaltijan kanssa ja verkonhaltijat keskenään. Jos verkkosopimuksella ja myyntisopimuksella on eri asiakastunniste, viedään sekä myyjän että verkkohaltijan asiakas- ja sopimustiedot datahubiin. Eroavaisuudesta ilmoitetaan myyjän tarkastusraporttiin. Huomaa, että tietokonversiosuunnitelma ei käsittele tarkastussääntöjä kattavasti. Tietokonversiojärjestelmään tulee iso määrä erilaisia tarkastuksia, jotka kuvataan erilliseen dokumenttiin pilottivaiheen aikana. Miksi jakeluverkonhaltijan on toimitettava tiedot yhtä suuressa laajuudessa datahubiin, jos niitä ei käytetä? Vastaus: Tiedot tarvitaan eheys- ja yhdenmukaisuustarkastuksissa. Säännöstö on myös muutettu. Katso vastaus edelliseen kysymykseen.

11 11 (29) Jos myyjällä ja verkolla on yhteiset asiakastiedot, siirtävätkö molemmat? Vastaus: Siirtävät. Tietoja tarvitaan sekä eheys- että yhdenmukaisuustarkastuksissa. Osapuolen sopimustietojen eheystarkastus tuottaa virheen, jos osapuoli ei ole toimittanut asiakastietoja. Onko mietitty tarkistukseen sääntöjä, joilla myyjälle/verkonhaltijalle palautetaan esim. tieto toisella osapuolella samalla käyttöpaikalla olevan asiakkaan tiedoista (hetu/nimi)? Vastaus: Prosessia ei ole vielä mietitty valmiiksi. Nykylainsäädännön nojalla datahubilla ei ole oikeutta jakaa henkilötietoja eri markkinaosapuolille, mikä osaltaan rajoittaa mahdollisuuksia tällä hetkellä. Lisäksi kilpailusyistä ei voida jakaa asiakastietoja myyntiyhtiöiden välillä. Tarkoitus on ilmoittaa eroavaisuuksia asianomaisille tarkastusraporttien kautta, jotta markkinaosapuolet voivat selvittää oikea tieto keskenään. Verkonhaltijan tietoja käytetään referenssinä, jotta myyntiyhtiöiden ei tarvitse selvittää keskenään. Voisiko tietokonversiojärjestelmä kontaktoida asiakkaita keskitetysti? Voisiko tietokonversiojärjestelmään miettiä toiminnallisuuksia, joilla asiakkaita kontaktoitaisiin keskitetysti tekstiviestitse tai sähköpostitse ja pyydettäisiin tarkistamaan/täydentämään tietonsa suoraan järjestelmään? Vastaus: Ei. Tietokonversiojärjestelmään ei luoda kuluttaja-asiakasrajapintaa. Mitä tunnusta tulee käyttää jos asiakkaalta puuttuu henkilötunnus? Järjestelmistä puuttuu asiakkaiden henkilötunnuksia tai asiakkailla on vain syntymäaika, joten tähän pitäisi saada jokin ratkaisu esim. keksitty tunnus, jota tällaisissa tapauksissa voidaan käyttää, jos lainsäädäntömuutosta ei voida toteuttaa. Vastaus: Vaihtoehtoinen tunnus on määritelty datastandardissa. Jos henkilötunnus puuttuu, asiakastunnisteeksi ilmoitetaan <markkinaosapuolen tunnus>_<sisäinen asiakastunniste>. Sama yritys on perustettu moneen kertaan samalla y-tunnuksella, miten hallitaan? Entä tilanteet, joissa esim. kaupunki-asiakkaalla on useita toimintoja vrt. Asiakkaan tarkenne - kenttä. Järjestelmiin on voitu perustaa sama yritysasiakas moneen kertaan samalla y-tunnuksella. Tällä tavalla on hallittu mm. laskujen kohdistamista. Asiakkaan tarkenne -kenttä datastandardissa: Tiedoilla voidaan tarkentaa asiakasta sopimuskohtaisesti, jos esimerkiksi asiakkaalla on useampi toiminto saman Y-tunnuksen alla

12 12 (29) Vastaus: "Asiakkaan tarkenne" kuuluu sopimustietoihin datastandardissa. Y-tunnuksen tulee olla asiakkaan yksilöivä tunniste. Kuvattu tilanne johtaa duplikaattivirheeseen tietokonversiojärjestelmän tarkastuksissa. 2.3 Osapuolitiedot GS1 GLN osapuolitunnuksen käyttö, voi olla ylimääräinen haaste konversio vaiheessa? Vastaus: Ei ole vielä päätetty mahdollisesta GS1 - GLN osapuolitunnuksen käyttöönotosta. Ei ole sinänsä ongelma tietokonversion kannalta, kunhan tunnuksia käytetään johdonmukaisesti. 2.4 Käyttöpaikkatiedot Voiko osoitteissa olla tarkenteita postin osoitteeseen verrattuna? On olemassa paljon käyttöpaikkoja, joihin ei löydy yhteyttä postin osoiterekistereistä. Voiko osoitteissa olla tarkenteita postin osoitteeseen verrattuna? Osoitteissa on hyvä sallia myös muita osoitteita. Esimerkiksi tarkenteet, kuten jakokaappi ja työmaa ovat tarpeellisia. Vastaus: Käyttöpaikan osoitteissa voi olla tarkenteita. Käyttöpaikan osoitetiedoissa on kenttä "Vapaa teksti" (150 merkkiä), joka on varattu tarkentavalle kuvaukselle käyttöpaikan sijainnista. Vapaa-ajanasunnoista isolle osalle ei ole postin jakelua. Mitä tietoa vasten osoitteet tarkastettaisiin? Postin osoitetietojärjestelmään vertaaminen herättää kysymyksiä, koska postin järjestelmä ei tunnista kaikkia käyttöpaikkoja, kaikkiin käyttöpaikkoihin kun ei kanneta postia. Voi olla myös muita perusteluja, miksi käyttöpaikan osoite poikkeaa postiosoitteesta. Huolten hälventämiseksi tähän (tai muualle tähän dokumenttiin) olisi siis hyvä tarkentaa, mitä tehdään niille tietoriveille, joissa käyttöpaikan osoite poikkeaa postin osoitteesta: edellyttääkö konversiojärjestelmä, että kyseiset rivit korjataan vai hyväksytäänkö ne osoitteiden erilaisuudesta huolimatta. Vastaus: Kaikkia osoitetietoja ei pystytä tarkistamaan Postin rekisteristä. Pyrimme löytämään keinon tunnistaa käyttöpaikat, joiden osoitetietoja ei voida tarkistaa, jotta järjestelmä ei luo samoja virheitä uudestaan ja uudestaan. Tietokonversiojärjestelmä ei edellytä osoitetietojen korjaamista rekisterivirheen takia.

13 13 (29) Voisiko pelastusviranomaisten osoiterekisteristä saada apua käyttöpaikan osoitteen tarkastusta varten? Vastaus: Pelastusviranomaisilla ei taida olla tarkoituksenmukaista valtakunnallista palvelua tarjolla. Sallitaanko erikoismerkkejä käyttöpaikkojen nimessä? EDI-käyttäjäpäivillä oli puhetta myös käyttöpaikkojen nimien erikoismerkeistä. Tämä jäi työryhmän selvitettäväksi. Esimerkiksi /-merkin käytöstä keskusteltiin. Vastaus: Datastandardissa ei ole käyttöpaikan nimi -kenttää. Yleisesti ottaen kaikki UTF-8 merkistön mukaiset erikoismerkit sallitaan. Voidaanko tarkistaa myös myyjällä käytössä olevien käyttöpaikkojen osoitetiedot? Eikö olisi hyvä, jos tässä yhteydessä myyjällä käytössä olevat käyttöpaikkojen osoitetiedot tulisi samalla tarkastettua/korjattua. Mikäli myyjä ei toimita kuin käyttöpaikan tunnistetiedot (sopimuksilla), niin tuota tarkistusta ei voida tehdä. Vastaus: Sellaista tarkastusta ei ole tällä hetkellä määritelty. Tarkastus olisi mahdollista toteuttaa, edellyttäen että myyntiyhtiöt lähettävät hallussaan olevat käyttöpaikkatiedot. Tämä vaatisi kuitenkin huomattava määrä lisätyötä, joten pitää arvioida onko hyöty vaadittavan lisätyön arvoinen. 2.5 Valtuutustiedot Saattaa olla hankalaa kolmannelle osapuolelle toimittaa valtuutustietoja. Eikö olisi parempi, että verkonhaltija ja myyjä toimittaisivat ne? Vastaus: Valtuutukset perustuvat kolmannen osapuolen valtakirjaan käsitellä määritellyn käyttöpaikan tietoja. Vastuuta valtuutustiedon toimittamiselle ei voida siirtää verkko- ja myyntiyhtiöille. Valtuutustiedot ovat rakenteeltaan yksinkertaiset, niiden toimittaminen ei tulisi olla ylivoimainen tehtävä kolmansille osapuolille. Kuka tarkistaa 3. osapuolen valtuutukset? Vastaus: Valtakirjat eivät tyypillisesti löydy tietojärjestelmistä, joten tarkastus on hoidettava tietojärjestelmien ulkopuolella. Fingrid vastaa menettelytavasta.

14 14 (29) 2.6 Tuotetiedot Samalla tuotteella ja tuotekomponentilla voi olla samaan aikaan eri hintoja eri hinnastoissa sekä sopimuskohtaisia hintoja Vastaus: Tuoterakenteesta on keskusteltu tietokonversiotyöryhmässä ja haasteita on tunnistettu. Tuoterakenteen mahdollisia muutostarpeita tulee viedä prosessityöryhmän käsiteltäväksi. 2.7 Sopimustiedot Tuodaanko sopimustiedot riittävän pitkältä aikaväliltä? Tulee tarkkaan selvittää tarvitaanko esim. tase- tai laskutuskorjauksia, historiatuntitietojen raportointia tms. varten sopimusten muutokset pidemmältä ajalta. Vastaus: Tämän hetken näkemyksen mukaan tasekorjauksia ei voida suorittaa datahubissa ajalle ennen datahubin käyttöönottoa. Tasekorjausten luotettava hallinta edellyttäisi tasekorjaushistorian tuontia datahubiin ja datahubin tasesarjojen verifiointia huomioiden aiemmin tehdyt korjaukset pitkältä aikaväliltä. Muutoshistoriaa ei todennäköisesti pystytä poimimaan luotettavasti markkinaosapuolten tietojärjestelmistä, mikä toisi lisää haasteita. Miksi päivämäärässä pitää olla kellonaika? Pitäisikö olla tuki vaihtaa sopimusta esim. klo 11:32:54? Miten luenta menisi silloin? Vastaus: Sopimukset ovat käytännössä voimassa kokonaisia vuorokausia. Sopimuksen voimassaolo määrää kuitenkin miten mittaustiedot allokoidaan taseselvitykseen ja miltä aikaväliltä datahub odottaa mittausarvoja sopimukseen kytketylle käyttöpaikalle. Tästä syystä voimassa-olo tulee toimittaa korkeammalla resoluutiolla, jotta datahub-järjestelmään ei jouduta luomaan ylimääräistä logiikkaa. Aikaleimojen ilmoitus minuuttiresoluutiolla on yleinen käytäntö esim. Prodat-sanomaliikenteessä, tämä on verrattavissa siihen. Huomioidaanko mitenkään mahdollisia tuotannon ostosopimuksia, jos siinä on eri myyjäyhtiö kuin toimituksella (myyntisopimus)? Vastaus: Tuotannon ostosopimustiedoissa on eri käyttöpaikkatunnus. Toistaiseksi ei ole määritelty mitään tarkastuksia, jotka ottaisivat kantaa tuotannon ja toimituksen myyjäyhtiöihin. Tuotannolla ja kulutuksella voi olla eri tai sama myyntiyhtiö.

15 15 (29) 2.8 Mittaustiedot Samalla asiakkaalla on voinut olla useita peräkkäisiä verkkosopimuksia. Poimitaanko vain viimeisimmän verkkosopimuksen voimassaolon verran (jos ollut yli 6 vko voimassa)? Vastaus: Poimitaan vain viimeisimmän verkkosopimuksen verran. Tuodaan sen sopimuksen mittaustiedot mikä tuodaan tietokonversiossa. Jos on vaihtunut monesti muu-tunti-muu-tunti, niin poimitaanko vain viimeisimmän tuntimittauksen ajalta? Vastaus: Poimitaan vain viimeisimmän tuntimittauksen ajalta. Onko mittaustietojen tuonti ainoastaan datahubiin riskin paikka? Mittaustietoja ei tarkasteta tietokonversiojärjestelmässä, vaan ne tuodaan suoraan datahubjärjestelmään? Vastaus: Tämä aiheuttaa riskin, mutta on arvioitu, että mittaustiedon tuonti tietokonversiojärjestelmään aiheuttaa vielä suuremman riskin ja suuret kustannukset. Mittaustiedon tuonti tietokonversiojärjestelmään moninkertaistaisi tiedon määrän ja loisi lisää suorituskykypaineita tietokonversiojärjestelmään. Lisäksi datahub-järjestelmällä on paremmat edellytykset luotettavaan tarkastukseen, koska siinä voidaan laskea tasesarjat, joita voidaan hyödyntää mittaustietojen tarkastuksessa. 3 Tietokonversioprojekti 3.1 Yleiset Millainen on järjestelmätoimittajien ohjaava rooli? Miten paljon järjestelmätoimittaja pystyy tukemaan meitä Datahub-asioissa? Vastaus: Järjestelmätoimittajilla ei ole ohjaavaa roolia, vaan tukeva rooli. Roolit ja vastuut on määritelty tietokonversiosuunnitelman luvussa 4.

16 16 (29) 3.2 Markkinaosapuolen oma tietokonversiosuunnitelma Voisiko FG toimittaa tähän valmiin pohjan, koska kaikilla toimijoilla suunnitelma on mitä ilmeisemmin hyvin samansuuntainen? Vastaus: Suunnitelmat tulevat käytännössä olemaan hyvin erilaiset riippuen olemassa olevista tietojärjestelmistä ja niiden kehityssuunnitelmista, joten kovin tarkkaa pohjaa emme pysty toimittamaan. Fingrid voi tehdä listan huomioitavista asioista. Tuleeko Fingrid auditoimaan suunnitelmia? Jos tulisi, tällä varmistettaisiin, että asia etenee eri osapuolilla. Tälle olisi hyvä olla myös tavoiteaikataulu. Vastaus: Fingridillä ei ole kapasiteettia auditoida osapuolten omia suunnitelmia. Tulemme seuraamaan työn etenemistä tietokonversiovastaaville suunnattujen kyselyjen avulla. Fingrid kehottaa epävarmoja markkinaosapuolia käyttämään ulkopuolista apua suunnitelman laadintaan. Tuleeko markkinaosapuolen rikastuttaa tiedot itse, jos esim. käyttöpaikoilla otetaan käyttöön uudet GS1-tunnukset? Vastaus: Kyllä, tarkka menettelytapa riippuu siinä tapauksessa GS1-tunnuksen käyttöönottomenettelystä, johon tietokonversioprojekti sopeutuu. GS1 käyttöönottoa on käsitelty prosessityöryhmässä ja tullaan käsittelemään vielä Fingridin tiedonvaihdon kehitysryhmässä sekä Energiateollisuuden tiedonvaihdon kehitysryhmässä. Tarkempi ohjeistus tehdään näiden jälkeen. 3.3 Tehtävät ja vastuut Miten Fingrid huomioi loppuasiakastiedottamisen? Vastaus: Fingridin näkemyksen mukaan loppuasiakastiedottaminen ei kuulu datahubin tietokonversiotyön laajuuteen. Järjestelmätoimittajille ohjeistus puuttuu. Sama tietopaketti kaikille järjestelmätoimittajille. Aineiston tuottamisen vastuu on Fingridillä. Vastaus: Järjestelmätoimittajille ei tehdä erillistä ohjeistusta. Tietokonversiosuunnitelma, siirtotiedostojen ohjeistus esimerkkitiedostoineen, tarkastussääntöjen kuvaus sekä tarkastusraporttien kuvaus kattavat myös järjestelmätoimittajien tarpeet. Lisäksi järjestelmätoimittajat liitetään tietokonversion tiedotuspiiriin.

17 17 (29) Tietokonversiojärjestelmän määrittely puuttuu. Vastaus: Tietokonversiojärjestelmän määrittely on osa järjestelmän hankintaa. Kaikkia projektin hallintaan ja määrittelyyn liittyviä ns. sisäisiä tehtäviä ei ole kuvattu tehtävälistaan. Onko tietokonversiokumppani tietokonversiojärjestelmän toimittaja? Vastaus: Voivat olla eri yrityksiä, mutta tietokonversiokumppanin toimittamat palvelut hankitaan tietokonversiojärjestelmän kanssa samassa hankinnassa. Mikä taho hankki luvan integraatioon VRK:n henkilötietopalveluun? Vastaus: Lupa edellyttää lainsäädännön muutosta. Datahub hankkii kun lainsäädäntö on valmis, edellyttäen, että uusi laki sallii VRK:n henkilötietopalvelun hyödyntämistä. 3.4 Aikataulu Onko tietokonversiojärjestelmä on valmis ottamaan vastaan ja analysoimaan pilottidataa ennen 12/2016? Vastaus: Ei ole, tietokonversiojärjestelmän hankinta on vasta käynnistymässä. Aikatauluja päivitetään kun toimittaja on selvillä. Kaksi kuukautta ei tule riittämään missään nimessään testaamiseen. Vastaus: Ei riitä, datahub-järjestelmä testataan monessa vaiheessa ja siihen tulee oma suunnitelmansa. Poistetaan datahubin testausjakso tietokonversiosuunnitelman aikataulukuviosta. Kakkoskierroksen aikataulua kannattaa vielä säätää joko ennen lomia tai sitten jälkeen. Vastaus: Aikataulua säädetään vielä kun tietokonversiojärjestelmän toimittaja on selvillä ja tarkennetaan pilottivaiheen aikana kun tietokonversioprosessista kertyy kokemuksia. Tuottavatko markkinaosapuolet aineiston samalta ajanhetkeltä? Tuottavatko markkinaosapuolet aineiston samalta ajanhetkeltä? Kuinka suuri aikamarginaali mahdollisesti annetaan aineiston tuottamiselle? Jos markkinaosapuolien aineistot on tuotettu eri ajankohtina, voi ristiriitoja olla eri osapuolien toimittamien aineistojen välillä; asiakastiedot voivat tulla useammalta myyjäyhtiöltä. Vastaus: Iteraatiovaiheessa 1 ja 2 sallitaan suurempi aikamarginaali, koska silloin aineisto tarkastetaan osapuolikohtaisesti. Iteraatiovaiheesta 3 lähtien tullaan koordinoimaan

18 18 (29) aineiston tuottamishetki, jotta koko aineisto olisi mahdollisimman samasta markkinatilanteesta. Iteraatiovaiheessa 4 aikamarginaalin tulee olla 1 2 päivän tasolla. Osa asiakastiedoista tulee joka tapauksessa useammalta myyjältä, koska samalla asiakkaalla voi olla useita sopimuksia voimassa (eri käyttöpaikoilla). Sen lisäksi tuodaan päättyneitä ja tulevaisuudessa alkavia sopimuksia, joten lähihistorian ja tulevaisuuden myyjän vaihdot tulevat näkymään aineistossa. Tämä on tietokonversion suurimpia haasteita, koska on odotettavissa, että asiakastiedot ovat osittain ristiriitaiset. 3.5 Pilottivaihe Saadaanko pilottivaiheen kokemuksia yleisesti markkinaosapuolten käyttöön? Vastaus: Saadaan. Fingrid viestii markkinaosapuolille projektin etenemisestä. Vakavuustason 1 ja 2 poikkeamat on korjattu tietokonversiojärjestelmässä. Tarkoittaako, että poikkeamat on korjattu ennen pilottivaihetta 1 vai sen jälkeen? Vastaus: Vakavat poikkeamat tulee korjata ja korjaukset tulee pystyä todentamaan pilottivaiheen aikana. Ei voida siirtyä varsinaiseen tietokonversiovaiheeseen, jos järjestelmässä on käytön estäviä tai oleellisesti haittaavia puutteita. Milloin pilottiyritykset valittiin ja miten voi osoittaa kiinnostusta ryhmään jäseneksi? Vastaus: Vuoden 2015 lopussa Fingrid pyysi Energiateollisuus ry:tä (ET) kartoittamaan ja nimeämään jäsenistöstään henkilöt pilottiryhmään siten, että ryhmään saataisiin 6 10 toimialan edustajaa. Ryhmä järjestäytyi helmikuun 2016 alussa ET:n toimittaman listan perusteella. Ryhmässä on edustajia eri markkinarooleissa toimivista, erikokoisista sekä eri ICT-järjestelmiä käyttävistä yhtiöistä. Ryhmään voidaan harkita uusia jäseniä sillä perusteella, että tietty ICT-järjestelmä ei ole edustettuna. Ryhmään ei valitettavasti voida hyväksyä järjestelmätoimittajia. Tällä hetkellä edustettuina ovat seuraavat ICT-järjestelmät (järjestelmätoimittaja): Forum (Tieto) Ellarex (Empower) Vertikaali (Enoro) CAB (Tieto) Kolibri (CGI) EllaEDM (Empower) GENERIS (Enoro) Rejlers EDM (Tieto)

19 19 (29) Onko pilottiyritysten valinnassa huomioitu, että yrityksillä on riittävästi käyttöpaikkoja, joilla on eri pilottiosapuolia myyjänä/verkonhaltijana, jotta voidaan testien kautta määrittää riittävät tarkistukset markkinatason tarkastusvaiheeseen? Vastaus: Pilottiryhmässä on useita erikokoisia myyjiä ja verkonhaltijoita ja tämä takaa, että riittävät yhdenmukaisuustarkastukset voidaan suorittaa. Testiympäristön päivitysajankohta täytyy olla ilmoitettuna hyvissä ajoin. Yhtiöillä voi olla omia testaus prosesseja yms. menossa ja sovittuna. Vastaus: Tavoiteajankohdat koordinoidaan työryhmässä, jossa kaikki pilottiyritykset ovat edustettuina ja tullaan viestimään toimialalle hyvissä ajoin. Miten käsitellään puuttuvat tiedot? Esim. henkilötunnus ei voine olla pakollinen konversio tiedoissa. Vastaus: Puuttuvista tiedoista kirjoitetaan virherivi virheraporttiin. Pilottivaiheessa markkinaosapuolen tulee korjata puutteet, jotka aiheuttavat koko tiedoston hylkäämisen tai jos puute on niin mittaava, että tiedoille ei voida suorittaa järkeviä tarkastuksia. Henkilötunnus ei ole pakollinen. Miksi mittaustietoja ei tarkasteta pilottivaiheessa? Vastaus: Mittaustietojen tarkastusta varten tarvitaan datahub-järjestelmä, joka ei ole vielä olemassa tietokonversion pilottivaiheessa. Mittaustietoa ei ole tarkoitus tuoda tietokonversiojärjestelmään ollenkaan. Mittaustietoja on kuitenkin tarkoitus toimittaa jo pilottivaiheessa, joten onko niille aikomus tehdä jonkinlaisia tarkastuksia ennen datahubiin siirtämistä? Vastaus: Pilottivaiheessa halutaan saada tietoa mittaustietojen poiminnan suorituskyvystä. Varsinaisia tietojen tarkastuksia ei suoriteta. Tarkastussäännöistä pitää saada tiedot, joita vasten omia tietoja voi tarkastaa. Vastaus: Pilottivaiheen aikana julkaistaan dokumentti, jossa tarkastussäännöt on kuvattu.

20 20 (29) 3.6 Datahubin toteutusvaihe Onko jossain määritelty miten pitkään lähdeaineiston poiminta saa kestää? Onko aika isoille ja pienille markkinaosapuolille sama vai esim. käyttöpaikkojen lukumäärään suhteutettu? Vastaus: Sama vaatimus isoille ja pienille ja se on asetettu markkinatasolla. Datahubin näkökulmasta sillä ei ole merkitystä, onko käyttöpaikkoja paljon vai vähän, kaikkien on toimitettava tiedot vaaditussa ajassa. Miksi tietokonversioon liittyvä ohjeistus pitää olla valmiina vasta tarkistuspisteessä T0? Vastaus: Varaudutaan siihen, että ohjeistus tarkennetaan pilottivaiheessa, koska vaiheen aikana syntyy paljon uutta tietoa. Alustavaa ohjeistusta tullaan julkaisemaan jo aiemmin. Miksi tarvitaan niin monta iteraatiovaihetta? Iteraatiomäärä on pelkän migraation kannalta varsin suuri ja aiheuttaa kustannuksia. Vastaus: Vaiheiden jako perustuu tarkistuspisteisiin, joissa halutaan varmistaa, että 1) Osapuolet pystyvät toimittamaan pakolliset tiedot oikeassa formaatissa, 2) Osapuolten omat tiedot ovat ehjät, 3) Osapuolten toimittamat tiedot ovat keskenään yhdenmukaiset, 4) Osapuolet pystyvät toimittamaan tiedot riittävän samanaikaisesti ja 5) Datahub voidaan ottaa tuotannolliseen käyttöön. Vaiheiden määrä on linjassa esim. norjalaisten Elhubin tietokonversiosuunnitelman kanssa. Voidaanko tietojen yhdenmukaisuustarkastusta aikaistaa? Tietokonversion iteraatiovaiheessa 2 mainitaan, että tavoitteena on tehdä viite-eheystarkastukset markkinaosapuolen lataamien tietojen välillä. Toimenpiteissä on kuitenkin iteraatiovaihetta 1 vastaava prosessi, jonka mukaan tarkistuksia toteutetaan vain markkinaosapuolen omiin tietoihin ja koko aineiston tarkistusraportti saataisiin iteraatiovaiheen 3 aikana. Tietojen siivouksen aikataulun kannalta olisi hyödyllistä tutkia, onko koko aineistosta mahdollista saada toimitetuksi raporttia markkinaosapuolelle jo vaiheen 2 aikana. Vastaus: Oletuksena on, että markkinaosapuolten toimitusvalmius on eri tasolla tässä vaiheessa. Yhdenmukaisuustarkastukset edellyttävät, että tietokonversiojärjestelmässä on kaikkien osapuolten tiedot. Jossain vaiheessa päästään siihen tilanteeseen myös tässä iteraatiovaiheessa, mutta eriaikaisten toimitusten johdosta on olemassa riski, että tarkastustulokset eivät ole täysin luotettavia, siitä syystä emme ole asettaneet yhdenmukaisuustarkastusta tavoitteeksi vielä tässä vaiheessa.

21 21 (29) Miksi mittaustietoja ei validoida tietokonversion iteraatiovaiheessa 1? Vastaus: Mittaustietoa ei tuoda tietokonversiojärjestelmään vaan suoraan datahubjärjestelmään, jossa suoritetaan mittaustiedon tarkastuksia. Tietokonversion iteraatiovaiheessa 1 datahub-järjestelmä ei ole vielä käytettävissä. Otetaanko tiedot markkinaosapuolten tuotantojärjestelmistä vai pitääkö testijärjestelmät tuoreuttaa tuotantoympäristöistä ennen iteraatiokierrosta? Vastaus: Tietokonversion iteraatiovaiheissa 1 3 tiedot otetaan testijärjestelmistä, joiden tietoja tulee päivittää tuotannosta ennen iteraatiovaiheen alkua. Iteraatiovaiheen 4 tavoite on käyttöönoton simulointi, mikä tarkoittaa että markkinaosapuolten poimintatyökalujen tulee olla valmiit ja että tiedot tulee poimia tuotantoympäristöstä. Miten tarkastussäännöissä voi olla poikkeamia? Konversiotyökalussa voi olla poikkeamia, samoin siirretyissä tiedoissa, mutta mitä tarkoittaa, että tarkastussäännössä on poikkeama? Vastaus: Osa tarkastussäännöistä tulevat olemaan huomattavan monimutkaisia ja on mahdollista, että huomataan tarkastussäännön olevan toteutettu väärin tietokonversiojärjestelmään. Tarkastussäännöt konfiguroidaan lähtökohtaisesti tietokonversiojärjestelmään, ne eivät ole osa ohjelmistoa, virheellisesti toimiva sääntö ei välttämättä tarkoita ohjelmistovirhettä. 3.7 Käyttöönotto Riittääkö kolme päivää tietoliikennekatkoon valmistautumiseen? On huomioitava että, esim. myyjänvaihtoprosessi voi kestää yli 3 kuukautta. Jouduttaneen huomioimaan ainakin keskeneräisten sopimusprosessien käsittely. Kolme päivää ei riitä tietoliikennekatkoon valmistautumiseen, mikäli sen aikana on tarkoitus suorittaa keskeneräiset prosessit loppuun. Entä kuinka toimitaan, jos prosessia ei saada päätettyä itsestään riippumattomista syistä (esim. myyjä ei saa verkonhaltijalta Z04 -sanomaa)? Perutaanko tuolloin keskeneräiset prosessit? Vastaus: Varsinainen tarve on se, että markkinoiden tiedot ovat yhdenmukaiset, eli kaikilla osapuolilla on samat perustiedot. Myyjänvaihtoprosessi, joka odottaa joskus tulevaisuudessa toimitettavaa mittausarvoa ei ole ongelmaa tietokonversion näkökulmasta. Nykyisten markkinasääntöjen mukaan PRODAT-sanomat on vietävä sopimusprosessin osalta läpi viidessä päivässä (myyjänvaihto). Ajatuksena on, että läpimenoaikoja voidaan hieman kiristää datahubin käyttöönoton yhteydessä. Poikkeusten hallinta yms. tullaan

22 22 (29) määrittelemään erillisessä käyttöönottosuunnitelmassa. Lähtökohtaisesti on epärealistista ajatella, että pääsemme 100-prosenttiseen tilanteeseen liiketoimintaprosessien osalta. Saisiko käyttöönottoaikaa lyhennettyä? Vastaus: Käyttöönottoaika on hahmotettu tanskalaisten kokemusten ja norjalasten suunnitelman perusteella. Emme pidä realistisena, että käyttöönottoaikaa voidaan lyhentää merkittävästi. Miten taataan suorituskyky? Vastaus: Pilottivaihe mitoitetaan siten, että pystymme suorittamaan luotettavia suorituskykytestejä. Tietokonversiovaiheen aikana meillä on mahdollisuus optimoida tietokonversiojärjestelmän suorituskykyä ja tavoitteeseen on päästävä iteraatiovaiheessa 3. Onko käyttöönotolla varasuunnitelma? Vastaus: Varasuunnitelma tehdään datahubin varsinaisessa käyttöönottosuunnitelmassa, joka ei kuulu tietokonversion laajuuteen. Tietokonversion osalta varasuunnitelmaan palataan silloin, kun meillä on käytännön kokemuksia prosessista. Katkon aikainen ohjeistus on tultava toimialalta ja sovittava tarkemmat aikataulut yhtiökohtaisesti esim. lataukselle Vastaus: Tietokonversiojärjestelmä mitoitetaan siten, että kaikki osapuolet voivat toimittaa tiedot samanaikaisesti. Yhtiökohtaiset aikataulut olisivat liian työläitä hallita, eivätkä toisi lisäarvoa prosessille. Mitä tarkoittaa että "tapahtumat kertyvät jonoon"? Vastaus: "Jono" on käsitteellinen termi tässä yhteydessä. Tarkoittaa, että emme voi estää kuluttajia muuttamasta ja tekemästä sähkösopimuksia datahubin käyttöönoton ajaksi. Käyttöönoton aikana syntyneitä tapahtumia ei voida käsitellä tiedonvaihtoprosesseissa, vaan ne on säilytettävä tavalla tai toisella kunnes tietoliikenne datahubiin avataan. Datahubin käyttöönotto on iso kokonaisuus, josta tietokonversio on vain osa. Käyttöönotosta tehdään oma erillinen suunnitelma. Koko tietokonversioprosessin läpiviemiseen käytettävä aika määriteltävä harkitusti huomioiden isojen yhtiöiden laajat aineistot Vastaus: Viime kädessä se on datahubin käyttöönottoprosessi, joka asettaa reunaehdot tietokonversion suorituskyvylle. Tämän hetken näkemyksemme mukaan tietokonversioon on aikaa noin viikko, mikä perustuu oletukseen, että markkinakatko voi olla korkeintaan kaksi viikkoa.

23 23 (29) 4 Tietokonversiojärjestelmä 4.1 Komponentit ja rajapinnat Miksi siirtotiedostojen muodoksi on valittu xlsx? Mitä Excel-versiota on käytettävä ja millaisen Excel-tiedoston raportti palauttaa? Tietojen käsittely hankaloituu huomattavasti, kun tietoja on käsiteltävä Excel-muodossa. Onko mahdollisuutta tarjota rinnalle toista dataformaattia, esim. yksinkertaisempi csv-muoto? Mikä lisäarvo tulee xlsx:n käytöstä? Vastaus: Pysytään xlsx -formaatissa. Perustelut: markkinoilla on iso määrä osapuolia ja iso määrä erilaisia järjestelmiä, mikä lähtökohtaisesti puoltaa standardiformaatin käyttöä csv (comma separated value) ei ole standardiformaatti. Se, että moni järjestelmä tukee csv-muotoa, ei tarkoita että ne pystyvät kirjoittamaan mitä tahansa csv-muotoa. xlsx on Office Open xml formaatti, joka on ISO:n ja IEC:n standardoima (ISO/IEC 29500) xlsx ei ole yhtä kuin Excel, eikä se ole sidottu Excel-versioon. Excel käyttää sitä versiosta 2007 eteenpäin, mutta sitä käytetään myös muissa sovelluksissa. xlsx tiedostoja ei ole siis pakko generoida Excelin (tai Microsoftin) komponentilla. xlsx on edistyksellinen formaatti, joka käytännössä pakottaa käyttämään standardikomponenttia tiedostojen luonnissa ja luennassa, mikä osaltaan vähentää virheiden ja variaatioiden riskiä tiedostojen luonnissa. Lisäksi: csv-formaatti ei ole kovin helppo lukea ja muokata yksinkertaisessa tekstieditorissa, vaan siihen käytetään usein juuri Exceliä, joten Excelin taipumus muuntaa tietoa näkyisi myös vaikka käytettäisiin csv-formaattia Mikä on siirtotietokannan rooli? Ainoastaan välivarasto? Jos kyllä, niin miksi se on tietokanta? Mikä osapuoli vastaa suorituskyvystä jne? Vastaus: Siirtokanta (muutetaan julkaisualueeksi) on alue, johon viedään datahubiin siirrettävät tiedot. Julkaisualueeseen ei viedä tarkastusprosessissa hylättyjä tietoja. Lähtökohta on, että kaikki julkaisualueeseen siirretyt tiedot ladataan myös datahubiin. Datahubin tuottamia tietokonversioraportteja verrataan julkaisualueella oleviin tietoihin, jotta voidaan varmistaa, että tiedot siirtyivät oikein datahubiin. Suorituskyvystä vastaa tietokonversiojärjestelmän toimittaja. Onko siirtokannasta lukeminen välttämätöntä? Vastaus: Siirtokanta on tässä vaiheessa käsitteellinen komponentti (muutetaan "julkaisualueeksi"). Julkaisualue on paikka, johon julkaistaan tiedot datahub-järjestelmään

24 24 (29) latausta varten. Aineisto tullaan siirtämään tietokonversiojärjestelmästä datahubiin tiedostomuodossa. 4.2 Tiedostojen tuonti Onko oletuksena, että tiedostot käsitellään rivikohtaisesti eli puutteelliset/virheelliset rivit eivät keskeytä tuontia? Vastaus: Tiedostot käsitellään rivikohtaisesti, puutteelliset rivit eivät keskeytä tietojen tuontia. Hylätyt tiedot kirjataan tarkastusraportteihin. Toki voi olla tilanteita, jolloin koko tiedosto hylätään, esimerkiksi jos sarakkeiden nimet eivät vasta siirtotiedostotyypin määrittelyä, jos tiedostomuoto ei ole xlsx tai jos tavuesitys ei ole UTF-8. Tuotujen rivien määrän lisäksi pitäisi näyttää mahdolliset hylätyt rivit ja näiden tunnistaminen (rivinumero). Vastaus: Hylätyt rivit kirjoitetaan tarkastusraportteihin. 4.3 Tietojen tarkastus Miten prosessissa on ajateltu toteuttaa esim. jakeluverkonhaltijan tietojen täydentäminen muiden myyjäyhtiöiden tuottamalla datalla? Miten prosessissa on ajateltu toteuttaa esim. jakeluverkonhaltijan tietojen täydentäminen muiden myyjäyhtiöiden tuottamalla datalla (esim. sähköpostiosoitteet, puhelinnumerot)? Onko konversiossa vielä lopuksi vaihe, jolla jakeluverkonhaltija saa ladattua tiedot massana omista sopimusasiakkaistaan, saako jakeluverkonhaltija lisätietoja validointiraporteissa vai kyselläänkö tietoja datahubista prosessin jälkeen asiakaskohtaisesti? Vastaus: Menettelytavat ovat vielä määrittelemättä. Tähän liittyy monta ulottuvuutta, esim. 1) Tiedon oikeellisuus on vaikea päätellä tietokonversiojärjestelmässä, 2) Tietosuojasyistä henkilötietoja ei voida jakaa markkinaosapuolten välillä ja 3) Kilpailusyistä asiakastietoja ei voida jakaa markkinaosapuolten välillä tietokonversiojärjestelmän toimesta. Tietokonversiojärjestelmä ei tule tarjoamaan pääsyä muiden osapuolten toimittamiin tietoihin tai niissä oleviin virheisiin. Millainen rooli kullakin valitulla rekisterillä vertailussa tai mahdollisessa tiedon rikastamisessa on? Vastaus: a. Yritysrekisteri ja yhdistysrekisteri:

25 25 (29) - Tarkistetaan asiakkaan nimi y-tunnuksen perusteella. Palautetaan korjausehdotus, mikäli tiedot eivät täsmää - Haetaan y-tunnus nimen perusteella, mikäli y-tunnus puuttuu lähdetiedoista. Palautetaan y-tunnus mikäli se löytyy. b. Väestörekisteri (ei voida toteuttaa nykyisen lainsäädännön puitteessa) c. Postin osoiterekisteri - Tarkistetaan että 1) Katuosoite, 2) Postinumero ja 3) postitoimipaikka löytyvät postin osoiterekisteristä. Palautetaan virhe mikäli tiedot eivät täsmää. On vielä epäselvä, jos pystymme luomaan korjausehdotuksia koneellisesti tässä tapauksessa. Tarkistetaanko, että Y-tunnus ja yrityksen nimi vastaavat toisiaan? Vastaus: Kyllä, tarkistetaan asiakkaan nimi y-tunnuksen perusteella. Palautetaan korjausehdotus mikäli tiedot eivät täsmää. Tullaanko väestörekisteriä käyttämään kuitenkin tietojen tarkastamiseen? Vastaus: Varaudutaan käyttämään kun datahubia koskeva lainsäädäntö on valmis. Ennen sitä ei voida toteuttaa rajapintaa väestörekisteriin. Onko käynnissä selvitys, että markkinaosapuolet voisivat hyödyntää väestörekisteriä omassa tietojen siivouksessaan datahub-hanketta varten? Vastaus: Asia on selvitetty. Nykylainsäädäntö ei anna markkinaosapuolille oikeutta täydentää henkilötietoja väestörekisteriä hyödyntämällä, eikä poikkeuslupaa anneta, joten markkinaosapuolten tulee täydentää tiedot omin voimin. Tehdäänkö markkinatason sääntöjen tarkistus prosessin vaiheessa 3? Vastaus: Suoritetaan kaikki tarkastukset paitsi siirtotiedoston syntaksiin liittyvät tarkastukset, jotka ajetaan siirtotiedoston tuonnin yhteydessä. Miksi varaudutaan kytkemään joitakin tarkastuksia pois päältä? Tämä on kyllä aika vaarallinen juttu. Varsinaisella tietokonversiokierroksella on nimenomaan tarkistettava, että kaikki tiedot ovat kunnossa ennen tuotantokonversiota (tietokonversioiteraatio 5). Pilottivaiheessa voidaan jättää asioita tarkastamatta. Tietokonversiokierroksella suorituskyky pitää olla vain parempi. Ehkä tuotantokonversiossa voidaan jättää joku tarkastus tekemättä, jotta aineistot saadaan nopeasti ladattua datahubiin, edellyttäen että tietokonversiokierroksella tiedot on tarkastettu hyväksytysti, vaikka se siellä veisi sitten pidempään. Tässä voisi jakaa vielä noita iteraatioita eri tasoihin. Käytännössä 3/4 kierroksella pitää kyllä kaikki asiat tarkistaa, jos haluaa, että datahub toimii. Toki jos huomataan jonkun säännön olevan turha, niin se voidaan poistaa, mutta toimintojen kannalta olennaisten sääntöjen tarkistusta ei kannata jättää tekemättä.

26 26 (29) Vastaus: Tietokonversiotyössä erotetaan osapuolten tietojen yhdenmukaistaminen ja datahubin alkulataus. Yhdenmukaisuustyössä voidaan hyödyntää ulkopuolisia rekistereitä yms., mutta ei voida odottaa että liitynnät ulkopuolisiin rekistereihin tarjoavat riittävää suorituskykyä datahubin käyttöönottolataukselle. Toisaalta on myös raskaita tarkastuksia, joita ei voida kytkeä pois päältä missään vaiheessa, esim. aikavälien tarkastukset ja duplikaattitarkastukset. Pitää myös muistaa, että yksi iteraatiovaihe ei tarkoita yhtä toimitusta. Yhden iteraatiovaiheen aikana voidaan suorittaa monta toimitusta, joille ajetaan kaikki tarkastussäännöt mukaan lukien rekisteritarkastukset. 4.4 Raportointi Poistetaanko iteraatiovaiheiden jälkeen siirtotiedostojen tietojen lisäksi myös raportit? Vastaus: Poistetaan kaikki henkilötiedot, joten myös tarkastusraportit, koska ne sisältävät henkilötietoa. Tietokonversiojärjestelmä ei ole henkilötietorekisteri, joten henkilötietojen säilyttäminen ei ole sallittua. Yhteenvetoraportit voidaan säilyttää. Datahub-järjestelmään tehtävien pistokokeiden laajuus on määriteltävä tarkemmin. Vastaus: Täsmällinen määrittely on mahdollinen tehdä vasta kun datahub-järjestelmä on olemassa. Miten korjausehdotusdokumentti linkitetään tietoihin, joita on tarkoitus massakorjata? Vastaus: Tarkastusraportti on poikkeamaraportti, joka sisältää kaikki havaitut virheet ja poikkeamat. Raporttiin kirjoitetaan alkuperäinen tieto, virhetyyppi sekä mahdollinen korjausehdotus. Tietokonversiojärjestelmä pystyy vain joissakin tapauksissa antamaan korjausehdotuksia. Fingrid ei velvoita markkinaosapuolia suorittamaan korjauksia koneellisesti. Miten toimitaan vielä konversion jälkeenkin jääneiden kriittisten virheiden osalta? Vastaus: Virheet on ensisijaisesti hoidettava datahubin rajapintojen kautta. Eikös käyttöönoton laatuvaatimusten pitäisi olla 100% Vastaus: Ei ole realistista edellyttää 100 % laatua. Tietojen laatu markkinoilla ei ole tälläkään hetkellä 100 %.

27 27 (29) Kaikki datahubiin ladatut omat tiedot pitäisi olla mahdollista hakea esimerkiksi csv/excel -muodossa omia eheystarkasteluja varten? Onko olemassa työkalu, jolla voidaan varmistaa, että kaikki tiedot ovat siirtyneet datahubiin? Vastaus: Tietokonversioprosessia muutetaan sillä tavalla, että datahubilta vaaditaan ns. osapuolikohtaiset tietokonversioraportit xlsx-muodossa. Raportit julkaistaan osapuolille tietokonversiojärjestelmän kautta. Datahubin tietokonversioraporttien avulla osapuolet voivat tarkistaa, että datahubiin ladatut tiedot vastaavat lähdejärjestelmässä olevia tietoja. Tietokonversion loppuraportti. Kuka raportoi ja kenelle? Vastaus: Fingrid raportoi markkinaosapuolille ja datahub-toimittajalle. Kenelle markkinaosapuolten pitää raportoida pistokokeiden tuloksista ja miten? Vastaus: Raportoivat Fingridille, raportointitapa on vielä määriteltävä. Korjaako konversiojärjestelmän toimittaja tietokonversiojärjestelmän ja datahubin välistä yhteyttä? Vastaus: Tietokonversiokumppani vastaa tietojen julkaisusta julkaisualueelle ja siitä, että julkaisualue on datahubin käytettävissä. Datahub-toimittaja vastaa tietojen latauksesta julkaisualueelta. Tietokonversiojärjestelmän toimittaja korjaa julkaisuprosessissa havaitut virheet ja datahub toimittaja latausprosessissa havaitut virheet. Kenelle tietokonversioraportit tehdään, kuka niitä lukee ja mitä tiedoilla tehdään? Vertaavatko markkinaosapuolet raportteja lähdejärjestelmiensä tietoihin? Vastaus: Tietokonversiojärjestelmälle ja markkinaosapuolille. Raporttien avulla tietokonversiojärjestelmä tarkistaa, että julkaistu lähdeaineisto vastaa datahubissa olevia tietoja. Markkinaosapuoli voi vastaavasti tarkistaa, että datahubiin ladatut tiedot vastaavat lähdejärjestelmässä olevia tietoja. 4.5 Tietojen julkaisu Julkaistaanko tiedot datahubiin ensimmäisen kerran vasta iteraatiovaiheen 3 jälkeen? Vastaus: Kyllä. Nykysuunnitelman mukaan meillä ei ole datahub-järjestelmää käytettävissä ennen sitä.

28 28 (29) 4.6 Tietojen siirtäminen datahubiin Kenellä on vastuu tiedon oikeellisuudesta, tai siitä että kaikki tiedot siirtyvät? Vastaus: Datahub-toimittaja vastaa siitä, että kaikki julkaisualueella olevat tiedot ladataan datahubiin. Datahub toimittaa tietokonversioraportteja takaisin tietokonversiojärjestelmään, jossa tarkistetaan että datahubissa olevat tiedot vastaavat julkaisualueella olevia tietoja. Datahubin tietokonversioraportit julkaistaan myös markkinaosapuolille. Markkinaosapuolet vastaavat tiedon oikeellisuudesta suhteessa lähdejärjestelmiin. 4.7 Suorituskykyvaatimukset Ladattavan / käsiteltävän tiedon määrä on epäselvä Yhtiöillä on erisuuruisia putkia tiedoston siirtämiseksi. Vastaus: Tietokonversiosuunnitelmassa ei oteta kantaa tietojen määriin. Käytännössä on niin, että suorituskykyvaatimukset ovat yhtiökohtaiset. Isolla yhtiöllä on yhtä paljon aikaa toimittaa tietoja kuin pienelläkin, mikä tarkoittaa, että ison yhtiön poimintatyökalujen tulee olla tehokkaimpia kuin pienen yhtiön. Suorituskykytaulukon tarkoitus on hahmottaa suorituskykyvaatimuksia koko tietokonversioprosessille. Lukiessa on huomioitava että prosessi kattaa useita järjestelmiä ja eri asioita (poiminta, lataus, validointi, raportointi). 4.8 Seuranta Jos yhdenmukaisuustarkastuksessa huomataan virheitä, miten niistä ilmoitetaan? Vastaus: Järjestelmä luo osapuolikohtaiset virheraportit ja lähettää sähköpostitse ilmoituksen, että tarkistus on valmis ja virheraportti on saatavilla. Tiedot voidaan aina yhdistää osapuoleen, vaikka tarkistusta ei tässä vaiheessa tehdä tiedostokohtaisesti tehokkuussyistä. Onko datastandardissa myös kenttä, johon tuonnin virheet merkitään? Vastaus: Datastandardissa ei löydy kenttää virheitä varten, vaan virheet kuvataan tietokonversiojärjestelmän tuottamiin virheraportteihin. Virheraporttien tarkka määrittely tehdään yhdessä järjestelmätoimittajan kanssa. Lisätään raporttien alustava tietosisältö suunnitelmaan.