EHF Pakkseddel

I Stortingsmelding nr. 36:2008-2009 Det gode innkjøp står det:

Fornyings- og administrasjonsdepartementet og Kirkedepartementet (FAD) anså bruk av åpne standarder som et grunnleggende element for å skape en velfungerende offentlig sektor, med god intern samhandling og et godt tjenestetilbud til innbyggere og næringsliv.

Målsetningen med dette dokumentet er å definere et felles format for fakturameldinger i det norske markedet, og å legge til rette for en effektiv innføring og utbredelse av elektronisk samhandling i fakturaprosessen basert på disse formatene.

Målgruppen for dokumentet (heretter omtalt som implementeringsveileder) er både faglig og teknisk personell hos brukere som ønsker å utføre hele eller deler av leveringsprosessen elektronisk. Det vil i praksis si å sende elektronisk pakkseddel. Dokumentet kan også benyttes av systemleverandør, ERP leverandør og meldingsformidlere.

Dokumentet er inndelt i følgende deler:

Denne revisjonen gjøres tilgjengelig for bruk fra 10. desember 2019. Den vil være obligatorisk fra samme dato.

Versjon 1.0.12 er en revisjon av EHF Pakkseddel 1.0, og dette innebærer at endringene i denne revisjonen er bakoverkompatibel med EHF Pakkseddel 1.0, og dermed at instansdokumenter som er gyldige i henhold til EHF Pakkseddel 1.0 også vil være gyldige i versjon 1.0.12. Det presiseres her at gyldig i henhold til EHF Pakkseddel 1.0 innebærer at det er gyldig i henhold til veilederen til EHF Pakkseddel 1.0, da det er dette som er den normative kilden.

EHF er en forkortelse for Elektronisk handelsformat.

EHF er basert på arbeidet som er gjort i CEN BII. Dette er så videre tilpasset norske forskrifter (bokføringsforskriften) og gjeldene praksis for de ulike aktuelle forretningsprosesser slik disse praktiseres i det norske markedet. Difi arbeider for at hele handelsprosessen skal kunne gjennomføres med EHF dokumenter. Dette gjelder dokumenter både før og etter kontraktsinngåelse.

Dokumenter helt fra anbudskatataloger til kreditnota skal dekkes under EHF paraplyen. I løpet av 2013 vil Difi tilrettelegge for bruk av EHF formatene i det vi kaller post award prosessen, med andre ord prosessen etter at en selger og kjøper har inngått en kontrakt.

Ved å benytte EHF dokumentene skal samhandlingen mellom kjøper og selger være forutsigbar. Elementer fra Katalogen skal man kunne gjenbruke i en ordre, og elementene fra en ordre skal kunne gjenbrukes i en faktura. Dette medfører at man vil få en helhetlig bruk av alle dokumentene som er under EHF paraplyen.

Difi har valgt å basere EHF-formatene på CEN BII og en syntaks implementering basert på Universal Business Language (UBL). UBL er en fritt tilgjengelig standard som ikke innebærer lisenskostnader, og det samme gjelder for EHF.

EHF forvaltes og vedlikeholdes av Difi.

De ulike EHF-formatene nevnt over, inneholder en del felles informasjonselementer. (Leverandør, kunde, vare, etc). Det er viktig at felles informasjon er konsistent i de ulike formatene. Det vil si at elementer med identisk innhold er definert på samme måte og så langt det lar seg gjøre har samme navn. For eksempel vil EHF Fakturaformatene gjenbruke elementer fra katalog og ordre for å sikre konsistens på tvers av meldingene slik at innhold i disse transaksjonene reflekteres i fakturameldingene. På denne måten understøttes en effektiv og automatisert kontroll av faktura mot bakenforliggende transaksjoner.

Bruk av tomme elementer er ikke lov i UBL, som EHF er basert på. Dette skyldes at tomme elementer kan tolkes til å ha mening, f.eks. at et element ikke er tilgjengelig ved utsendelse. I tillegg vil numeriske felt og datofelt ha krav til innhold som vil feile i validering dersom de sendes som tomme elementer.

Ved å benytte PEPPOL Transport Infrastruktur vil man få en effektiv bruk og transport av EHF formatene. PEPPOL Transport Infrastruktur har som utgangspunkt å gjøre det enkelt med handel på tvers av landegrenser. Erfaringen viser også at det er enklere å etablere elektronisk meldingsutveksling internt i Norge, blant annet fordi alle tjenestetilbydere benytter standardprosesser.

Det er viktig å merke seg at alle dokumenter som skal sendes inn i transport infrastrukturen må være validert OK i henhold til Difis validator. Dette kan gjøres enten av dokumentutsteder eller av tjenesteyter på dokumentutsteders vegne.

Tidligere Fornyings- Administrasjons- og Kirkedepartementet (FAD) anbefaler i sitt Rundskriv P-10/2012, at alle statlige virksomheter skal benytte PEPPOL Transport Infrastruktur.

I tråd med den metodiske tilnærmingen som ligger til grunn for EHF formatene (se CEN BII) vil de elektroniske meldingene som inngår i et format bli utvekslet mellom de aktuelle aktørene som en del av en elektronisk samhandlingsprosess – en profil.

En profil er definert som den elektroniske samhandlingsprosess som en aktuell meldingsutveksling er en del av. En profil vil typisk omfatte flere relaterte meldinger som utveksles mellom to parter, men kan i sin enkleste form omfatte utveksling av kun en enkelt melding.

Så langt det har latt seg gjøre benytter EHF seg av profiler utarbeidet av BII eller PEPPOL. Eksempler på relevante profiler er:

De meldinger som utveksles innenfor en profil er tilpasset (engelsk: customized) for å tilfredsstille de krav til innformasjonsinnhold som gjelder for den spesifikke bruken av det aktuelle forretningsdokumentet.

