transportxml Dokumentasjon av samhandlingsmodell og XML-meldinger for transport TransportXML Transportmeldinger Ver. 2.0 mars 2002

Transkript

1 transportxml Prosjekt i regi av Norsk EDIPRO Dokumentasjon av samhandlingsmodell og XML-meldinger for transport Versjon 2.0 april 2002 i

2 Forord Dette dokumentet beskriver en anbefaling (heretter kalt nbefalingen) av hvordan elektronisk samhandling innen forretningsdomenet transport kan gjennomføres basert på XML. XML (extensible Markup Language) er et generelt databeskrivelsesspråk med stor utbredelse, spesielt ved løsninger der internettrelatert teknologi ligger til grunn. nbefalingen er utarbeidet i regi av Norsk EDIPRO gjennom prosjektet transportxml, der en rekke aktører knyttet til forretningsområdet transport har deltatt. Prosjektet ble startet 15.mai nbefalingen dekker to funksjonsområder innen transportdomenet: transportoppdrag og Track&Trace. Begge områdene er vidt definert, og løsningene anses derfor å dekke behov innen mange ulike scenarier som finnes relatert til en eller flere transporter. Bakgrunn. Transportbransjen er en virksomhet der store mengder informasjon formidles mellom ulike parter. Dette skyldes flere forhold. For det første må aktørene under selve utførelsen av sin virksomhet forholde seg til en rekke dokumentasjons- og rapporteringskrav fra myndighetsinstanser i ulike land tolldeklarasjon, transittering, farlig gods-deklarasjon for å nevne noen få eksempler. Videre er det i en transportkjede spesielt ved internasjonale transporter mange parter involvert, og det er viktig at informasjon flyter mellom disse partene på riktig måte og til riktig tid. Det var derfor naturlig at transportbransjen var blant de første til å ta automatisert informasjonsutveksling i bruk, og næringen kan trolig oppvise noen av de mest vellykkede og komplette EDI-implementasjoner som finnes. Utøverne har også gjennom 90-tallet vist stor vilje til å samarbeide om standardisering av løsninger, både når det gjelder implementasjonsguider for EDIFCT-meldinger og relaterte løsninger som for eksempel strekkodestandarder. De siste årene har vi sett en stadig sterkere bruk av internettrelatert teknologi, der webbaserte tjenester samspiller med EDI-løsninger. Innen transportbransjen er løsninger for sporing av gods track & trace et eksempel på dette. Tiden er derfor inne til å bli enige om en enhetlig måte å anvende denne teknologien på: språk, meldingsstrukturer, tilgjengelighet og verktøy for implementasjon. Dette leder oss naturlig til XML (extensible Markup Language). ii

3 Per 1 aprill er status for de ulike delene av spesifikasjonen følgende: Klassediagram Transportoppdrag ktivitetsdiagram Transportoppdrag Semantiske beskrivelser Transportoppdrag Ferdig Ferdig Ferdig Kodelister Ferdig Meldingsmodell Transportoppdrag XML-meldingstype Transportoppdrag Ferdig. Ferdig Profiler Ferdig Mapping Pharos <- > transportxml: Påtenkt, men ikke påbegynt. Track&trace: Dette funksjonsområdet startet arbeidsgruppen å jobbe med på møtet 15.november. Vi har så langt identifisert de tilstandene en godsenhet kan ha. Oslo, 1 april 2002 rild Nybakk Mariann Sundvor iii

4 Innholdsfortegnelse 1 Innledning Kort bakgrunn om prosjektet og arbeidsform rbeidsgruppe Funksjonsområder Konkrete leveranser modell og melding Samhandlingsscenarier (bruksmåter) Transportoppdrag: Track&Trace: Prinsipper for utarbeidelse av modell / meldingstyper Vidt anvendelsesområde per meldingstype - fleksibel meldingsstruktur Representasjon av generaliseringer/spesialiseringer i modell og meldingstype Datatyper i modell og meldingstype ttributter kontra elementer i XML-meldingstyper Navngiving: Kamelskrift og engelsk/norsk språk Basisobjekter og strukturer struktur på meldingsmodell og meldingstype Transportdomene Samhandlingsmodell beskrevet som klassediagram Samhandlingsmodell klassediagram. Del: Part Samhandlingsmodell klassediagram. Del: Transportstrekning Samhandlingsmodell klassediagram. Del: Farlig gods Samhandlingsmodell klassediagram. Del: Frakt Produkt Dato Samhandlingsmodell klassediagram. Del: Toll Samhandlingsmodell markedsplass (ikke ferdig) Samhandlingsmodell prosessmodell beskrevet ved aktivitetsdiagram Samhandling: Transportforespørsel innland (Request) Samhandling: Transportreservasjon innland (Booking) Samhandling: Transportoppdrag innland (Instruction) Samhandling: Transportadvis innland (dvice) Samhandling: Utlandstransport import (Manifest) Samhandling: Utlandstransport eksport (Manifest) Samhandling: Komplett transportinformasjon (Information) Samhandlingsmodell semantiske beskrivelse av klasser og attributter Generiske attributtnavn i XML-meldingsinstanser: ttributter i rotelementet i en XML-meldingsinstans: Samhandlingsmodell semantisk beskrivelse av relasjonene Samhandlingsmodell kodelister Samhandlingsmodell definerte profiler Innenlands profil Innenlands BasisObjekt Innenlandsmodell - Struktur del 1: FarligGods, Utstyr, Transport, Innenlandsmodell - Struktur del 2: LeveringsBetingelse, Part (1) Innenlandsmodell - Struktur del 3: Part (2) Innenlandsmodell - Struktur del 4: Part (3) Innenlandsmodell - Struktur del 5: Produkt, TollInfo Innenlandsmodell - Struktur del 6: Dato (1) Innenlandsmodell - Struktur del 6: Dato (2) nbefaling om bruk av obligatoriske attributter i innenlands profil. (ikke ferdig) Meldingsmodell Meldingsmodell for TransportOppdrag Meldingsmodell Oversiktdiagram BasisObjekt Struktur Meldingsmodell BasisObjekt Meldingsmodell - Struktur del 1: FarligGods, Utstyr, Transport, iv

5 3.1.4 Meldingsmodell - Struktur del 2: LeveringsBetingelse Part (1) Meldingsmodell - Struktur del 3: Part (2) Meldingsmodell - Struktur del 4: Part (3), Meldingsmodell - Struktur del 5: Produkt, TollInfo Meldingsmodell - Struktur del 6: Dato (1) Meldingsmodell - Struktur del 7: Dato (2) Meldingsmodell for Track&Trace (ikke ferdig) XML meldinger Sekvensiell gjennomgang med eksempel XML meldings meldingstype for TransportOppdrag - XSD schema XML-meldingstype for Track&Trace XSD-skjema XML-meldingstype for Track&Trace eksempler Mapping Pharos-transportinstruksjon transportxmltransportoppdrag (ikke påbegynt)...88 v

