Pöytäkirja 1 (7) Prosessityöryhmän kokous 5.4.2019 Aika 5.4.2019 klo 8.30 14.30 Paikka Duetto Business Park, Läkkisepäntie 23, 00620 Helsinki nh. Kuolajärvi Läsnä Marjut Puukangas (pj.) Emmi Kaivosoja Teemu Hellas (siht.) Esa Pietarinen (Skype, kohdassa 5) Tiina Leppälahti Helen Sähköverkko Oy Emma Mäki-Kala Elenia Oy Jari Rusanen Loiste Sähköverkko Oy Pia Aaltonen Fortum Markets Oy Satu Kortesmäki Caruna Oy Poissa Tero Vänttilä Väre Energia Oy 1 Kokouksen avaus ja edellisen kokouksen muistio Puheenjohtaja avasi kokouksen klo. 8.39. Puheenjohtaja läpikävi viime kokouksen (13.2.2019) pöytäkirjan. Edellisen kokouksen pöytäkirjan osalta ei noussut esiin kommentteja ja pöytäkirja hyväksyttiin. Sovittiin, että edellisessä skype-kokouksessa läpikäytyjä ja sovittuja asioita tuodaan käsiteltävien asioiden taulukosta tämän pöytäkirjan osaksi. 2 Lyhyt katsaus projektiin Tietokonversio 1. vaihe päättyy toukokuun lopussa. Lähes kaikki osapuolet ovat tehneet tietokonversio sopimuksen. Sopimus puuttuu tällä hetkellä yhdeltä suljetulta jakeluverkolta ja kolmelta myyjältä. Tiedon laatu Titta-palvelussa on parantunut tammikuun lopun jälkeen kiitettävästi. Titan seurantapalvelussa käyttöönottosuunnitelmien täyttämistä on aloittanut 196/218 osapuolesta. Uusia kysymyksiä on päivitetty viimeksi 4.4.2019. Järjestelmätoimituksen osavaihe 1 on testattu CGI:n toimesta ja toimitettu Fingridin testaukseen. Testaus on edennyt hyvin. Virheitä ja puutteita on löytynyt, mutta kokonaisuutena järjestelmän toiminta vakuuttaa. Seuraava osavaihe saadaan Fingridin testaukseen toukokuussa. Järjestelmätoimittajien testiympäristö on valmis ja yhteystestaukset alkavat 9.4. Pilottitestauksesta heräsi kysymyksiä. Mm. miten verkko voi testata myyjältä tulevaa käyttöpaikan päivityspyyntösanomaa. Puheenjohtaja lupasi viedä tämän kysymyksen eteenpäin projektissa. Demottiin järjestelmän ensimmäistä versiota. Käyttöpaikka luotiin rajapinnan kautta, jonka jälkeen käyttöpaikka haettiin käyttöliittymästä ja tehtiin sille kytkentä.
Pöytäkirja 2 (7) 3 Osoiterakenne eri käyttötarpeisiin Käytiin läpi esimerkkejä ja niiden käyttöä eri osoitteiden rakenteista. Todettiin, että osoitteiden käytöstä, esimerkiksi rivitalojen, olisi hyvä olla ohjeistus. Rivitalossa asunnon kirjain kirjataan porrastunnus-kenttään, eikä huoneisto-kenttään. Tarkenne-kentällä haku olisi hyvä lisätä hakusanomaan. Esimerkiksi katuvalokäyttöpaikoillla ei ole välttämättä tarkkaa osoitetta, vaan katuvalon tunnus merkitään tarkenne-kenttään. Osoiterakenteen kenttien nimeämisestä käytiin keskustelua, mm. porrastunnus ei kuvaa kentän käyttöä hyvin. Todettiin, ettei nimeämistä kannata muuttaa, vaan ohjeistetaan eri kenttien käyttö. Tietokonversiosta nousseiden osoiterakennekysymysten osalta todettiin, että osoiterakenneohjeesta löytyy esimerkit osoitteiden käytöstä. Muistutetaan osoiterakenneohjeen käytöstä. Huoneisto kentän pituutta tullaan kasvattamaan kymmeneen merkkiin. Todettiin, että porrastunnus kentän pituutta kasvatetaan myös kymmeneen merkkiin. Puolustusvoimien käyttöpaikoista on tullut pyyntö, ettei laskuilla näkyisi osoitteita. Puolustusvoimien kanssa on aiemmin käyty keskustelua Datahubin toimesta ja silloin on todettu, ettei osoitetiedolle tarvitsisi tehdä mitään. Koordinaattitiedot ja asiakastiedot tulisi olla salaisia. Puukangas on yhteydessä Datahubin puolesta Hansel Oy:n ja selvittää onko puolustusvoimilla vaatimuksia Datahubin suuntaan osoitteiden käsittelyn osalta. Energiateollisuudelta pyydetään ohjeistusta uuden lain muutoksista puolustusvoimien osalta. Energiateollisuus on tehnyt selvityksen tyyppikäyttäjistä. Selvityksen lopputuloksena on tehty uusi lista tyyppikäyttäjistä. Rusanen välittää selvityksen prosessityöryhmän jäsenille. 4 Peruutustapahtumien tarkennusta Peruutustapahtumia on käyty CGI:n kanssa läpi. Alun perin oli suunniteltu, että käytössä olisi yleinen peruutustapahtuma. Läpikäynnin yhteydessä on todettu, ettei yleinen peruutustapahtuma toimi yksinkertaisesti, vaan peruutuksille tarvitaan tapahtumakohtaisia sääntöjä. Peruutuksille, jotka oli tarkoitus tehdä yleisellä peruutustapahtumalla, on tehty ehdotus omista peruutustapahtumista. Asiakastietojen osalta DH-111 peruutettaisiin ilmoittamalla uusi asiakastietojen päivitys. Käyttöpaikkatietojen osalta käyttöpaikan luonnin voi peruuttaa käyttöpaikan poistolla, jos käyttöpaikalla ei ole sopimustapahtumia. Käyttöpaikkatietojen päivitys tapahtuma peruutetaan ilmoittamalla uusi päivitys. Käyttöpaikan poistoa tai myyjän lähettämää käyttöpaikan päivityspyyntöä ei voi peruuttaa. Poistetun käyttöpaikan tilalle tulee luoda uusi käyttöpaikka eri GSRN-tunnuksella. Myyjän päivityspyynnön osalta tulee lähettää uusi päivityspyyntö tai olla tarvittaessa yhteydessä jakeluverkonhaltijaan. Työryhmäläiset kommentoivat, että käyttöpaikan poiston peruutus tulisi olla mahdollista virheiden varalta. Operaattori voisi esimerkiksi peruuttaa käyttöpaikan poiston. Käyttöpaikan luonnin peruutus tulisi olla myöskin mahdollista tilanteissa, joissa verkko esimerkiksi virheellisesti ilmoitta veroero- tai takamittauskäyttöpaikan, jota ei kuitenkaan tulisi poistaa jakeluverkon omasta järjestelmästä. Tähänkin tulisi luoda operaattorin oma prosessi, jossa verkkoyhtiön ei tarvitsisi lähettää poistotapahtumaa, eikä siitä lähtisi poiston vahvistusta verkkoyhtiön järjestelmään. Sopimustapahtumien osalta uudelle sopimukselle ja verkkosopimuksen vahvistukselle on jo omat peruutustapahtumat. Myynti- ja verkkosopimusten päivitysten peruutukset tehdään tekemällä uudet sopimuksen päivitykset. Myynti- ja verkkosopimusten päättämisille
Pöytäkirja 3 (7) luodaan uudet peruutustapahtuma DH-351 ja DH-352. Päättämisen voi perua ainoastaan kuluvalle päivälle tai tulevaisuuteen, jo päättyneen sopimuksen päättämistä ei voi peruuttaa. Ehtona on, että käyttöpaikalle ei saa olla uusia sopimuksia alkamassa sopimuksen päättämisen jälkeen. Sisäänmuuttokohteen myyjän ulosmuuttoilmoitus asiakkaan käyttöpaikalle tapahtumaa ei voi perua, vaan silloin myyjän tulee olla yhteydessä jakeluverkonhaltijaan. Sopimuksen peruuttamisia ei voi perua. Myyntisopimuksen peruminen takautuvasti taseikkunan sulkeuduttua. Uuden sopimuksen peruneelle myyjälle jää tasevastuu ja mahdollisesti myös sopimustieto voimaan taseikkunan ulkopuoliselta ajalta. Myyntisopimus palautetaan vanhalle myyjälle taseikkunan alusta alkaen. Tähän liittyen esimerkiksi prosessidokumentin sopimusperuutusten esimerkkiä 2 tulee tarkentaa. Jos alkuperäisen edeltävän sopimuksen ja voimaan palautettavan sopimuksen väliin on jäämässä katkos, tätä ei käsitellä datahubissa yhtenä sopimuksena, vaan kahtena erillisenä sopimuksena. Myyjä ilmoittaa jälkimmäisen osan erillisenä sopimuksena datahubiin. Myyntisopimuksen perumisessa tulisi tarkentaa syykoodeja, jotta vanha myyjä voisi päätellä onko hänen vanha sopimuksensa palautettu voimaan, vai tarvitseeko hänen ilmoittaa uusi sopimus datahubiin, jos haluaa asiakkaan takaisin myyntiinsä. Kytkentä- ja katkaisupyyntö myyjältä tapahtumille luodaan peruutustapahtumat DH-414 ja DH-424. Vain pyynnön johon ei olla vielä vastattu kytkentä-/katkaisuilmoituksella voi perua. Katkaisupäivänä katkaisupyynnön peruutus tehdään kytkentäpyynnöllä, kuten on prosessidokumentissa kuvattu. Kytkentäpäivänä kytkentäpyynnön peruutus ei ole enää mahdollista. Tällöin myyjän tulee olla yhteydessä jakeluverkonhaltijaan. Tämän osalta Datahubiin tulee vielä miettiä aikarajat kytkentä- ja katkaisupyyntöjen peruutukselle ottaen huomioon peruutuksen vaikutus tasevastuuseen. Kytkentä- ja katkaisuilmoitukselle lähetetään perumisen sijaan vastakkainen katkaisu- tai kytkentäilmoitus. Viivästysilmoituksia ei peruuteta. Osapuolen ilmoittamaa valtuutusta ei peruuteta, vaan valtuutukselle asetetaan päättymisaika. Tulevaisuudessa alkavan valtuutuksen voi päivittää päättymään samalla ajanhetkelle kuin alkamisaika, jolloin se ei tule koskaan voimaan. Jo alkaneen valtuutuksen voi päättää kuluvalle päivälle. 5 Tuotetietojen käsittelyn tarkennusta Tuotetietojen ylläpitoon on tällä hetkellä määritelty yksi tapahtuma. Samalla päivityksellä päivitettäisiin rakenteelliset tiedot, hinnat sekä hinta-aikasarjat. Nykyinen prosessi on raskas ja eri tiedoille on erilainen päivityssykli. Ehdotus on, että tapahtuma jaetaan neljään eri tapahtumaan: tuotetiedon luonti, rakenteellisen tiedon päivitys, hintojen päivitys, ja hinta- ja kalenteri-aikasarjan päivitys. Tuotetiedon luonnissa voidaan tuotteen rakenteelliset tiedot ilmoittaa ilman hintatietoja. Hinta- ja kalenteriaikasarjojen päivitys toimisi vastaavasti kuin mittaustietojen ilmoitus, eli voidaan ilmoittaa vain uudet ja muuttuneet tiedot. Rakenteellisten tietojen osalta ilmoitetaan aina koko tuoterakenne. Hintatiedon ilmoituksessa ilmoitetaan aina koko hintahistoria. Työryhmässä nousi kysymys siitä, onko koko hintahistorian päivitys turhan raskas prosessi. Ehdotus, että ainoastaan muuttunut hinta lähetettäisiin, koska verkko ei päivitä hintojaan niin usein, että uusi hinta ehdittäisiin ilmoittaa datahubiin ennen kuin virhe huomataan. Markkinaosapuoli voisi ilmoittaa vain uusia hintoja ja operaattori tekisi mahdolliset takautuvat korjaukset. Hinta-aikasarjan osalta todettiin, että ainoastaan uudet tiedot riittäisi ilmoitukseen. Tuotetiedon hausta todettiin,
Pöytäkirja 4 (7) että tuotetietoja haettaisiin aina osapuolikohtaisesti. Haulla voi myös hakea yksittäistä tuotetta. Hakuun tulisi sisällyttää tuotteen voimassaolorajaus sekä valinta haetaanko nykyinen tilanne vai myös historiatiedot. 6 Käsiteltävien asioiden listan läpikäynti 6.1 Tuotetiedot Läpikäytiin käsiteltävien asioiden Excel-listan avoimet kohdat. Kysymys osaako myyjä laskea alvittomasta hinnasta alvillisen oikein. Kuinka monella desimaalilla verkon pitäisi ilmoittaa alviton hinta. Tulisiko datahubiin ilmoittaa molemmat? Päätettiin, että molemmat hinnat tuodaan ja hinnalla on kymmenen desimaalia. Hintojen desimaalimäärä voi aiheuttaa epätarkkuutta, jos lasketaan alveja pyöristetyillä hinnoilla. Tuotekomponentin hinnalle erikseen alvillinen ja alviton hinta, molempiin mahdollistetaan 10 desimaalia. Aiemmin puhuttiin, että kappaletuotteita ei ole välttämätöntä viedä hubiin, olisiko hyvä viedä katkaisu ja kytkentäkulut, jotta myyjät näkevät nämä tiedot heti Ohjeistetaan, että katkaisu- ja kytkentätuotteet ja muut verkon palvelutuotteet ilmoitetaan datahubiin, jotta myyjä saa ne sieltä heti asiakkaalle selville. 6.2 Valtuutukset 1. Onko tarvetta mahdollistaa toimeksiannot useammalle osapuolelle yhtä prosessia varten. 2. Voiko jakeluverkonhaltija toimeksiantaa mittaustietojen toimituksen usealle palveluntarjoajalle? Per mittausalue vai per käyttöpaikka? Laskuriveissä lienee tarve voida valtuuttaa useita osapuolia vastaanottamaan yhden osapuolen laskurivejä, laskurivien lähetyksen yhteydessä aina määritetään mille taholle laskurivit välitetään. Tuotetietojen hakuun voi valtuuttaa useita osapuolia. 3. Onko muita tapauksia, joissa osapuoli toimeksiantaisi jonkin tietyn datahub-tapahtuman tai tapahtumien ryhmän useammalle kuin yhdelle palveluntarjoajalle? Sisääntulevat ilmoitukset voidaan määritellä tulevaksi usealta osapuolelta joilla toimeksianto, datahubin lähettämät ilmoitukset voivat mennä vain yhdelle osapuolelle. Esimerkiksi puuttuvien mittaustietojen muistutus lähtee JVH:lle vaikka mittaustiedon toimittaa useampi osapuoli. CMS tuote sallii valmiiksi sen, että useammalle osapuolelle valtuutetaan tapahtuma, jossa osapuoli toimittaa tietoa datahubiin (esim. mittaustiedon ilmoitus). Laskuriveissä useita osapuolia, sanomassa määritellään mille taholle laskurivisanoma toimitetaan. Tuotetietojen haku usealle osapuolelle mahdollista. Ei tunnistettu muita tilanteita.
Pöytäkirja 5 (7) Olemme aiemmin keskustelleet valtuutuksista ja siitä että valtuutuksilla tulee olla kaksi aikarajaa. Toinen kertoo sen, minkä ajan valtuutus on voimassa ja toinen sen minkä ajan tietoihin valtuutus oikeuttaa osapuolen. Olemme myös määritelleet, että valtuutettu 3. osapuoli on oikeutettu saamaan valtuutuksen voimassaoloajalta mittaustiedot. Mietimme joskus aiemmin, että keino millä valtuutuksen päättymisen jälkeen tämä kolmas osapuoli saisi mahdollisesti myöhemmin ilmoitetut mittaustiedot ja määrittelimme tämän keskustelun perusteella aikarajaksi 6 viikkoa. Mielestämme tämä on liian pitkä aika, joten ehdotamme muutettavaksi taseikkunan eli 11 pv. Muutetaan ehdotuksen mukaan 11 päivään. Valtuutustyyppi määrittää sen kuka voi ko valtuutuksen ilmoittaa ja mitä tietoja tällä valtuutuksella saa. Keskustelimme CGI:n kanssa siitä mistä MDM tunnistaa sen voiko ko. valtuutuksella saada mittaustietoja. Eli ongelma tulee tilanteissa, jos asiakas antaa valtuutuksen käyttöpaikkaan johon on vasta muuttamassa. Tämä on sama valtuutustyyppi kuin jos asiakas jo olisi ko. käyttöpaikan asiakas. CMS voi tämän perusteella palauttaa haussa meidän määrittelemät tiedot, mutta myös MDM:n puolelle on saatava tieto siitä voiko mittaustiedot palauttaa ilmoitetun valtuutuksen perusteella. Luodaanko uusi valtuutustyyppi, jolloin niin myyjän kuin asiakkaan on osattava antaa oikeanlainen valtuutus? Periaatteessa voisi toimia, mutta ei saa muodostua kulutusasiakkaalle liian vaikeaksi. Jos asiakaskäyttöliittymä osaa suoraan tarjota oikeaa valtuutustyyppiä, voisi toimia. Käydään uudelleen läpi valtuutusten ilmoittamista tilanteissa, jossa käyttöpaikalla on useampi asiakas. Useamman asiakkaan käsittely monimutkaistaa prosessia. Tietosuojan näkökulmasta ei ole ongelma jos esim. kahdesta sopimuskumppanista toinen valtuuttaa jonkun muun sopimuksen aikaisiin tietoihin, koska molemmilla sopimuskumppaneilla on samanlaiset oikeudet tietoihin. Jos käyttöpaikan asiakkaista toinen on salattu ja toinen ei: Ei pitäisi tapahtua? Voisiko tulla tietokonversiossa jo tällaisia? FG selvittää. Pitäisikö estää, että tällaisia ei synny datahubiin? Voi tulla tilanne, jossa se asiakas joka ei ole antanut valtuutusta kyseenalaistaa millä oikeudella käyttöpaikan tietoja on käytetty. Ei pitäisi olla ongelma, kun on lain mukaan. Ei katsota olevan ongelma, että DH-133 tapahtumassa jos yksi käyttöpaikan asiakkaista (kenellä on sopimus) valtuuttaa käyttöpaikan tietoihin ja mittaustietoihin, ei vaadita kaikkien asiakkaiden valtuutusta. Asiakastiedot saa vain siitä asiakkaasta, joka on antanut valtuutuksen. Sama sääntö pätee 3.osapuolien kohdalla tapahtumaan DH-135. Olemme määritelleet, että laskurivitietoja ei valtuuteta edelleen toiselle osapuolelle. Järjestelmä mahdollistaa tämän, mutta sallitaanko? Sallitaan se, että yhteislaskutustilanteessa laskuttavalla osapuolella voi olla palveluntarjoaja. Tässä tilanteessa sallitaan valtuutuksen "eteenpäin valtuuttaminen". Korjattua mittaustietoa tai muutettua käyttöpaikkatietoa ei välitetä päättyneen sopimuksen myyjälle, mutta tietojen haku CMS:ssä toimii niin että jälkikäteen haettuna antaa viimeisimmän tiedon haetulta ajanhetkeltä. Eli korjatun tiedon. Asiakastiedon osalta tietoja ei voi päivittää jälkikäteen, joten tämän osalta toimii oikein ja muuttunut tieto ei näy. Mutta
Pöytäkirja 6 (7) käyttöpaikkatietoa voidaan päivittää jopa 10 vuotta takautuvasti, näin ollen myös sopimuksen voimassaoloajalle tullut muutos näkyisi jälkikäteen tehdyssä haussa. Ei ole ongelma, että myyjä voi hakutapahtumalla saada käyttöpaikan tiedon, joka on muuttunut myyjän sopimuksen päätyttyä, jos päivitys on tehty takautuvasti niin että se koskee aikaa, jolloin myyjällä oli sopimus voimassa. 6.3 Määräaikaisen myyntisopimuksen päivitys 6.4 Aika-askel Aiemmin on sovittu, että sopimuksen määräajalle lisätään määrittelyihin määräajan alkupäivämäärä. Tämän avulla voidaan ylläpitää samaa sopimusta, jos määräaikaa on tarve muuttaa. Määräajan osalta kuluttaja-asiakasta koskeva sääntö siitä, että sopimusta voidaan käsitellä toistaiseksi voimassaolevana 2 vuoden jälkeen voidaan laskea määräajan alkupäivästä. Tuleeko toistaiseksi voimassaoleva sopimus voida päivittää määräaikaiseksi sopimukseksi vai onko aina kyseessä uusi sopimus? Voidaan päivittää määräaikainen jatkuvaksi, jatkuva määräaikaiseksi tai määräaikaiselle perään uusi määräaikainen jakso. Määräajan osalta kuluttaja-asiakasta koskeva sääntö siitä, että sopimusta voidaan käsitellä toistaiseksi voimassaolevana 2 vuoden jälkeen voidaan laskea määräajan alkupäivästä. Kappaleessa 4.4 DH-121 Käyttöpaikan luonti on todettu Tietoja Loissähkösarjat saatavilla ja Mittausaika-askel ei välitetä käyttöpaikkatapahtumassa. Datahub päättelee nämä tiedot vastaanotettujen mittaustietojen perusteella". Vaikuttaisi siis siltä, että Datahub dokumentaatio on ristiriitainen. Edellä mainitussa kohdassa todettu noin ja kappaleessa 5.1 DH-211 Mittaustiedon ilmoitus todettu validoinneissa Mittaustiedon resoluutio on sama kuin mittauspisteelle ilmoitettu aika-askel. Tekstiä korjataan, mittausaika-askel välitetään. Aika-askel määritetään käyttöpaikan ominaisuuksiin. Datahub ei päättele aika-askelta mittaustietojen perusteella. 6.5 Muut asiakkaan osoitteet Asiakas saattaa haluta hintakirjeet eri osoitteeseen vielä kuin asiakkaan postiosoite tai sopimuksen laskutusosoite. Tätä ei ole mahdollista kirjata datahubiin. Muutenkin asiakkaan kanssa sovittuja mahdollisia muita osoitteita ei ole mahdollista kirjata datahubiin ja siten välittää datahubin kautta myyjältä jakeluverkonhaltijalle. Tästä keskusteltiin alustavasti CGI:n kanssa. Riittääkö tähän samat tiedot mitä tällä hetkellä on määritelty laskutusosoitteelle? Entä mikä olisi tämän osoitteen tyyppi? Muut yhteysosoite? Monet osapuolten järjestelmät eivät tue tällaista lisäosoitetta. Ei lähdetä toteuttamaan nyt, mahdollisesti myöhempään versioon. 6.6 Salatun asiakkaan käsittely Määrittelimme toimintamallin sille, miten salatun asiakkaan käsittely menee. Määrittelyssä on mukana se, että mikäli asiakkaalla on ollut 3. osapuolen valtuutus, päättyy tämä valtuutus tällöin. Mietimme sitä, että tämän 3. osapuolen olisi varmaan hyvä saada tieto
Pöytäkirja 7 (7) myös tästä asiakastietojen päivityksestä, että on muutettu tieto salaiseksi jolloin ymmärtää myös sen miksi valtuutus päättyy. Voimme tarvittaessa rajata tällöin 3. osapuolelle lähetettävää ilmoituksessa lähetettäviä tietoja, mutta onko tarvetta? Ei ilmoiteta suoraan syytä, ilmoitetaan vain, että valtuutus päättyy. 6.7 Rajapisteiden mittaustiedot Datahub v1.7 dokumentaatiossa on kappaleessa 3.3.2.4 Mittaustietojen ilmoituksen valvonta todettu: Muistutukset lähetetään ainoastaan voimassaoleville mittauspisteille ja käyttöpaikoille siltä osin, kun käyttöpaikan verkkosopimus on voimassa.. Tämä siis muistutuksia koskien, tosin määritelmää tuolle voimassaoleville mittauspisteille ei dokumentaatiosta vaikuttaisi löytyvän. Kaikilla mittauspisteillä tulee olemaan voimassaolo. Rajapisteiden ja tuotantoyksiköiden kohdalla tätä käytetään muistutusten lähettämiseen. Dokumentaatiota tarkennetaan tämän osalta osavaiheen 4 yhteydessä. Rajapisteillä ei taida Datahub mallissa(kaan) olla sopimuksia ja myös rajapisteille tarvitaan aikasarjan lähettämiseksi käsittelysäännöt Ei ole sopimuksia. Mittaustietojen ilmoitussanoma tulee näillä näkymin päivittymään rajapisteiden aikasarjan lähettämiseen liittyen. 7 Kokouksen päätös ja seuraavat kokoukset Sovittiin työryhmälle uusi Skype-kokous keskiviikolle 24.4. klo 12.00-14.00. Puheenjohtaja päätti kokouksen klo 14.45. Työryhmän seuraava kokous paikan päällä Duetto Business Parkissa 28.5.2019. Liite Esitysmateriaali Jakelu Prosessityöryhmä Esa Pietarinen