EHF Ordreprosess

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 ordreprosessen elektronisk. Det vil i praksis si å sende og motta elektronisk ordre og ordrebekreftelse. Dokumentet kan også benyttes av systemleverandør, ERP leverandør og meldingsformidlere.

Dokumentet er inndelt i følgende deler: * Kapittel 1 gir en kort introduksjon som beskriver bakgrunn og målsetning med implementeringsveileder. * Kapittel 2 beskriver de endringer som er gjort mellom forskjellige versjoner av implementasjonsveilederen. * Kapittel 3 beskriver EHF formatene generelt. * Kapittel 4 inneholder definisjoner som er relevant for ordreformatene. * Kapittel 5 beskriver generelle prinsipper og forutsetninger for ordreformatene. * Kapittel 6 gir en detaljerte beskriver av sentrale informasjonselementer i ordreformatene. * Kapittel 7 omhandler validering. * Kapittel 8 inneholder vedlegg som separate dokumenter.

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

Versjon 1.0.13 er en revisjon av EHF Ordreprosess 1.0, og dette innebærer at endringene i denne revisjonen er bakoverkompatibel med EHF Ordreprosess 1.0, og dermed at instansdokumenter som er gyldige i henhold til EHF Ordreprosess 1.0 også vil være gyldige i versjon 1.0.13. Det presiseres her at gyldig i henhold til EHF Ordreprosess 1.0 innebærer at det er gyldig i henhold til veilederen til EHF Ordreprosess 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:

De elektroniske ordremeldingene som denne veilederen omfatter er EHF Ordre og EHF Ordrebekreftelse. Kjøper og selger må kunne utveksle begge meldingene elektronisk for å være i overenstemmelse med denne veilederen. Kjøper sender en ordre til selger som via en ordrebekreftelse kan angi et begrenset antall endringsmuligheter i forhold til hva som kan leveres. Ordrebekreftelsen setter dermed leverandøren i stand til å informere kjøper om hva som blir levert og kan gjennomføre leveransen uten forsinkelser. Omfanget av endringene, hvilke endringer som tillates og tidspunktet for når meldinger skal sendes bør avtales mellom partene i en kjøpsavtale eller en samhandlingsavtale, ref. kapittel 3.6.

Ordreprosessen foregår post-award, dvs. etter at avtale er inngått mellom leverandør og kjøper. Figuren under viser hvilke funksjoner som dekkes av EHF ordremeldinger og hvilke roller som inngår. I tillegg må også leveringssted angis i meldingene.

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.

Ordreprosessen omfatter opprettelse og oversendelse av ordre fra kjøper til selger og ordrebekreftelse i retur fra selger til kjøper. Dette er en vanlig gangbar forretningsprosess som de fleste foretak som bedriver handel forstår.

Ordreprosessen kan beskrives som følgende arbeidsflyt:

Figuren under viser ordreprosessen med bruk av EHF ordremeldingene. Denne prosessen er basert på profil 28 i CENBII (BII28 - Ordering). Denne profilen forutsetter at både ordre og ordrebekreftelse blir sendt elektronisk, og at bekreftelsen kan innebære at ordren enten aksepteres eller helt eller delvis eller forkastes.

Kvittering på at en EHF melding er mottatt kan være i form av en e-post, telefon eller en elektronisk kvitteringsmelding. Bruk av elektronisk kvitteringsmelding er beskrevet i kapittel 3.4. Dette må eventuelt avtales spesielt mellom aktørene.

Følgende roller kan angis i formatet. Disse kan innehas av samme aktør eller ulike aktører avhengig av hvordan håndtering av ordremeldingene er organisert. Type aktøridentifikator som brukes skal angis i schemeID med kodeliste i henhold til «Peppol Policy for use of identifiers» . Følgende koder er aktuelle for bruk i Norge:

ZZZ skal som et eksempel brukes for interne kunde- eller leverandørnummer.