6 1 Innledning 1.1 Kort bakgrunn om prosjektet og arbeidsform Prosjektet ble initiert mai 2001, og har hatt følgende mål:. En samhandlingsmodell for et subsett av forretningsområder innenfor transport & logistikk som er uavhengig av konkrete meldingsdefinisjoner eller konkret meldingssyntaks. Modellen utarbeides i UML (Universal Modelling Language). Subsettet er identifisert som funksjonsområdene Transportbestilling/advis og Track&Trace. B. Meldingsmodeller beskrevet i UML for de meldingstyper som er nødvendige for å støtte/implementere ehandelsfunksjoner innenfor de funksjonsområder som er listet i punkt. C. Konkrete XML-meldingstyper avledet av de UML-meldingsmodellene som er beskrevet i punkt B. Disse meldingstypene beskrives ved hjelp av XML-skjemaer. D. Beskrivelse av (lagring av) de definerte UML-modellene og XML-meldingstypene i en informasjonsbank (et registry/repository) som er allment tilgjengelig via en internett-adress. 1.2 rbeidsgruppe. nbefalingen er utarbiedet av en arbeidsgruppe med følgende medlemmer: Firma Danzas SG DFDS Tollpost-Globe Deltaker Ole-Kristian Smaadahl Håkon Stokke Sæther Entra Data/Take Cargo Kurt rve Veum, (fra nov. 01) Systema Svein Terje Berg, (fra nov. 2001) Linjegods NorCargo Frans Maas ErgoSolutions Norsk EDIPRO Skandinavisk Transport System Svein Vikhamar tle Thorstensen Øyvind Bondkall Inger Lise Berglund Mariann Sundvor rild Nybakk 1 /94

7 KSD Software Norway Jon-rild Ludvigsen (fra feb. 2002) Posten Logistikk Gemsys Dag Sørensen Morten Hanssen Faglig leder for arbeidgruppen har vært/er rild Nybakk. Mariann Sundvor har hatt/har ansvaret for administrasjon og sekretariats funksjon rbeidsgruppen har hatt møter 1 gang i måneden siden mai 2001, samt at det har blitt utført arbeid av hver enkelt deltaker i periodene mellom hvert møte. 1.3 Funksjonsområder. nbefalingen dekker følgende to funksjonsområder: Transportoppdrag. Dette inkluderer alle løsninger (modell og meldinger) der det er behov for å formidle all (relevant) informasjon relatert til en godstransport. Slik formidling kan skje: før en transport skal utføres, mens en transport er underveis, når en transport nettopp er avsluttet, når som helst etter at en transport er gjennomført, f.eks. som del av en statistikkfunksjon. Track & trace. Dette funksjonsområdet inkluderer løsninger for forespørsel om og svar vedrørende administrative og operative hendelser, herunder avviksrapporter, relatert til en godstransportenhet (transportmiddel, sending, kolli, mm). Hendelser kan også rapporteres gjerne fra ledd til ledd gjennom hele transportkjeden uavhengig av forutgående forespørsel. En av hendelsesrapportene er Proof of Delivery. Kort oppsummert skal transportoppdrag-løsningene brukes når samhandlingen krever at all informasjon om en godstransportenhet (sending, kolli, konsolidert transport, etc.) formidles. Track&trace-løsningene skal brukes når samhandlingen krever at en statusinformasjon (tilstandsrapport) gis om godstransportenheten. 1.4 Konkrete leveranser modell og melding. nbefalingen inneholder følgende leveranser: 2 /94

8 Samhandlingsmodell. nbefalingen inneholder en meldingsuavhengig modell for forretningsområdet transport (en såkalt samhandlingsmodell) som et minimum inkluderer den all informasjon (informasjonsmodell) og de prosesser (aktivitetsmodell) som er relevante for de funksjonsområder som er valgt ut. Modellen presenteres i modellspråket Unified Modelling Language (UML) i form av: Klassediagram: v praktiske årsaker er klassediagrammet delt opp i flere deler (for eksempel del Part, del Transportstrekning, etc., men det skal likevel betraktes som en enhetlig beskrivelse av informasjonsmodellen i transportdomenet). Semantiske beskrivelser: En detaljert beskrivelse av meningsinnholdet i hver komponent i modellen (klasser, attributter og relasjoner). Kodelister for attributter der datainnholdet er kodet. ktivitetsdiagram: Et sett aktivitetsdiagram som beskriver prosessene eller samhandlingene. Meldingsmodeller. For hvert funksjonsområde inneholder nbefalingen en meldingsmodell også beskrevet i UML basert på den overordnede samhandlingsmodellen. Meldingsmodellene reflekterer den informasjon som skal utveksles mellom partene og den strukturen denne informasjonen har. XML-meldingstyper (XSD-skjema og eksempelmeldinger). For hver meldingsmodell inneholder nbefalingen en XML-meldingstype, som er laget ved konvertering fra meldingsmodellen. Meldingstypene er beskrevet ved hjelp av XSD-skjemaer, den nye standarden for beskrivelse av XML-dokumenter som nå er en W3C-rekommendasjon. For å lette forståelsen av meldingstypene gir dokumentasjonen også et gjennomgående eksempel for hver meldingstype. Mapping mot e-com Logistics-løsninger. nbefalingen innholder en oversettelse mellom transportxml-meldingstypene og de XML-meldingstyper som er utarbeidet gjennom det svenske Pharos-prosjektet i regi av e-com Logistics. Vi understreker at de to overskyggende viktige leveransene fra prosjektet er samhandlingsmodellen og XML-meldingstypene. Meldingsmodellene er kun et hjelpemiddel en missing link som er laget for lettere å kunne lage XML-meldingstyper basert på samhandlingsmodellen. 3 /94

9 Det er viktig å understreke at samhandlingsmodellen ikke bare skal beskrive informasjonsinnholdet og sammenhengen i dette, men også definere meningen med hvert enkelt modellelement. Samhandlingsmodellen gir en semantisk definisjon XMLmeldingstypene bruksmåten og meningsinnholdet til enhver konstruksjon i XMLmeldingstypene er definert i samhandlingsmodellen (vi kan si at beskrivelsen av XML-meldingen i XSD-skjemaet sammen med de semantiske definisjonene i samhandlingsmodellen skal gi informasjon tilsvarende den som EDIFCT-løsninger har som mål å nedfelle i implementasjonsguider). 1.5 Samhandlingsscenarier (bruksmåter). nbefalingen identifiserer et sett med samhandlinger eller scenarier (bruksmåter) for transportxml-løsningene. Disse scenariene utgjør transportdomenemodellens aktivitetsmodell og er dokumentert i modellens aktivitetsdiagrammer. Vi gjør oppmerksom på at spesielle behov relatert til fly- og oversjøtransporter ikke er dekket i de nåværende scenariene. Vi beskriver samhandlingene nedenfor i Prosaform Transportoppdrag: Samhandling 1 Transportforespørsel innland: En oppdragsgiver sender forespørsel til transportør/speditør om utførelse av en bestemt type transport, eventuelt som skal utføres på et bestemt tidspunkt Transportør foretar en vurdering om han kan utføre et slikt transportoppdrag Hvis transportør ikke kan eller ikke ønsker å utføre et slikt transportoppdrag, gir han en begrunnet negativ tilbakemelding til oppdragsgiver Hvis transportør kan utføre et slikt transportoppdrag, beregner han svar på konkrete forespørsler i mottatt melding (f.eks. frakt) og sender positiv tilbakemelding til oppdragsgiver 4 /94

