JHS XXX Hankintatietojen elektroninen välitys

Transkriptio

1 JHS XXX Hankintatietojen elektroninen välitys Versio: Julkaistu: XX.XX.2008 Voimassaoloaika: XX.XX.XXXX Sisällys 1 Johdanto Soveltamisala Termit ja määritelmät Elektroninen standardimuotoinen tiedonsiirto Elektronisen tiedonsiirron osapuolet Elektronisen tiedonsiirron vaiheet Lähetysprosessi Poiminta Muunnos Siirto Vastaanottoprosessi Siirto Opastavat tiedot Johdanto Tämä opas on tarkoitettu organisaatioille, jotka ovat kehittämässä tai hankkimassa järjestelmiä, joiden avulla välitetään hankintatoimen tietoja partnereille. Oppaan avulla hankintatoimen järjestelmistä vastaavat organisaatiot ja henkilöt pystyvät ymmärtämään elektronisen tiedonsiirron sekä elektronisten lomakkeiden käytön mahdollisuudet ja järjestelmävaatimukset sekä itse tiedonsiirron eri vaiheet ja osapuolet. Oppaassa esitetään julkisten hankintojen menettelyt käytettäessä UBL pohjaisia sanomia ja elektronisia lomakkeita tietojen välitykseen. Oppaassa esitetään ne vaatimukset ja ominaisuudet, jotka elektronista hankintatointa hoitavan järjestelmän on täytettävä. Lisäksi kerrotaan, miten järjestelmiä olisi kehitettävä, jotta niissä voitaisiin käyttää tehokkaasti hyväksi elektronisessa muodossa tuleva informaatio. 2 Soveltamisala Tämä dokumentti on tarkoitettu käytettäväksi julkisten hankintojen tietojärjestelmien elektronisen tiedonsiirron kehittämisessä. Suosituksen kohderyhmiä ovat: Julkisista hankinnoista ja järjestelmistä vastaavat organisaatiot ja henkilöt Järjestelmätoimittaja Konsultit Tavara- ja palvelutoimittajat. 1/12