Et produkt kan identifiseres på ulike måter avhengig av hvordan leverandøren identifiserer varen når de mottar ordren Ved katalogkjøp så hentes artikkelnummer eller varenummer fra katalogen som leverandøren har sendt.

Følgende id’er er mulige i formatet: * Selgers identifikasjon * Identifikasjon ihht. en standard, f.eks. GTIN

Leverandørens artikkelnummer/varenummer eller standard id bør være med.

Selve produktnavnet legges i <Name> under <Item> på linjenivå. Lang beskrivelse av en vare kan legges i <Description> under <Item> på linjenivå, men ofte sendes ikke lang beskrivelse i ordren.

<Name> blir ofte hentet fra katalogen til leverandør. Lengden på dette feltet bør ikke overstige 160 tegn da dette er kommunisert ut som maksimalt antall karakterer til de fleste innkjøpssystemer som offentlige virksomheter benytter i dag. Dette feltet overføres også i handlekurven i forbindelse med OCI punchout (round trip).

Det er mulig å angi ulike kvantum som gjelder for en artikkel eller tjeneste i en ordre. For alle typer kvantum må det angis enhet. I priselementet på linjenivå angis antall eller volum som en ordre omfatter for den aktuelle artikkel. I priselementet på samme linje skal det angis hvilke enhet prisen gjelder for.

Følgende kvantum er mulig å angi:

Dersom priser skal kontrolleres som en del av ordreprosessen må pris overføres i ordren. Dette vil være aktuelt både for katalogordre og fritekst-ordre. Alternativt kan priser være avtalt som en del av katalogprosessen og overføres og kontrolleres som en del av fakturaprosessen. Dersom pris overføres i ordren vil det også være mulig å endre denne i ordrebekreftelsen.

Alle priser er relatert til artikkelen eller tjenesten brukt i ordren og det er mulig å angi følgende priselementer:

Merk at bruttopriser før eventuelle rabatter og tillegg ikke er mulig å angi.

Feltet for å sende vedlegg i formatet er valgfritt og kan gjentas mange ganger. Det er for eksempel grafikk, image eller andre tilleggsopplysninger som kan være et vedlegg til en ordremelding. Vedlegget kan da sendes som et binært objekt innebygd i meldingen, eller at det overføres en referanse til stedet hvor vedlegget er lagret, for eksempel en URL. Vedlegg kan kun sendes på hodenivå.

Det er anbefalt å sende tilleggsinformasjon innebygd i dokumentet og ikke som eksternt vedlegg.

Andre anbefalinger:

Offentlige virksomheter stiller krav til miljø, økologisk produsert mat og at grunnleggende menneskerettigheter blir respektert i produksjon og handel av varer (sosialt ansvar eller etisk handel).

I katalogen er det definert klassifiseringskoder for miljømerking og annen merking slik at dette kan vurderes ved valg av leverandør. Disse kodene er det også mulig å overføre i ordren for å måle innkjøpsadferd direkte i innkjøpssystemene. Informasjon om merking må da kunne presentere i statistikkverktøy som er tilgjengelig for kjøpers organisasjon. Slik kan offentlige virksomheters krav i konkurransen kontrolleres og riktige kjøp kan tilstrebes.

Produktegenskaper som ikke er spesifisert i egne felt kan angis som tilleggsegenskaper med beskrivelse av hva elementet inneholder og selve innholdet. Dette kan også brukes for Smartform.

For å angi anbrekkskode (D-pak, F-pak o.l.) på en ordrelinje, kan elementet cac:AdditionalItemProperty benyttes.

Selve anbrekkskoden legges i elementet cbc:Name og verdien hentes fra kodelisten Packagelevel, og samsvarer med tilsvarende koder på EHF Katalog. Elementet cbc:Value skal inneholde verdien "Anbrekk"

Ordrebekreftelse er en melding fra selger til kjøper der selger angir evne til å etterkomme bestillingen. Følgende regler gjelder for ordrebekreftelsen:

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.