10 Samhandling 2 Transportreservasjon innland: En oppdragsgiver booker en transport av konkret godsenhet/konkrete godsenheter på et spesifisert tidspunkt til transportør/speditør Transportøren vurderer bookingbetingelsene Hvis transportøren ikke kan påta seg oppdraget, returnerer han en begrunnet negativ tilbakemelding til oppdragsgiver. lternativt returnerer transportøren en melding der han angir at han kan påta seg transportoppdraget, men i henhold til endrede betingelser. I så fall vurderer oppdragsgiver om han kan godta endrede betingelser kan han dette, bekrefter han bookingen i en ny booking-melding til transportøren. Kan han ikke godta endrede betingelser, må han løse sitt transportbehov på andre måter. Hvis transportøren kan påta seg transportoppdraget med de betingelser som er angitt i booking-meldingen, sender han en bookingbekreftelse til oppdragsgiver. Samhandling 3 Transportoppdrag innland Dette er en melding om gods som umiddelbart skal eller allerede er lastet på hentede transportmiddel. vsender påfører godsets kolli strekkodede merkelapper og laster godset. Oppdragsgiver sender en transportoppdragmelding til transportør meldingen inneholder informasjon om det godset som lastes. Transportør losser (og eventuelt scanner) godset. Transportør mottar transportoppdragsmelding, kontrollerer eventuelt angitte mål mot foretatt scanning og beregner også eventuelt frakt. Transportør sender kvitteringsmelding tilbake til oppdragsgiver og eventuelt ankomstmelding til mottaker. 5 /94

11 Samhandling 4 Transportadvis innland Gods ankommer eller er underveis til en transportør eller speditør. Hvis godset skal videresendes til annen transportør, kan første transportør sende en advisering om gods underveis til neste transportutøver. Hvis godset skal innfortolles av speditør, utføres slik fortolling, hvorpå ankomstmelding kan sendes mottaker. Hvis godset skal innfortolles av mottaker, sender speditør ankomstmelding til mottaker. Hvis godset skal fortolles av en annen speditør, sendes ankomstmelding til denne fortollingsspeditøren. Sistnevnte foretar fortolling og kan så sende ankomstmelding til mottaker. Samhandling 5 Utlandstransport import vsenderspeditør sender en manifest-melding til speditør i Norge. Mottakerspeditør losser godset hvis varepartiet har manko eller skade, sendes en avviksrapport tilbake til avsenderspeditør. Hvis varepartiet ikke har skade eller manko, sender mottakerspeditør losserapport tilbake til avsenderspeditør. Deretter behandles hver enkelt sending på varepartiet vi går da inn i prosesser som er beskrevet i samhandling 4 og/eller samhandling 3. 6 /94

12 Samhandling 6 Utlandstransport eksport En eksportør sender transportinstruksjon til speditør for transport til utlandet av konkret godsenhet/konkrete godsenheter på et spesifisert tidspunkt. Speditøren vurderer transportbetingelsene. Hvis speditøren ikke kan påta seg oppdraget, returnerer han en begrunnet negativ tilbakemelding til oppdragsgiver. lternativt returnerer speditøren en melding der han angir at han kan påta seg transportoppdraget, men i henhold til endrede betingelser. I så fall vurderer eksportøren om han kan godta endrede betingelser kan han dette, bekrefter han transportoppdraget i en ny instruksjonsmelding til speditøren. Kan han ikke godta endrede betingelser, må han løse sitt transportbehov på andre måter. Hvis speditøren kan påta seg transportoppdraget med de betingelser som er angitt i instruksjonsmeldingen, sender han en oppdragsbekreftelse til eksportør. Speditøren besørger eventuelt innhenting av vareparti som skal eksporteres (kfr. samhandling 3). Speditøren foretar eventuelt utgående tollekspedering og transittering. Speditøren konsoliderer og laster utgående gods og sender så manifestmelding til mottakerspeditør i utlandet. Speditør i utlandet mottar manifest, losser aktuell sending (normalt sammen med øvrige samlastede sendinger) og sender losserapport hvis manko eller skade, med angivelse av slik manko eller skade tilbake til avsenderspeditør. 7 /94

13 Samhandling 7 Komplett transportinformasjon. En aktør i transportkjeden sender enten uoppfordret eller på forespørsel komplett informasjon om en konkret godsenhet / konkrete godsenheter til en annen aktør i transportkjeden. Dette kan for eksempel være statistikk- eller sporingsinformasjon som gis lenge etter at en transport er utført. Samhandling 8 uksjon via transportportal/ markedsplass Denne samhandlingen er under konstruksjon i arbeidsgruppen Track&Trace: rbeidsgruppen har nettopp startet arbeidet med å finne aktuelle scenarier for dette området. 1.6 Prinsipper for utarbeidelse av modell / meldingstyper. For de som skal implementere løsninger basert på spesifikasjonene i transportxml, kan det være nyttig å være klar over en del prinsipper som er bakt inn i modellene og meldingstypene. NB! Dette avsnittet er av klart teknisk karakter og er ment for dem som trenger å forstå modellene og meldingstypedefinisjonene i transportxml! Vidt anvendelsesområde per meldingstype - fleksibel meldingsstruktur. nbefalingen spesifiserer en meldingsmodell per hovedfunksjonsområde (TransportOppdrag og Track&Trace), og derved en meldingstype per funksjonsområde. Det betyr at vi har en meldingstype for å formidle komplett informasjon om en godsenhet/godenheter og en meldingstype for å formidle tilstandsrapport om en godsenhet/godsenheter. For hver av meldingsmodellene kan det trekkes ut subsett som identifiseres som profiler: innlandsprofil, utlandsprofil, etc. Dette er et subsett av det innholdet samhandlingsmodellen har. Innen engere brukergrupper eventuelt hos en konkret aktør kan det videre trekkes ut egne subsett, enten av andre profiler eller av meldingsmodellen. transportxml-prosjektet anser at denne fleksibiliteten er nødvendig for å imøtekomme de nødvendige behov for variasjoner som finnes ved utførelsen av transporttjenester. Det er et krav at alle slike profiler er subsett av meldingsmodellen og at alle konstruksjoner i en profilmelding derved kan relateres 8 /94