2 3 Termit ja määritelmät Elektroninen standardimuotoinen tiedon siirto Elektronista, määrämuotoista, sanomista koostuvaa tietojen siirtoa osapuolten tietojärjestelmien välillä hyväksyttyjä standardeja ja pelisääntöjä noudattaen. Elektroninen tiedon siirto Elektronista, määrämuotoista, sanomista koostuvaa tietojen siirtoa osapuolten tietojärjestelmien välillä hyväksyttyjä standardeja ja pelisääntöjä noudattaen. Rakenteinen tiedon esitystapa Rakenteisen tiedon esitystavalla tarkoitetaan sellaista tiedon esitystapaa eli säännöstöä, jossa tiedot on tiettyjen sääntöjen mukaan nimetty ja eroteltu toisistaan sekä ryhmitelty tiettyihin, yleensä loogisin kokonaisuuksiin. Nämä säännöt määrittelevät myös tiedon poisjäännin esittämisen. Rakenteinen tieto Tieto, joka noudattaa tiettyä rakenteisen tiedon esitystapaa. Sanoma Tietojoukko, joka sisältää hankintatoimen tietyn kaupallisen asiakirjan tiedot elektronisessa muodossa. 4 Elektroninen standardimuotoinen tiedonsiirto Kuten paperilomakkeilla, joilla hankintatoimen tietoja siirretään perinteisesti osapuolten välillä, on jokaiselle tiedolle oma paikkansa lomakkeen tietyssä laatikossa, niin myös standardimuotoisessa tiedonsiirrossa on jokaiselle tiedolle oma paikkansa siirrettävässä tiedostossa. Elektronisessa tiedonsiirrossa perinteisesti paperilla esitettyä asiakirjaa, kuten tilaus tai lasku, vastaa sanoma, joka sisältää kauppatapahtuman tietyn asiakirjan tiedot. Elektronisella standardimuotoisella tiedonsiirrolla tarkoitetaan kahden eri organisaation välistä elektronisesti eli sähköisesti tapahtuvaa tiedonsiirtoa, jossa siirrettävä tieto on esitetty jollakin tietyllä yhteisesti sovitulla tavalla. Tällainen yhteisesti sovittu menettelytapa tai standardi määrittelee siirrettävien tietojen järjestyksen, muodon, nimeämisen, ryhmittelyn ja tietojen erottelun siirrettävässä sanomassa. Tällä tavalla esitettyä tietoa nimitetään rakenteiseksi tiedoksi. Siirrettävä sanoma on siis rakenteeltaan aina periaatteessa samanlainen siirrettäessä hankintatoimen tiettyyn asiapaperiin liittyviä tietoja. Siis tilauksen tiedot esitetään sanomassa aina samalla tavalla ja samassa järjestyksessä. Siirtokohtaisesti poisjääville tiedoille on myös laadittu omat sääntönsä poisjäännin esittämiseksi. Standardimuotoisessa tiedonsiirrossa tietty siirrettävä tieto on aina samassa kohti siirrettävää sanomaa ja sen on esitetty siinä tietyllä tavalla. Täten vastaanottava järjestelmä pystyy sen käsittelemään automaattisesti. Sähköpostiviesti ei ole standardimuotoista tiedonsiirtoa, sillä sähköpostiviestissä esitettävät asiat voivat olla periaatteessa missä tahansa järjestyksessä, kunhan niiden esittäminen noudattaa loogista asioiden esittämistapaa ja kielioppisääntöjä. Kuitenkin sähköpostiviestin sisältö ja muoto riippuvat viestin kirjoittajasta ja hänen kirjoittamishetken tunnetilasta ja muista viesti sisältöön ja muotoon vaikuttavista tekijöistä. ohjelmateknisesi tällaisen viestin automaattinen käsittely on täten vaikeaa. 5 Elektronisen tiedonsiirron osapuolet Elektronisessa tiedonsiirrossa on eri osapuolia, joiden tehtävät ja rooli määräytyvät sen mukaan, mitä sanomaa siirretään ja miten tiedonsiirto on määritelty. 2/12

3 Sanomaa lähettävä organisaatio on sanoman lähettäjä tai lyhyesti lähettäjä. Tämä osapuoli poimii järjestelmistään sanomassa tarvittavat tiedot ja järjestää nämä sanoman rakenteen mukaisesti oikeaan järjestykseen. Kun sanoman on valmis lähetettäväksi, lähettäjä lähettää sanoman sovitulla tavalla vastaanottajalle. Sanoman vastaanottaja eli lyhyemmin esitettynä vastaanottaja on osapuoli joka vastaanottaa sanoman ja purkaa sen tiedot omaan tietojärjestelmäänsä. Kuviossa 5.1 on esitetty tiedonsiirto lähettäjän ja vastaanottajan välillä. Kuva 5.1: Tiedonsiirto lähettäjä- ja vastaanottajaorganisaation välillä Edellä esitetty tiedonsiirtotapa on käytössä tilanteissa, joissa lähettäjällä ja vastaanottajalla ovat samat tietojärjestelmät käytössä tai lähettäjä muuntaa lähetettävän tiedon sellaiseen muotoon, että vastaanottaja pystyy käsittelemään ja muuntamaan sen tietojärjestelmänsä vaatimaan muotoon sekä tallettamaan sen omaan tietojärjestelmäänsä. Jos lähettäjällä tai vastaanottajalla tai kummallakin osapuolella on useita yhteistyökumppaneita, jotka lähettävät tai vastaanottavat sanomia, käyttävät lähettäjät ja vastaanottajat operaattoreita, jotka muuntavat lähettäjän poimimat tiedot vastaanottajan vaatimaan muotoon. Kuviossa 5.2 on esitetty, miten muunnospalveluita tarjoavat operaattorit sijoittuvat tiedonsiirtoketjussa. Kuviossa sekä lähettäjä että vastaanottaja käyttävät muunnospalveluita tarjoavan operaattorin palveluita. Lähettäjän käyttämä operaattori muuntaa lähettäjän tiedot sanomaksi, joka lähetetään vastaanottajan operaattorille käyttäen sovittua tiedonsiirtomuotoa. Vastaanottajan operaattori vastaanottaa sanoman ja muuntaa sanoman tiedot vastaanottajan järjestelmän hyväksymään muotoon sekä siirtää tiedot vastaanottajalle. 3/12