En CustomizationID (tilpasningsidentifikator) benyttes for å identifisere de forretningsregler som gjelder for det aktuelle forretningsdokumentet, dvs. det sett av forretningsregler som ble lagt til grunn av utsteder når dokumentet ble etablert.

Nedenstående eksempel på CustomizationID indikerer at innholdet i den aktuelle meldingen er basert på forretningsregler fastsatt av BII (urn:www.cenbii.eu:transaction:biitrns010:ver2.0), utvidet (extended), tilpasset og presisert av PEPPOL (urn:www.peppol.eu:bis:peppol5a:ver2.0) og ytterligere utvidet, tilpasset og presisert for norske forhold i EHF Faktura veilederen (urn:www.difi.no:ehf:faktura:ver2.0).

Eksempel på CustomizationID dersom det sendes en PEPPOL BIS, ytterligere info om PEPPOL BIS kan finnes på PEPPOL.

Kombinasjonen av registreringer i ELMA og de veiledningene denne registreringen henviser til, gjør at det ikke er behov for å inngå en mer formell samhandlingsavtale mellom avsender og mottaker. Gjennom registreringen i ELMA har en aktør deklarert sin evne og vilje til å ta imot forretningsdokumenter som er satt opp i henhold til den aktuelle veilederen, og alle andre kan derfor fritt velge å sende det aktuelle forretningsdokumentet til denne aktøren.

Ved utveksling av katalog og ordre hvor registrering i ELMA ikke benyttes, anbefales det at bruken av elektroniske meldinger reguleres via kjøpskontrakten (rammeavtalen) eventuelt med en egen samhandlingsavtale som vedlegg. Dette for å knytte den elektroniske samhandlingen mot de merkantile bestemmelsene og dermed få en jevnlig revidering av den elektroniske prosessen.

Difi forbeholder seg retten til å endre nåværende format til et nytt format dersom behovet skulle oppstå. Difi vil publisere informasjon om dette på sine nettsider samt at de vil varsle sine registerte kontakter med e-Post.

Difi forvalter formatet på følgende måte:

Den elektroniske meldingen som denne veilederen omfatter er pakkseddel. Pakkseddelen er en melding fra leverandør/selger til kjøper, og er en annonsering av en nært forestående leveranse. Den forteller hvilke kolli leveransen består av og hvilke varer som inngår i hvilke kolli. Pakkseddelen har referanse til ordren som leveransen gjelder.

Figuren under viser hvilke roller som inngår i leveringsprosessen.

Alle meldinger har ProfileID og CustomizationID. ProfileID identifiserer forretningsprosessen meldingen er en del av, CustomizationID identifiserer hvilken dokumenttype meldingen er og hvilke regler meldingen etterlever.

Profiler er knyttet til en forretningsprosess og en eller flere dokumenttyper. Gyldige instansdokumenter må ha både ProfileID og CustomizationID fra samme profil.

I oversikten under er hver dokumenttype knyttet til mottakers rolle når instansdokumenter sendes. Ved registrering i ELMA er det hvilke dokumenttyper mottaker kan motta som registreres.

Denne versjonen av EHF Pakkseddel gjør bruk av UBL XML schema versjon 2.1.

Leveringsprosessen omfatter opprettelse og oversendelse av pakkseddel fra leverandør til kunde samt mottak og behandling hos kunde.

Leveringsprosessen kan beskrives ved følgende arbeidsflyt:

Figuren under viser leveringsprosessen med bruk av EHF pakkseddel meldingen. Denne prosessen er basert på profil 30 i CENBII2 (BII30 – Dispatch only).

Følgende roller kan angis i formatet. Disse kan innehas av samme aktør eller ulike aktører avhengig av hvordan håndtering av meldingen er organisert.

Benyttes for å refere til hvilken ordre pakkseddelen gjelder. En pakkseddel kan kun gjelde EN ordre. En ordre kan leveres ved hjelp av flere pakksedler.

Hver pakkseddel linje må referene til hvilken ordrelinje pakkseddel linjen gjelder. Dersom pakkseddel linjen ikke gjelder en spesifikk ordrelinje, kan verdien NA (Not Applicable) angis i elementet OrderLineReference.

Beskrivelse av den aktuelle forsendelsen.

Beskrivelsene nedenfor gjelder elementer på pakkseddellinje.

Nivåer i valideringsprosessen:

Kombinasjonen av ProfileID og CustomizationID i et XML instansdokument definerer hvilke valideringsregler som gjelder for meldingen.

CustomizationID kan utvides med flere element for bransjespesikke og firmaspesifikke valideringsregler.

Difis Validator er et program som brukes til å validere EHF XML-filer.

Informasjon om tjenesten her: https://vefa.difi.no/ehf/knowledge-base/validation/

Vedlagt er strukturtabell som gir en skjematisk oversikt for aktuelle meldinger.

Vedlagt er komplett meldingstabell for aktuelle meldinger.

Gjeldende kodelister for EHF:

UBL 2.1 Schema som denne implementasjonsguiden baserer seg på er tilgjengelig fra OASIS.

Ved validering vil syntaksvalidering gjøres mot aktuelle schema.

For mer informasjon om UBL 2.1 henviser vi til standarden. Ytterligere ressurser er også tilgjengelig.

Valideringsfiler basert på Schematron er tilgjengelig i vårt Github-repoistory. Release "2021-02-15" inneholder gjeldende versjon og branch "master" inneholder utvikling og høring.

Fra og med release 2016-11-15 distribueres valideringsfiler som Schematron i stedet for XSLT.

Eksempelfiler er gjort tilgjengelig for å hjelpe utviklere. Eksempelfiler for denne implementasjonsguiden er inkludert i eksempelfil-pakken.