14 tilbake til samhandlingsmodellen. På den måten vil ikke dette konseptet være til hinder for den ønskede standardiseringen av XML-løsninger. I tillegg til å (kunne) være definert som tilhørende en profil, vil en melding ha en veldefinert funksjon innenfor en definert samhandling (collaboration). Eksempel (funksjonen BookingDecline i samhandlingen Booking): <TransportJob messagefunction="bookingdecline" version="1.0" definedby="norsk EDIPRO" profile="domesticno" collaboration= Booking > Dette prinsippet innebærer bl.a. at ingen modell- eller meldingskomponenter er definert som obligatoriske. I profiler kan vi imidlertid angi det subsettet (av klasser og attributter) som vi anbefaler skal være til stede i en meldingsforekomst for å sikre at en samhandling skal kunne gjennomføres på lik måte overfor ulike samhandlingspartnere Representasjon av generaliseringer/spesialiseringer i modell og meldingstype. Samhandlingsmodellen inneholder mange generalisering/spesialisering-strukturer (superklasse/subklasse). Her er følgende to prinsipper lagt til grunn: I modellen er subklasser modellert eksplisitt med assosiasjoner til hver enkelt subklasse (alternativet ville være å ha flere alternative assosiasjoner til superklassen og på den måten bake semantikken i subklassen inn som en del av semantikken i subklassen), kfr. f.eks. delmodellen for superklasen Part. I XML-meldingstypen er en subklasse representert ved et element som bærer superklassens navn og som har et attributt subclass med verdi = subklassenavnet. Eksempel: <ddress subclass="physicalddress"> <PostalCode>0575</PostalCode> <City>OSLO</City> <CountryCode>NO</CountryCode> 9 /94

15 </ddress> Denne teknikken gjør det mulig å plukke ut superklasser som har flere roller i en konkret melding og representere en slik klasse ett sted i meldingen Datatyper i modell og meldingstype. transportxml anvender enkle datatyper i all hovedsak numerisk og alfanumerisk. De rikere datatypene som bl.a. XSD-skjema muliggjør, har vi valgt ikke å ta i bruk. Lengder på attributter er ikke begrenset. transportxml anvender en spesiell datatype: numerisk med enhet, forkortet Ne i dokumentasjonen. Datatypen er introdusert for å slippe å definere en rekke kompliserte datatyper i modellen og samtidig entydig kunne knytte en enhet til en målt verdi. ttributter som BruttoVekt og FakturaBelop har denne spesielle datatypen. I XML-representasjonen vil et element som representerer et slikt modellattributt ha et attributt med navnet enhet. Eksempel: <Width unit="cmt">120</width> <GrossWeight unit="kgm">4</grossweight> Internasjonalt er det i UN/CEFCT-regi i ferd med å bli tatt fram et sett basistyper (såkalte core component-basistyper) som kan brukes som typer for modellkomponenter og derved objekter representert i XML-meldinger. Eksempler på slike er mount, Measure, Code, Identifier, osv. Norsk EDIPROs infrastrukturprosjekt anbefaler at disse basistypene anvendes i beskrivelse av samhandlingsmodeller. Det kan derfor være aktuelt i en senere versjon av transportxml å introdusere disse basistypene i transportxmls modell eventuelt i kombinasjon med de enkle typene numerisk og alfanumerisk ttributter kontra elementer i XML-meldingstyper. transportxml følger en anbefaling fra Norsk EDIPRO: Modellattributter skal oversettes til XML-attributter dersom de er å betrakte som metadata og til XMLelementer i andre tilfeller. Spesifikt bruker transportxml attributter for å representere subklasseidentifikatorer (attributtet subklasse (subclass), se ovenfor), måleenheter (attributtet enhet (unit), se ovenfor), identifikatorer og referanser (til identifikatorer andre steder i samme melding). 10/94

16 1.6.5 Navngiving: Kamelskrift og engelsk/norsk språk. I henhold til anbefaling fra Norsk EDIPRO og ebxml anvender transportxml en navngivingsstandard der UpperCamelCase brukes for XML-elementer og lowercamelcase brukes for XML-attributter. Denne versjonen av transportxml presenterer navngiving av modellkomponenter og følgelig elementer og attributter i XML på norsk såvel som på engelsk. Oversettelsen mellom norsk og engelsk (eller vice versa) framgår av kapittel 2.5. Ved valg av engelske termer har vi i den grad det har vært mulig, anvendt termer som finnes i tilsvarende internasjonalt arbeid spesielt har vi forsøkt å bruke uttrykk anvendt i det svenske Pharos-prosjeket der de har vært relevante Basisobjekter og strukturer struktur på meldingsmodell og meldingstype. I transportxml anvendes en struktur på meldingsmodellene og derved på meldingstypene der de objekter som kan gå igjen flere steder i en meldingsinstans, f.eks. fordi den konkrete objektinstansen kan ha flere roller eller fordi den kan gjelde flere enheter i meldingen, plukkes ut og prepresenteres som basisobjekter (vi introduserer en egen BasisObjekt-klasse som i XML blir til et BasisObjekt-element). I en egen Struktur-del i modellen (og i meldingstypen) defineres så alle de strukturene som basisobjektene kan inngå i disse objektene representeres her kun ved referanser. Metodikken har mange fordeler: Innholdet i et objekt behøver kun å bli beskrevet en gang. I en transportoppdragmelding vil en part kunne ha flere roller, et produkt vil kunne gjelde mange sendinger i meldingen, osv. Det gir større mulighet for fleksible meldingsstrukturer, fordi strukturkombinasjonene i Struktur-delen av meldingen kan være akkurat så mange og nøyaktig slik som det konkrete behovet tilsier. Vi tror vi lettere tar vare på den semantiske informasjonen i samhandlingmodellen på denne måten. Vanligvis risikerer man å tape semantisk informasjon ved overgang fra samhandlingsmodell til meldingsmodell/meldingstype, først og fremst fordi samhandlingsmodellen er et nettverk med semantikk knyttet til komplekse relasjonsstrukturer, mens meldingsmodellen/meldingstypen er et hierarki. Ved å legge relasjonsstrukturene ut i en egen Struktur-del, blir den resiterende meldingstypen mer tro mot samhandlingsmodellen. Vi kan lettere bytte ut komponenter i meldingsmodell/meldingstype. Etter hvert vil det internasjonalt framkomme mange UML- og XML-baserte core components og business information entities. En slik komponent kan for eksempel representere begrepet transportprodukt. Da kan vi i en senere versjon av transportxml velge å erstatte vår nåværende egendefinerte Produkt-klasse med den internasjonalt standardiserte komponenten kun ved å bytte ut Produkt-objektet ett sted i melingsmodellen/meldingstypen. 11/94