4 Kuva 5.1: Tiedonsiirto lähettäjä- ja vastaanottajaorganisaation välillä muunnospalveluita tarjoavien operaattoreiden välityksellä Siirrettäessä tietoa osapuolien välillä yleensä tiedon lähettäjä on aktiivinen tiedon vastaanottajaan nähden. tämä tarkoittaa sitä, että tiedon lähettäjä aktivoi siirron itsensä ja vastaanottajan välillä ja siirtää tiedoston tämän koneelle. Tietyissä tilanteissa kuitenkin vastaanottaja voi olla aktiivinen osapuoli. Tällöin tiedon lähettäjä on muodostanut siirrettävän tiedoston ja tallettanut sen tiettyyn hakemistoon omalle tietokoneelleen siten, että vastaanottajalla on oikeudet päästä tähän hakemistoon. Aktiivisessa roolissa oleva vastaanottaja aktivoi yhteyden lähettäjän ja itsensä välillä ja käy noutamassa eli siirtää itselleen tiedoston kyseisestä hakemistosta. Yleensä tässä tapauksessa vastaanottaja myös yleensä tuhoaa hakemistossa olevan tiedoston siirron jälkeen, jotta sitä ei siirretä uudelleen seuraavalla kerralla tai jotta se ei estäisi uuden tiedoston muodostumista hakemistoon. 6 Elektronisen tiedonsiirron vaiheet Edellisessä luvussa tarkasteltiin elektronisen tiedonsiirron eri osapuolia. Jos siinä yhteydessä mainittiin siirrettävän tiedon lähettämisestä ja vastaanottamisesta. Tässä kappaleessa tarkastellaan tiedonsiirron vaiheita tarkemmin. Tämä kappale on tarkoitettu selvittämään järjestelmiä hankkiville ja kehittäville tahoille järjestelmiltä vaadittavia ominaisuuksia, jotta tiedonsiirto voitaisiin toteuttaa. 6.1 Lähetysprosessi Lähetettäessä tietoa lähetysprosessi voidaan jakaa kolmeen eri osaan: poiminta, muunnos ja siirto. Kuvassa on esitetty nämä vaiheet sekä niihin sisältyvät toiminnot. 4/12

5 Kuva Elektronisen tiedonsiirron lähetysprosessi 5/12

