Logistiikan sähköiset toimintatavat ovat edellytys virheettömälle, laadukkaalle ja kustannustehokkaalle kuljetustoiminnalle. Sähköiset kuljetustiedot auttavat kuljetuspalvelujen tuottajia toteuttamaan oman osuutensa logistiikkaketjussa, mikä takaa loppuasiakkaallehyvän palvelutason. Liian moni lähetys harhautuu ja/tai myöhästyy nykyään puutteellisten tai epäselvien kuljetustietojen vuoksi.
Logistiikan sähköinen tietopaketti on ensisijaisesti suunnattu kuljetus- ja logistiikkayritysten asiakkaille, jotka haluavat aloittaa sähköisen asioinnin kuljetusyritysten kanssa tai parantaa nykyistä toimintatapaa.
Tietopaketti antaa yleistietoa sähköisen toimintatavan käytöstä kuljetuslogistiikan tehostamisessa.
Oppaaseen on laadittu ”kilometripylväitä” jotka realisoituvat standardiasiakirjoina ja sähköisinä sanomina, joiden avuilla välitetään tietoa muille liiketoimintakumppaneille. Tietopaketissa käydään muun muassa läpi kolme vaihtoehtoista tapaa aloittaa sähköisen kuljetustiedon käyttöön siirtyminen sekä sähköiseen tiedonsiirtoon liittyviä tekniikoita, standardeja ja toimintatapasuosituksia.
TIEKE on koonnut Logistiikan sähköisen tietopaketin liikenne- ja viestintäministeriön sekä Logistiikkayritysten Liiton toimeksiannosta.
Logistiikan merkitys yrityksen kilpailukyvylle, asiakaspalvelun tasolle ja toiminnan kannattavuudelle on huomattava – Logistiikkaselvitys 2010 mukaan tätä mieltä on yli 90%:a suurista ja keskisuurista kaupan- ja teollisuudenalan yrityksistä. Logistiikkakustannusten osuus on lähes 12 % yritysten liikevaihdosta, pitäen sisällään myös ulkomailla aiheutuneet kustannukset. Pienissä ja mikroyrityksissä logistiikan vaikutusta kustannuksiin ja yrityksen kannattavuuteen ei mielletä yhtä suureksi, mutta asiakaspalvelun merkityksen osalta ollaan lähempänä samoja lukemia suurten yritysten kanssa.
Tietojärjestelmien ja tiedonhallinnan osaamisen sekä suorituskyvyn kuilut todeataan Logistiikka-selvityksessä kohtuulisen kapeiksi, siten että mitä pienempi yrityskoko sen pienemmäksi koetaan osaamisen ja suorituskyvyn olemassa olevan tason ja tarpeen välimnen ero. Yritysten ja opetushenkilökunnan näkemyserot suorituskykykuilun olemassaolosta ovat suurimmillaan juuri logistiikan ja tuotannonohjauksen tietojärjestelmien osalta.
Logistiikan tiedonhallinta ja tietojärjestelmät on ulkoistettu osittain tai kokonaan noin 40 %:ssa kaupan ja teollisuuden yritykstä. Ulkoistamisvauhti on ollut kuitenkin ennakoitua hitaampaa ja jopa lievästi hiipunut.
TIEKE suoritti vuoden 2010 lopussa liikenne- ja viestintäministeriön Älylogistiikkaohjelmaan liittyen kyselyn kuljetusasiakkaitten joukossa. Kyselyssä selvitettiin kuljetusasiakkaitten sähköisten menettelyjen ja sähköisen tiedonsiirron käyttöä. Erityisesti selvitettiin kuljetustilauksen, lähetystietojen (rahtikirja) ja toimitustietojen (vastaanottotiedot) käyttöä. Kyselyn tuloksista voitiin todeta, että sähköistä tiedonsiirtoa käytetään eniten lähetystietojen toimittamiseen. Kuljetustilauksen osalta sähköisten menettelyjen käyttö oli hyvin vähäistä ja kuljetusten tilaaminen tapahtuukin useimmiten puhelimitse, myös vakionoutoa käytetään melko runsaasti. Merkillepantavaa on, että kuljetusyritysten tarjoamat internet-tilauspalvelut ovat saamassa kasvavaa suosiota.
Tiedon sekä järjestelmätuen puute esiintyivät vastaajien suurimpana esteenä sähköisten toimintatapojen käytölle kaikilla osa-alueilla. Monet yritykset eivät yksinkertaisesti näe tarvetta sähköisten toimitapojen käytölle, tähän esitetään syyksi mm. pienet volyymit. Ne yritykset jotka käyttävät sähköisiä toimintatapoja ilmoittavat käytön syiksi ja eduiksi ennen kaikkea helppouden, vaivattomuuden ja virheettömyyden.
Logistiikan merkitys yrityksen kilpailukyvylle, asiakaspalvelun tasolle ja toiminnan kannattavuudelle on huomattava – Logistiikkaselvitys 2010 mukaan tätä mieltä on yli 90%:a suurista ja keskisuurista kaupan- ja teollisuudenalan yrityksistä. Logistiikkakustannusten osuus on lähes 12 % yritysten liikevaihdosta, pitäen sisällään myös ulkomailla aiheutuneet kustannukset. Pienissä ja mikroyrityksissä logistiikan vaikutusta kustannuksiin ja yrityksen kannattavuuteen ei mielletä yhtä suureksi, mutta asiakaspalvelun merkityksen osalta ollaan lähempänä samoja lukemia suurten yritysten kanssa.
Tietojärjestelmien ja tiedonhallinnan osaamisen sekä suorituskyvyn kuilut todeataan Logistiikka-selvityksessä kohtuulisen kapeiksi, siten että mitä pienempi yrityskoko sen pienemmäksi koetaan osaamisen ja suorituskyvyn olemassa olevan tason ja tarpeen välimnen ero. Yritysten ja opetushenkilökunnan näkemyserot suorituskykykuilun olemassaolosta ovat suurimmillaan juuri logistiikan ja tuotannonohjauksen tietojärjestelmien osalta.
Logistiikan tiedonhallinta ja tietojärjestelmät on ulkoistettu osittain tai kokonaan noin 40 %:ssa kaupan ja teollisuuden yritykstä. Ulkoistamisvauhti on ollut kuitenkin ennakoitua hitaampaa ja jopa lievästi hiipunut .
TIEKE suoritti vuoden 2010 lopussa liikenne- ja viestintäministeriön Älylogistiikkaohjelmaan liittyen kyselyn kuljetusasiakkaitten joukossa. Kyselyssä selvitettiin kuljetusasiakkaitten sähköisten menettelyjen ja sähköisen tiedonsiirron käyttöä. Erityisesti selvitettiin kuljetustilauksen, lähetystietojen (rahtikirja) ja toimitustietojen (vastaanottotiedot) käyttöä. Kyselyn tuloksista voitiin todeta, että sähköistä tiedonsiirtoa käytetään eniten lähetystietojen toimittamiseen. Kuljetustilauksen osalta sähköisten menettelyjen käyttö oli hyvin vähäistä ja kuljetusten tilaaminen tapahtuukin useimmiten puhelimitse, myös vakionoutoa käytetään melko runsaasti. Merkillepantavaa on, että kuljetusyritysten tarjoamat internet-tilauspalvelut ovat saamassa kasvavaa suosiota.
Tiedon sekä järjestelmätuen puute esiintyivät vastaajien suurimpana esteenä sähköisten toimintatapojen käytölle kaikilla osa-alueilla. Monet yritykset eivät yksinkertaisesti näe tarvetta sähköisten toimitapojen käytölle, tähän esitetään syyksi mm. pienet volyymit. Ne yritykset jotka käyttävät sähköisiä toimintatapoja ilmoittavat käytön syiksi ja eduiksi ennen kaikkea helppouden, vaivattomuuden ja virheettömyyden.
Suomessa kuljetustoimiala, erityisesti maatiekuljetuksen osalta on varsin hajanainen, perustuen muutaman suuren ketjun ja lukuisten pienten yritysten palvelutarjontaan. Muun muassa kentän hajanaisuudesta johtuen yhdenmukaisten toimintatapojen käyttöönotto kuljetusalalla on hyvin puutteellista: Suurtenkin toimijoiden esittelemät ratkaisut ovat olleet toisistaan poikkeavia. Tämä on myös näkyvissä logistiikan sähköisten toimintatapojen ja niiden käyttöönoton alueella. Tilanne on haastava, ei yksin kuljetusyrityksille vaan myös heidän asiakkailleen.
Logististen toimintojen kehittyessä yritysten välillä olevat taloudelliset verkostot tiivistyvät ja kilpailukykyä sekä kannattavuutta haetaan omaa toimintaa tehostamalla. Samalla pyritään pitämään yllä entistä tiiviinpää yhteyttä liiketoimintakumppaneihin. Toimitussyklit nopeutuvat ja vasteaikavaatimukset kiristyvät, liikekumppanit vaativat entistä tarkempaa ja nopeampaa lähetysten tilan seurantaa ja raportointia.
Kokonaisratkaisua näihin haasteisiin ei voida toteuttaa millään yksittäisellä toimenpiteellä, vaan toiminnan tehostamista on etsittävä kaikilta osa-alueilta. Ratkaisua voidaan lähteä etsimään toimintatapojen yhdenmukaistamisen ja harmonisoimisen alueelta yrityksen koko toimintaketjussa. Keskeisellä sijalla tässä työssä on toimitusketjun tietotarpeiden määrittely ja tietosisältöjen harmonisointi siten, että samaa tietoa voidaan käyttää toimitusketjussa samanmuotoisena mahdollisimman laajasti. Tämän jälkeen voidaan siirtyä toimintatapojen sähköistämiseen ja sähköiseen tiedonsiirtoon.
Toimitusketjun tietosisältöjen määrittelyä ja sähköisen toimitavan käyttöönottoa varten on laadittu ”kilometripylväitä” jotka realisoituvat standardiasiakirjoina ja sähköisinä sanomina, joiden avuilla välitetään toimitusketjua ohjaavaa ja toteutumista raportoivaa tietoa muille asianomaisille liiketoimintakumppaneille.
Sähköisen toimintatavan edut nousevat perinteisesti parhaiten esiin suhteelliseen vakiintuneessa liiketoimintaympäristössä, jossa kumppaneiden välillä liikkuu runsaasti tietoa, mutta uudet XML- ja internet-pohjaiset ratkaisut tuovat joustavuutta kommunikointiin ja pienilläkin tiedonsiirtosiirtotarpeilla voidaan saavuttaa tehokkuutta sekä kustannushyötyjä ja parempaa laatua.
Sähköisestä toimintatavasta logistiikassa on runsaasti hyötyjä. Käyttöön otolla on vaikutusta sekä kuljetusasiakkaan että kuljetusyrityksen toimintaan. Seuraavassa on listattuna syitä miksi kuljetuspalveluja käyttävälle yritykselle on edullista ottaa sähköinen toimintatapa käyttöön:
- vähentää virheitä ja manuaalisia työvaiheita,
- tehostaa logistiikkatyötä ja alentaa kustannuksia,
- mahdollistaa kuljetusketjut ja kuljetusten yhdistelyn tehokkaan hallinnan ja seurannan,
- luo perustaa logistiikka-alan palvelujen kehittymiselle tulevaisuudessakin,
- edistää sähköisten toimintatapojen käyttöönottoa pienissä ja keskisuurissa yrityksissä,
- tehostaa (kuljetus)yritysten välistä yhteistyötä,
- luo alalle kilpailua ja kehittää logistiikkapalvelutarjontaa,
- parantaa suomalaisten kuljetusyritysten ja Suomen logistista kilpailukykyä,
- ehkäisee harmaata taloutta sekä
- vähentää kuljetusten ympäristöhaittoja ja hillitsee ilmastonmuutosta.
[1] Logistiikkaselvitys 2010, liikenne- ja viestintäministeriön julkaisuja 36/2010
- tavaroiden kuljetusta ja käsittelyä varten tarvittavat tiedot löytyvät standardirahtikirjasta
- varmistaa kuljetussopimuksen
- toimii adapterina manuaalisen ja sähköisen prosessin välillä (ei sulje pois sähköisen tiedonsiirron käyttöä)
- standardirahtikirjan täyttöohjeet löytyvät standardin soveltamisohjeesta
Standardirahtikirjan käyttö on välivaihe siirryttäessä kohti sähköistä toimitusketjua. Standardirahtikirjan käytön edut ovat selkeät niin kuljetusasiakkaalle kuin rahdinkuljettajallekin. Kuljetusasiakkaalle standardirahtikirjan käyttö varmistaa sen että kaikki kuljetuksen perille toimittamiseen tarvittava tieto sekä ohjeet siitä miten kuljetus tehdään tulevat kirjattua ja tiedoksi rahdinkuljettajalle. Rahtikirja toimii myös kuljetussopimuksen vahvistavana dokumenttina.
Kuljetusyritykselle oikein täytetty standardirahtikirja antaa kaiken tarvittavan tiedon toimituksen suorittamista varten sekä tarvittavat tiedot kuljetettavista tuotteista niiden asianmukaista käsittelyä varten.
Sen lisäksi että standardirahtikirjassa on varattu paikka ja määritetty sijainti kaikille tarvittaville tiedoille, on tietojen ilmoittamiselle varattu sovittu kenttäpituus (merkkimäärä), joten tiedot voidaan helposti siirtää paperiasiakirjasta sähköiseen järjestelmään. Standardirahtikirja toimikin eräänlaisena adapterina paperitoimintojen ja sähköisten järjestelmien välillä. Standardirahtikirja suositellaan aina täytettäväksi koneellisesti tai tulostettavaksi tietojärjestelmästä.
Suomen Standardisoimisliitto SFS:n julkaisema uusi rahtikirjalomake SFS 5865 on päivitetty vuoden 2010 lopulla ja se on aiempaa käytännönläheisempi ja vastaa paremmin kuljetusten muuttuneita tarpeita, kuten yhteensopivuutta sähköisen tiedonsiirron kanssa. Päivitystyön yhteydessä myös standardin soveltamisohjeita on täsmennetty.
Tärkeimmät muutokset uudessa rahtikirjalomakkeessa ovat:
- kuljetuksen osapuolitietojen selkiyttäminen, kuljetusohje -kentän sijaintimuutos ja kahden eri lomakevaihtoehdon mahdollistaminen.
- Osapuolitiedoissa on nyt neljä osoitetietoaluetta entisen viiden sijaan. Lisäksi ne on ryhmitelty nyt järjestykseen ”Lähettäjä”, ”Vastaanottaja”, ”Lähtöpaikka” ja ”Määräpaikka”.
- Kuljetusohje-kenttä on siirretty lomakkeen yläosaan Rahdinkuljettaja-kentän alapuolelle, josta se näkyy myös rahtikirjalomaketta taitettuna käsiteltäessä.
Uuden standardirahtikirjan toinen lomakevaihtoehto on ns. laajennetun keskiosan rahtikirja, jossa rahdin ja jälkivaatimuksen maksukentät on poistettu ja lisätty tavararivejä niiden tilalle. Tällaista rahtikirjalomaketta voidaan käyttää asiakas- ja kuljetusliikekohtaisesti, kun maksuerittelyille ei ole tarvetta. Kuva uudesta SFS 5865 rahtikirjalomakkeesta on tämän oppaan liitteessä 1.
Rahtikirjastandardia SFS 5865 voi tilata Suomen standardisoimisliitosta http://sfs.fi tai suoraan SFS:n verkkokaupasta http://sales.sfs.fi/
• ainutkertaiset rahtikirjanumerot ja rahtikirjojen yksilöitävyys ovat edellytys sähköiselle toimintatavalle
• selkeyttää ja nopeuttaa tavaroiden ja tietojen käsittelyprosessia
• mahdollistaa lähetysten seurannan kuljetusyrityksen verkkopalvelussa ja toimitusilmoituksen lähettämisen
• tavoitteena että rahtikirjan yksilöllinen numerointi on käytössä 1.1.2012 alkaen.
Sähköisessä tiedonsiirrossa ja tietojenkäsittelyssä tietojen ja niiden muodostamien sähköisten dokumenttien yksilöitävyys on edellytys järjestelmän sujuvalle toiminnalle. Tämä toteutuu erityisesti rahtikirjan osalla, koska tehokkaiden ja virheettömien toimitusten varmistamiseksi kuljettavat lähetykset on voitava helposti ja nopeasti yhdistää toimitusta ohjaavaan tietoon toimitusketjun eri osapuolten toiminnoissa ja järjestelmissä.
Tavarat (kolliosoitelappu), toimituserä (rahtikirja) ja niihin liittyvät sähköisessä muodossa olevat tiedot pitää voida yhdistää toisiinsa sekä tietojärjestelmissä että esimerkiksi tavaraterminaalissa.
Ainutkertaisten rahtikirjanumeroiden käytöllä voidaan välttää tilanne jossa kuljetusliikkeen terminaaliin tulee, esimerkiksi vuodenvaihteen jälkeen, yhtä aikaa jopa kymmeniä rahtikirjoja joiden numero on 100, 1000 tai 10000. Ainutkertaisten rahtikirjanumeroiden avulla on myös mahdollista nopeasti tunnistaa tavaran lähettäjä tai jäljittää harhautunut lähetys. Ainutkertainen rahtikirjanumerointi tarjoaa myös tarvittavat tiedot lähetysten tosiaikaisen seuranta- ja toimitustilannepalvelun toteutukselle esimerkiksi kuljetusyrityksen verkkosivuilla tai tiedon toimitusilmoituksen lähettämiseen kuljetuksen tilaajalle tai muulle sovitulle osapuolelle.
Suomessa ainutkertaisia rahtikirjanumeroita on mahdollista saada Suomen Osto- ja Logistiikka-yhdistyksen verkkopalvelusta http://www.rahtikirjanumerot.fi
Suomen Osto- ja Logistiikkayhdistys LOGY ry on muuttanut rahtikirjanumeropalvelunsa nettipohjaiseksi. Uudistuksella tuetaan tavoitetta koko toimitusketjun sähköistämiseksi. Numeropalvelusta voi tilata ainutkertaisia rahtikirjanumeroita rekisteröitymällä palvelun käyttäjäksi ja antamalla rahtikirjanumeroita tilaavan yrityksen ja yhteyshenkilön yhteystiedot. Ennen numerointia kontrolloitiin manuaalisesti, mutta uudessa nettipalvelussa hakukone valitsee automaattisesti numerot ja pitää yllä rekisteriä.
Uudessa 12-numeroisessa rahtikirjanumerossa kolme ensimmäistä numeroa on varattu järjestelmän käyttöön ja seuraavat 8 numeroa ovat vaihtuvia. Numerosarjan viimeisenä on tarkistenumero. Se lasketaan samalla periaatteella kuin pankkimaksujen viitenumeroissa[2]. Järjestelmässä luotujen rahtikirjanumeroiden yksilöllisyys perustuu rekisteröityneen käyttäjän Y-tunnukseen.
Palvelun rahtikirjanumerot ovat voimassa 18 kuukautta tilauspäivästä. Tilaajien toivotaan arvioivan yrityksessään kirjoitettavien rahtikirjojen määrä ja niissä tarvittava numerotarve. Tilausjärjestelmässä rahtikirjanumeroiden kertatilauksen vakiomääriä ovat 1 000, 2 000, 5 000, 10 000, 20 000 ja 50 000 kappaletta. Lisäksi voi vapaavalintaisesti tilata suurempia määriä rahtikirjanumeroita. Ainutkertainen rahtikirjanumero on maksullinen tuote ja hintatiedot löytyvät Suomen Osto- ja Logistiikka-yhdistyksen verkkopalvelusta aiemmin mainitusta linkistä.
[2] Tarkistenumeron laskenta: Ensimmäiset 11 numeroa kerrotaan oikealta vasemmalle painoilla 7, 3, 1, 7, 3, 1,… saadut tulot lasketaan yhteen ja summa vähennetään seuraavasta täydestä kymmenestä. Jos erotus on 10, merkitään se nollaksi.
- kolliosoitelappu on linkki toimitustiedon (rahtikirja) ja kuljetettavan tavaran (kollit) välillä
- käytetään kollien tunnistamiseen ja jäljitykseen toimitusketjun eri vaiheissa
- viivakoodin/RFID:n avulla toimii linkkinä sähköisen tiedon ja kuljetettavan tavaran välillä
- monet kuljetusohjelmistot ja palvelut pystyvät tuottamaan myös kolliosoitelapun.
- oikea käyttö vähentää toimitusvirheitä
Suurimmassa osassa yritysten lähettämistä kolleissa on osoitelappu, joka sisältää kuljetusta ohjaavia tietoja. Ongelmia syntyy, kun osoitelapun sisältämät tiedot ovat puutteellisia, epäselviä tai harhaanjohtavia. Yrityksillä on käytössä hyvin monenlaisia ja eri kokoisia osoitelappuja. Lisäksi niiden sijainti kollissa ei aina ole sitä käsittelevän henkilön tai lajittelukoneen kannalta paras mahdollinen. Osoitelapun tulisi olla kaikissa kolleissa aina samassa paikassa ja asetettuna kolliin siten, että se on helposti luettavissa – ensisijaisesti kollin sivulle.
Jos kolliosoitelapun tiedot ovat puutteellisia turhaa aikaa ja rahaa kuluu tarvittavien tietojen selvittämiseen ja virheiden korjaamiseen. Lähetykset eivät aina löydä perille oikeaan osoitteeseen ja sovittuun aikaan. Uudelleen lähettäminen aiheuttaa lisätyötä ja se saattaa myös vahingoittaa lähetyksiä. Kustannuksia syntyy niin lähettäjille, kuljettajille kuin vastaanottajillekin.
Kansainvälisen ISO -standardin pohjalta on kehitetty selkeä osoitelappu, joka on jo käytössä muun muassa Ruotsissa ja Norjassa. Tämä standardoiduksi kolliosoitelapuksi kutsuttu osoitelappu sisältää tiedot, jotka tarvitaan mahdollisimman luotettavan kuljetuksen takaamiseksi. Standardoitu kolliosoitelappu on yhdenmukainen GS1:n kolliosoitelapun kanssa ja hyödyntää mm. SSCC-koodia.
Kuva: Standardoitu kolliosoitelappu
Standardoidun kolliosoitelapun voi ottaa käyttöön mikä tahansa yritys, jolla ei ole omaa yhtä selkeää kolliosoitelappua käytössään. Joillakin isommilla yrityksillä on myös omia, usein samaan standardiin perustuvia kolliosoitelappuja, joissa on otettu yrityksen erityistarpeet huomioon[3].
Kolliosoitelappu on linkki toimitustiedon (rahtikirja) ja kuljetettavan tavaran (kollit) välillä, samalla se toimii viivakoodin avulla myös linkkinä sähköisen tiedon ja kuljetettavan tavaran välillä. Monet kuljetusohjelmistot ja palvelut pystyvät tuottamaan rahtikirjatiedon avulla myös kolliosoitelapun.
Vieressä olevassa havainnekuvassa on esitetty kollilapun asettelumalli ja kolliosoitelapun tietosisältö. Tiedoista osa on pakollisia osa valinnaisia.
Kollilappu sisältää:
- Mistä –kentän (pakollinen)
- EDI –tiedonsiirtomerkintä (valinnainen)
- Päivämäärä (valinnainen)
- Minne –kentän (pakollinen)
- Kuljetusohjeet (valinnainen)
- SSCC (pakollinen)
- Lähetys/Tilaus tunnisteen (valinnainen)
- Kolliluku (pakollinen)
- Paino (pakollinen)
- Viivakoodi ja sovellustunnus + SSCC (pakollinen)
Lisätiedot ja ohjeistus kolliosoitelapun tarkoista mitoista, asettelusta ja sijoittamisesta kolleihin löytyvät Standardoitu kolliosoitelappu –oppaasta: http://www.tieke.fi/mp/db/file_library/x/IMG/12388/file/Raportti_fits27_20032.pdf ja GS1:n sivuilta.
[3] Tässä oppaassa esitetty standardoitu kolliosoitelappu ei sovellu sellaisenaan esimerkiksi Itellan prosessiin. Erityistarpeiden selvittäminen ja standardoidun kolliosoitelapun käyttöönotto kannattaa aina tehdä yhdessä yrityksen logistiikkapartnerin kanssa.
- käytetään kuljetusyksiköiden tunnistamiseen, toimitusten seurannassa ja jäljityksessä toimitusketjun eri vaiheissa
- voidaan esittää viivakoodilla tai RFID-tunnisteella
- voidaan käyttää myös silloin kun lähetys koostuu ominaisuuksiltaan erilaisista tuotteista
- vähentää toimitusvirheitä
- asiakaspalvelu paranee
SSCC on standardimuotoinen tunnistenumero, jota käytetään kuljetus- ja/tai varastointiyksikön tunnistamiseen. GS1 on kehittänyt SSCC -koodin vastaamaan päivittäis- ja erikoistavarakaupan tarpeisiin. Se on suunniteltu niin, että sitä pystytään hyödyntämään erilaisissa käyttökohteissa ja kaikissa toimitusketjun vaiheissa. SSCC = Serial Shipping Container Code = Sarjatoimitusyksikkökoodi.
Tuotteiden valmistajat tai alihankkijat voivat käyttää SSCC -koodia tuotannon ja varastonhallintaan sekä asiakirjojen teon ja muiden toimintojen helpottamiseen. SSCC-koodin sisältävä viivakoodi voidaan liittää jo tuotantolinjalla muodostettuihin tuotepakkauksiin. Tavarankuljettaja voi käyttää SSCC-koodia sisäisessä sekä yritysten välisessä tavaroiden jäljittämisessä ja valvonnassa. Tavaran vastaanottaja voi lukea koodit saapuvista tavaroista. Luettuja tietoja verrataan tietojärjestelmässä oleviin tietoihin siitä, mitä piti saapua.
SSCC -koodissa käytetään GS1-128 viivakooditekniikkaa[4]. SSCC -koodi on logistisen yksikön (esim. lava- tai kolliosoitelapun) pakollinen tieto.
Esimerkki: (00) 1 64YYYYYYY 0000001 T
00 = Sovellustunnus (käytetään aina kun SSCC sijoitetaan GS1 viivakoodiin)
1 = Laajennustunnus (vapaavalintainen luku 0-9 väliltä)
64YYYYYYY = GS1 yritystunniste (7- tai 9-numeroa pitkä, voi olla myös 6-numeroa)
0000001 = Sarjanumero (suositellaan juoksevaa numerointia)
T = Tarkistusnumero (lasketaan modulo 10 laskentasäännön mukaan, GS1:n nettisivuilta löytyy myös tarkistusnumerolaskuri)
SSCC-koodin edessä olevaa sovellustunnusta tarvitaan vain viivakoodia käytettäessä tai SSCC-koodia välitettäessä. Se on aina 00, ja kertoo että kyseessä on sarjatoimitusyksikkö.
SSCC –koodin muodostaa osapuoli, joka muodostaa yksilöitävän kuljetusyksikön. Koodin muodostaminen aloitetaan laajennustunnuksella, jonka avulla kasvatetaan SSCC-koodin numerointikapasiteettia. Laajennustunnus on arvoltaan 0-9,jonka yritys voi itse päättää. Laajennustunnuksen jälkeen laitetaan yritystunnus jonka GS1 Finland myöntää yrityskohtaisesti. Sarjanumeroksi suositellaan juoksevaa numeroa. Viimeiseksi numeroksi lasketaan tarkistusnumero.
Kuva: EPC-96 SSCC-koodin ja GS1 SSCC-viivakoodin tietojen vastaavuus
SSCC koodi voidaan esittää myös RFID tunnisteena, jolloin SSCC-koodin lukemisen ei tarvita fyysistä näkyvyyttä. EPCGlobal[5] on kehittänyt EPC (Electronic Product Code) –standardin tuotteiden ja kuljetusyksiköiden tunnistamiseen. Tätä standardia käytetään RFID –tekniikassa (Radio Frequency Identifier) siten, että RFID-tunnisteella on talletettu kuljetusyksikköä identifioivat tiedot.
Periaatteet SSCC:n käytöstä toimitusketjussa:
1.Ketjun edellinen toimija lähettää seuraavalle ensin tiedon (esim. DESADV -sanoma) ja sitten tuotteen. Lähetystiedot perustuvat aina lastausvaiheen tietoon, eivät oletukseen, mitä piti lastata.
2.Tieto – liittyen mm. tilaukseen, laskutukseen, kuittaukseen tai poikkeamaan – välitetään sähköisessä muodossa (EDI) läpi koko ketjun.
3.Tavarantoimittaja tuottaa SSCC:n, jota hyödynnetään läpi koko ketjun sekä yritysten sisäiseen ohjaukseen että koko toimitusketjun hallintaan.
4.Verrataan vastaanotettua tavaraa ja siitä luettua viivakoodia ennakkoon saapuneeseen tietoon. Kuittaukset, laskut, poikkeamaraportit jne. perustuvat näiden kahden tiedon vertaamiseen.
5.SSCC luetaan aina tuotteen siirtyessä organisaatiorajojen yli. Koodi voidaan lukea myös yrityksen sisäisen ohjauksen tarpeita varten.
6.SSCC- koodi säilyy koko logistisen yksikön elinkaaren ajan samana. Elinkaari päättyy jos logistiseen yksikköön tehdään sisältöön vaikuttavia muutoksia (lisätään, vähennetään tai muuten muutetaan sisältöä). Tällöin logistiselle yksikölle tulee antaa uusi SSCC-koodi.
SSCC koodin käyttämiseksi yritys tarvitsee GS1-yritystunnisteen, joita myöntää GS1 Finland Oy. Yritystunniste on maksullinen ja sen hinta koostuu myöntämismaksusta ja vuosittaisesta käyttömaksusta. Samalla yritystunnisteella voidaan muodostaa myös muita GS1 yksilöinnin avaimia (mm. GTIN, GLN, GINC) ilman lisämaksuja Hintatiedot löytyvät GS1 Finland Oy:n sivuilta.
Lisätietoja kuljetusyksiköiden merkitsemisestä:
[4] GS1 -128 ja esim. rahtikirjanumeron viivakoodissa käytetävää code -128 viivakooditekniikkoja ei pidä sotkea keskenään
[5] EPCGlobal on osa GS1 organisaatiota
Miten aloittaa logistiikkatietojen sähköinen lähettäminen
- kuljetustietojen sähköisen lähettämisen aloittaminen on helppoa
- sähköiseen toimintaan löytyy useita erilaisia työkaluja
- valitse tarpeisiisi sopiva vaihtoehto
Sähköisten toimintatapojen käyttöönotto ei välttämättä ole kallista tai edes vaikeaa. Monilla yrityksillä kynnys sähköisten toimitapojen käyttöönottoon nousee tiedonpuutteesta ja mielikuvasta että sähköisen liiketoiminnan aloittaminen on vaikeaa ja vaatii erityistä osaamista. Tietyissä tapauksissa mielikuva pitää paikkansa, mutta sähköisten toimintataparatkaisujen sopivalla valinnalla on mahdollista aloittaa minimikustannuksilla ja minimiosaamisella sähköisestä tiedonsiirrosta ja tietotekniikasta.
Tässä kappaleessa kuvataan kolme eri tapaa aloittaa sähköisten toimintatapojen käyttö kuljetuksien tietojensiirrossa ja vertaillaan lyhyesti niiden etuja ja haittoja sekä yleisesti että keskenään[6].
Periaatteessa tarvittavat välineet ovat minimissään internet-yhteys ja päätelaite. Päätelaitteena toimii useimmiten tietokone, mutta jos on valmis tyytymään vähän hitaampaan yhteyteen ja epämukavampaan käyttöliittymään voi logistiikan sähköisen toimintatavan aloittaa vaikka internet-liittymällä varustetulla matkapuhelimella.
Sähköisten logistiikkatietojen lähettämisen suunnittelun yhteydessä on pidettävä mielessä että yhtä kaikille sopivaa tapaa toimia ei ole olemassa. Erityisesti aloitusvaiheessa on hyvä miettiä tarkasti omat tarpeensa ja myös ennakoida muutaman vuoden tähtäimellä yrityksen kehityspolkua ja tarpeita.
Kuva: Sähköisten ratkaisujen vertailua siirrettävän tiedon ja yhteyskumppaneiden määrän suhteessa
Yllä olevassa kuvassa on eri vaihtoehtoja vertailtu tiedonsiirtoratkaisun näkökulmasta. Kun siirrettäviä tietoja ja/tai kumppaneita on paljon, tulee kysymykseen erikoistunut logistiikkasovellus ja sanoma-pohjainen tiedonsiirto. Tällöin kustannus sanomaa tai kumppania kohti muodostuu kohtuulliseksi.
Pienellä kumppani- tai tapahtumamäärällä logistiikkapalvelutarjoajan verkkosivut ja portaaliratkaisut ovat edullisia ja helppokäyttöisiä, eikä kokonaiskustannus nouse liian suureksi. Liikkeelle pääsee minimi-investoinnilla.
Näiden väliin asettuu palvelukeskusratkaisu, jossa sähköinen toiminta ulkoistetaan haluttuun mittaan saakka ja oman osaamisen ja resurssien tarve pienenee samassa suhteessa. Toisaalta kustannukset kasvavat, joten tämä vaihtoehdon valinnassa tulee olla selvillä oman yrityksen toiminnankustannuksista ja resursseista. Palvelukeskusratkaisu tarjoaa vastapainoksi huolettomuutta ja skaalautuvuutta kuljetus-asiakkaan tarpeisiin.
Logistiikkapalveluntarjoajien verkkosivut ja portaalit
Logistiikkapalvelun tarjoajan portaalin tai verkkosivujen sähköisiä palveluita voidaan käyttää edellä mainittujen perusvalmiuksien kautta. Verkkosivujen ja portaalien avulla kuljetusasiakas pystyy lähettämään kuljetukseen liittyvät tietonsa, kuten kuljetustilauksen ja rahtikirjan kuljetusyritykselle sähköisesti, sekä usein myös seuraamaan lähetyksensä tilaa.
Kuljetusyritysten verkkopalvelut antavat usein asiakkaalle mahdollisuuden myös tulostaa standardin mukaisen rahtikirjan ja kolliosoitelaput annettujen tietojen mukaan täytettynä. Mikäli kuljetuksen tilaaja ei ole tavaran lähettäjä, tulee rahtikirja toimittaa lähettäjälle kuljettajalle tavaroiden mukana annettavaksi.
Monet kuljetusyritykset tarjoavat asiakkailleen mahdollisuuden lähettää kuljetusdokumentteja tai seurata lähetyksiä edellä kuvatulla tavalla.
Verkkosivustojen ja portaalien käyttö tapahtuu siten, että asiakas syöttää kuljetusyrityksen verkkosivulla selaimeen avautuman lomakkeen avulla tiedot ja lähetä –nappia painamalla toimittaa tiedot kuljetus-yrityksen järjestelmään, jossa niitä on tämän jälkeen mahdollisuus käsitellä sähköisesti.
Monet kuljetusyritykset tarjoavat sähköisiä palvelujaan omilla verkkosivullaan usein sekä avoimena palveluna että sopimusasiakkaan palveluna.
Avoimessa palvelussa kuka tahansa voi lähettää asiakirjatiedot kuljetusyritykselle verkkosivujen kautta ja kuljetustoimeksiannosta sovitaan tai se vahvistetaan erikseen. Sopimusasiakkaan palveluun rekisteröidytään ennakkoon, jolloin asiakkaan sisään kirjautuminen ja toimitetut dokumentti tiedot käynnistävät toimeksiannon. Useissa tapauksissa myös asiakkaan pysyvät perustiedot voidaan tallentaa kuljetusyrityksen verkkopalveluun tai asiakkaan selaimelle.
Monet kuljetusyritykset tarjoavat myös sähköisiä kuljetusten seurantapalveluita, joko siten että asiakas voi seurata lähetyksen tilannetta kuljetusyrityksen verkkosivulla tai saada tiedon lähetyksen tilasta viestinä. Seurantapalvelua käyttääkseen asiakkaan tulee syöttää kuljetusliikkeen verkkosivulle rahtikirjan numero tai lähetysviite.
Tämän toimintatavan ehdoton etu asiakkaalle on sen käyttöönoton helppous ja edullisuus. Toisaalta taas toimituksen tietojen manuaalinen kirjaaminen ja mahdollisten muutosten tekeminen kuljetusasiakirjoihin on työläämpää. Dokumenttikopion saadakseen asiakkaan on myös tulostettava asiakirja itse.
Karkeana nyrkkisääntönä voidaan pitää että mikäli kuljetusasiakkaan päivittäisten rahtikirjojen määrä jää alle 20kpl:een, on logistiikkapalveluntarjoajan verkkosivulla oleva sovellut tai portaali erinomainen vaihtoehto. Samoin mikäli asiaks käyttää vain yhtä kuljetuspalvelujen tarjoajaa, tällöin ei myöskään rahkirjojen määrä ole yhtä merkittävä. Mikäli lähetettävien rahtikirjojen määrä on selkeasti suurempi, voi olla aiheellista tehdä kustannuslaskentaa ja vertailua mm. palvelukeskusratkaisun kanssa. Asiaan vaikuttaa luonnollisesti rahtikirjojen määrän lisäksi yhteyskumppaneiden määrä ja rahtikirjan rivien määrä sekä rivitietojen vaihtelu eri rahtikirjoissa.
Palvelukeskusratkaisu
Logistiikan sähköisen tiedonsiirron käyttöönoton voi toteuttaa myös palvelukeskusratkaisun avulla. Palvelukeskusratkaisujen tarjonta on Suomessa vielä varsin vaatimatonta ja alkuvaiheessa. Tämä johtunee ainakin osittain suomalaisesta toimintakulttuurista, jossa toimintojen ulkoistaminen ei ole kovin laajamittaista vaan kaikki toiminnot halutaan tehdä ja toteuttaa omassa organisaatiossa. Sen sijaan esimerkiksi Ruotsissa tämä toimintamalli on selkeästi laajemmin käytössä.
Palvelukeskus voi tarjota yritykselle erilaisia vaihtoehtoja sähköisen toiminnan suhteen. Kuljetus-dokumenttien tuottaminen ja lähettäminen ulkoistetaan haluttuun mittaan saakka ja oman osaamisen sekä resurssien tarve pienenee samassa suhteessa. Toisaalta myös kustannukset kasvavat vastaavassa suhteessa, joten tämä vaihtoehdon valinnassa tulee olla selvillä oman toiminnan kustannuksista ja resursseista. Palvelukeskusratkaisu tarjoaa vastapainoksi huolettomuutta ja skaalautuvuutta kuljetusasiakkaan tarpeisiin.
Kuljetusasiakaan kannalta on hyödyllistä että palvelukeskuksen kautta voi olla yhteydessä useampiin kuljetusyrityksiin ja uusien liittymien ja rajapintojen toteuttaminen on nopeaa ja helppoa. kuljetus-asiakkaan omaa rajapintamäärittelyä ei siis välttämättä tarvitse tehdä kokonaan uudelleen ja monet yritykset liittävätkin palvelukeskusratkaisun olemassa olevaan ERP-järjestelmäänsä. Palvelukeskus tarjoaa usein myös muunnospalveluita jolloin asiakkaan omassa tiedostomuodossa olevat dokumentit muunnetaan standardin mukaisiksi (EDIFACT tai XML) sanomiksi. Palvelun avulla voidaan myös tulostaa rahtikirjat ja kolliosoitelaput ja lavalaput. Palvelun kautta asiakkaalla on käytössään viimeisimmät versiot standardinmukaisista asiakirjoista.
Palvelukeskusratkaisu on luonnollisesti kustannuksiltaan kalliimpi kuin kuljetusyritysten verkkosivujen tai portaalien kautta tapahtuva sähköinen tiedonsiirto, mutta on näitä kattavampi ja monipuolisempi. Räätälöitävyys ei vastaa oman ohjelmiston joustavuutta. Kustannusvertailu oman ohjelmiston kanssa on vaikeampaa, mutta mikäli transaktiot ja siirrettävät tietomäärät eivät nouse mittaviksi on palvelukeskusratkaisu hyvin kilpailukykyinen oman ohjelmiston vaihtoehtona.
Karkeana nyrkkisääntönä voidaan pitää että kun päivittäisten rahtikirjojen määrä nousee yli 50 kpl:een, voi olla aiheellista harkita kustannuslaskentaa ja vertailua mm. oman järjestelmän ja sanomaliikenteen kanssa. Valitusta palvelutasosta riippuen voi palvelukeskus olla varteenotettava ratkaisuvaihto myös pienemmillä ja/tai huomattavasti suuremmilla rahtikirjamäärillä. Asiaan vaikuttaa luonnollisesti tässäkin rahtikirjojen määrän lisäksi yhteyskumppaneiden määrä: Mitä useampaa kuljetuspalvelujen tarjoajaa käytetään, sitä pienemmillä rahtikirjamäärillä palvelukeskusratkaisu tulee kilpailukykyiseksi. Samoin asiaan vaikuttavat myös rahtikirjan rivien määrä sekä rivitietojen vaihtelu eri rahtikirjoissa.
Esimerkkinä palvelukeskusratkaisujen tarjoajista voidaan mainita Consignor Oy , Shipit Oy Ab jaUnifaun Oy.
Oma ohjelmisto tai järjestelmä
Suomessa on tarjolla monien toimittajien ohjelmistoja kuljetusdokumenttien laatimiseen, tulostamiseen ja lähettämiseen sähköisesti. Ohjelmistoratkaisut voivat olla itsenäisiä yhden tai useamman toiminnon sovelluksia tai modulaaristen ohjelmistojen osia. Modulaariset, sähköisiin kuljetusasiakirjoihin liittyvät ohjelmistot, ovat usein myös toiminnanohjausjärjestelmien (ERP) osia.
Yrityksen siirtyessä käyttämään omaa toiminnanohjaus- tai logistiikanhallintaohjelmistoa, projektiin liittyy usein myös toimintatapojen uudelleenarviointia ja mahdollisia toimintaprosessien uudistamisia. Toimintaprosessien analysointi ja muutos ovat tarpeen, jotta sähköisestä järjestelmästä saataisiin irti parhaat mahdolliset hyödyt. Tehokkuutta ja synergioita pyritään löytämään mm. integroimalla kuljetus- ja toiminnanohjausratkaisut myynnin ja tilaustenkäsittelyn ja taloushallinnon, kuten laskutusjärjestelmien kanssa.
Kuljetusasiakkaan tarvitsema ratkaisu sähköisten logistiikkatietojen lähettämiseen ei siis ole kovinkaan monimutkainen, vaan kuljetustilaukseen, lähetystietoihin (rahtikirja) sekä esimerkiksi lähetyslistaan tarvittavat tiedot ovat saatavissa yrityksen myynti- ja ERP- järjestelmistä lisättynä muutamilla kuljetusspesifeillä tietoelementeillä ja tulostusratkaisuilla esim. rahtikirjan ja kolli- sekä lavalappujen osalta. Vastaavasti kuljetusten kuittaustiedot ja seurantatiedot joita logistiikkaoperaattori toimittaa yritykselle tulisi edelleen integroida edellä mainittuihin järjestelmiin mm. laskutuksen ja toiminnan- ohjauksen tukitiedoiksi. Kehittyneemmissä järjestelmissä voidaan seurantatietojen avulla valvoa ja analysoida myös toimitusten täsmällisyyttä ja laatua (virheet ja poikkeamat).
Kokonaan toinen asia ovat kuljetusliikkeen päässä tarvittavat ohjelmistot jotka keskittyvät kuljetusten ja niihin liittyvien asiakirjojen hallinnan lisäksi myös kalustonhallintaan ja kuljetusten suunnitteluun.
Oman järjestelmän avulla sähköiseen toimintatapaan siirtymiseen ei luonnollisesti riitä pelkästään ohjelmisto jolla sähköiset asiakirjat tuotetaan vaan myös tiedonsiirtoratkaisu on selvitettävä. Tiedonsiirrosta ja siihen liittyvistä asioista, kuten rajapintamäärittelyistä, sanomista ja tiedonsiirtomenetelmistä kerrotaan tarkemmin jäljempänä tässä oppaassa.
Karkeana nyrkkisääntönä voidaan pitää että kun päivittäisten rahtikirjojen määrä nousee yli 50-60 kpl:een, voi olla aiheellista harkita kustannuslaskentaa ja vertailla oman järjestelmän hankkimista ja sanomaliikenteen aloittamista. Samoin mikäli asiakkaalla on jo ennestään sähköinen toimintatapa käytössä jollakin liiketoiminnan alueella, kuten myynnissä tai toiminnanohjauksessa, vaihtoehto tulee huomattavan kilpailukykyiseksi jo pienilläkin dokumenttimäärillä. Asiaan vaikuttaa luonnollisesti tässäkin rahtikirjojen määrän lisäksi yhteyskumppaneiden määrä ja rahtikirjan rivien määrä sekä rivitietojen vaihtelu eri rahtikirjoissa. Parhaimmillaan tämä vaihtoehto on tilanteissa, joissa suurehkolla kuljetusasiakkaalla tasainen ja suuri asiakirjamäärä.
Sähköisellä standardimuotoisella tiedonsiirrolla tarkoitetaan tietojen välittämistä osapuolten välillä sähköisesti siten, että tiedot ovat esitetty jonkun yleisesti hyväksytyn standardin eli esitystavan mukaisesti. Tämä esittäminen tarkoittaa sitä, että siirrettävät tiedot on nimetty, ryhmitelty ja järjestetty siirrettävässä tiedostossa yhteisesti sovitulla tavalla. Tiettyyn asiakokonaisuuteen, kuten rahtikirjaan tai kuljetustilaukseen, liittyvät tiedot siirretään periaatteessa jokaisella kerralla samassa muodossa. Tietojen sisältö vaihtelee tilanteesta riippuen, mutta samaa asiaa tarkoittava tieto on aina siirrettävässä tiedostossa samassa paikassa samalla tavalla esitettynä. Myös tietojen poisjäännistä on olemassa ohjeet niin, että tiedoston vastaanottava järjestelmä pystyy käsittelemään tiedot automaattisesti, vaikka tiettyä tietoa ei olisikaan kyseisellä kerralla siirretty.
Voimme verrata sähköistä standardimuotoista tiedonsiirtoa
lomakkeeseen, kuten rahtikirjaan, joka lähetetään täytettynä
vastaanottajalle. Lomakkeessa on tietyt kentät eli laatikot, jotka on
täytettävä. Osa näistä laatikkoihin tulevista tiedoista on pakollisia ja
osa valinnaisia. Pakolliset tiedot on aina lähetettävä, jotta lomakkeen
sisältö olisi ymmärrettävä tai yleensä käyttökelpoinen
vastaanottajalleen.
Samoin sähköisessä standardimuotoisessa tiedonsiirrossa tiedot on
esitetty tietyssä järjestyksessä ja tiedoilla on nimet, kuten lomakkeen
laatikoillakin. Tietyt tiedot ovat pakollisia ja tietyt valinnaisia.
Pakolliset tiedot on aina välitettävä, jotta tiedoston vastaanottaja
pystyisi käsittelemään tiedot järjestelmissään tai ne olisivat
ymmärrettäviä ja käyttökelpoisia. Valinnaisilla tiedoilla täsmennetään
muita tietoja.
Usein ajatellaan, että sähköpostin lähettäminen ja vastaanottaminen
on standardimuotoista tiedonsiirtoa. Näin ei kuitenkaan ole. Sähköpostin
sisältö on vapaamuotoista tekstiä eikä yksittäisiä tietoja ole nimetty
sähköpostiviestissä. Viestin sisältö voi vaihdella tapauskohtaisesti,
vaikka sillä ilmoitettaisiinkin samasta asiasta. Lisäksi sähköpostin
kirjoittajan tyyli ilmaista asioita sekä mielentila kirjoitushetkellä
vaikuttavat viestin sisältöön.
Myös viestin vastaanottajan status vaikuttaa siihen, miten asia
ilmaistaan. Työkaverille kerrotaan samasta asiasta yleensä eri tavalla
kuin esimiehelle. Tällaista viestiä on vaikea käsitellä automaattisesti,
koska tietoja ei ole siinä esitetty tiettyjen sääntöjen mukaisesti,
kuten sähköisessä standardimuotoisessa tiedonsiirrossa tehdään. Tämä
standardimuotoisuus tekeekin sähköisen tiedonsiirron sääntöjen mukaan
muodostetun tiedoston tietojen käsittelyn verrattain helpoksi ja
yksinkertaiseksi.
Edellä mainittiin, että sähköisesti välitettävien asiakirjojen tietojen esittämiseksi on kehitetty standardeja eli esitystapoja. Vuonna 1986 syntyi tähän tarkoitukseen EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport), joka on sittemmin saanut maailmanlaajuisen hyväksynnän eri käyttäjäryhmien piirissä. EDIFACTin kehittäminen ja ylläpito tapahtuvat YK:n Euroopan Talouskomissiossa (ECE). EDIFACT on tietynlainen kielioppi, joka määrittelee sähköisesti siirrettävän asiakirjatiedoston muodon ja rakenteen.
Tietyn asiakirjan tiedoista muodostuu sanoma (message), Sanomat on määritelty EDIFACT-hakemiston sanomahakemistossa EDMD (EDIFACT Message Directory). Vuoden 2010 lopussa ilmestyseessä EDIFACT-hakemistossa D10.B on kaikkiaan 196 eli ohjeistus 196 asiakirjalle. Näistä kuljetukseen liittyviä sanomia on 40 kappaletta. Sanomista käytetään aina kuusikirjaimisia tunnisteita.
Seuraavassa on esimerkki EDIFACT-kieliopin mukaisesta IFTSTA (International multimodal status report message) –sanomasta, jolla ilmoitetaan kuljetuksen tila:
UNH+1857+IFTSTA:D:96B:UN:FI0043′
BGM+44+K3196S/1128+9′
DTM+137:201103141012:203′
NAD+MR+003707209560:100+AB SÄHKÖ OY+PL 600+VAASA+65101+FI’
NAD+MS+003707095540:100++MERIKULJETUS OY+28101+FI’
CNI+12+339053′
STS+1+5′
RFF+AAO:1235′
DTM+334:20110314:102′
LOC+14+00100:16::HELSINKI’
PCI+12+35544-2:35544-3:35544-4′
EQD+CN+ICSU123456-7+20 JALAN IC-KONTTI++ZAP’
UNT+13+1857′
On huomattava, että sanoman rakenteen tunteminen on tärkeää vain henkilölle, joka joutuu kehittämään järjestelmiä tai vastaa sanomien siirrosta. Normaalin käyttäjän on tiedettävä ainoastaan, mitä tietoa partnerille sähköisesti lähetetään tai häneltä voidaan odottaa vastaanotettaman. Järjestelmää kehitettäessä käyttäjien on osattava sanoa, mitkä tiedot ovat toiminnan kannalta pakollisia ja mitkä valinnaisia, jotta sanomassa välitettäisiin tarvittava tietosisältö.
Koska EDIFACT-sanomat on laadittu siten, että ne olisivat käyttökelpoisia monissa erilaisissa tilanteissa, ovat ne verrattain laajoja ja samaa asiaa voidaan esittää monella eri tavalla. Jotta eri osapuolet voisivat hyödyntää sanomia juuri tietyssä tilanteessa, on EDIFACT-sanomille laadittu joko toimialakohtaisia tai kansallisia soveltamisohjeita, joissa on yksityiskohtaisesti esitetty, miten sanomaa käytetään. Lisäksi alkuperäisestä UN/ECE:n tekemästä sanomasta on karsittu pois sellaisia osia ja rakenteita, joita kyseisessä käyttötarkoituksessa ei tarvita.
TIEKEn Verkottaja-palvelussa on suomenkieliset soveltamisohjeet 11 kuljetuksen asiakirjalle, jotka on esitetty kahdessa seuraavassa taulukoossa. Ensimmäisessä taulukossa on esitetty yleisimmin käytettävät sanomat ja toisessa taulukossa harvemmin käytettävät. Taulukoitten ensimmäisessä sarakkeessa on esitetty asiakirjan suomenkielinen nimi. Toisessa sarakkeessa on esitetty asiakirjaa vastaavan EDIFACT-sanoman tunnus ja kolmannessa sarakkeessa sanoman nimi, josta lyhenne on tavalla tai toisella muodostettu.
| Asiakirja | EDIFACT -sanoma | EDIFACT-sanoman nimi |
| Rahtikirja / Kuljetussanoma | IFCSUM | Forwarding and consolidation summary message |
| Kuljetus- / huolintaohje | IFTMIN | Instruction message (HUOM! Sanomaa käytetään myös rahtikirjana) |
| Kuljetuksen tila | IFTSTA | International multimodal status report message |
| Kuljetus- ja huolintalasku | INVOIC | Invoice message |
| Kuljetuksen aikataulu- ja saatavuuskysely ja sen vastaus | IFTSAI | Forwarding and transport schedule and availability information message |
| Kuljetusvaraus | IFTMBP | Provisional booking message |
| Kuljetustilaus | IFTMBF | Firm booking message |
| Kuljetustilausvahvistus | IFTMBC | Booking confirmation message |
| Avisointi (lähtö ja saapuminen) | IFTMAN | Arrival notice message |
| Kuljetustilanne | IFTMCS | Instruction contract status message |
TIEKEn tekemien kuljetusalan soveltamisohjeiden rakenne on seuraava:
- Sanoman tarkoitus, jossa esitellään sanoman käyttö ja esitellään lyhyesti EDIFACT-kielioppia
- Tietoryhmäkuvaus, jossa esitetään sekä alkuperäisen UN/ECE:n rakenteen mukainen että tämän soveltamisohjeen mukaisen karsitun EDIFACT-sanoman rakenne
- Tietoryhmäkohtaiset soveltamisohjeet, jossa esitellään sanoman yksityiskohtainen käyttö ja tietosisältö
- Esimerkit, jossa on esimerkkejä, joilla pyritään havainnollistamaan sanoman käyttöä.
Edellä on esitetty EDIFACT-kielioppiin perustuvien sanomien käyttöä. Internetin laajenemisen myötä XML-muotoinen tiedon esitystapa on lisääntynyt, sillä Internet käyttää XML-muotoista esitystapaa toisin sanoen tiedostot, joita Internetissä siirretään, ovat yleensä XML-muotoisia. XML (eXtensible Markup Language) on kuvauskieli, jolla tietoa voidaan esittää standardisoiduissa, tekstimuotoisissa tiedostoissa eli dokumenteissa (document). World Wide Web Consortium (W3C) julkaisi XML-esitystavan vuonna 1998 ja se perustuu aiemmin luotuun SGML (Standard Generalized Markup Language) –kielioppiin. XML-pohjainen tiedosto, jonka rakenne perustuu W3C suosituksiin, on oikein muodostettu (well-formed) XML-dokumentti.
XML-kielioppia noudattavia tiedostoja käytetään nykyisin hyväksi laajalti. EDIFACT-sanomastandardin rinnalle että OASIS (Organization for the Advancement of Structured Information Standards) -organisaatio on kehittänyt UBL (Universal Business Language) –sanomastandardin. Myös UN/ECE on kehittämässä omia sanomia XML-kielioppiin perustuen.
XML-esitystavan kolme perusajatusta ovat:
- Laajennettavuus (Extensibility). Mikä tahansa tieto, joka voidaan esittää tekstimuotoisena ja joka voidaan sijoittaa XML-dokumentin merkintöjen (tag) väliin, voidaan katsoa olevan XML-muotoista.
- Rakenteisuus (Structured): XML-esitystapa esittää tiedon rakenteisessa muodossa, jota XML-jäsennin (parser) ja muut XML-esitystavan omaavan tiedon käsittelyyn laaditut ohjelmistot voivat käyttää hyväkseen. Rakenteinen tarkoittaa tässä, että tiedostolla on sellainen rakenne, että sen sisältö voidaan avata eri selaimilla ja muilla ohjelmistoilla.
- Oikeellisuus (Validity): XML-dokumentin rakenteiden ja sisällön
oikeellisuus voidaan todeta kahden eri validointistandardin avulla:
- XML Schema
- Data Type Definition (DTD)
OASIS-organisaatio julkaisi vuoden 2006 joulukuussa UBL-sanomahakemiston version 2.0. Tässä hakemistossa on kaikkiaan 31 sanomaa, joista seuraavat viisi sanomaa on tarkoitettu kuljetuksen ja huolinnan käyttöön:
- Bill of Lading
- Forwarding Instruction
- Freight Invoice
- Transportation Status
- Waybill
Edellä oli esimerkki IFTSTA EDIFACT-sanomasta, jolla ilmoitetaan kuljetuksen tila. Vastaava tieto esitettynä UBL 2.0 version mukaisella Transportation Status sanomalla on liitteessä 3.
TIEKE on tehnyt UBL version 2.0 Waybill-sanomaan suomenkielisen soveltamisohjeen, joka sisältää seuraavat osat:
- Sanoma ja sen soveltamisala
- Dokumentin esittely ja sen yhteydet muihin dokumentteihin
- Sanomaan liittyvä toimintaprosessi
- Sanoman tietosisältö (tietosisältölista)
- Sanoman rakenne (UML-luokkamalli)
- Sanoman määrittely
- Sanomaesimerkki
- Liitteet
Kuva: UBL-Rahtikirja-sanoman prosessikaavio
Lisäyksenä UBL-muotoisten sanomien soveltamisohjeissa on EDIFACT-muotoisiin soveltamisohjeisiin nähden prosessikaaviot, joista selviää kyseisen sanoman lähettämiseen ja vastaanottoon liittyvät osapuolet ja heidän tehtävät. Lisäksi näissä soveltamisohjeissa on myös UML (Unified Modeling Language) –luokkamalli, jolla kuvataan sanomassa välitettävien tietojen riippuvuus toisistaan. Alla on esitetty UBL-Rahtikirja-sanoman soveltamisohjeessa esiintyvä prosessikaavio. Soveltamisohjeessa on esitetty myös sanallisesti prosessin kulku.
TIEKEn tekemien EDIFACT- ja UBL-muotoisten sanomien soveltamisohjeet sekä muutakin sähköiseen tiedonsiirtoon liittyvää materiaalia löytyy osoitteesta: http://verkottaja.tieke.fi/ .
Sähköinen tiedonsiirto tapahtuu aina kahden eri osapuolen välillä. Näillä osapuolilla on omat roolinsa sen mukaan, miten siirrettävä tiedosto liikkuu näiden välillä.
Osapuoli, joka lähettää sanoman sisältävän tiedoston, on nimeltään sanoman lähettäjä eli lyhyesti lähettäjä. Tämä osapuoli myös poimii sanomassa lähetettävät tiedot tietojärjestelmistään, järjestää tiedot sanoman sovellusohjeen määräämään järjestykseen, valmistelee lähetyksen ja lähettää sanomatiedoston sovittua tiedonsiirtomenettelyä käyttäen partnerilleen. Samalla kertaa voidaan lähettää yksi tai useampi sanoma samassa tiedostossa. Samalla kertaa lähetettävät sanomat muodostavat lähetyskerran.
Sanomatiedoston vastaanottavaa partneria eli osapuolta nimitetään sanoman vastaanottajaksi eli lyhyesti vastaanottajaksi. Tämä osapuoli ottaa sanomatiedoston vastaan, varmistaa lähettäjän oikeellisuuden lähettää tiedostoja, tekee mahdollisia tarkastuksia tietojen oikeellisuudesta ja purkaa sanoman tiedot tietojärjestelmiinsä.
Alla oleva kuva esittää sanomatiedoston siirron sanoman lähettäjän ja vastaanottajan välillä. Kuvan esittämässä tapauksessa sanoman lähettäjällä ja vastaanottajalla on samat järjestelmät, jolloin vastaanottajan tietojärjestelmät pystyvät tallentamaan suoraan vastaanottamansa tiedon. Jos lähettäjällä ja vastaanottajalla on eri tietojärjestelmät, muuntaa sanoman lähettäjä tietojärjestelmistään poimimansa tiedot standardimuotoon, kuten esimerkiksi EDIFACT- tai UBL-muotoon, ja lähettää standardimuotoisen sanomatiedoston vastaanottajalle. Tämä muuntaa vastaanottamansa tiedot järjestelmiensä tarvitsemaan muotoon ja tallettaa muunnetut tiedot tietojärjestelmiinsä.
Kuva: Sanomatiedoston siirto sanoman lähettäjän ja vastaanottajan välillä
Edellä on kuvattu tilanne, jossa lähettäjällä ja vastaanottajalla on sama järjestelmä, jolloin siirrettävää sanomatiedostoa ei välttämättä tarvitse muuntaa standardimuotoon. Edellä mainittiin myös tilanne, jossa lähettäjällä ja vastaanottajalla on eri järjestelmät. Tällöin lähettäjä muuntaa tiedoston itse standardimuotoon ja vastaanottaja muuntaa standardimuotoisen tiedon järjestelmiensä tarvitsemaan muotoon. Jos lähettäjällä on monta partneria, joille tämä lähettää sanomatiedostoja, ja vastaanottajalla on monta partneria, joilta tämä vastaanottaa tiedostoja, voivat lähettäjä tai vastaanottaja käyttää ulkopuoleista operaattoria.
Sanoman lähettäjän käyttämä operaattori vastaanottaa lähettäjän lähettämän tiedoston, joka on lähettäjän tietojärjestelmien tuottama ja noudattaa järjestelmän valmistajan määrittelemää muotoa. Tämän, niin sanotun välitiedoston eli in-house-tiedoston operaattori muuntaa standardimuotoiseksi sanomatiedostoksi ja lähettää sen vastaanottajalle tai tämän käyttämälle operaattorille. Jos sanoman lähettäjän tietojärjestelmät tuottavat jo itsessään standardimuotoisen sanomatiedoston, operaattori pelkästään lähettää eli reitittää sanomatiedoston vastaanottajalle tai tämän käyttämälle operaattorille.
Vastaanottajan operaattori vastaanottaa sanomatiedoston ja muuntaa sen vastaanottajan järjestelmien ymmärtämään muotoon. Tätäkin tiedostoa nimitetään välitiedostoksi eli in-house-tiedostoksi. Jos vastaanottaja muuntaa itse sanomatiedoston tai jos tämän tietojärjestelmät pystyvät käyttämään suoraan hyväksi standardimuotoista sanomatiedostoa, ei operaattori muunna sanomatiedostoa. Tällöin operaattorin tehtäväksi jää ainoastaan sanomatiedoston vastaanotto ja siirto vastaanottajalle.
Seuraavassa kuvassa on esitetty tiedonsiirtotilanne, jossa sekä sanoman lähettäjä että vastaanottaja käyttävät ulkopuoleista operaattoria.
Kuva: Tiedonsiirto käyttäen muunnos- ja reitityspalveluita tarjoavia operaattoreita
Tiedonsiirrossa yleensä osapuoli, joka lähettää tiedoston, on aktiivinen osapuoli. Tämä osapuoli voi olla sanoman lähettäjä, joka lähettää välitiedoston operaattorille, tai operaattori, joka lähettää tiedoston sanoman vastaanottajan käyttämälle operaattorille tai itse vastaanottajalle. Lisäksi tiedoston lähettäjänä toimii vastaanottajan käyttämä operaattori, joka lähettää välitiedoston sanoman vastaanottajalle. Tiedoston lähettäjän aktiivisuus tarkoittaa tässä sitä, että lähettäjä aktivoi tiedonsiirron itsensä ja vastaanottajan välillä ja siirtää tiedoston sovitulla tavalla vastaanottajan tietokoneelle sovittuun hakemistoon. Vastaanottaja on tässä tapauksessa joko sanoman lähettäjän käyttämä operaattori, sanoman vastaanottajan käyttämä operaattori tai sanoman vastaanottaja.
Toisinaan kuitenkin tiedoston vastaanottaja voi olla sovitusti aktiivinen. Tällöin tämä aktivoi tiedonsiirron ja käy noutamassa siirrettävän tiedoston lähettäjän tietokoneelta tietystä hakemistosta, johon tällä on oikeudet. Kun tiedosto on siirretty onnistuneesti aktiivisesti toimivan vastaanottajan tietokoneelle, tuhoaa vastaanottaja tiedoston sanoman lähettäjän tietokoneelta, ettei samaa tiedostoa siirretä uudestaan, kun yhteys aktivoidaan seuraavan kerran uudelleen. Siitä, kumpi osapuoli, tiedoston lähettäjä vai vastaanottaja, toimii tiedonsiirrossa aktiivisena osapuolena, on sovittava tiedonsiirron osapuolten kesken. Yleensä sovittu rooli pysyy tietyn sanomatiedoston siirron osalta muuttumattomana. Yleistä kuitenkin on, että väli- tai sanomatiedoston lähettäjä on aktiivinen.
Edellä on kuvattu tilanne, jossa sanoman lähettäjä poimii tiedot
omista tietojärjestelmistään. Jos tietojen lähettäjäorganisaatio on
pieni ja heillä ei ole käytössään kehittyneitä tietojärjestelmiä,
voidaan käyttää sähköisiä lomakkeita, joille tiedot voidaan kirjoittaa,
ja joka muodostaa tiedoista UBL-tiedoston. Tällaisia lomakkeita voidaan
luoda esimerkiksi Microsoftin InfoPath-ohjelmistolla tai
Acrobat-ohjelmiston lomake-editorilla. Luotujen lomakkeiden tiedot
voidaan lähettää vastaanottajalle joko tiedostona tai lomakkeen kuvana.
Jos tiedot lähetetään kuvana, voi vastaanottaja ainoastaan tulostaa
lomakkeen. Vastaanottaja voi käyttää hyväkseen sovelluksessa
automaattisesti ainoastaan tiedostona lähetettyjä tietoja.
Tiedonsiirto voi tapahtua esimerkiksi sähköpostitse. Tällöin on
suositeltavaa, että sähköisiä lomakkeita käyttävä osapuoli avaa
sanomaliikennettään varten oman sähköpostitilin, jonne saapuvat ja
lähtevät sähköpostit talletetaan liitetiedostoineen. Sähköpostien
liitetiedostot sisältävät kyseiset lomakeohjelmistolla luodut sanomat.
Käytettäessä sähköpostia sanomien välittämiseen, on partnerin kanssa
sovittava sähköpostiosoitteen lisäksi sähköpostin ja sen liitetiedoston
nimi, jolloin sähköpostin liitteenä olevien sanomatiedostojen
automaattinen käsittely mahdollistuu.
Samoin kuin operatiivisista järjestelmistä luoduista sanomista ja niiden lähetyksestä ja vastaanotosta jää tieto lokille, myös sähköposteista ja niiden liitetiedostoista on jäätävä tieto lokille. Osapuoli, joka on luonut sanoman lähetyksen ja vastaanoton käyttäen hyväksi sähköpostia, voi käyttää tätä myös lokina. Sieltä on nähtävissä sekä lähetetyt että vastaanotetut viestit liitetiedostoineen. Lisäksi sähköpostin avulla voidaan käynnistää viestin uudelleen lähetys, jos lähetys jostakin syystä epäonnistuu.
Kuva: Operatiivisessa järjestelmässä ja sähköisellä lomakkeella luotujen sanomien siirto
Osapuoli, joka käyttää lomakeohjelmistolla luotuja sähköisiä lomakkeita, voi vastaanottaa sanomia ja nähdä niiden sisällön lomakkeellaan, jos sanoma noudattaa niitä määrittelyjä, joiden mukaan lomake on muodostettu. Jos sanomat välitetään vastaanottajalle sähköpostitse, on syytä käyttää tiettyjä sähköposti- ja liitetiedostonimiä, jolloin sanoma on helppo saada lomakkeella näkyviin. On suositeltavaa, että sähköpostin liitteenä olevat sanomatiedostot talletetaan omiin kansioihin, joista niitä on myöhemmin helppo ottaa käsittelyyn.
Osapuolten, jotka välittävät keskenään tietoa sähköisesti, on syytä tehdä keskinäinen tiedonsiirtosopimus. Tällä sopimuksella selkeytetään osapuolten vastuita ja velvollisuuksia sekä tiedonsiirtotapahtumaa yleensä. Tässä luvussa tarkastellaan sopimukseen sisällytettäviä asioita. Lisäksi sanoman lähettäjät ja vastaanottajat tekevät sopimuksia operaattoreiden kanssa. Näitä sopimuksia eikä niiden sisältöä esitellä tässä.
Sopijaosapuolet
Tässä kohdassa esitetään sopimuksen sopijapuolten nimet, heidän Y-tunnukset, osoitteet ja yhdyshenkilöt sopimusasioissa.
Sopimuksen soveltamisala
Tässä kohdassa esitetään tiedonsiirrossa pääasiallisesti käytettävä tiedon esitystapa sekä maininnat muista mahdollisesti käytettävistä esitystavoista. Tässä kohdassa kerrotaan, miten organisaatioiden eri yksiköiden harjoittama sähköinen tiedonsiirto esitetään sopimuksessa. Lisäksi esitetään liitteiden käyttö sopimuksessa sekä niiden ja varsinaisen sopimuksen tekstin suhde toisiinsa.
Määritelmät
Tässä kohdassa esitellään sähköiseen tiedonsiirtoon liittyviä termejä ja käsitteitä, joiden tunteminen on tärkeää sopimustekstin ymmärtämisen kannalta.
Kulut ja kustannukset
Tässä kohdassa esitetään sopimuksen aiheuttamat mahdolliset maksuvelvoitteet osapuolille sekä näiden vastuut kuluista ja kustannuksista.
Tietoturva
Tässä kohdassa esitetään osapuolten vastuut ja velvollisuudet EDIFACT- tai UBL-sanomia lähettävien ja vastaanottavien järjestelmien turvaamisesta asianmukaisesti. Lisäksi kohdassa esitetään osapuolten salassapitovelvollisuudet sanomien ja niiden tietosisällön osalta.
Lähetyskerran tarkastaminen
Tässä kohdassa esitetään osapuolten velvollisuudet ilmaista lähetyskerrassa lähettäjä ja vastaanottaja. Lisäksi kohdassa esitetään, miten lähetyskerran eheys voidaan varmistaa. Myös salakirjoituksen ja avainten mahdollinen käyttö esitetään tässä.
Sanoman tarkastaminen
Tässä kohdassa esitetään, miten lähetyskerrassa saapunut sanoma voidaan tunnistaa ja miten sen osapuolet on tunnistettavissa. Lisäksi kohdassa esitetään, miten sanoman eheys varmistetaan.
Sanoman virheettömyys
Tässä kohdassa esitetään osapuolten velvollisuudet sanomilla välitettyihin tietoihin suhteessa paperidokumentilla tai muilla tavoilla välitettyihin vastaaviin tietoihin. Lisäksi esitetään osapuolten velvollisuus niihin muutoksiin, joiden on havaittu syntyneen sanomaan siirron aikana, sekä näiden korjausmenettelyt. Tässä kohdassa esitetään myös lähettäjän vastuu sanoman tietojen virheettömyyteen. Lisäksi esitetään vastaanottajan vastuut virheellisen tiedon tulkintaan. Myös niiden sanomien käsittely, jotka eivät ole tarkoitettu tälle vastaanottajalle, mutta jotka jompikumpi sopijaosapuoli on lähettänyt, esitetään tässä kohdassa.
Sanoman vastaanoton vahvistaminen
Tässä kohdassa esitetään vastaanoton vahvistamiseen liittyvät asiat sekä vastaanoton kuittaussanoman käyttö.
Sanoman käsittely
Tässä kohdassa esitetään sanoman vastaanottajan velvollisuudet vastaanotetun sanoman käsittelyyn ajallisesti. Tässä siis esitetään, kuinka nopeasti saapunut sanoma on pyrittävä käsittelemään niin, että sen sisältö on operatiivista järjestelmää käyttävän henkilön luettavissa järjestelmästä.
Sanoman säilytys
Tässä kohdassa esitetään lähetettyjen ja saapuneiden sanomien säilyttämiseen liittyvät velvoitteet sekä talletusajan että turvallisuuden suhteen.
Muunnos- ja tiedonsiirtopalveluiden tarjoajat
Tässä kohdassa esitetään velvoitteet, jotka osapuolen on asetettava muunnos- ja/tai tiedonsiirtopalveluita tarjoavalle osapuolelle eli operaattorille, jonka muunnos- ja/tai tiedonsiirtopalveluita osapuoli käyttää.
Sopimuksen voimassaolo, irtisanominen ja purkaminen
Tässä kohdassa esitetään tämän sopimuksen ja sen liitteiden irtisanomismenettelyt sekä aikataulut sekä velvoitteet vastaanotettujen sanomien suhteen. Lisäksi esitetään sopimuksen purkamiskäytännöt sopimusehtojen rikkomistilanteessa. Lisäksi esitetään tämän sopimuksen irtisanomisen suhde muihin osapuolten välisiin sopimuksiin ja niiden voimassaoloon.
Sopimuksen siirtäminen
Tässä kohdassa esitetään, miten sopimus on mahdollista siirtää kolmannelle osapuolelle.
Ylivoimainen este
Tässä kohdassa esitetään ylivoimaisen esteen vaikutus sanomiin ja niiden sähköiseen siirtoon. Lisäksi esitetään ilmoitusvelvollisuus ylivoimaisesta esteestä ja sen päättymisestä.
Tiedonannot
Tässä kohdassa esitetään sopimukseen liittyvät tiedonantomenettelyt.
Riitaisuuksien ratkaiseminen ja sovellettava laki
Tässä kohdassa esitetään menettelyt riitaisuuksien ratkaisemiseksi sekä sopimukseen sovellettava laki.
Sopimusmuutokset
Tässä kohdassa esitetään sopimuksen muutosmenettelyt.
Allekirjoitukset
Tässä kohdassa ovat maininta samasanaisista sopimuskappaleista sekä allekirjoitusaika ja –paikka sekä allekirjoitukset.
Sopimuksen liitteet
Tiedonsiirtosopimuksen liitteinä esitetään tarpeen mukaan yksikkökohtaiset kuvaukset sähköisen tiedonsiirron toteuttamisesta. Jos koko yritys käyttää samoja ratkaistuja, esitetään näissä liitteissä yrityskohtaiset ratkaisut. Liitteissä esitettävät tiedot ovat:
- käytettävä esitystapa ja versio,
- tiedonsiirtotapa,
- luettelo välitettävistä sanomista ja niiden käyttötarkoituksesta,
- käytettävä sanomasuositus,
- käytettävät koodistot, mikäli sanomasuositus ei niitä määrittele,
- sanoman eheyden varmistus,
- vastaanoton kuittaus,
- sanomien säilytys,
- yhdyshenkilöt,
- siirtoajankohdat,
- varajärjestelmät,
- päivystysnumerot häiriö- tai virhetilanteissa,
- tiedoksiantojen postitusosoitteet,
- allekirjoitusaika ja –paikka sekä allekirjoitukset.
Liite 1
Liite 2
Sähköisten toimintatapavaihtoehtojen vertailua
| Edut | Haitat | Käyttösoveltuvuus | |
| Kuljetusyritysten ja logistiikkapalvelutarjoajien verkkosivut ja portaalit | Edullisuus (Ilmainen/minimikustannus) Yksinkertaisuus – ei edellytä IT taitoja Helppo käyttöönotto Huolettomuus Sisäänrakennettu tiedonsiirtoratkaisu | Joustamattomuus Kuljetusyrityskohtaisuus Räätälöintimahdollisuuden puuttuminen Heikko Integrointi muihin järjestelmiin Seuranta eri sovelluksessa (sivulla) Raportoinnin vaatimattomuus | Pienille volyymeille ja satunnaiseen tarpeeseen |
| Erikoistunut palveluntarjoaja | Skaalautuvuus Integroitavuus muihin järjestelmiin* Modulaarisuus Monipuolinen raportointi Sisäänrakennettu tietokanta /rekisteri Helppo käyttöönotto Huolettomuus | Kustannukset Edellyttää oman yrityksen kustannusrakenteen ja toimintakustannusten tarkkaa tuntemusta Pienemmät räätälöintimahdollisuudet | Keskimääräisille volyymeille ja useamman logistiikkapalvelutarjoajan ympäristöön Vaihteleviin volyymitarpeisiin |
| Oma ohjelmisto tai järjestelmä | Räätälöitävyys Skaalautuvuus* Integroitavuus muihin järjestelmiin* Modulaarisuus* Monipuolinen raportointi Sisäänrakennettu tietokanta /rekisteri | Kustannukset Edellyttää osaamista (omaa tai ostettua) Ylläpidosta huolehtiminen Tiedonsiirtoratkaisu t mietittävä | Suuremmille yrityksille ja volyymeille Useamman logistiikka-palvelutarjoajan ympäristöön |
* varauksin – mahdollista suurimmassa osassa ohjelmistoja
Liite 3
UBL 2.0 version mukainen Transportation Status sanoma
<TransportationStatus xsi:schemaLocation=”urn:oasis:names:specification:ubl:schema:xsd:ForwardingInstructions-2 ..\xsd\maindoc\UBL-TransportationStatus-2.0.xsd”>
<cbc:UBLVersionID>2.0</cbc:UBLVersionID>
<cbc:CustomizationID schemeAgencyID=”292″>FI10XX</cbc:CustomizationID>
<cbc:ProfileID schemeID=”UN/ECE 1001″ schemeAgencyID=”6″>44</cbc:ProfileID>
<cbc:ID>K3196S/1128</cbc:ID>
<cbc:IssueDate>2011-03-14</cbc:IssueDate>
<cbc:IssueTime>10:12:00</cbc:IssueTime>
<cac:Consignment>
<cbc:ID>339053</cbc:ID>
<cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
<cac:ConsignorParty>
<cac:PartyIdentification>
<cbc:ID schemeID=”ISO 6523″ schemeAgencyID=”5″>003707209560</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>AB Sahko Oy</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:Postbox>PL 600</cbc:Postbox>
<cbc:CityName>Vaasa</cbc:CityName>
<cbc:PostalZone>65101</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>FI</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
</cac:ConsignorParty>
<cac:CarrierParty>
<cac:PartyIdentification>
<cbc:ID schemeID=”ISO 6523″ schemeAgencyID=”5″>003707095540</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Merikuljetus Oy</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:Postbox>PL 310</cbc:Postbox>
<cbc:CityName>Pori</cbc:CityName>
<cbc:PostalZone>28101</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>FI</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
</cac:CarrierParty>
</cac:Consignment>
<cac:TransportEvent>
<cbc:OccurrenceDate>2011-03-14</cbc:OccurrenceDate>
<cbc:TransportEventTypeCode listID=”UN/ECE 9011″ listAgencyID=”6″>5 </cbc:TransportEventTypeCode>
<cbc:Description>Otettu kuljetettavaksi</cbc:Description>
<cac:ReportedShipment>
<cac:Delivery>
<cac:DeliveryLocation>
<cbc:ID>00100</cbc:ID>
<cbc:Description>Helsinki</cbc:Description>
</cac:DeliveryLocation>
</cac:Delivery>
<cac:TransportHandlingUnit>
<cbc:ID>ICSU123456-7</cbc:ID>
<cbc:TransportHandlingUnitTypeCode listID=”UN/ECE rec 21″ listAgencyID=”6″>CN </cbc:TransportHandlingUnitTypeCode>
<cbc:HazardousRiskIndicator>false </cbc:HazardousRiskIndicator>
<cbc:TotalPackageQuantity unitCode=”C62″>3 </cbc:TotalPackageQuantity>
<cac:ActualPackage>
<cbc:ID>35544-2</cbc:ID>
</cac:ActualPackage>
<cac:ActualPackage>
<cbc:ID>35544-3</cbc:ID>
</cac:ActualPackage>
<cac:ActualPackage>
<cbc:ID>35544-4</cbc:ID>
</cac:ActualPackage>
</cac:TransportHandlingUnit>
</cac:ReportedShipment>
</cac:TransportEvent>
<cac:DocumentReference>
<cbc:ID>1235</cbc:ID>
<cbc:DocumentTypeCode listID=”UN/ECE 1153″ listAgencyID=”6″>AAO </cbc:DocumentTypeCode>
</cac:DocumentReference>
</TransportationStatus>