17 2 Transportdomene 2.1 Samhandlingsmodell beskrevet som klassediagram Samhandlingsmodell klassediagram. Del: Part Varepost 0..1 Cod 1 1 CodMottaker vsender gent Mottaker gent 1..* 1..* vsender vsenderhente 1 FakturaMottaker Kontakt Maate Referanse Fritekst 1 1 Transport Oppdrag Meldings Mottaker Meldings vsender TaesUtFra LeggesInnPaa Speditor * OppdragsGiver TollLager Holder Mottaker MottakerLevere Transportor Importor Eksportor Fysisk dresse Part * dresse Post dresse 12/94

18 2.1.2 Samhandlingsmodell klassediagram. Del: Transportstrekning Part Varepost * 0..1 Utstyr 0..1 Transport strekning 1..* Transport Middel * 1 Transportor StartLokasjon 1 StoppLokasjon 1 vsender Hente Lokasjon Mottaker Levere 1 Transport Oppdrag 13 /94

19 2.1.3 Samhandlingsmodell klassediagram. Del: Farlig gods FarligGods Transport Oppdrag Varepost 14 /94

20 2.1.4 Samhandlingsmodell klassediagram. Del: Frakt Produkt Dato Referanse 0..1 Dato UtleveringsDato nkomstdato LasteDato Fritekst MeldingsDato HenteDato TidligsteHente Dato SenesteHente Dato TidligsteLeverings Dato SenesteLeverings Dato Produkt Transport Oppdrag Varepost 0..1 Leverings Betingelse Frakt 1 1..* Debitering /94

21 2.1.5 Samhandlingsmodell klassediagram. Del: Toll Part Transport Bestilling Eksportor 1 1..* TollInfo Importor 1 1..* Speditor TollVarepost 1 1..* HandelsFaktura Samhandlingsmodell markedsplass (ikke ferdig) 16 /94

22 2.2 Samhandlingsmodell prosessmodell beskrevet ved aktivitetsdiagram Forklaring på de ulike konstruksjoner i aktivitetsdiagrammene: Swimlane: Et aktivitetsdiagram består av flere svømmebaner disse er adskilt av stiplede vertikale linjer. Hver svømmebane beskriver aktiviteter/prosesser hos en bestemt aktør (en rolleinnehaver) som er navngitt over svømmebanen. ctivity: Et sett operasjoner som utføres hos en aktør. ngis i ovale firkanter. Branch: Et punkt i prosessen der evalueringen av en betingelse medfører valg av ett av flere mulige videre prosessforløp. ngis som en stående firkant. Fork/Join: Start og avslutning av to eller flere parallelle prosesser. ngis ved tykk heltrukken linje. Source/Sink: Start og avslutning av selve samhandlingsprosessen. Det kan kun være ett startpunkt, men det kan være flere avslutninger. ngis som sirkler, der startpunktet er helt svart mens sluttpunktet inneholder en hvit ring. ctivity med gul farge: Dette er en aktivitet som er direkte relatert til sending eller mottak av en TransportOppdrag-melding til/fra en annen aktør. Selve meldingen identifiseres ved et understreket navn (dette kalles gjerne et flow object). ctivity med grønn farge: Dette er en aktivitet som er direkte relatert til sending eller mottak av en TrackndTrace-melding til/fra en annen aktør. Meldingen som sendes er her ennå ikke identifisert. ctivity med blå farge: Dette er en aktivitet som er direkte relatert til sending eller mottak av en elektronisk melding som ikke er definert som del av transportxml-prosjektet. 17 /94

23 2.2.1 Samhandling: Transportforespørsel innland (Request) Oppdragsgiver [trenger å få utført en gitt transporttjeneste - visse betingelser gjelder] Transportør/Speditør Registrer nødvendige data om transporttjeneste Generer og send Forespørsel Request Motta Forespørsel Kontroller inndata Vurder om forespurt tjeneste er aktuell [forespurt tjeneste er ikke aktuell å påta seg] [kan påta seg forespurt tjeneste ] Motta melding Tjeneste er ikke aktuell RequestDecline Lag og send melding Tjeneste er ikke aktuell inkl. begrunnelse for avslag Beregn svar på konkrete forespørsler i mottatt melding (f.eks. frakt, transporttid, etc.) Motta Svar på Forespørsel RequestResponse Lag og send Svar på Forespørsel 18 / 94

24 2.2.2 Samhandling: Transportreservasjon innland (Booking) Oppdragsgiver [vareparti skal sendes - visse betingelser (f.eks. tidspunkt) gjelder] Transportør/Speditør Registrer nødvendige bookingdata Korriger bookingdata [Kan endre betingelser] Generer og send Transportbooking Velg annen transportør Kan ikke endre betingelser] Booking Motta Transportbooking Kontroller bookingdata og vurder bookingbetingelser [kan ikke påta seg oppdrag med angitte betingelser/data ] [kan påta seg oppdrag med angitte betingelser/data ] Motta melding Oppdrag kan utføres med endrede betingelser BookingConditionalConfirmation Motta melding Oppdrag kan ikke utføres BookingDecline Lag og send melding Oppdrag kan utføres med endrede betingelser Lag og send melding Oppdrag kan ikke utføres inkl. begrunnelse for avslag Beregn ev. frakt Note: Merk at en BookingConditionalConfirmation må bekreftes fra Oppdragsgiver til Speditør i form av en ny Booking Motta oppdragsbekreftelse Booking Confirmation Lag og send Bekreftelse 19 / 94

25 2.2.3 Samhandling: Transportoppdrag innland (Instruction) Oppdragsgiver [vareparti klar for forsendelse] vsender (kan = oppdragsgiver) Transportør Mottaker (kan = oppdragsgiver) Registrer nødvendige sendingsdata Lag strekkodede transportetiketter Last sending på transportmiddel Losse sending og scan kolli Generer og send Transportoppdrag Instruction Motta Transportoppdrag Korriger mål og beregn frakt Motta kvittering InstructionConfirmation Lag og send kvittering med fraktinfo Lag og send ankomstmelding rrival Notice Motta ankomstmelding 20 / 94

26 2.2.4 Samhandling: Transportadvis innland (dvice) Mottaker Transportør 2 Transportør 1/Speditør 1 Speditør 2 [gods ankommet eller underveis] [ skal videresendes av Transportør 2 ihht. avtale] [ skal fortolles av mottaker] [ skal fortolles her] [ skal fortolles av/ forpasses til speditør 2] Generer og send ankomstmelding rrival Notice Motta ankomstmelding Motta transportadvis Transport Generer og dvice send transportadvis Utfør fortolling Motta sending Utfør fortolling Motta ankomstmelding rrivalnotice rrivalnotice Generer og send ankomstmelding Generer og send ankomstmelding 21 / 94

27 2.2.5 Samhandling: Utlandstransport import (Manifest) Mottaker Fortollingsspeditør Mottakerspeditør i Norge Speditør i utlandet Motta manifest [gods ankommet og losset ] Manifest [vareparti lastet på avgående transportmiddel] Generer og send elektronisk manifest [vareparti losset uten anmerkning ] [vareparti manko eller skadet ] Lag og send avviksrapport Motta avviksrapport rrivalnotice Motta ankomstmelding [Skal fortolles av annen speditør] Generer og send ankomstmelding [skal fortolles] Lag og send losserapport Motta losserapport Motta ankomstadvisering rrivalnotice Generer og send advisering Utfør fortolling 22 / 94