6 6.1.1 Poiminta Lähetysprosessi ensimmäisenä vaiheena on tietojen poiminta, joka on esitetty kuvassa 6.1 osassa POIMINTA. Tällöin lähetettävään sanomaan tarvittavat tiedot poimitaan organisaation käyttämän järjestelmän tietokanasta. Poimitut tiedot muodostavat tiedoston, joka on organisaation omassa sisäisessä muodossa. Tämä tarkoittaa sitä, että tiedot voivat olla jossakin tietyssä järjestyksessä, joka ei välttämättä ole sanoman määräämä tietojen järjestys. Tietojen pituudet saattavat poiketa sanomastandardin mahdollisesti määrittelemistä pituuksista tai tiedoston sisältämät koodiarvot voivat poiketa sanomasuosituksen määrittelyistä. Tiedostosta voi lisäksi tässä vaiheessa puuttua joitakin sanoman kannalta oleellisia tietoja. Tämän vuoksi tiedostoa on muokattava paremmin tiedonsiirtoa palvelemaan muotoon ryhmittelemällä sen tietoja tiettyihin loogisiin kokonaisuuksiin ja lisäämällä siihen UBL-esitystavan tai vastaanottajan järjestelmän kannalta tärkeitä tietoja. Myös järjestelmän omia koodeja on muunnettava yleisesti käytössä oleviksi. Muokkauksen tuloksena syntyvää tiedostoa nimitetään välitiedostoksi. Poimitussa tiedostossa koodiarvoiset tiedot sisältävät järjestelmän käyttämiä koodeja. Jos järjestelmä käyttää yleisesti käytössä olevia, yleensä ISO-standardin mukaisia koodeja tai EU/ECE:n (Euroopan talouskomission) julkaisemia koodeja, ei koodeja tarvitse muuntaa. Jos kuitenkin järjestelmä käyttää omia järjestelmän toimittajan tai käyttäjäorganisaation määrittelemiä koodeja, on koodit muunnettava yleisesti käytössä oleviksi koodeiksi, kuten ISO-standardin mukaisiksi tai UN/ECE:n koodistojen mukaisiksi koodeiksi. Tämä muunnos on välttämätön, sillä vastaanottaja ei voi päätellä lähettäjän omien koodiarvojen perusteella koodin varsinaista merkitystä. Oletetaan, että lähettäjän tietojärjestelmässä kuljetustapa autokuljetus saa koodiarvon A. Vastaanottajan järjestelmä ei voi A-kirjaimen perusteella päätellä, mitä lähettäjä kyseisellä koodilla tarkoittaa. Toisaalta ei voida olettaa, että vastaanottaja rakentaa järjestelmiinsä kaikkien partnereittensa käyttämien koodien muunnostaulukot. Täten kuljetusmuotokoodi A on muunnettava UN/ECE-suosituksen 19 (Code for modes of transport) mukaiseksi koodiksi, joka on numero 3. UBL-sanomassa siirretään koodiarvon mukana myös tieto käytettävästä koodistosta, jolloin vastaanottaja tietää, että vastaanottamansa kuljetustapakoodi 3 tarkoittaa autokuljetusta. Ongelmalliseksi vastaanottajan kannalta tulisi tilanne, jos lähettäjä ei suorittaisi koodimuunnosta ja lähettäjäorganisaation tietojärjestelmissä kuljetustavan autokuljetus koodi olisi esimerkiksi koodiarvo 1. Tämä koodiarvo on kuitenkin UN/ECE suosituksen 19 mukaan merikuljetusta ilmaiseva koodi. Tällöin pahimmassa tapauksessa lähettäjän tarkoittama autokuljetus muuttuu vastaanottajan järjestelmissä merikuljetukseksi. Koodimuunnos voidaan toteuttaa järjestelmissä kahdella eri tavalla. Suositeltavampi tapa on luoda tauluja eli taulukoita, joita poimittua tiedostoa muokkaava ohjelma käyttää hyväkseen. Näihin muunnostauluihin kuvataan järjestelmän käyttämät koodit sekä niitä vastaavat yleisesti käytetyt koodit. Nämä muunnostaulut ovat käytännöllisiä, sillä koodivaihtoehtojen lisääntyessä tai mahdollisesti muuttuessa lisäykset ja muutokset voidaan tehdä suoraa tauluihin. on lisäksi suositeltavaa, että muunnostaulut on laadittu niin selkeiksi, että järjestelmien käyttäjät voivat tehdä niihin lisäyksiä ja muutoksia tarvittaessa ilman järjestelmätoimittajan työtä. On myös huomattava, ettei näissä kooditauluissa tarvitse olla kaikki vastaavan ISO-standardin tai UN/ECE-koodiston koodilistan mukaisia koodeja vaan ainoastaan ne koodit, joita järjestelmä ja sen käyttäjät tarvitsevat. Kuvassa on esitetty muunnostaulu, jota käytetään hyväksi muunnettaessa järjestelmän kuljetustapakoodeja UN/ECE suosituksen 19 mukaisiksi koodeiksi. Muunnostauluun on otettu mukaan vain neljä koodi, joita organisaatio tarvitsee toiminnassaan. Muut viisi UN/ECE suosituksen 19 mukaisista koodeista on jätetty taulukosta pois, koska organisaatio ei niitä toiminnoissaan tarvitse. 6/12

