TETR. 0$1,)(67,1Ã.b<77gÃ.b<7g1Ã(67((7. -$ÃÃ.(+,77b0,67$53((7 /23385$32577, (XURSHDQÃ8QLRQÃ'LUHFWRUDWHÃ*HQHUDO

Transkriptio

1 0$1,)(67,1Ã.b<77gÃ.b<7g1Ã(67((7 -$ÃÃ.(+,77b0,67$53((7 /23385$32577, 9,.,1* 6XSSRUWHGÃE\ÃWKHÃ&RPPLVVLRQÃRIÃWKH (XURSHDQÃ8QLRQÃ'LUHFWRUDWHÃ*HQHUDO IRUÃ7UDQVSRUWÃÃ7(17 1

2 Selvityksen tekemiseen on saatu Euroopan unionin liikenteen perusrakenteen kehittämiseen tarkoitettuaten-t (Trans-European Networks Transport) rahoitusta. This study has been granted European Union financial aid in the field of Trens-European Networks Transport (TEN-T).

3 (18) 6,6b//<6/8(77(/2 352-(.7,1Ã7$92,7( 352-(.7,1Ã727(87867$3$Ã-$Ã.2+'(5<+0b 0$1,)(67,1Ã78277$0,6(1Ã9$,+((7Ã72,0,786.(7-866$ 0$1,)(67,1Ã7,(726,6b/7g9$$7,08.6(7 4.1 KAUPALLINEN MANIFESTI TULLIN MANIFESTI 6 0$1,)(67,1Ã7,(72-(1Ã.b<77gÃ.b<77b-b5<+0,77b,1.$16$,19b/,6(7Ã0bb5b<.6(7ÃÃ67$1'$5',7Ã-$ 67$1'$5',(1Ã.b<77g (+'2786Ã<+7(1b,6(1Ã0$1,)(67,1Ã7,(726,6b//g.6, 7.1 EHDOTUS KÄYTETTÄVIKSI EDI-SANOMIKSI 11.2.(,/8<03b5,67g1Ã7(.1,1(1Ã5$7.$,68.216(37, 8.1 YLEISTÄ XML:STÄ DOCUMENT TYPE DEFINITION, DTD XML:N EDUT XML:N KÄYTTÖ 14 ;0/FOLHQWLVVD ;0/VHUYHULVVl 8.5 XML:N KÄYTTÖ ERI SOVELLUSTEN VÄLISEEN TIEDONSIIRTOON XML:N KÄYTTÖ MANIFESTIN TIETOJEN SIIRROSSA MANIFESTIN XML-PILOTIN JÄRJESTELMÄKUVAUS bb7g.6(7Ã-$Ã(+'2786Ã-$7.272,0(13,7(,.6, 9.1 JOHTOPÄÄTÖKSET EHDOTUS JATKOTOIMENPITEIKSI 18 /,,77((7 LIITE 1 LIITE 2 Käsitemääritys Manifestin tietosisältö

4 (18) 352-(.7,1Ã7$92,7( Manifestiprojekti on toteutettu osana Liikenneministeriön TETRA-ohjelmaan kuuluvaa Satamatoiminnot-hanketta. Hankkeen tavoitteena on ollut muodostaa kokonaiskuva manifestista, sen tietosisällöstä ja tiedon hyväksikäytöstä eri sidosryhmissä koko toimitusketjun aikana. Projektissa selvitettiin myös manifestiin liittyvät kansainväliset määräykset ja standardit. Selvityksessä on huomioitu erot eri meriliikennemuotojen osalta samoin erot merikuljetuksissa EU:n tullialueella ja sen ulkopuolelta sekä ulkopuolella. Toisena tavoitteena on ollut suunnitella sähköisen manifestin kokeiluympäristön tekniset reunaehdot. 352-(.7,1Ã727(87867$3$Ã-$Ã.2+'(5<+0b Manifestiprojektista vastasi Oy EDI Management Finland Ltd. Projekti toteutettiin kevään 1999 aikana haastattelemalla manifestiin tuottamiseen liittyviä keskeisiä sidosryhmiä. Haastatellut organisaatiot olivat seuraavat Varustamot ja varustamojen edustajat Finncarriers Transfennica Containerships Unifeeder Viking Line Aug. Lindberg Satamaoperaattorit Finnsteve Steveco (myös varustamon edustaja) Rauma Stevedoring (myös varustamon edustaja) Kuljetusliikkeet VR Cargo BTL/Schenker ASG Vienti- ja tuontiyritykset Inex UPM-Kymmene Seaways

5 (18) viranomaiset tullihallitus Helsingin ja Kotkan tullikamarit merenkulkulaitos Haastatteluissa keskityttiin selvittämään kunkin organisaation osuus manifestin tuottamisessa tai sen käytössä sekä tähän liittyvät mahdolliset ongelmat ja pullonkaulat. Lisäksi toteutettiin kirjoituspöytätutkimuksena kartoitus sähköisen manifestin käytöstä Antwerpenin ja Felixstowen satamissa. 0$1,)(67,1Ã78277$0,6(1Ã9$,+((7Ã72,0,786.(7-866$ Manifesti voidaan määritellä aluksen lastiluetteloksi, joka kattaa tavaraerät aluksen yhden lähtö- ja tulosataman välillä. Manifesti on siis satama-parikohtainen, jolloin esimerkiksi laivan suorittaessa matkaa usean eri sataman välillä, syntyy kyseisestä matkasta myös useita manifesteja. Esimerkkinä voidaan käyttää laivan matkaa Helsinki-Antwerpen-Felixstowe. Tällöin matkasta syntyvät manifestit ovat lastiluettelo tavaraeristä välillä Helsinki-Antwerpen lastiluettelo tavaraeristä välillä Helsinki-Felixstowe ja lastiluettelo tavaraeristä välillä Antwerpen-Felixstowe Manifesti on itse asiassa tietokokonaisuus, joka muodostuu viennin kuljetus-ketjun aikana laivaajan, huolinta- ja kuljetusliikkeen, varustamon ja satama-operaattorin toimittamien tietojen pohjalta. Viennissä manifestin tuottamisen eri vaiheet ovat seuraavat: (QQHQÃODVWDXVWD lastitilan varaus (buukkaus) laivaaja, joka voi olla vientiyritys tai huolintaliike, lähettää varustamolle lastitilavarauksen (buukkaus) feeder-liikenteessä buukkaukset lähetetään valtamerivarustamolle, joka puolestaan buukkaa tarvittavan lastitilan feeder-varustamolta buukkaukset tehdään laivaajasta riippuen eri tavoilla, tyypillinen tapa pksektorilla on hoitaa buukkaus joko puhelimitse tai faksilla buukkaustieto ei useinkaan sisällä vielä tarkkoja tietoja tavaraerästä, vaan se kattaa tiedot varustamolta halutusta lastitilasta tiettynä lähtöpäivänä

6 (18) suuryritysten (kuten metsäteollisuus) viennissä buukkaukset välitetään usein jo sähköisesti ja ne sisältävät jo valmiiksi toimituserätason tiedot laivaaja hoitaa myös kuljetustilavaraukset ja rahtikirjat edeltävän kuljetuksen osalta (maantie- tai rautatieliikenne) varustamo (tai laivaaja) välittää buukkaustiedot myös satamaoperaattorille lastitilavarauksen vahvistus varustamo vahvistaa laivaajalle lastitilan laivasta haluttuna lähtöpäivänä tavaraerän tiedot tarkemmat tiedot tavaraerästä saadaan laivaajalta joko laivausohjeella tai konossementtiohjeella, rahtikirjalla tai kopiolla kauppalaskusta tavaraerän tiedot tarvitaan manifestia varten, ne yksilöivät mm. tarkemmat osapuolitiedot ja tavarankuvauksen tavaraerätietojen pohjalta varustamo tuottaa konossementin (B/L) tai merirahtikirjan (LWB), tosin sisäkaupassa suuntauksena on näiden käytöstä luopuminen /DVWDXNVHQÃDLNDQD kun laivaajan tavaraerät ovat saapuneet satamaan, hoitaa satamaoperaattori erien lastauksen laivaan ja tarkistaa että laivatut erät vastaavat rahtikirjatietoja (ns. taljaus) /DVWDXNVHQÃMlONHHQ satamaoperaattori välittää toteumatiedot lastauksesta varustamolle varustamo lähettää laivaajalle laivausvahvistuksen, ts. tiedon siitä, mitkä tavaraerät kyseiseen laivaan lastattiin varustamo tuottaa tältä pohjalta laivan manifestin ja toimittaa sen tullille sekä edustajalleen määräsatamassa Seuraava kaavio esittää yleistettynä manifestitietojen tuottamisen viennin kuljetusketjussa

7 (18) buukkaus ja vahv. rahtikirjat LAIVAAJA buukkaus ja vahv. tavaraerätiedot B/L, LWB VALTAMERI- VARUSTAMO KULJETUS- LIIKE laivausvahvistus B/L LWB tavaraerätiedot buukkaus ja vahv. buukkaus ja vahv. VARUSTAMO manifesti manifesti satamavahvistus buukkaus manifesti VARUSTAMON EDUSTAJA (määräsatama) SATAMA- OPERAATTORI TULLI Tuonnissa kyse on peilikuvasta, varustamon edustaja saa määräsatamassa kopion vientimanifestistä, joka toimii avisointina jatkokuljetukselle, purkaussataman satamaoperaattorin purkauksen tarkistuskappaleena sekä tullin dokumenttina. Ã 0$1,)(67,1Ã7,(726,6b/7g9$$7,08.6(7 Manifestia voidaan tarkastella tietovirtana joko varustamon ja varustamon edustajan välillä tai tietovirtana eri viranomaisten suuntaan, lähinnä tulliin. Seuraavassa on käsitelty manifestin tietosisältöä termillä kaupallinen manifesti puhuttaessa varustamon ja sen edustajan välisestä kommuni-koinnista ja termillä tullin manifesti puhuttaessa tullin esittämistä tieto-sisältövaatimuksista. Ã.DXSDOOLQHQÃPDQLIHVWL Kaupallisen manifestin osalta voidaan todeta, että mitään yleisiä tietosisältövaatimuksia ei ole. Kyse on kahden osapuolen (varustamon ja sen edustajan) välisestä tietovirrasta, josta osapuolet sopivat keskenään. Vientimanifesti on kooste aluksen lastista sen lähtiessä lastaussatamasta ja varustamo välittää sen purkaussatamassa toimivalle edustajalleen, joka toimii ja välittää tietoja aluksen lastista manifestin perusteella edelleen. Manifestin tietosisältö riippuu pitkälti meriliikennemuodosta esimerkiksi Suomen ja Ruotsin välisessä lauttaliikenteessä manifestin tietosisältö on huomattavasti suppeampi verrattuna roro-liikenteeseen Suomen ja Saksan välillä. Suomen ja

8 (18) Ruotsin välisessä lauttaliikenteessä käytetään manifestina ns. märkrullaa, jossa kerrotaan yksikön (perävaunu, kontti) tunnistetieto, lyhyesti tavaran kuvaus, kollien lukumäärä, paino ja mahdollinen vastaanottaja. Syy tähän on liikenteen nopeus ja tyyppi; tietoja ei tarvita tämän tarkemmalla tasolla. Mikäli haluttaisiin tarkastella jonkin tietyn perävaunun sisältöä tarkemmin, ovat nämä tiedot saatavissa kuljetusliikkeeltä. Toinen esimerkki tietosisällöstä liittyy feeder-liikenteeseen, jossa voidaan manifestilla kuvata yksikkö (kontti) hyvinkin tarkalla tasolla, mutta manifestilta puuttuu tieto kontin sisällöstä lähettäjä- ja vastaanottajatasolla. Tämä selittyy sillä, että feeder-varustamo hoitaa valtamerivarustamon syöttöliikennettä, eikä edes tiedä tavaraerittäin lopullisia lähettäjä-/vastaanottajatietoja eikä näitä tietoja välttämättä valtamerivarustamolta ole saatavissa. Yleisesti voidaan todeta, että kaupallisen manifestin tietosisältöä on erittäin vaikea harmonisoida täysin yhtenäiseksi, koska tietosisällön määrää pääsääntöisesti meriliikennemuoto ja tietojen käyttötarkoitus sekä -tarve. Yhtenäistetyllä tietosisällöllä silloin kun puhutaan kaupallisesta manifestista voidaan ajautua tilanteeseen, jossa standardointi edellyttäisi sellaisten tietojen välittämistä, joita varustamolla tai sen edustajalla ei ole ja/tai joilla ei operatiivisen toiminnan kannalta ole merkitystä. Ã 7XOOLQÃPDQLIHVWL Tullin manifestilla tarkoitetaan aluksen sellaista lastiluetteloa, jota tulli viranomaisena edellyttää saavansa. Käytännössä tullille on manifesti toimitettava sekä viennissä että tuonnissa, poikkeuksen muodostaa vain yhteisön säännöllisessä reittiliikenteessä oleva alus, jonka lastina ei ole passitettavaa tavaraa. Tullilainsäädännössä on manifestin tietosisällön osalta esitetty vaatimuksia kahdessa eri tapauksessa; kun varustamolla on edelleen yksinkertaistetun passitusmenettelyn lupa (yhteisön säännöllisessä reittiliikenteessä) ja muussa liikenteessä silloin, kun manifestia käytetään tavaran tullistatuksen osoittamiseen. Jälkimmäinen edellyttää joko tullin vahvistusta tai hyväksytyn lähettäjän lupaa. Tietosisältövaatimukset manifestin osalta ovat seuraavat meriliikenneyhtiön nimi ja täydellinen osoite aluksen nimi tavaroiden lastauspaikka ja päivämäärä tavaroiden purkauspaikka sekä jokaisesta lähetyksestä viittaus konossementtiin tai muuhun kaupalliseen asiakirjaan

9 (18) kollien lukumäärä, kuvaus, merkit ja numerot tavaroiden kuvaus bruttomassa kilogrammoina tarvittaessa konttien tunnistenumerot tavaroiden tullioikeudellista asemaa koskevat merkinnät Edellisessä kuvauksessa on rajauduttu lastia koskeviin tietosisältö-vaatimuksiin. Erikseen on tuonnin osalta määritelty alukseen ja sen matkaan liittyvät tietosisältövaatimukset tullin yleisilmoituksen osalta. 0$1,)(67,1Ã7,(72-(1Ã.b<77gÃ.b<77b-b5<+0,77b,1 Seuraavaan luetteloon on koottu manifestilla olevien tietojen käyttö kuljetusketjussa eri sidosryhmittäin. Laivaaja laivaaja (vientiyritys, huolitsija) toimii itse lähtötietojen antajana välittämällä buukkaus- ja konossementtitiedot laivaaja tarvitsee manifestin valmistuttua laivausvahvistuksen omien lähetyseriensä osalta Kuljetusliike (edeltävä kuljetus) merikuljetusta edeltävää kuljetusta hoitava kuljetusliike ei tarvitse tietoja manifestilta Satamaoperaattori (lähtösatama) saa alusta koskevat buukkaustiedot varustamolta vastaa aluksen lastauksesta, vahvistaa laivatut erät ja välittää tiedon varustamolle Terminaalinpitäjä (lähtösatama) terminaalinpitäjälle manifesti on kirjanpidon tosite Varustamo (lähtösatama) tuottaa manifestin buukkaus- ja konossementtitietojen sekä satamaoperaattorin toimittaman satamavahvistuksen perusteella välittää laivausvahvistukset laivaajille toimittaa manifestin tullille Tulli (lähtösatama)

10 (18) tarvitsee manifestitiedot valvontaa varten Satamalaitos (lähtösatama) osa satamalaitoksista käyttää manifestitietoja tavaramaksulaskutuksen ja tilastoinnin perustietoina, jolloin manifesti on oleellinen dokumentti Varustamo (määräsatama) saa tuontimanifestitiedot lähtösataman varustamolta toimittaa tiedot satamaoperaattorille ja tullille, avisoi jatkokuljetuksesta vastaavia yrityksiä Satamaoperaattori (määräsatama) saa tuontimanifestitiedot, jotka muodostavat perustiedot purkausluettelolle, purkauksessa tarkistus manifestitietoja vastaan Terminaalinpitäjä (määräsatama) terminaalinpitäjälle manifesti on kirjanpidon tosite Tulli (määräsatama) tarvitsee manifestitiedot valvontaa varten Satamalaitos (määräsatama) vastaavasti kuin viennissä tarvitsee osa satamista manifestitiedot tuonnissa tavaramaksulaskutusta ja tilastointia varten Kuljetusliike (jatkokuljetukset) jatkokuljetuksista vastaava kuljetusliike on kiinnostunut saamaan etukäteen tiedon lähtösatamasta alukseen laivatuista yksiköistä sekä aluksen tullessa määräsatamaan yksiköiden arvioidusta purkausajasta, jotta ajojärjestelyt voitaisiin optimoida mahdollisimman hyvin Tuontiyritys (määräsatama) tuontiyritys ei tarvitse manifestin tietoja sellaisenaan, vaan se on kiinnostunut saapumisavisointitiedoista.$16$,19b/,6(7ã0bb5b<.6(7ãã67$1'$5',7ã-$ã 67$1'$5',(1Ã.b<77g

11 (18) EDI-muodossa välitettävän manifestin osalta standardointikysymyksiin ovat keskittyneet UN/CEFACT/EWG-organisaation ITIGG-työryhmä (International Transport Implementation Guideline Group) sekä kansainvälinen EDI-käyttäjäryhmä SMDG (User Group for Shipping Lines and Container Terminals). ITIGG-työryhmällä on tekeillä kansainvälinen manifestin EDI-sanoman suositus, joka on tasolla Principles and Rules. Tämän suosituksen arvioidaan valmistuvan kesällä 1999 ja se pohjautuu IFCSUM-sanomaan. SMDG-ryhmän jäsenistä Felixstowen Port Community organisaatio MCP (Maritime Cargo Processing) sekä Antwerpenin vastaava yritys Seagha ovat ottaneet käyttöön tullin manifestiin liittyvät EDI-sanomat; CUSREP ja CUSCAR. Antwerpenin tulli on vaatinut tämän vuoden alusta manifestitiedot EDInä varustamoilta. Tällä hetkellä kansainvälisten EDI-sanomien osalta kehitys näyttää siltä, että kaupallisiin tarkoituksiin kuten varustamon ja sen edustajan väliseen tiedonsiirtoon käytetään IFCSUM-sanomaa ja tullille välitettävien manifestitietojen osalta tullin CUSREP- ja CUSCAR-sanomia. International Maritime Organisation (IMO) suosittelee jäsenmailleen PROTECTryhmän määrittelemän EDI-sanoman käyttöönottoa vaarallisten aineiden lastitietojen välittämiseen. PROTECT-ryhmä on määritellyt IFTDGN (International Forwarding & Transportation Dangerous Goods Notification) sanoman soveltamisohjeen, joka on yleisesti käytössä Euroopan suurimmissa satamissa. Vastaava sanoma on tarkoitus ottaa käyttöön uudessa Port@Net-järjestelmässä. (+'2786Ã<+7(1b,6(1Ã0$1,)(67,1Ã7,(726,6b//g.6, Manifestin tietosisältöä yhtenäistettäessä on ehdotuksena se, että tietosisältö harmonisoidaan siten, että se vastaa tullin esittämiä vaatimuksia. Toinen tietosisältöön vaikuttava tekijä on uuden Port@Net-järjestelmän käyttöönotto vuoden 1999 lopulla. Uudella Port@Netillä korvataan nykyinen Portnet-järjestelmä. Port@Net-järjestelmä kuten Portnetkin edellyttävät alusten tulo- ja lähtöilmoitusten välittämistä valtakunnalliseen järjestelmään. Tulo- ja lähtöilmoitukset käsittävät valtaosin samoja tietoja kuin tullin manifesti. Tästä syystä on tietosisällön osalta lähtökohtana näiden kahden tietovirran yhdistäminen niin, että välittämällä nyt ehdotettu manifesti voidaan samalla välittää merenkulkulaitoksen ja satamien vaatimat tiedot. Tarkemmin ehdotettua ratkaisua on kuvattu seuraavassa luvussa. Ehdotus manifestin yhtenäiseksi tietosisällöksi on seuraava, tiedon-käyttäjiksi on merkitty joko satama, tulli, MKL tai nämä 2WVLNNRWDVRQÃWLHGRW

12 (18) tieto lähtö- ja määräsatama ja määräsatamaa seuraava satama lähtö- ja tulopäivä tullin tulo/lähtönumero aluksen nimi aluksen radio call sign aluksen brutto- ja nettovetoisuus, kantavuus aluksen laji aluksen jäämaksuluokka aluksen kaksoispohja aluksen pituus aluksen leveys aluksen kansallisuus varustamo varustamon asiamies asiamiehen LY- tai luottoasiakastunnus (säännöllisen reittiliikenteen lupanumero, aluskohtainen) - tieto Port@Net-järjestelmässä automaattisesti (yksinkertaistetun menettelyn lupanumero, varustamokohtainen) - tieto Port@Net-järjestelmässä automaattisesti hyväksytty lähettäjä alus on kotimaan liikenteessä/ulkomaanliikenteessä alus saapuu/lähtee painolastissa päällikön nimi satamamaksujen maksaja tiedonkäyttäjä tulli MKL, tulli MKL, tulli MKL MKL MKL, tulli tulli, satama tulli tulli tulli MKL, satama MKL satama Aluksen tiedot lähetetään täydellisinä vain silloin kun kyseessä on sellainen alus, joka ei aiemmin ole Suomessa käynyt, muuten riittää aluksen tiedoista nimi ja call sign.

13 (18) 5LYLWDVRQÃWLHGRWÃ\KWlÃWDYDUDHUllÃNRVNHYDWÃWLHGRW tieto laivaajan nimi- ja osoitetiedot vastaanottajan nimi- ja osoitetiedot notify- osapuolen nimitieto LWB- tai B/L-numero toimituserätasolla lastaussatama purkaussatama alkuperäinen lähtösatama (feederliikenne) lopullinen määräsatama (feederliikenne) tavaran kuvaus tekstinä tavaran HS-nimike tai MKL:n tavaraluokka kollien lukumäärä ja laji merkit ja numerot tavaraerän paljous (tonni, kappale, kilo) tavaraerän status onko tavaraerä kauttakuljetuksessa kuljetusyksikön tyyppi ja tunniste tyhjät kuljetusyksiköt, niiden tyyppi ja lukumäärä kuljetusyksikön uudelleen lastaus toiseen alukseen, aluksen nimi (feederliikenne) matkustajien lukumäärä matkustajamaksun maksavien lukumäärä henkilö- ja linja-autojen lukumäärä tiedonkäyttäjä tulli, satama tulli, satama tulli tulli tulli tulli tulli MKL, satama tulli tulli tulli tulli MKL, satama Vaarallisten aineiden lastitiedot välitetään erillisellä EDI-sanomalla, joka pohjautuu kansainväliseen PROTECT-ryhmän suositukseen. (KGRWXVÃNl\WHWWlYLNVLÃ(',VDQRPLNVL Koska lähtökohtana on ollut yhtenäistää manifestin tietosisältö tullin edellyttämällä tavalla, on järkevintä ottaa käyttöön CUSREP (Customs Conveyance Report) sekä CUSCAR (Customs Cargo Report) sanomat. Tällöin voidaan aluksen matkaan liittyvät tiedot välittää etukäteen CUSREP-sanomalla, johon myöhemmässä vaiheessa liitetään varsinaiset manifestitiedot CUSCAR-sanomalla. Yhteys näiden kahden sanoman välillä voidaan toteuttaa käyttämällä viitenumerona tullin tulo/lähtönumeroa.

14 (18) Ã.2.(,/8<03b5,67g1Ã7(.1,1(1Ã5$7.$,68.216(37, Lähtökohtana kokeiluympäristön suunnittelussa on uuden hyödyntäminen. Koska sitä toteutettaessa joudutaan nykyiset EDI-sanomat muuttamaan, voidaan samalla ottaa käyttöön nyt ehdotetut CUSREP- ja CUSCARsanomien soveltamisohjeet. Tällöin varustamo, joka voi välittää manifestitiedot ehdotetulla tietosisällöllä, välittää samalla myös merenkulkulaitoksen ja sataman vaatiman tulo/lähtöilmoituksen tiedot. Etuna on tällöin se, että tulli voi jo etukäteen saada manifestitiedot esille jolloin voidaan harkita esimerkiksi yleisilmoituksen toimittamista jälkikäteen arkistointia varten. Toisaalta on huomioitava se seikka, että varustamot eivät ainakaan alkuvaiheessa voi lähettää manifestitietojaan EDI-muodossa, mistä syystä on tarjottava myös muita vaihtoehtoja sähköisen manifestin toimittamiseen. Tästä syystä on seuraavassa esitetyssä kokeiluympäristön teknisesssä ratkaisukonseptissa päädytty ehdottamaan XML-pohjaista vaihtoehtoa, joka soveltuu varsinkin pienille varustamoille paremmin, koska se ei edellytä niin suurta investointia kuin EDIn käyttöönotto. Seuraava kuva esittää ajateltua järjestelmää Varustamo Vaihtoehto 1 EDI-sanomana CUSREP ja siihen liittyvät CUSCAR-sanomat (tullin manifesti ja MKL:n/sataman tulo/lähtöilmoitus) Vaihtoehto 2 tullin manifesti ja MKL:n/sataman tulo/lähtöilmoitus XML-tiedostona aineiston selaus Tulli tuontimanifesti vientimanifesti (esim. CUSREP ja CUSCAR) Meriliikennetietojärjestelmä Port@Net aineiston poiminta ja/tai selaus MKL aineiston poiminta ja/tai selaus Varustamo lähtö/määräsatama Satamat Kokeiluympäristön teknisestä suunnittelusta vastasi At Business Communications Oy, joka toteuttaa myös uuden Port@Net-tietojärjestelmän. Lähtökohtana

15 (18) kokeiluympäristön suunnittelussa on ollut edellisessä kappaleessa kuvatun toimintamallin käyttöönotto. Ã <OHLVWlÃ;0/VWl XML (extensible Markup Language) on standardi, joka on tarkoitettu tiedon tallennukseen ja jakeluun verkossa. XML sisältää sekä fyysisen että loogisen rakenteen. Looginen rakenne kuvaa dokumentin sisällön rakennetta. Silloin kun XML-dokumentti sisältää DTD:n, dokumentin looginen rakenne määritellään siinä. Looginen rakenne muodostuu: esittelyosasta, joka on pakollinen valideissa ( jos sisältää DTD:n ) XMLdokumenteissa mutta ei hyvin muodostetuissa elementeistä kommenteista entiteettiviitteistä CDATA-osioista, joiden sisältö tulostetaan täsmälleen sellaisena kuin kirjoittaja on sen kirjoittanut sisällön käsittelyohjeista XML-dokumentin fyysinen rakenne on usein erilaisten kokonaisuuksien, entiteettien yhdistelmä. Kaikilla entiteeteillä on nimi ja sisältö. Sisältönä voi olla mm. kuvia, tekstiä, merkkijonoja, ääntä, videopätkiä yms. Jokainen entiteetti on tallennettu itsenäisesti. Niihin viitataan juuri- eli dokumentti-entiteetissä. XML-prosessori aloittaa koko käsittelyn juuresta ja kokoaa dokumenttiin kuuluvat muut entiteetit juuressa asetettujen käsittelyohjeiden mukaan. HTML-kielen ja XML-kielen ero on siinä, että HTML- sisältää vain dokumentin ulkoasuun liittyvän määrityksen. HTML-kielen avulla kuvataan miten tiedot näytetään selaimessa. XML on saanut eniten huomiota clientin dokumenttien hallinnassa, mutta suurin hyöy sovelluskehityksessä saadaan kun se kohdistetaan sinne missä arvokkain data sijaitsee, eli siis palvelimelle. Palvelin on paikka jossa tiedonkäyttäjät ja tuottajat tapaavat toisensa ja puhuvat kukin omaa kieltään. XML, yhteinen muoto datanvälitykseen voi olla ratkaisu tähän ongelmaan olemalla objektimallina jaetulle tiedolle.

16 (18) Ã 'RFXPHQWÃ7\SHÃ'HILQLWLRQÃ'7' DTD määrittää dataobjektin rakenteen siten että sovellukset voivat varmistua mitä atribuutteja on mukana ja mitkä kentät ovat valinnaisia. Tämä mahdollistaa applicationserverin (sovelluspalvelimen) tulkitsemaan dataa lennossa ja vastaamaan dynaamisesti. Koska XML on itsekuvaavaa jokainen tietorakenne ei vaadi omaa koodausta, sovellukset voidaan kirjoittaa yleisellä tasolla. Dataa voidaan käsitellä ja tulkita yleisluontoisesti huolimatta tiedon lähteestä tai sen tarkasta rakenteesta. Ã ;0/QÃHGXW yksinkertaista lukea täysin siirrettävää koska se on ASCII-muotoista ja siirrossa voidaan käyttää standardiprotokollia kuten HTTP vastaanotettuna eri sovellukset voivat tulkita sitä käyttäen yksinkertaista parseria (jäsentäjää) ja saada tietoa navigoimalla puurakennetta jokainen kenttä ja attribuutti on erotettu tunnistavalla tagilla siten jokaiseen rakenteen osaan välittyy tunnistettava metadata kenttien sisäistys (nesting) määrää elementtien rakenteen siten rakenteen osien väliset suhteet voidaan päätellä XML-koodi on helposti jatkettavissa. Koodiin voi helposti lisätä esim uusia kenttiä rikkomatta olemassa olevaa rakennetta. Tietokantakaavioita ei tarvitse suunnitella uudestaan eikä sovelluksia tarvitse kirjoittaa uudestaan. XML mahdollistaa sovellusten jakaa ja muokata dataa vapaasti. Ã ;0/QÃÃNl\WW XML-clientissa XML clientissä tekee niihin toimitetusta datasta smart dataa antaen sovellukselle mahdollisuuden tehdä enemmän ilman palvelimen apua. Se voi tehdä tehokkaampia etsintöjä, hakuja ja muokkausta ja enemmän clientissa tapahtuvaa prosessointia. Tämä tekee clientista smart clientin joka voi etsiä dokumenttidataa tai prosessoida sovellusdataa. XML-dokumenttien ulkoasun määrittelyyn käytetään XSLtyylistandardia (Extensible Style Language) XML-serverissä XML:ää voidaan myös käyttää taustapuolella (back end) tehokkaana varastointiformaattina en hierarkkisten tietojen varastointiin olkoon kyseessä

17 (18) dokumentti- tai sovellusdata. Jos data on hierarkkista on järkevää tallentaa myös rakenne. Middle tier-osassa, jossa sovelluspalvelinten ja back end -tietokanta-varastojen kommunikointi ja datan jakaminen tapahtuu, voi XML ratkaista sovellusten suunnittelussa vastaan tulevia ongelmia. Koska XML-kieli on itsekuvaavaa voidaan sitä käyttää yhteisenä formaattina datan vaihtoon ja siten yksinkertaistaa ratkaisuja middle tier-osassa. XML:ää voidaan käyttää neutraloimaan dataa ja siten vähentää työmäärää middletier-ratkaisujen toteutuksessa. Ã ;0/QÃNl\WW ÃHULÃVRYHOOXVWHQÃYlOLVHHQÃWLHGRQVLLUWRRQ Perinteinen tapa eri sovellusten väliseen tiedonsiirtoon on tehdä perättäis-tiedostoja, joiden rakenne on ennalta määrätty. Näissä tapauksissa sekä lähettävän että vastaanottavan ohjelmiston tulee tietää tiedoston rakenne, jotta tiedot voidaan vastaanottavassa päässä oikein tulkita ja siirtää tietokantaa. EDI-standardi on tuonut tähän jonkin verran helpotusta, mutta lopullinen hyöty on kuitenkin jäänyt saavuttamatta kalliden EDI-muunnin kustannusten takia. XML-pohjaisella tiedonsiirrolla on mahdollista tehdä tiedonsiirto-sovelluksia, jotka eivät ole riippuvaisia datan sisällöstä vaan ne voivat XML-koodia tulkitsemalla siirtää tietoja tietokantaan. Tiedonsiirto-ohjelmista voidaan tehdä geneerisiä, jolloin käsittelysäännöstö kulkee suurelta osin XML-koodin mukana. Tällaiset ohjelmistot on myös helposti parametroitavissa erilaisiin tiedonsiirtotarpeisiin. Ã ;0/QÃNl\WW ÃPDQLIHVWLQÃWLHWRMHQÃVLLUURVVD Meriliikenteen tietojärjestelmän satamatoimintojen tietokantaan tullaan siirtämään tietoja XML-pohjaisesti. XML/EDI-liittymä tehdään vain vastaanottavaan päähän, jolloin joudutaan tulkitsemaan EDI-sanomat ensin XML-muotoon ennen tietokantaan siirtoa. Tällöin ei voida kokonaisuudessa hyödyntää XML-formaatin antamaa etua. Tämän rinnalle voitaisiin kokeilla manifestin tietojen siirtoa meklarilta suoraan XML-muodossa. Tällainen kokeilu edellyttää XML-parserin tekemistä sekä lähettävään että vastaanottavaan päähän. Vastaanottavassa päässä tullaan joka tapauksessa käyttämään XML-parseria sovellukseen tulevien sanomien käsittelyyn. Ã 0DQLIHVWLQÃ;0/SLORWLQÃMlUMHVWHOPlNXYDXV Meklarin järjestelmä: 1) haetaan manifestin tiedot tietokannasta

18 (18) 2) muodostetaan peräkkäistiedosto 3) parsitaan peräkkäistiedosto XML-muotoon 4) lähetetään XML-muotoinen ascii-tiedosto meriliikenteen tietojärjestelmään 2-kohta on mahdollista ohittaa ja tehdä suoraan XML-tiedostoa. Tämä edellyttää lähdejärjestelmältä selkeää sovellusrajapinan esim. SQL:n käyttöä XMLparseriohjelmistossa. Meriliikenteen tietojärjestelmä: 1) vastaanotetaan XML-muotoinen tiedosto 2) tulkataan tiedosto ja muodostetaan XML-kuvauksen perusteella tietokantaa päivittävät SQL-lauseet 3) suoritetaan SQL-lauseet ja samalla tehdään lokia mahdollisista virheistä 0HNODUL 7XOOL XML -tiedosto Manifestit )73 Yllä on kuvattu kuinka manifestin tiedot välitetään meklarin järjestelmästä meriliikenteen tietojärjestelmään, josta tulli voi saada manifestin tiedot käyttöönsä. voidaan rajoittaa, ketkä saavat nähdä eri tietoja.

19 (18) ;0/OXNLMD ;0/WLHGRVWR.RQWUROOHUL ;0/SDUVHUL 7LHWRNDQWD NlVLWWHOLMl 0HULOLLNHQWHHQ WLHWRMlUMHVWHOPl Edellä on kuvattu manifestien käsittelyprosessi 1) luetaan XML-muotoista tiedosto 2) tulkataan tiedosto ja muodostetaan XML-kuvauksen perusteella tietokantaa päivittävät SQL-lauseet 3) suoritetaan SQL-lauseet ja samalla tehdään lokia mahdollisista virheistä 7LHWRNDQQDQ OXNLMD 2SHUDWLL YLQHQ NDQWD.RQWUROOHUL 3HUlWWlLV WLHGRVWRQ PXRGRVWDMD ;0/SDUVHUL $6&,, WLHGRVWR 7LHGRVWRQ OlKHWWlMl ;0/ WLHGRVWR

20 (18) Edellä on kuvattu meklarin tietojärjestelmän manifestien käsittelyprosessi: 1) haetaan manifestin tiedot tietokannasta 2) muodostetaan peräkkäistiedosto 3) parsitaan peräkkäistiedosto XML-muotoon 4) lähetetään XML-muotoinen ascii-tiedosto meriliikenteen tietojärjestelmään à $ 27 6 $7.272,0 3,7,.6, à RKWRSllW NVHW Tehtyjen haastattelujen pohjalta näyttää siltä, että manifestin tietosisältöä on vaikea yhtenäistää kaikissa tapauksissa, koska sen sisältöön vaikuttavat monet eri tekijät kuten meriliikenteen muoto sekä varustamon ja sen edustajan keskinäiset sopimukset. Toisaalta EDI-muodossa välitettävän ns. kaupallisen manifestin osalta ei kansainvälisiä ylemmän tason soveltamis-ohjeita vielä löydy. Sen sijaan tullille välitettävän EDI-muotoisen manifestin käyttö on jo alkanut Antwerpenin ja Felixstowen satamissa ja näiden satamien soveltamisohjeita voidaan Suomessa käyttää pohjatietoina. Toinen merkittävä seikka on uuden Port@Net-järjestelmän käyttöönotto vuoden 1999 lopulla, jolloin lisäämällä tullin tietosisältövaatimuksiin myös merenkulkulaitoksen ja satamien tietosisältövaatimukset, päästään tilanteeseen, jossa yhdellä välitettävällä EDI-muotoisella sanomalla saadaan manifestista tarvittava tieto yhteen keskitettyyn tietojärjestelmään. Tästä tietojärjestelmästä manifestin tiedot ovat käyttöoikeuksien mukaan eri osapuolten saatavilla. Samalla on kuitenkin huomioitava ne varustamot tai varustamojen edustajat, joilla EDI-valmiuksia ei ole. Tästä syystä ehdotetaan XML-pilotoinnin käynnistystä. à KGRWXV MDWNRWRLPHQSLWHLNVL Manifestiprojektin jatkotoimenpiteiksi ehdotetaan seuraavia ehdotetun tietosisällön huomioiminen Port@Net-järjestelmää kehitettäessä ehdotetun XML-pilotoinnin teknisten reunaehtojen huomioimista em. järjestelmää kehitettäessä halukkaan pilottiyrityksen nimeämistä EDI-muotoisen manifestin välittämiseksi halukkaan pilottiyrityksen nimeämistä XML-muotoisen manifestin välittämiseksi aktiivista seurantaa ns. kaupallisen manifestin EDI-sanoman soveltamisohjeen kehityksessä sekä samoin muiden EU-maiden tullien kehityksen seurantaa tullin manifestisanomien käyttöönotossa

21 LIITE (2) /,,7 ±. 6,7 0,7 6 Agentti Alusmaksulaskutus Bruttovetoisuus Buukkaus CUSCAR Agentilla tarkoitetaan varustamon asiamiestä. Alusmaksuilla tarkoitetaan satamalaitoksen laskuttamia alukseen ja sen satamakäyntiin liittyviä kuluja, veloitusperusteena käytetään yleisesti mk/nettovetoisuusyksikkö. Synonyyminä käytetään termiä satamamaksu aluksesta. Aluksen koko tilavuutta kuvaa bruttovetoisuus, mittana on bruttorekisteritonni (brt). Buukkauksella tarkoitetaan lastitilan varausta halutusta aluksesta haluttuna määräpäivänä. CUSREP CUSCAR (Customs Cargo Report) on EDIFACT-standardin mukainen EDIsanoma, joka määrittelee tullille tai muille viranomaisille elektronisesti välitettävän lastiluettelon tietosisällön. Elektroninen manifesti Feeder-liikenne CUSREP (Customs Conveyance Report) on EDIFACT-standardin mukainen EDI-sanoma, joka määrittelee tullille tai muille viranomaisille elektronisesti välitettävän aluksen matkaa koskevan ilmoituksen. Elektronisella manifestilla tarkoitetaan lastiluettelon tietojen välitystä sähköisessä muodossa tietojärjestelmältä toiselle. Feeder-liikenteellä tarkoitetaan syöttöliikennettä valtamerisatamien ja muiden pienempien satamien välillä, ts. lasti uudelleenlaivataan valtamerialuksista pienempiin aluksiin tai päinvastoin.

22 LIITE (4) Huolitsija Hyväksytty lähettäjä IFTDGN Huolitsijalla tarkoitetaan yleisesti huolintatoimia hoitavaa yritystä. Tulliviranomainen voi antaa säädetyt edellytykset täyttävälle henkilölle luvan itse todistaa tavaroiden yhteisöasema joko T2L-asiakirjalla tai vastaavalla merkinnällä kaupallisiin asiakirjoihin esittämättä niitä tulliviranomaisen vahvistettavaksi. Tällaisen luvan saaneesta käytetään nimitystä hyväksytty lähettäjä. IFTDGN (International Forwarding & Transportation Dangerous Goods Notification) on EDIFACT-standardin mukainen EDI-sanoma, joka määrittelee vaarallisten aineiden lastitietojen elektronisesti välitettävän tietosisällön IFCSUM Kantavuus IFCSUM (Forwarding and Consolidation Summary) on EDIFACT-standardin mukainen EDI-sanoma, joka määrittelee yhdistettyjen lastitietojen elektronisesti välitettävän tietosisällön. Kantavuudella tarkoitetaan aluksen kantokykyä (lastin, polttoaineiden, varusteiden, henkilöiden ja varastojen yhteispaino lastimerkin mukaan). Kaupallinen manifesti Kaupallisella manifestilla tarkoitetaan tässä yhteydessä alukseen, sen matkaan ja lastiin liittyviä tietoja, joita välitetään varustamon ja sen edustajan välillä. Kaupallisen manifestin tietosisältö on osapuolten keskenään sopima ja vaihtelee meriliikennemuodosta ja varustamosta riippuen. Konossementti, B/L (Bill of Lading) Laivaaja Konossementti on varustamon antama asiakirja, joka sisältää kuittauksen tietyn tavaramäärän vastaanottamisesta kuljetettavaksi asiakirjasta ilmenevillä ehdoilla ja sitoumuksen luovuttaa sen määräpaikalla asiakirjaa vastaan. Laivaaja on se yritys tai henkilö, joka luovuttaa tavaran kuljetettavaksi lastaussatamassa. 2

23 LIITE (4) Laivausvahvistus Laivausvahvistuksella tarkoitetaan varustamon vahvistusta tietyn tavaraerän laivauksesta nimettyyn alukseen tiettynä ajankohtana. Liner Waybill (LWB) Manifesti Liner Waybill on varustamon antama rahtikirja, jolla se ilmoittaa ottaneensa tavaran vastaan kuljetusta varten. Varustamo sitoutuu hoitamaan kuljetuksen asiakirjan määrittelemällä tavalla ja luovuttamaan tavaran määräsatamassa rahtikirjassa nimetylle henkilölle. Märkrulla Manifestilla tarkoitetaan aluksen lastiluetteloa, joka kattaa tavaraerät aluksen yhden lähtö- ja määräsataman välillä. Nettovetoisuus Satamavahvistus Märkrulla on Suomen ja Ruotsin välisessä autolauttaliikenteessä käytetty suppea lastiluettelo. Aluksen lastitilojen vetoisuutta kuvaa nettovetoisuus, mittana on nettorekisteritonni (nrt). Satamavahvistuksella tarkoitetaan satamaoperaattorin vahvistusta varustamolle tavaraerien lastauksesta nimettyyn alukseen tiettynä ajankohtana. Säännöllisen reittiliikenteen lupa Säännöllisellä reittiliikenteellä tarkoitetaan aluksen liikennöintiä säännöllisesti yhteisön satamien välillä niin että mikään satamista ei ole vapaasatama. Säännöllisen reittiliikenteen luvalla tarkoitetaan tullin myöntämää aluskohtaista lupaa, joka mahdollistaa sen että alukselta, varustamolta tai tavaranhaltijalta ei vaadita mitään tullille toimitettavia ilmoituksia, mikäli koko lasti on yhteisötavaraa. Mikäli kuljetetaan muita kuin yhteisötavaroita, edellytetään tavaroilta T1-passitusasiakirjaa. 3

24 LIITE (4) Taljaus Taljaus on tavaran määrän ja kunnon toteamiseksi suoritettava laskenta- ja tarkastustoimenpide. Tavaramaksulaskutus Tullin manifesti Tavaramaksu on satamalaitoksen laskuttama maksu tavaran tuonnista tai viennistä, yleisesti mk/tonni. Tavaramaksuluokat vaihtelevat satamittain. Synonyyminä käytetään termiä satamamaksu tavarasta. Tullin manifestilla tarkoitetaan tässä yhteydessä alukseen, sen matkaan ja lastiin liittyviä tietoja, jotka tulli on määrännyt ilmoitettavaksi. Tullin manifestin tietosisältö on suppeampi kuin kaupallisen manifestin tietosisältö ja se on tarkoitettu vastaamaan tullin sekä muiden viranomaisten tietotarpeita. Tulo- ja lähtöilmoitus Tulo- ja lähtöilmoitus on merenkulkulaitokselle ja satamille tarkoitettu ilmoitus, jossa kerrotaan alusta, sen matkaa ja lastia koskevat toteutuneet tilastotiedot. Yksinkertaistetun menettelyn lupa Yksinkertaistetun menettelyn luvalla tarkoitetaan tullin myöntämää varustamokohtaista lupaa yksinkertaistaa yhteisön passitusmenettelyjä sallimalla tavaroita koskevan tavaraluettelon (kuten manifestin) käytön yhteisön passitusilmoituksena tai asiakirjana. Yksinkertaistetun menettelyn lupa edellyttää säännöllisen reittiliikenteen lupaa. 4

25 LIITE (2) /,,7 ± 0$, 67, 7, 726,6 /7 Ennakkoilmoituksen tietosisältö (CUSREP) Ennakkoilmoitus Ilmoituksen perustiedot Matkan tiedot Varustamon edustajan tiedot Aluksen tiedot Lastitiedot tyyppi numero antoaika antaja status vapaa teksti tullin tulo/lähtönumero aluksen lähtösatama satamanosa aluksen käyntisatama satamanosa käyntisatamaa seuraava satama ETA käyntisatamaan ETS käyntisatamasta tulo/lähtösyväys varustamon nimi ulkomaanliikenne/ kotimaanliikenne päällikkö satamamaksujen/ tavaramaksujen/ matkustajamaks. maksaja matkanumero edustajan nimi edustajan ovt-tunnus hyväksytyn lähettäjän lupa call sign IMO/Lloydsnumero nimi aluslaji kansallisuus jääluokka pituus leveys kaksoispohja kantavuus bruttovetoisuus nettovetoisuus lastaus/purkaus osittain/kokonaan ei lastaa/purkaa mitään purettavan lastin määrä lastattavan lastin määrä

26 LIITE (2) Lasti-ilmoituksen tietosisältö (CUSCAR) Lasti-ilmoitus Ilmoituksen perustiedot Matkan tiedot Aluksen tiedot Lastitiedot: manifestitaso Lastitiedot: tilastotaso Muut lastitiedot tyyppi numero antoaika antaja status tullin tulo/lähtönumero call sign laivaajan nimi- ja osoite vastaanottajan nimi ja osoite notifyn nimi ja osoite LWB- tai B/L-numero muu viitenumero yksi kuljetussopimus (vienti/feeder) lastaussatama purkaussatama alkuper. lähtösatama (feeder) alkup. määräsatama (feeder) tavaran kuvaus tekstinä tavaran HS-nimike tai MKL:n tavaraluokka kollien lukumäärä ja laji tavaraerän paljous tavaraerän tullistatus transit-indikaattori kuljetusyksikön tyyppi ja tunniste kulj.yksikön tila (tyhjä/täysi) uudelleenlaivaus (feeder) lastaussatama purkaussatama MKL:n tavaraluokka tavaraerän paljous transit-indikaattori kuljetusyksikön tyyppi kulj.yksikön tila (tyhjä/täysi) kuljetusyksiköiden lukumäärä matkustajien lukumäärä matkustajmaksun maks. lukumäärä henkilö- ja pakettiautojen lukumäärä linja-autojen lukumäärä