28 2.2.6 Samhandling: Utlandstransport eksport (Manifest) Eksportør [vareparti klar for eksport] Speditør i Norge Speditør i utlandet Registrer nødvendige sendingsdata Generer og send Transportoppdrag [kan ikke påta seg oppdrag med angitte betingelser/data ] Instruction Motta Transportoppdrag Korriger sendingsdata [Kan endre betingelser] Motta melding Oppdrag kan utføres med endrede beting. Motta melding Oppdrag kan ikke utføres Velg annen speditør Kan ikke endre betingelser] Instruction ConditionalConfirmation Instruction Decline Instruction Confirmation Lag og send melding Oppdrag kan utføres med endrede betingelser Lag og send Bekreftelse Lag og send melding Oppdrag kan ikke utføres med begrunnelse [Trenger ikke innlandstransport] [skal hentes] [Trenger innlandstransport] [kan påta seg oppdrag med angitte betingelser/data ] Note: Merk at en InstructionConditionalConfirmation må bekreftes fra Eksportør til Speditør i form av en ny Instruction Motta oppdragsbekreftelse [skal leveres av eksportør] Innhent sending Utfør aktivitet Transportoppdrag innland Konsolider og last opp sending Utfør toll- og transitteringsbehandling Send elektronisk manifest Manifest Motta elektronisk manifest Losse sending [ komplett og uskadet] [ manko eller skadet] Motta losserapport (status) Lage og sende ren losserapport Lage og sende avviksrapport 23 / 94

29 2.2.7 Samhandling: Komplett transportinformasjon (Information) ktør 1 i transportkjeden ktør 2 i transportkjeden [trenger komplett informasjon om en godsenhet] [har avtale om å sende transportinformasjon (statistikk, etc.) til aktør 1 ] Generer og send forespørsel om identifisert godsenhet TransportDetailsRequest Motta forespøsel om transportinformasjon [har info om identifisert godsenhet] Motta komplett transportinformasjon TransportDetails Generer og send forespørsel om identifisert godsenhet 24 / 94

30 2.3 Samhandlingsmodell semantiske beskrivelse av klasser og attributter Nedenfor følger en tabell med semantiske beskrivelser av klasser og attributter som benyttes i transportdomenet. Klassene og attributtene er også beskrevet med engelske navn samt at det er henvisninger til kodelister. Klassene er venstrestilt i tabellen mens de underliggende subklassene innenfor en klasse er høyrestilt. Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder dresse (ddress) Lokaliseringen til Part. Kan være fysisk lokasjon eller lokasjon av postboks (avhengig av subklasse). Poststedidentifikasjon etter norsk/europeisk mønster PostNr (PostalCode) N Det navn som lokal/nasjonal postorganisasjon har tilordnet dresse.postnr. PostSted (City) Poststedidentifikasjon som følger mønsteret til f.eks. US, Canada og Storbritannia ZIPKode (ZipCode) Valget av Postnr. eller Zip kode, er avhengig av verdien av Landkode Identifikasjon av et område som dekker flere dresse.poststed, f.eks. County i Storbritannia eller State i US. StatRegion (StateOrRegio n) Kode som entydig identifiserer det landet som dresse.poststed er lokalisert i. LandKode (CountryCode ) 2 Ref. ISO (to bokstavskod e) 25 / 94

31 Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder Fysiskdresse (Physicalddress) Fysisk lokasjon av Part Navn på gate eller vei som inneholder fysisk lokasjon av Part GateNavn (Street) Nummer eller Nummer/bokstav tilknyttet fysisk lokasjon i Fysiskdresse.GateNavn og som nærmere avgrenser fysisk lokasjon av Part GateNr (StreetNo) Ytterligere identifikasjon eller avgrensning av lokasjon av Part. dresselinje (ddressline) Denne kan repeteres (f.eks. etasje, bygning, eksempel: 4.etasje) Postdresse Postboksadresse (Postalddress) Det postkontor som postboksen er definert i forhold til i den offisielle postboksadressen. PostKontor (PostOffice) Nummer eller annen kodet identifikasjon som identifiserer en postboks, eventuelt i relasjon til Postdresse.PostKontor. PostBoks (POBox) Cod (Cod) Utleveringsforbehold. Godset skal kun utleveres mot oppfyllelse av forbeholdet. Cod kan være både fraktetterkrav og vareetterkrav. Se torsken (f.eks. kvittering for betalt beløp) Type Cod (f.eks. remburs, sjekk, CodType (CodType) edipro.no/tr ansportxm 26/ 94

32 Objektnavn Semantisk beskrivelse bankkvittering eller lettsaltet) ttributter /N Spesifiseri nger Koder L/codes/co dtypecode s Kundebegrep for reskontroføring. Identifiserer en betalingstransaksjon. Kan inneholde kontrollsiffer. Kid (TransactionId entifier) Det beløp som skal være betalt før gods kan utleveres Belop (Codmount) Ne Kontrollsiffer knyttet til Cod.Belop. KontrollSiffer PaBelop N1 (ControlDigit) Dokumentnummer som utleveringsforbeholdet henviser til DokumentId (DocumentId) Kan repeteres Dato (DatendTimes) Tidsangivelse År e.kr. (f.eks. 2002). ar N4 (Year) Månedssekvensnr innenfor Dato.ar. Mnd (Month) N2 Dagsekvensnr innenfor Dato.Mnd. Dag (Day) N2 Timesekvensnr (0-23) innenfor Dato.Dag. Time (Hour) N2 Minuttsekvensnr (0-59) innenfor Dato.Time. Minutt (Minute) N2 UtleveringsDato (DeliveryDate) nkomstdato (rrivaldate) LasteDato (LoadingDate) Dato på hvilken eller forventes utlevert, kreves utlevert eller er utlevert hos MottakerLevere. Dato på hvilken eller ankommer eller ankom en nærmere angitt lokasjon Dato på hvilken eller blir lastet på eller er 27/ 94

33 Objektnavn Semantisk beskrivelse lastet på TransportMiddel på nærmere angitt lokasjon ttributter /N Spesifiseri nger Koder MeldingsDato (MessageDate) HenteDato (PickupDate) Dato på hvilken den aktuelle forekomsten av meldingen TransportOppdrag er generert. Dato på hvilken eller skal hentes eller er hentet hos vsenderhente. TidligsteHenteDato (EarliestPickupDate) SenesteHenteDato (LatestPickupDate) Tidligste Dato eller er klart til å bli hentet hos vsenderhente. Seneste Dato eller kreves hentet hos vsenderhente. TidligsteLeverings Dato (EarliestDelivery Date) SenesteLeverings Dato (LatestDeliveryDat e) Tidligste Dato det er mulig å levere hos MottakerLevere eller. Seneste Dato eller kreves levert hos MottakerLevere. Debitering (ChargeItem) Opplysninger om belastningen av 1 kostnadsslag. Inneholder den informasjon som kommer på fakturaen. Kode som identifiserer type Debitering. DebiteringsKo de (ChargeCode) txml/codes /chargecod es Tekst som beskriver type Debitering DebiteringsTe kst (ChargeText) Kode som angir hvorvidt det er belastet eller skal belastes MV av MvaKode (VTCode) 0=MV debiteres ikke 28/ 94