7 Kuva esimerkki koodimuunnostaulusta Toinen, vähemmän suositeltava tapa on ohjelmoida koodimuunnos poimittua tietoa muokkaavaan ohjelmaan. Tällöin jokainen koodilisäys tai muutos on tilattava järjestelmän toimittajalta, mikä voi pahimmillaan haitata elektronisen tiedon siirron käyttöönottoa uusien kauppakumppaneiden välillä. Koodimuunnosten lisäksi välitiedostoon on sen muodostamisvaiheessa liitettävä muita tietoja, jotka sanoman tai sen myöhemmän käsittelyn kannalta ovat oleellisia. Tällaisia tietoja voivat olla esimerkiksi OVT-tunnus, jonka avulla vastaanottajan järjestelmät tunnistavat lähettäjän tai muut sanomassa esitetyt osapuolet organisaatioina. Toisaalta lisättäviä tietoja voivat olla tullauksessa tarvittavat CN- tai HS-nimikkeet. Nämä tiedot on lisättävä välitiedostoon, jos niitä ei esiinny tietojärjestelmän tietokannoissa, joista ne voitaisiin poimia muiden tietojen poiminnan yhteydessä. Myös tällaisille sanomassa käytettäville lisätiedoille voidaan luoda tauluja, joihin tiedot on talletettu ja joista ne voidaan poimia tiettyjen kriteerien perusteella. Kuten koodimuunnoksessa, myös lisätietojen liittämisen tapauksessa taulujen käyttö on suositeltavampaa kuin tietojen tallettaminen muunnosohjelmaan Muunnos Välitiedoston muodostamisen jälkeen suoritetaan tiedostolle muunnos, jonka seurauksena tiedoston sisältämät tiedot ovat tietyn UBL-sanoman mukaisessa muodossa. Muunnosvaihe on esitetty kuvassa 6.1osassa MUUNNOS. Muunnoksessa tapahtuvaa välitiedoston muuntamista UBL-sanoman muotoon on havainnollistettu kuvalla Muunnoksen suorittaa yleensä tietty muunnosohjelmisto, johon muuntamiseen tarvittavat tiedot on kuvattu. Tämä tarkoittaa sitä, että muuntimelle on kuvattu toisaalta järjestelmistä siirrettävän välitiedoston rakenne ja toisaalta UBL-sanoman rakenne, joksi välitiedosto on tarkoitus muuntaa. Toisaalta järjestelmään on talletettava tiedot siitä, mistä hakemistosta muunnettava välitiedosto löytyy muunnettavaksi ja miten se tunnistetaan kyseisestä hakemistosta. Muunninjärjestelmään on myös kuvattava, miten se selvittää, miksi UBL-sanomaksi kyseisen välitiedoston tiedot on muunnettava. On oleellista, ettei muunnin pyri muodostamaan tilaustietoja sisältävän tiedoston tiedoista laskusanomaa. Muunninjärjestelmästä riippuen tämä tunnistus tapahtuu joko välitiedoston nimestä, hakemistosta, johon välitiedosto on talletettu, tai jonkin välitiedoston tiedon arvosta päätellen. Muuntimeen on kuvattu myös UBL-sanoma, joksi välitiedosto on muunnettava. Jotta UBL-sanoma olisi oikein muodostettu ja rakenteeltaan oikea, on suositeltavaa, että muunnin käyttää jossakin muunnosvaiheessa hyväkseen UBL-Scheemaa, jossa kyseisen UBL-sanoman rakenne ja sen elementtien tyypit on määritelty. Jos UBL-Scheemaa ei suoranaisesti käytetä hyväksi jokaisessa muunnoksessa, jonka muunnin suorittaa, on Scheemaa syytä käyttää hyväksi muuntimen määrittelyvaiheessa, jolloin voidaan välttyä virheiltä. Muuntimeen vahingossa jääneet virheet aiheuttavat virheellisen UBL-sanoman, jonka käsittely vastaanottajan muunninjärjestelmissä päätyy virheeseen. 7/12

