MUISTIO 1(7) Vähittäismarkkinoiden menettelytapojen kehitysryhmä 7/2010 Aika Maanantaina 13.12.2010 klo 9.30-16.00 Paikka Airport Congress, Helsinki-Vantaa lentokenttä, terminaali 2 Osallistujat Jari Rusanen, pj E.ON Kainuu Oy Minna Arffman Vattenfall Verkko Oy Saku Ruottinen Fortum Distribution Jan Segerstam Empower Oy Sari Wessman Jyväskylän Energia Oy Hannele Ylönen Savon Voima Oy Riina Heinimäki Energiateollisuus ry Ina Lehto Energiateollisuus ry, siht. Energiateollisuus ry Este Kirsi Kuusisto Helsingin Energia Pia Sillstén Turku Energia Oy 1. Kokouksen avaus Puheenjohtaja avasi kokouksen. 2. Esityslistan hyväksyminen Esityslista hyväksyttiin sellaisenaan. 3. Edellisen kokouksen muistio Edellisen kokouksen muistio hyväksyttiin muutoksitta. 4. Peruutussanomien käyttöönotto Käytiin läpi kokouskutsun liitteenä ollut ohjeluonnos peruutussanomien käytöstä. Ohjeeseen liittyen heräsi muutamia kysymyksiä ja kommentteja: - Myyntisopimuksen peruuttaminen ei aina johdu tapahtuneesta virheestä, mikä oli ohjeessa peruutuksen lähtökohta, vaan asiakas voi halutessaan perua täysin oikeiden menettelyjen mukaisesti tehdyn sopimuksen peruutusajan puitteissa. Peruutussanomia kuitenkin käytetään ainoastaan ennen toimituksen alkua tapahtuviin peruutuksiin. Ohjetta korjattiin tältä osin. - Prosessin onnistumista voidaan seurata erilaisilla yhtiöiden sisäisillä mittareilla. Ohjeessa oli mainittu esimerkkeinä prosessin läpimenoaika ja työmäärä. Mittareihin lisättiin myös sanomaliikenteen oikeellisuus ja viestien perillemeno. - Markus kertoi Kirsin lähettämästä kommentista, jossa kysyttiin täytyisikö peruutusprosessikuvauksessa ottaa erikseen huomioon myös tilanne, jossa uusi myyjä on paikallinen myyjä ja uusi peruttava sopimus on kokonaistoimitussopimus. Tässä tilanteessa kaikkien yhtiöiden sisällä ei todennäköisesti lähetetä Z03[1]- sanomaa, eikä siten jatkossa lähetettäisi myöskään Z03[C]-sanomaa. Tällöin kokonaistoimitussopimuksen peruvan asiakaspalvelijan olisi huomioitava verkkosopimuksen palauttaminen ja huolehtia Z05[C]-sanoma erikseen matkaan. Todettiin, että ohjeiden mukaan Z03[1]-sanoma tulisi lähettää myös tässä tilanteessa, eikä haluta tehdä peruutussanomaohjeeseen poikkeusta vastoin muuta ohjeistusta. Ohjeistuksen tulee olla yhtenäinen kaikkien toimijoiden kesken. Keskusteltiin lyhyesti peruutussanomien rakenteesta ja sanomien rakennetta kuvaavasta PRODAT-Inhouse taulukosta. Aikaisemmin sovittiin, että peruutussanomat toteutetaan
MUISTIO 2(7) niin, että ne ovat syykoodia lukuun ottamatta identtisiä Z03[1]- ja Z05[1]-sanomien kanssa. Peruutussanomissa ei todellisuudessa tarvita kaikkia alkuperäisten sanomien kenttiä, mutta saman sanoman käyttö vähentää testaustarvetta. Peruutettava sopimus tunnistetaan peruutussanomalla välitettävän sopimustunnuksen avulla. Sanomien rakenne on tekninen kysymys, josta päätetään teknisen ryhmän seuraavassa kokouksessa. Myös PRODAT-Inhousen muokkauksesta vastaa tekninen ryhmä. Kehitysryhmän tehtävä on kehittää prosessikuvaus ja ohje peruutussanomien käytöstä. Toimikunnille pitää perustella, että testausta ei tarvita. Riina kysyi milloin peruutussanomat voisivat kehitysryhmän mielestä olla käyttöönotettavissa? Toimikuntien ensimmäiset kokoukset ovat tammi-helmikuun vaihteessa, johon mennessä tulisi uusi ohjeistus / menettelyohjeiden muutokset olla valmisteltuna ja ehdotus aikataulusta. Peruutussanomien käyttöönotossa on järjestelmätoimittajilla tekemistä, joten käyttöönotto voisi tapahtua aikaisintaan loppukeväästä tai kesällä. Aikataulusta keskustellaan vielä teknisen ryhmän seuraavassa kokouksessa. 5. Puuttuvien tuntitietojen arviointi Teknisestä ryhmästä perustettu pienryhmä on valmistellut ohjetta puuttuvien tuntitietojen arviointimenetelmistä. Tuntimittaussuosituksessa on jo ohjeistettu korkeammalla tasolla puuttuvien tietojen arviointia, mutta nyt valmisteilla olevan ohjeen on tarkoitus tarjota verkkoyhtiöille, joilla vastuu arvioinnista on, yksi teknisesti yksiselitteinen vaihtoehto puuttuvien tuntitietojen arvioinnin toteuttamiseksi. Ohjetta ei siis ole pakko soveltaa, vaan verkkoyhtiöt voivat myös itse kehittää arviointimenetelmiä, mikäli kokevat sen paremmaksi vaihtoehdoksi. Valmiin ohjeen myötä kaikkien yhtiöiden ei kuitenkaan tarvitse erikseen kehittää samaa asiaa rinnakkain. Lähtökohtana arvioinnille on, että käytetään käyttöpaikan historiadataa ja kumulatiivisista lukemista laskettua energiaa puuttuvalle ajalle aina kun mahdollista. Historiadataa käytetään siten, että lasketaan puuttuvan tunnin edellisen kolmen vastaavan ajan keskiarvo. Mikäli puuttuvan ajan energia on tiedossa, skaalataan se tunti tunnilta laskettujen keskiarvojen avulla saadun tuntikäyrän mukaiseksi. Ohjeessa on myös menetelmät muun muassa lyhyiden ajanjaksojen arviointiin, tilanteisiin, jossa ei ole käytettävissä historiadataa sekä arkipyhille. Ohje herätti joitakin kommentteja ja kysymyksiä: - Saku kertoi, että verkkoyhtiöllä ja myyjillä statukset voivat olla erinimisiä, kuin mitä ohjeessa on käytetty. Ohjeessa kuitenkin viitataan EDIEL-standardin mukaisiin statuksiin, joita tulee aina käyttää toimijoiden välisessä sanomaliikenteessä. Yhtiöiden sisällä voidaan lisäksi käyttää muitakin statuksia, mutta niitä ei saa käyttää muille toimijoille lähetettävissä sanomissa. Ohjetta muokattiin hieman tältä osin ja Markus vielä viimeistelee statuksista kertovat kohdat kuntoon. - Keskusteltiin tilanteesta, että historiadatassa on epävarma-statuksella olevia vertailutietoja. Voidaanko epävarmaa käyttää vai jätetäänkö käyttämättä. Tilanteessa, jossa puuttuvan ajan energia on tiedossa, voidaan epävarmastatuksella olevia vertailutunteja käyttää, sillä energiat kuitenkin täsmäävät. Saku kertoi, että epävarmalla statuksella olevissa tiedoissa voi olla piikkejä, mutta tämän pitäisi olla poistuva ongelma uusissa mittareissa. Lisäksi vertailutuntien keskiarvostus tasaa mahdollisia piikkejä. - Ohjeeseen oli vielä toistaiseksi jätetty menetelmä lämpötilan vaikutuksen arvioinnille sähkölämmityskohteilla, vaikka pienryhmässä olikin jo keskusteltu, että kohta tulisi mahdollisesti kokonaan poistaa. Lämpötilan vaikutuksen huomioinnissa on monta ongelmaa, joista ensimmäisenä se, että luentajärjestelmä, missä arviointi
MUISTIO 3(7) tapahtuu, ei tiedä mitkä kohteet ovat sähkölämmityskohteita ja mitkä eivät. Päätettiin, että lämpötilakorjausta ei arvioinnissa suoriteta ja siten poistetaan sitä koskeva kohta ohjeesta kokonaan. - Keskusteltiin arkipyhien huomioimisesta arvioinnissa. Arkipyhiä arvioitaessa vertailupäivinä käytetään joko edellisiä lauantai- tai sunnuntaipäiviä ohjeessa olevan arkipyhätaulukon mukaisesti tai, mikäli vertailujaksolle mahtuu, niin edellisiä arkipyhäpäiviä. Menetelmää pidettiin kehitysryhmässä loogisena ja helpompana toteuttaa kuin vertailemalla vuoden takaisiin vastaaviin tietoihin. - Huomautettiin, että ohjeessa olevan Pääkytkinkohteet -kappaleen nimi ei välttämättä avaudu lukijalle, joten se tulisi muokata paremmin ymmärrettävään muotoon. Lisäksi huomautettiin, että kyseisen kappaleen tulisi koskea myös kohteita, joista on tiedossa korjaustyöt, viat ja vastaavat, jolloin mittarin jännitteet eivät ole kytkeytyneenä. Ehdotettiin, että voisi tehdä myös kappaleen niistä pääkytkinkohteista, joiden ei tiedetä olevan pääkytkinkohteita. Näiden kohteiden arviointi tapahtuisi seuraavasti: Ensin arvioidaan nollaa puuttuva-statuksella, sitten tiedot arvioidaan normaalin menetelmän mukaisesti epävarma-statuksella ja lopuksi tiedot muutetaan nollaksi arvioitu-statuksella. Ehdotettu kappale lisättiin ohjeeseen. - Lopuksi Minna kertoi yhtiönsä kommentit ohjeesta. He olivat huolissaan, että kehitetään tällainen ohje verkkoyhtiön sisäiselle työlle, mutta Riina huomautti, että tätä ohjetta ei ole pakko soveltaa, vaan yhtiöissä voidaan toki kehittää myös itse paremmat menetelmät. Tämän ohjeen tarkoitus on antaa toimialalle yksi vaihtoehto arvioinnin toteuttamiseen, jotta kaikkien ei tarvitse suunnitella ja tilata samaa asiaa erikseen. Minnan kommenteissa ihmeteltiin myös kuormituskäyrän soveltamista arvioinnissa, kun historiadataa ei ole käytettävissä. Todellisuudessa tilanne on harvinainen, sillä kohteita ei normaalisti viedä tuntiluentaan ennen kuin luentayhteys toimii. Verkkoyhtiöt voivat tällaisissa tilanteissa hyödyntää kokemustaan vastaavista kuluttajista, mikä antaa todennäköisesti valtakunnallista kuormituskäyrää luotettavamman arvion. Kommenteissa kyseenalaistettiin myös kolmen edellisen viikon käyttäminen kiinteästi vertailutietona. 6. MSCONS-yhteystietotaulukko Edellisessä kokouksessa keskusteltiin teknisen ryhmän ideoimasta MSCONSyhteystietotaulukosta. Silloin päätettiin, että teknisen ryhmän Sampsa Vaulimon tekemä ehdotus taulukosta ja pohditaan jatkotoimenpiteitä seuraavassa kokouksessa. Sampsan tekemä taulukkoluonnos noudatti pitkälti olemassa olevaa PRODATyhteystietotaulukkoa. Taulukkoon oli ainoastaan lisätty uusi sarake Osapuolen tunnus NAD:lla, jos eri kuin osapuolen virallinen tunnus. Tämä ero johtuu siitä, että joidenkin osapuolien kohdalla MSCONS-sanomissa virallisen osapuolitunnuksen sijaan käytetään toista tunnusta. Keskusteltiin taulukon sisältämistä toimijoiden tietojärjestelmiä koskevista sarakkeista, jotka eivät välttämättä ole kovin tarpeellisia. Lisäksi MSCONS-taulukossa taseselvitysjärjestelmä voisi mieluummin olla oma sarakkeensa ja ATJ/EDI-muunnin oma sarakkeensa. Päätettiin kuitenkin, että taulukon rakenne voi yhdenmukaisuuden vuoksi olla ehdotettu. Keskusteltiin siitä miten PRODAT- ja MSCONS-taulukot tulisi esittää ET:n EDIEL-sivuilla. Jan ehdotti, että paras ratkaisu olisi yksi Excel-taulukko, jossa PRODAT- ja MSCONS-tiedot ovat eri välilehdillä. Myös muiden mielestä tämä olisi selkeä ratkaisu. Päätettiin kysyä vielä teknisen ryhmän kanta asiaan.
MUISTIO 4(7) Riina kysyi kuinka toimijoiden tiedot saadaan helpoiten taulukkoon. Saku ehdotti, että kehitysryhmän jäsenet syötävät taulukkoon ensin omien yhtiöidensä tiedot esimerkkinä muille toimijoille. Tämän jälkeen, mikäli tekninen ryhmä on yhtä mieltä eri välilehdille jaetusta taulukosta, lähetetään jäsentiedote, jossa kehotetaan täyttämään taulukko EDIEL-sivuilla olevan nettilomakkeen avulla. Lomaketta pitää vielä muokata siten, että se mahdollistaa tietojen lisääjän valita päivittääkö PRODAT- vai MSCONS-tietoja. Markus keskustelee Adaton Risto Heliön kanssa asiasta. 7. Avoimia kysymyksiä 7.1 PRODAT-tunnukset kun verkko sulautuu osaksi toista verkkoa Saku esitti kehitysryhmälle kysymyksen liittyen tilanteeseen, jossa jakeluverkko sulautuu osaksi toista jakeluverkkoa, eli yhden verkon käyttämä osapuolitunnus lakkautetaan ja kyseisen verkon käyttöpaikat siirtyvät toisen verkkotunnuksen alle. Käyttöpaikkatunnukset eivät tämän johdosta vaihdu. Varsinainen kysymys oli, että minkä verkon nimissä PRODAT-sanomat tulee milloinkin lähettää. Pohdittiin kahta erilaista vaihtoehtoa (oletetaan, että virallinen vaihtopäivämäärä olisi esim. 1.6.2011): 1. PRODAT-sanomissa käytetään lakkautettavaa osapuolitunnusta 31.5. asti ja 1.6. alkaen uutta tosien verkon osapuolitunnusta. 2. PRODAT-sanomissa ennakoidaan osapuolitunnuksen vaihtoa pitäen silmällä esimerkiksi uuden myyntisopimuksen voimassatulopäivää. Eli esimerkiksi 20.5. lähetetyssä Z03[1]-sanomassa olisi jo uusi tunnus, koska sanomaa koskeva sopimus tulee voimaan vasta 1.6. jälkeen. Kehitysryhmässä oltiin yhtä mieltä, että ensimmäinen vaihtoehto on kaikkien osapuolien kannalta helpompi toteuttaa. Joten linjattiin, että verkkojen sulautuessa yhteen tulee käyttää vanhoja osapuolitunnuksia viralliseen vaihtopäivämäärään asti. MSCONS-sanomat lähetetään voimassa olevan taseikkunan mukaan, joten vanhalla osapuolitunnuksella lähetetään aikasarjoja vielä kaksi viikkoa kesäkuun alun jälkeenkin. 7.2 Statustieto PRODAT-sanomilla välitettäviin lukematietoihin Eräissä muissa Euroopan maissa myös PRODAT-sanomilla välitettäviin lukematietoihin liitetään statustieto. Kehitysryhmä keskusteli lyhyesti tulisiko tätä harkita myös Suomessa. Kehitysryhmän kokouksessa 5/2010 (27.9.) on kuitenkin jo linjattu seuraavaa: Verkonhaltijan tulisikin siten laskuttaa ja lähettää eteenpäin vain vahvoilla statuksilla (OK, Korjattu OK ja Arvioitu) saatuihin mittaustietoihin perustuvia käyttöjä. Tämä on verkonhaltijan omankin edun mukaista, sillä verkonhaltija vastaa vääristä mittaustiedoista aiheutuneista seurauksista. Linjattiin, että mikäli verkonhaltija joutuu korjaamaan aiemmin lähettämiään lukemia tai käyttöjä, tulee myyjään ottaa ensin yhteyttä ja sopia korjaavista toimista. Suomessa käytettävä Z11-sanomarakenne ei myöskään nykyisellään mahdollista statustietojen välittämistä. Sanomarakenteen muutoksessa olisi iso työ saatuihin hyötyihin nähden, sillä ongelma on tuntitietojen välityksen myötä poistuva. Joten statustietoa ei tulla lisäämään PRODAT-sanomiin. 7.3 Käyttöpaikkanumero muuttuu asiakkaanvaihdon yhteydessä Kehitysryhmän tietoon on tullut, että eräällä verkkoyhtiöllä on käytäntönä vaihtaa käyttöpaikkanumeron viimeistä numeroa aina kun kyseisen käyttöpaikan asiakas
MUISTIO 5(7) vaihtuu. Tämän seurauksena verkkoyhtiöltä saadussa Z04[1]-sanomassa on eri käyttöpaikkanumero kuin alkuperäisessä muuttoilmoituksessa. Siten Z04[1] jää aina myyjällä virhelistalle. Käyttöpaikan yksilöllinen tunnistettavuus on ensisijaisen tärkeää toimivan sähkön vähittäismarkkinan kannalta. Tunnusta käytetään yksittäisten sopimusten identifiointiin. Sopimuksen perusteena olevaa tietoa ei saa muuttaa prosessin aikana. Sovittiin, että Jari on yhteydessä kyseiseen yhtiöön ja kertoo heille kehitysryhmässä käydystä keskustelusta, että tämä ei ole sopiva toimintatapa. 7.4 Etäkytkentäkohteiden kytkentä kun muuttotieto tulee sanomana 8. Muut asiat Keskusteltiin kuinka etäkytkettävään kohteeseen tulisi kytkeä jännitteet päälle, kun muuttotieto tulee sanomana, eikä verkkoyhtiöllä välttämättä ole asiakkaan puhelinnumeroa. Turvallisuussyistä asiakkaaseen tulisi aina olla yhteydessä ennen etäkytkentää, mikäli mittari ei mahdollista valmiustilaa, josta asiakas voi itse lopuksi kytkeä jännitteet päälle. Jari kertoi, että heillä pyritään hakemaan asiakkaan puhelinnumero numeropalvelusta ja sopimaan asiakkaan kanssa menettelystä. Asiakas voi esimerkiksi soittaa kun on käyttöpaikalla. Asiakkaat eivät kuitenkaan aina vastaa puheluihin, jotka tulevat tuntemattomasta numerosta. Toinen vaihtoehto on lähettää asiakkaalle tekstiviesti, että ottaa yhteyttä asiakaspalveluun kun on käyttöpaikalla ja haluaa sähköt kytkettävän. Mikäli asiakkaaseen ei yrityksestä huolimatta saada yhteyttä, hän kyllä itse soittaa kun kohteessa ei ole sähköä. Puhelinnumero muuttosanomissa olisi hyödyllinen, mutta vaatisi suuren muutostyön sanomarakenteisiin. Numerot voidaan kuitenkin hakea numeropalvelusta, joten tällä hetkellä ei nähdä tarvetta tehdä suuria muutoksia. 8.1 Tiedoksi: Jäsenviesti menettelyohjeiden päivityksestä lähetettiin Menettelyohjeiden päivitysurakka saatiin päätökseen ja valiokunnat ja toimikunnat hyväksyivät tehdyt muutokset. Asiasta lähetettiin 1.12. jäsentiedot, jossa kerrottiin tehdyistä muutoksista ja niiden vaikutuksista sekä kehotettiin ottamaan muutokset käyttöön mahdollisimman pian. 8.2 Esitys klo 14.15: Tullihallituksen kokemuksia sanomaliikenteestä Tullihallituksen sanomaliikenteen järjestelmäpäällikkö Pirjo Perhonen tuli pitämään kehitysryhmälle mielenkiintoisen esitelmän heidän kokemuksistaan tiedonvaihdosta ja meneillään olevista kehityshankkeista. Perhonen on ollut Tullihallituksen palveluksessa vasta noin vuoden, mutta hänellä on pitkä kokemus IT-alalta. Tullin päätehtävä on valvoa Suomeen tulevia ja Suomesta lähteviä tavaravirtoja sekä kohdistaa niihin mm. vero- ja kauppapoliittisia toimenpiteitä. Asiakkaat ovat hyvin erikokoisia ulkomaankauppaa harjoittavia yrityksiä. Toimiala on luonnollisesti hyvin kansainvälinen ja etenkin EU:n sisällä tiedonvaihtoon liittyvää kehitystä tehdään pitkälti yhteistyössä, sillä EU muodostaa yhden yhtenäisen tullialueen. EU:ssa on myös käynnissä hanke elektronisesta tulliympäristöstä, joka etenee rinnakkain EU:n tullilainsäädännön uudistuksen myötä. Tiedonvaihdon kehittämisessä tullitoimialalla EU on siis vahvassa roolissa. Tullihallituksella on tiedonvaihtoa myös EU:n ulkopuolelle. Koska Tullihallituksen asiakkaat ovat hyvin erilaisia, yksityisistä henkilöistä suuriin yrityksiin, tulee palvelukanavat myös suunnitella siten, että erilaiset asiakasryhmät saavat niistä täyden hyödyn. Yksityishenkilöllä ei voi olla käytössään
MUISTIO 6(7) sanomajärjestelmää, joten luonnollinen palvelukanava tiedonvaihtoon toimii selainkäyttöliittymällä internetin yli. Suuret asiakkaat puolestaan saavat omiin tietojärjestelmiin integroidut sanomajärjestelmät tehokkaammin hyödynnettyä. Sanoma-asioinnin aloittaminen Tullin kanssa vaatii tietyn lupamenettelyn, johon sisältyy luvan haun lisäksi myös muun muassa asiakastestaus tullin ja asiakkaan omalla aineistolla. Tullin tarjoama testausympäristö on asiakkaille maksuton. Yritysasiakkaiden sanomaliikenne tullin kanssa voidaan tulevaisuudessa hoitaa kahdella eri tavalla. Nykyinen operaattorivälitteinen sanoma-asiointi muistuttaa pitkälti sähkömarkkinoiden tiedonvaihtoa. Asiakkaiden sovellukset kommunikoivat EDIFACTja XML-pohjaisilla sanomilla Tullin palvelusovelluksen kanssa käyttäen yhtä useista välitysoperaattoreista. Luotettavan verkkoyhteyden tarjoavat operaattorit tarvitsevat Tullilta tietyn hakumenettelyn mukaisen valtuutuksen saadakseen toimia välitysoperaattorina. Tulevaisuudessa sanoma-asiointi perustuu Tullin TESB-väylään (Tulli Enterprise Service Bus), jonka TESB-edustaan asiakkaat voivat ottaa suoraan yhteyttä julkisen verkon(internet) yhteyden kautta. Edusta toimii varsinaisen Tullin sisäisen palveluväylän ja julkisen verkon tietoturvaeristeenä, hoitaen mm. - Webservice-rajapinnan - Liikenteen salauksen - Sanomien lähettäjien tunnistuksen ja valtuutuksen - Sanomien kehysten validoinnin ja eheyden tarkistuksen - Sanomien kehystietojen muuntamisen Inhouse-muotoon - XML-uhkien torjunnan Tämä niin kutsuttu suora sanoma-asiointi perustuu pääosin XML-pohjaiseen sanomaliikenteeseen, joka välitetään HTTPS/SOAP protokollan yli. Varsinaiset sovellussanomat ovat samoja suorassa ja operaattorivälitteisessä sanoma-asioinnissa. Tullin sovelluksen takaisin asiakkaille lähettämät sanomat eivät suoraan välity asiakkaille saakka, vaan asiakkaiden tulee noutaa sanomat oma-alotteisesti TESBväylän viestivarastosta. Tämä asiakkaiden tekemä pollaus ei kuormita väylää merkittävästi. Yksi syy uuteen suoraan sanoma-asiointiin on operaattorivälitteisen asioinnin kalleus pienille asiakkaille. Kaikki Tullihallituksen tiedonvaihto muiden EU:ssa toimivien tulliviranomaisten ja EU:n komission välillä tapahtuu erillisen CCN-verkon kautta. Myös CCN-verkko yhdistyy Tullihallituksen TESB-palveluväylään, tosin CCN-gateway:n kautta, jollainen on kaikissa CCN-verkkoa käyttävissä maissa. Kansainvälisessä liikenteessä käytetään yhteisesti määriteltyjä sanomarakenteita, mutta järjestelmät rakennetaan kansallisesti. Tavoitteena on saavuttaa yhtenäisemmät käytännöt. TESB-väylää käytettään myös muuhun, kuin pelkästään ulkoiseen sanoma-asiointiin. TESB tarjoaa rajapinnan myös muiden Web-pohjaisten palveluiden ja Tullin sovellusten välillä sekä rajapinnan Tullin järjestelmästä toiseen tapahtuvalle sisäiselle liikenteelle. Yleiskäyttöinen palveluväylä tiedonvaihdon hoitamiseen antaa merkittäviä hyötyjä kokonaan erillisiin rinnakkaisiin järjestelmiin verrattuna. Muun muassa tietoturva ja järjestelmäpalveluiden hallinta helpottuvat sekä sanomien reititys järjestelmien välillä monipuolistuu. Toistaiseksi Tullin tiedonvaihtojärjestelmät toimivat vielä pääosin EDIFACT-sanomilla, mutta tulevaisuudessa ne tulevat perustumaan XML-sanomiin. EDIFACT on kankea tietoformaatti ja sen osaaminen on hiipumassa. XML:n suosio sen sijaan kasvaa monipuolisesti eri aloilla, joten tarvittavaa osaamista löytyy paljon. Myös monet yleiset ohjelmat, kuten MS Excel, osaa tuottaa valmista XML-muotoista dataa.
MUISTIO 7(7) Riina kertoi, että sähkömarkkinoilla kapasiteetin riittävyys on riski, kun sanomamäärät lähivuosina kasvavat räjähdysmäisesti. XML-sanomat ovat erilaisen rakenteensa ansiosta kooltaan EDIFACT-sanomia suurempia, mikä myös vaikuttaa kapasiteetin riittävyyteen. XML-tiedosto sisältää varsinaisen tietoelementin lisäksi myös kuvauksen elementin sisällöstä, eli XML on niin kutsuttu kuvauskieli. Tullitoiminnassa sanomamäärät eivät kuitenkaan ole yhtä suuria, kuin mitä sähkömarkkinoilla tulee olemaan, joten kapasiteettia ei nähty ongelmaksi. Tullitoiminnassa sanomien aikarajat sen sijaan ovat huomattavasti tiukemmat, eikä katkoksia voida sallia ollenkaan. Sanomaprosessien kestot ovat vain joitakin minuutteja, sähköalan joihinkin päiviin verrattuna. Myös kaikki Tullihallituksen järjestelmäpäivitykset tehdään ennalta sovittuina ajankohtina neljä kertaa vuodessa. Sanomaliikenteen ongelmat havaitaan yleensä tuntien sisällä ja haasteena onkin saada välitettyä tiedot eteenpäin mahdollisimman nopeasti. 8.3 Loppulaskuosoite myös myyjälle Keskusteltiin lyhyesti mitä ohjeet sanovat asiakkaan loppulaskun osoitetiedon välittämisestä vanhalle myyjälle, kun asiakas muuton yhteydessä vaihtaa myyjäänsä. Luottamuksellisuus- ja syrjimättömyysohjeet asiakaspalvelutilanteisiin ohjeistavat, että verkonhaltija ei automaattisesti voi uutta osoitetietoa luovuttaa vanhalle myyjälle, mutta jos asiakas on pyytänyt uutta myyjää ilmoittamaan uuden osoitteen eteenpäin loppulaskua varten, niin tällöin osoitetieto välitetään myyjälle PRODAT-sanoman laskutusosoite-kentässä. 8.4 Alueelliset tuntimittauskoulutukset Riina kertoi nopeasti, että puhujat kerääntyvät alkuvuodesta kokoukseen, jossa sovitaan yhdessä mitkä viestit koulutuksessa halutaan tuoda esille. Kolmelle samansisältöiselle koulutustilaisuudelle on sovittu seuraavat ajankohdat: - 17.3 Jyväskylä - 24.3 Oulu - 30.3 Helsinki 8.5 Järjestelmäpäivitysten aiheuttamat sanomaliikennekeskeytykset Keskusteltiin erään vähittäismarkkinoilla toimivan konsernin käynnissä olevan järjestelmäpäivityksen aiheuttamasta sanomaliikennekeskeytyksestä. Kyseinen yhtiö on ilmoittanut muille toimijoille, että sen verkko- ja myyntiyhtiöt eivät pysty käsittelemään mitään sanomia noin neljään viikkoon, vaan katkon aikaiset sanomaketjut viedään loppuun vasta katkon jälkeen. Menettely johtaa sanomaliikenteen aikarajojen ylittymiseen ja on siten vastoin ET:n ohjeistusta ja jopa vastoin sanomaliikenneasetusta. Sovittiin, että Markus ottaa yhteyttä kyseiseen yhtiöön ja kertoo olemassa olevasta ET:n ohjeesta Järjestelmämuutoksien vaikutukset sanomaliikenteen hoitamiseen. Ohjeessa kerrotaan kuinka tulisi toimia tilanteessa, jossa tietojärjestelmiin tehtävät muutostyöt aiheuttavat väliaikaisia ongelmia sanomaliikenteen hoitamiseen. 9. Seuraava kokous Seuraava kokous sovittiin pidettävän torstaina 17.2.2011 klo 9.30 16.00 Airport Congressissa.