34 Objektnavn Semantisk beskrivelse Debitering.NettoBelop. ttributter /N Spesifiseri nger Koder 1=MV debiteres Belastet beløp inklusive MV BruttoBelop Ne Belastet beløp eksklusive MV Belastet NettoBelop i henhold til utsteders ordinære prisliste Debitering.RegulativBelop Debitering.NettoBelop Tilleggsinformasjon om eller kommentar til Debitering selvforklarende eller forvirrende (Grossmount ) NettoBelop (Netmount) RegulativBelo p (Tariffmount) RabattBelop (Discount) Kommentar (Comment) Ne Ne Ne FarligGods (DangerousGoods) Opplysninger om, VarePost eller som omfattes av særskilte regler og bestemmelser i henhold til DR eller UMDG, se gjeldende forskrifter. Konferer DR-håndbok kap. 5.4, (tilsvarende for øvrige konvensjoner) Konferer DR -åndbok kap. 5.4, (tilsvarende for øvrige konvensjoner) Konferer DR-håndbok kap. 5.4, (tilsvarende for øvrige konvensjoner) Konferer DR-håndbok kap. 5.4, (tilsvarende for øvrige konvensjoner) UNNr (UNNo) VareNavn (Commodity) FareKlasse (Class) EmballasjeGr uppe (Group) N N 29/ 94

35 Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder Frakt (Charges) Samlingen av belastninger (= mengden Debitering-objekter) som foretas for eller = FakturaMottakers kostnad FriTekst (FreeText) Tekst som kan skrives fritt Felt som forteller hva Tekst skal brukes til. TekstBruk (Usage) ICN=Informa tion for consignee SIC=Sender s instruction to carrier HN=Handli ng instructions I=General instructions Instruksjon eller annen tekst som skal anvendes slik det er identifisert i FriTekst.TekstBruk. Tekst (Text) ntall tegn i FriTekst.Tekst. Lengde N (NoOfCharact ers) HandelsFaktura (CommercialInvoice) Faktura fra vareselger til varekjøper (normalt resp. Eksportor og Importor). Det nummer som vareselger har påført HandelsFaktura som identifikasjon ved utstedelse. FakturaNr (InvoiceNo) Den dato som vareselger har påført HandelsFaktura ved utstedelse. FakturaDato (InvoiceDate) Det totalbeløp som vareselger har påført HandelsFaktura som FakturaBelop (Invoicemou ) Ne 30/ 94

36 Objektnavn Semantisk beskrivelse belastning og/eller vareverdi. ttributter nt) /N Spesifiseri nger Koder (Package) En fysisk enhet beregnet for transport, som inneholder en eller flere varer sammenstilt/pakket som en fysisk enhet. Et referansenummer som unikt identifiserer. Identifikat or (PackageId) Identifiserer type Identifikator. (f.eks. den norske standarden definert av Norsk EDIPRO) IdType (IdType) For all innenlandstr ansport i Norge anbefaler transportxm L bruk av ENSSCC. ENSSCC= Serial Shipping Container Code slik dette er definert i Norsk EDIPRO s Dokumenta sjon i innenlandstr ansport Other= Defa ult (dyr som lever i vann) Den ene av 3 dimensjoner ved, der de 2 øvrige er Bredde og Lengde. Hoyde (Height) Ne MTR=Meeter DTM=Desim eter CMT=Centim eter Den ene av 3 dimensjoner ved, der de 2 øvrige er Hoyde og Lengde. Bredde (Width) Ne MTR=Meeter DTM=Desim eter CMT=Centim eter Den ene av 3 dimensjoner ved, der de 2 øvrige er Hoyde og Bredde. Lengde (Length) Ne MTR=Meeter DTM=Desim 31/ 94

37 Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder eter CMT=Centim eter Type pakning i kodet form Type (PackageType Code) Bruk koder fra til UN/ECE-rek. nr. 21 Type pakning i tekstlig form. (f.eks. pakke, fat, flasker) TypeTeks t (PackageType Text) ntall vektenheter (av den type som er angitt av enhetkoden) inklusive antall vektenheter i emballasje. BruttoVekt (GrossWeight) Ne KGM=kilogra m GRM=gram TON=tonn ntall vektenheter (av den type som er angitt av enhetkoden) eksklusive antall vektenheter i emballasje. NettoVekt (NetWeight) Ne KGM=kilogra m GRM=gram TON=tonn (se rec 21) ntall volumenheter (av den type som er angitt i enhetkoden). Volum (Volume) Ne DMQ=Kubuk kdesimeter MTQ=Kubikk meter ntall meterlengder som benyttes på TransportMiddel (arealbegrep) LasteMeter (LoadingMetre s) N Tekst, nummer eller annen id som bidrar til å identifisere Merket (Marking) KontaktMate (Contact) Beskrivelse av en måte den tilknyttede Part kan kontaktes på, ev. kommuniseres med 32/ 94

38 Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder Telefonnummer. TlfNr (PhoneNo) Telefaksnummer. FaxNr (TelefaxNo) dresse for elektronisk post. ( ddress ) Navn på person som skal kontaktes KontaktPerso n (ContactName ) Stilling eller avdeling til KontaktMate.KontaktPerson. Funksjon (ContactFuncti on) LeveringsBetingel se (TermsOfDelivery) vtale mellom selger og kjøper uttrykt i gjeldende INCOTERMS eller COMBITERMS, som definerer hvem som betaler for de ulike involverte transporttjenester = frankatur) Kode for leveringsbetingelse LevBetKode (TODConditio ncode) Beskriver om dette er COMBITERMS eller INCOTERMS KodeType (TODConditio ncodelist) Incoterms=I ncoterms 2000 Combiterms =Combiterm s 1990 Lokasjon som leveringsbetingelsen gjelder i forhold til StedsNavn (TODLocation ) 33/ 94

39 Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder Lokasjon (Location) Geografisk sted. Entydig identifikasjon av Lokasjon. LokasjonId (LocationId) Beskriver hvilken type id som benyttes i Lokasjon.LokasjonId. IdType (IdType) Eksempler: 140: Middelhavet, Østlandet 163:fylke,ko mmune, state,county 16 Postnr. 139 Havn. 140 Gjensidig avtalt geografisk område. 145 IT. 162 Land Offisiell betegnelse på region eller område innenfor land. UNLOCOD E UNlokasjonsk ode EN ENlokasjonsnr. Type lokasjon (f.eks. terminal, rampe, pub) LokasjonType (LocationType ) edipro.no/tr ansportxm L/codes/loc ationtype: Terminal Ramp Hub Pub Gate Industrialre a Den betegnelse som brukes for å navngi Lokasjon Navn 34/ 94