8 Kuva Tietojen muuntaminen välitiedostomuodosta UBL-sanoman muotoon Mikäli välitiedostosta puuttuu joitakin UBL-sanoman kannalta oleellisia tietoja, on niistä tultava virheilmoitus muuntimelta. Yleensä toiminnassa olevien järjestelmien muodostamissa, testatuissa välitiedostoissa ja niiden muodostamisessa ei pitäisi esiintyä virheitä, mutta järjestelmiin tehdyt muutokset saattavat aiheuttaa virheitä. Muutostöiden yhteydessä voi nimittäin käydä niin, että välitiedoston testaus muutostöiden yhteydessä jää tekemättä. Toisaalta virhetilanne voi muodostua tilanteessa, jossa järjestelmän käyttäjä jättää syöttämättä tiettyjä tietoja, jotka sanoman kannalta ovat oleellisia. Tällainen tilanne voidaan välttää määrittelemällä tällaiset tiedot pakollisiksi järjestelmän näytöille Siirto Muuntimella luotu UBL-sanoma on tämän jälkeen siirrettävä sanoman vastaanottajalle tai tämän muunnospalvelujen tarjoajalle. UBL-sanoma sinänsä ei sisällä minkäänlaisia tietoja siitä, kenelle sanoma olisi lähetettävä. Voidaan ajatella, että paperidokumenttina UBL-sanomaa vastaa kirje, joka on kirjoitettu paperille. Kirje on suljettava kirjekuoreen, jonka päälle on kirjoitettava vastaanottajan nimi. Lähettäjäkin on yleensä hyvä merkitä kirjeen päälle. Samoin on laita siirrettäessä UBL-sanomia partnereitten välillä. UBLsanomaan on liitettävä tietoja, joiden avulla se voidaan lähettää vastaanottajalle. Nämä tiedot vastaavat paperisen kirjeen kirjekuorta ja sen päälle kirjoitettavaa vastaanottajan ja lähettäjän tietoja. Näitä liitettäviä tietoja nimitetään tiedonsiirron parametreiksi. Näiden liittäminen UBL-sanomaan saa aikaan siirtotiedoston, joka siirretään elektronisesti vastaanottajalle. Siirtotiedosto siis pitää sisällään varsinaisen UBL-sanoman sekä sen alkuun ja loppuun lisättyjä tietoja, joilla sanoma voidaan reitittää oikeaan paikkaan ja oikealle vastaanottajalle. Siirtotiedoston muodostamisen yhteydessä lisättäviin tietoihin sisällytetään myös siirtotiedoston muodostamisajankohta, joka toimii aikaleimana kuten postileima normaalissa kirjepostissa. Lisäksi jokaiselle siirtotiedostolle on syytä muodostaa oma yksilöivä tunnus, jolla siirtotiedosto voidaan myöhemmin tunnistaa ja jäljittää. On myös huomattava, että samassa siirtotiedostossa voi olla yksi tai useampia sanomia aivan samoin kuin kirjekuoressa voi olla useita kirjeitä. Siirtotiedoston rakennetta ja erilaisia elektronisia kirjekuoria on esitelty kappaleessa Siirtotiedosto. 8/12

9 Siirtotiedoston muodostamisen jälkeen tiedosto siirretään vastaanottajalle tai tämän operaattorille elektronisesti. Vastaanottajan kanssa on pitänyt sopia siitä, miten ja milloin siirto suoritetaan. Tiedonsiirron teknisiä ratkaisuja on esitetty kappaleessa Tiedonsiirron toteutus. Siirtotiedoston lähetyksestä on sen lähettäjälle jäätävä tieto. Tätä varten lähettäjän on pidettävä itsellään lokia, johon lähettyjen siirtotiedostojen tunnukset, vastaanottajatiedot ja siirtoajankohdat tallentuvat. Esimerkki lokitiedoston muodosta on esitetty kuvassa On huomattava, että siirtotiedoston siirtoajankohta voi poiketa siirtotiedoston muodostamisajankohdasta. Tätä lokia selaamalla voi lähettäjä myöhemmin selvittää, milloin tiettyjä UBL-sanomia on lähetetty ja kenelle. Jos lähettäjä käyttää operaattorin palveluja, on operaattorilta vaadittava lokin ylläpitoa. Loki on tarpeellinen esimerkiksi silloin, kun siirto jostakin syystä epäonnistuu, eikä vastaanottaja saakaan lähetettyä tiedostoa. Lokin avulla lähettäjä pystyy selvittämään, milloin kyseinen tiedosto on lähetetty ja mikä sen tunnus oli. lokilla olisi myös oltava tieto siitä, onnistuiko siirto siihen siirtoreitin kohtaan asti, johon lähettäjä tai tämän operaattori on siirrosta vastuussa. Jotkin tahot, kuten Tulli, vaativat lokin käyttöä, sillä tämän avulla voidaan todistaa tiettyjen tullaustietojen lähetys säädettyjen aikataulujen puitteissa. On myös huomattava, että yleisten käytäntöjen ja säännösten mukaan, joita on luotu elektroniseen tiedonsiirtoon, lokin todistusvoimaisuutta ei voida kyseenalaistaa. Täten riitatilanteissa, jotka mahdollisesti syntyvät siirtotiedostojen katoamisen ja täten tietojen vastaanoton ja niiden synnyttämien toimintojen estymisen vuoksi, lokia käytetään todistusaineistona. Tämä tarkoittaa myös sitä, ettei lokitiedostoa saa mennä muokkaamaan. Kuva : Esimerkki lähetettävien siirtotiedostojen lokitiedostosta Ennen kuin siirtotiedosto siirretään vastaanottajalle, on siitä syytä ottaa kopio. Tämä on syytä tehdä useammastakin syystä. Jos siirto syystä tai toisesta epäonnistuu, voidaan uusi siirtoyritys tehdä siirtämällä vastaanottajalle kopio jo aiemmin kopioidusta siirtotiedostosta. Tämä nopeuttaa ja helpottaa siirtoa. Toisaalta aikaisemman, hävinneen siirtotiedoston sisältämien sanomien tietoja voi olla vaikea jälkikäteen saada sovelluksista. Tiedot voivat olla jo toiminnan seurauksena muuttuneet ja lisäksi sovelluksesta riippuen tietojen uudelleen poiminta järjestelmistä voi olla hankalaa. Lisäksi tilanne, jossa tiedot pitää uudelleen poimia järjestelmistä, vaatii yleensä järjestelmien käyttäjän osallistumista poiminnan käynnistämiseen. Tämä hidastaa siirtotiedoston lähettämistä vastaanottajalle. Kiireellisissä toimitustilanteissa tällaista koko siirtoketjun läpikäyntiä ei edes voida tehdä. Lisäksi siirtotiedoston kopiolla voidaan riitatilanteessa osoittaa, mitä vastaanottajalle oltiin lähettämässä tai lähetetty. Jos vastaanottajan järjestelmät käsittelevät aineiston väärin ja tämä aiheuttaa esimerkiksi vääränlaisen toimituksen, voidaan siirtotiedoston kopiosta aina tarkastaa se, mitä vastaanottajalle lähettiin. Lähettäjä, joka ei ota kopioita lähettämistään siirtotiedostoista eikä talleta niitä tarpeeksi pitkiä aikoja, on riitatilanteissa erittäin huonossa asemassa. Siirtotiedosto ja sen sisältö vastaa paperipohjaisessa kauppatapahtumassa paperisia asiakirjoja. 9/12