40 Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder (LocationNam e) StartLokasjon (StartLocation) StoppLokasjon (EndLocation) Kode som entydig identifiserer det landet som dresse.poststed er lokalisert i. Lokasjon der TransportStrekning begynner. Lokasjon der TransportStrekning slutter. LandKode (CountryCode ) 2 ISO TransportOppdrag (TransportJob) Handling som initierer transport Part (Party) En aktør i forbindelse med en transport, f eks. Mottaker, vsender Entydig identifikasjon av Part. PartId Typen identifikasjon er angitt av attributtet IdType (PartyId) ngivelse av hva som brukes som PartId (F eks. org.nr, internt kundenr. ) IdType (IdType) Sendes kode 91, skal informasjon være kjent hvis ikke må full partsinforma sjon gis 9 = ENlokasjon snr 82=Enhetsre gisteret i Brønnøysun d 87=Bestemt av transportutøv er 91=Bestemt av annen part (f.eks. mottakers kundenr hos avsender) Et firmas eller en organisasjons offisielle navn, alternativt en persons fulle Navn(Name) 35/ 94

41 Objektnavn Semantisk beskrivelse navn. ttributter /N Spesifiseri nger Koder Unik identifikasjonsnummer gitt av et lands myndigheter. Organisasjons Nr Tilsvarer VT-nr. i EU (I Norge: enhetsnr for firma og personnr for personer) (VTNo) Parts kundenr. hos tollmyndigheter TollkredittKont o (CustomsCred itno) Mottaker (Consignee) MottakerLevere (DeliveryParty) OppdragsGiver (OrderingParty) Den juridiske mottaker av eller. Trenger ikke være adressen som eller blir levert hos. Part hos hvilken eller, skal leveres hos eller er levert hos. Part som bestiller transporten som beskrives av TransportOppdrag. FakturaMottaker (FreightPayer) Part som skal belastes. Kan være avsender, mottaker eller annen Part vsender (Consignor) Den juridiske avsenderen av eller. Trenger ikke være adressen som eller blir hentet hos. vsenderhente (DespatchParty) Part hos hvilken eller, skal hentes hos er eller hentet hos. CodMottaker (CashOnDeliveryP ayee) Part som er mottaker av COD-beløp, eller den som utleveringsforbeholdet utføres på vegne av. Trenger ikke være avsender. Bank, kontotype og løpenr BankKontoNr 36/ 94

42 Objektnavn Semantisk beskrivelse satt sammen til et komplett bankkontonr. (I Norge 11 siffer) ttributter (ccountno) /N Spesifiseri nger Koder Navn på bank BankForbindel se (BankName) Kode som identifiserer CodMottaker.BankForbindels e benyttes ved internasjonale betalinger SwiftKode (SwiftCode) TollLagerHolder (BondedWarehous eparty) Speditor (Forwarder) Transportor (TransportCompan y) Eksportor (Exporter) Part som innehar autorisasjon fra myndighetene til å kunne registrere og lagre gods før fortolling Part som tilbyr transport og tilhørende logistikktjenester (f.eks. fortolling) - eksempelvis bergenser. Part som ansvarer for hele eller deler av transporten av eller. Vareeier ved utgående tollgrensepassering Importor (Importer) Vareeier ved inngående tollgrensepassering vsendergent (Despatchinggent ) Mottakergent (Receivinggent) Speditor som er avsender av manifestert gods ved internasjonal transport Speditor som er mottaker av manifestert gods ved internasjonal transport MeldingsMottaker (MessageRecipient )) Part som en instans av et TransportOppdrag er adressert til Normalt forutsettes at avsender og mottaker av melding angis i omsluttende konvolutt (Feks. SOP) 37/ 94

43 Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder Meldingsvsender (MessageSender) Part som genererer en instans av TransportOppdrag Se kommentar for MeldingsMo ttaker Produkt (Service) Identifikasjon av et produkt/en tjeneste Transportor eller Speditor har (f.eks. stykkgods, partigods, varmegods, farlig gods, levende dyr, giroservice, osv.) Kode som identifiserer Produkt ProduktID (BasicService Code) Ref. Transportor/ Speditor. nbefalte koder ved forespørsel: DoorDoor Express Groupage Tilleggstjeneste som er knyttet til ProduktId. Kan repeteres. TilleggTjenest eid (dditionalser vicecode) Ref. Transportor/ Speditor. Prioritet uavhengig av produktdefinisjon relatert til andre egne forespørsler/bestillinger ProduktPriorit et (Priority), B, C... =Highest Indikator som sier om eller skal transporteres innenfor visse temperaturgrenser. TemperertGod sindikator (Temperature ControlledGoo dsind) YES NO Maksimumstemperatur MaxTemp (MaxTemperat ure) N Forutsetter Celsius Minimumstemperatur MinTemp (MinTemperat ure) N Forutsetter Celsius Idealtemperatur IdealTemp (IdealTempera ture) N Forutsetter Celsius Eks. Lollipop 17.5 C 38/ 94

44 Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder Referanse (Reference) Informasjon fra avsender eller mottaker som er relevant for en annen enn den som sender informasjonen. Benyttes kun dersom det objekt som refereres, ikke er en del av den konkrete forekomsten av transportmo dellen (dvs. av meldingen som utveksles). Identifikasjon av Reference. RefNr (ReferenceNo ) Type RefNr. (f.eks. senders ordrenr, etc.) IdType (IdType) O Mottakers referanse CU Senders referanse BN Booking number FF Speditørs referanse ICO Forsikrings referanse SS Selgers referanse CO Kjøpers referanse EP Fraktbetaler s referanse 39/ 94

45 Objektnavn Semantisk beskrivelse ttributter /N Spesifiseri nger Koder Selvforklarende Tekst (Text) (Consignment) Gods som transporteres på vegne av Oppdragsgiver fra en eller flere vsender til en eller flere Mottaker. Et referansenummer som unikt identifiserer Nr (ConsignmentI d) For innenlandsk e transporter bør man benytte Norsk EDIPROs anbefaling om sendingsnu mmer. ntall palleplasser som bestilles for transport av eller er anvendt ved transport av. ntallpallepla sser (NoOfPalletFo otprints) N Verdi av den varen eller de varene omfatter. VareVerdi (GoodsValue) Ne Beløp som den varen eller de varene omfatter, er forsikret for med den type forsikring som er identifisert ved.forsikringskategori. ForsikringsVer di (InsuranceVal ue) Ne Type forsikring ForsikringsKat egori (TypeOfInsura nce) TollInfo (CustomsInformati on) Informasjon til bruk ved fortolling av vareparti som omfattes av. 40/ 94