10 6.2 Vastaanottoprosessi Vastaanotettaessa tietoa vastaanottoprosessiprosessi voidaan jakaa kolmeen eri osaan: siirto, muunnos ja talletus. Kuvassa on esitetty nämä vaiheet sekä niihin sisältyvät toiminnot. Yleensä ottaen voidaan todeta, että UBL-sanoman vastaanottamiseen sisältyy enemmän vaiheita kuin sen lähettämiseen. Tämä johtuu lähinnä siitä, että vastaanottajan on pystyttävä automaattisesti hyväksymään ja ymmärtämään lähetetyn aineiston sisältö ja looginen oikeellisuus, jotta saapuneita tietoja vastaava toiminta voidaan käynnistää. 10/12

11 Kuva Elektronisen tiedonsiirron vastaanottoprosessi 11/12

12 6.2.1 Siirto Vastaanotettaessa UBL-sanomia sisältävää siirtotiedostoa, joka saapuu vastaanottajalle tai tämän käyttämälle operaattorille sovittua tiedonsiirtomenetelmää käyttäen, on vastaanottajan tunnistettava lähettäjä. Tämä tapahtuu siirtotiedostossa olevan lähettäjä-tiedon perusteella. Jos lähettäjä tunnistetaan ja tämän kanssa on sovittu elektronisesta tiedonsiirrosta, voidaan siirtotiedostosta poistaa lähetyksen aikaiset tiedot, jotka liitettiin siihen lähetettävän siirtotiedoston muodostamisen yhteydessä. Purkamisen seurauksena vastaanottajalla on käytössään yksi tai useampi UBL-sanoma, jotka saapuivat siirtotiedostossa. Jos lähettäjän tarkastamisen tuloksena havaitaan, että lähettäjällä ei ole oikeutta lähettää sanomia vastaanottajalle tai jos siirtotiedostoa ei ole tarkoitettu ollenkaan vastaanottajalle, siis sen sisältö ei vastaa sovittua tai tiedosto on tullut kokonaan väärälle vastaanottajalle, on saapunut tiedosto tuhottava ja tiedoston lähettäjälle on tavalla tai toisella pyrittävä ilmoittamaan havaitusta virheestä. Olipa vastaanotettu tiedosto tarkoitettu vastaanottajalle tai ei, on siitä jäätävä tieto vastaanottajan ylläpitämälle lokille samaan tapaan kuin lähetettäessä tiedostoja. Tämän lokin avulla vastaanottaja voi myöhemmin selvittää, mitä tiedostoja se on vastaanottanut, milloin ja kuka on tiedoston lähettäjänä. Lokitiedostoon kirjautuu tieto vastaanottoajasta. Jotkut tahot, kuten esimerkiksi Tulli, vaativat lokitiedoston käyttöä, jolla voidaan myöhemmin osoittaa, että vastaanottaja on saanut tiettynä aikana siirtotiedoston. Myös riitatilanteissa lokin tiedot ovat todistusaineistona tiedostojen saapumisesta tai saapumatta jäämisestä. Kuviossa on esitetty esimerkki vastaanottolokista. Kuva : Esimerkki vastaanotettavien siirtotiedostojen lokitiedostosta 7 Opastavat tiedot Tätä suositusta ylläpitää Julkisen hallinnon tietohallinnon neuvottelukunta JUHTA, puh (09) , sähköposti jhs-sihteeri@intermin.fi. Sisäasianministeriö / JUHTA PL Valtioneuvosto 12/12