Elektronisk Handelsformat - EHF - Veileder for systemleverandører
Elektronisk handelsformat (EHF) gjør det mulig med standardisert, elektronisk kommunikasjon mellom virksomheter, uten direkte integrasjoner mellom datasystemer.
Hva er EHF?
Elektronisk handelsformat (EHF) er en standard for elektronisk utveksling av informasjon mellom oppdragsgiver og leverandør, i hele anskaffelsesprosessen.
Følges standarden, vil dokumenter som sendes fra for eksempel en oppdragsgiver, kunne leses inn i leverandørens datasystem selv om systemene er ulike. Virksomhetene unngår dermed dyre én-til-én-integrasjoner mellom ulike datasystemer.
Det Europeiske formatet kalles PEPPOL BIS. EHF er kompatibelt med formatet PEPPOL BIS fo de meldinger som dette formatet dekker. Ved å tilpasse dine systemer til EHF-standarden, vil du dermed kunne kommunisere med andre Europeiske land som følger BIS-standarden. Målet er å standardisere prosesser og meldingsinnhold på tvers av landegrenser.
EHF kan være både anbefalt, i henhold til Referansekatalogen eller obligatorisk i henhold til lov/forskrift. ved elektronisk fakturering i staten.
Hva er en EHF prosess?
En EHF prosess er i denne sammenheng den prosess som understøttes av én eller flere EHFer. Mens EHF kunngjøring er navnet på EHFen, er EHF kunngjøring prosess navnet på prosessen. Legger prosess til EHF navn.
Hvorfor har vi EHF prosesser?
Anskaffelse er en prosess - en systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål for anskaffelsen. For å oppnå en god anskaffelse må man ha en god anskaffelsesprosess. Digitalisering er bruk av teknologi i forbedring av prosesser. Man kan ikke lykkes med digitalisering, for eksempel ved bruk av EHF, uten en prosessorientert tilnærming. For eksempel:
Før vi skal utvikle en EHFer må vi vite hvilken prosess som EHF skal benyttes i. Når vi utvikler EHF tegnes disse inn i prosessen slik at vi kan analysere og identiferes hvilke tekniske, prosessuelle og organisatoriske endringer og gevinster som kan oppnås. Etter utviklingen får brukerne en beskrivelse av prosessen og et prosessdiagram. Hensikten er å forenkle arbeidet med implementering og sikre at alle som deltar får den informasjon de trenger for å utføre og samarbeide på en effektiv måte.
Hvordan utvikles EHFer og EHF prosesser?
Prosessen for utvikling og forvaltning av EHF og prosessene de(n) benyttes i består av 5 faser:

1. Analysere behov
I første fase identifisere vi interessentene – hvem som må inkluderes i utviklingen. Vi kartlegger prosessen slik den utføres og nåsituasjon for interessentene – hva de er fornøyd med, hva de har problemer med, og andre tanker om forbedring og fornying. Etter kartleggingen gjennomføres det analyser for å identifisere og velge den beste løsningen, mål og krav til EHF. Fasen oppsummeres i en rapport som danner grunnlag for planlegging og gjennføring av utviklingsarbeidet.
2. Utvikle EHF
Etter kartlegging og analyse utvikles EHFen(e). Første trinn er utvikling av en informasjonsmodell – beskrivelse av informasjonselementene i EHF. Informasjonsmodellen gjøres så om til en datamodell som knytter sammen alle elementene til en helhet med avhengigheter og regler. Datamodellen danner grunnlag for den tekniske beskrivelsen som systemleverandører trenger for å implementere EHFen.
3. Utbredelse og implementering
Når utviklingen er ferdig vil brukerne motta:
- En EHF/Implementeringsveileder for systemleverandører.
- Valideringsstøtte for systemleverandører.
- EHF prosessdefinisjon som gir nøkkelinformasjon om prosessen og hvordan den skal brukes og implementeres, samt et prosessdiagram. Denne kan og bør benyttes av alle faggrupper som skal delta i implementering- og gevinsterealiseringsarbeidet.
- Eventuelle veiledere tilpasset målgruppens behov.
- System for å gi tilbakemeldinger.
- Brukerstøtte.
4. Gevinstrealisering
Målet er at systemleverandører, oppdragsgivere, leverandører og andre som skal benytte prosessen får den informasjon de trenger (se over) for å implementere, nyttiggjøre, gi tilbakemeldinger og komme med forslag til forbedringer og nyutvikling av EHF.
5. Forvaltning
Samtidig som fase 4 er slutten på utviklingsfasen er den starten på en ny fase – forvaltning av EHF. Hensikten med denne fasen, som aldri tar slutt, er gjennom kontinuerlig forbedring å sikre at brukerne til enhver tid har de tjenestene som dekker deres behov.
Hvem har nytte av prosessdefinisjonene?
Prosessdiagrammene og definisjonen er i utgangspunktet generiske og kan derfor brukes av alle i alle typer prosessarbeid, ikke bare digitalisering. Vårt prosessrammeverk og definisjoner kan med stor fordel benyttes av alle.
Dersom du er interessert i å vite mer om vårt prosessrammeverk, hvordan det kan benyttes og fordelene med. Ta kontakt med Jan Mærøe.
Hva er EHF prosessrammeverk
EHF prosessrammeverk består av tre elementer: Prosessoversikt. Prosessdefinisjoner. Og metoder for prosessarbeid.
EHF prosessrammeverket har to formål:
Det ene er å sikre at det arbeides med riktig prosess på riktig måte - sikre at EHF har riktig kvalitet.
Det andre er å sikre at alle som skal delta i utviklingen, og bruke EHF prosessen - oppdragsgivere, leverandører, systemleverandører, osv., får den informasjonen de trenger for å forstå og bruke prosessen på en riktig måte.
1. Prosessoversikt
Prosessoversikten er en tabell som viser alle typer/former for aktivitet som utføres i en anskaffelsesprosess uavhengig av type anskaffelser. Det er viktig å forstå at oversikten IKKE beskriver en prosess eller prosdyre – hvilke aktiviteter som skal utføres i hvilken rekkefølge på hvilken måte - kun de ulike typer aktiviteter. Det samme som en liste med ingredienser du trenger for å lage en matrett, eller hvilke typer legoklosser du trenger for å lage en legofigur, osv.
I en anskaffelse er det mange forskjellige aktiviteter. For å forenkle arbeidet er alle aktiviteter gruppert og organisert i et hierarki etter følgende mønster.
Nivå | Type/kategori prosess | Eksempel |
1 | Kategori - hva slags kategori/type prosess det er. | X= Anskaffelser. Dersom man ønsker å utvide rammeverket til å gjelde andre typer prosesser, for eksempel HR-prosesser vil denne kategorien tildeles en bokstav eller tall om man ønsker å bruke det. |
2 | Hovedgrupper i kategori - prosesser som logisk hører sammen samles i en gruppe. | X2=Avklare behov og forberede konkurranse – er en gruppe prosesser i X som logisk hører sammen i anskaffelser. Det som ofte kalles en fase. |
3 | Prosess i hovedgruppe | X21= Vurdere behov - er en prosess i hovedgruppen X2. |
4 | Del-prosess og eller oppgave i prosess | X211=Beskrive dagens utfordringer og dagens løsning - er en del-prosess i prosessen X21 |
5 | Dersom prosessen består av flere nivåer med del-prosesser kan det opprettes flere nivåer. | X2111=Identfisere prosess, osv. - er en oppgave i del-prosessen X211 osv. |
6,7.. | Nederste nivå er oppgavenivået |
Når man kartlegger og beskriver prosesser er det vanlig å begynne på et detaljert nivå. Ulempen med det er at det fort blir uoversiktlig og kanskje også unødvendig. Fordelen med hierarkisk modellering hvor du begynner på et overordnet nivå, er at du beholder oversikten og sammenhengen samtidig som du ikke detaljerer mer enn det du trenger – mer effektiv og bedre måte å kartlegge og beskrive prosesser på.
Oversikten er en tabell som består av disse 4 kolonnene:
ID | Aktivitet | EHF prosess | Rolle |
Hver aktivitet får tildelt en unik ID som ikke endres. | Navn på aktiviteten som utføres i anskaffelsen. Disse navnene referer til beskrivelsen av aktivitetene i anskaffelsesprosessen på anskaffelser.no | Når en prosess/aktivitet digitaliseres får den et eget navn og definisjon. Klikker du på navnet får du opp prosessdefinisjonen. | Hvilken organisasjon som deltar i prosessen, for eksempel oppdragsgiver, leverandør, etc. |
ID
Identifikatoren består som sagt av en bokstav som beskriver hvilken type/kategori prosess det er, samt et antall siffer som samlet sett angir hvilket nivå man er på.
ID endres ikke. Fordelen med det er at vi kan spore aktiviteten over tid. Ulempen er at den ikke gir noen mening ut over å beskrive hva slags type prosess og hvilket nivå den er på.
Aktivitet
Navn på aktiviteten som utføres i en anskaffelse. Dette skal være de samme aktivitetene som står beskrevet på anskaffelser. no. Det er lagt inn lenker på overordnet nivå som tar deg til den siden på anskaffelser.no hvor denne aktiviteten står beskrevet.
EHF Prosess
Er navnet på den prosess som understøttes av EHFer. Aktivitetene som står beskrevet i kolonne 2 hentes fra anskaffelser.no og er beskriver kun hva som må gjøres av aktivtet uavhengig av om det er en person eller et system.
Når disse digitaliseres ved bruk av EHFer får vi en digital variant med et eget navn, for eksempel «EHF spørsmål og svar», som er den digitale varianten av aktiviteten «Spørsmål og svar av eventuelle avklaringer til oppfyllelse av kvalifikasjon» som du finner i beskrivelsen av prosessen på anskaffelser.no.
Dersom du ikke finner navn på EHF i denne kolonnen betyr det at den ikke er utviklet, eller er under utvikling.
Dersom du klikker på navnet til EHF prosessen får du opp en prosessdefinisjon, se nærmere forklaring under.
Rolle
Beskriver hvilke organisasjoner som deltar i prosessen, for eksempel oppdragsgiver, leverandør, publiseringstjeneste.
Her finner du lenke til EHF Prosessoversikt
2. EHF prosessdefinisjon
Alle EHFer har en egen prosessdefinisjon, et dokument som inneholder både et prosessdiagram og all grunnleggende informasjon du må ha for å forstå prosessdiagrammet.
Hensikten med prosessdefinisjonen er å sikre at alle som skal bidra i utvikling, implementering og vedlikehold – oppdragsgivere, leverandører, systemleverandører, prosjekter, etc. Får den informasjon de trenger for å arbeide og samarbeide på en effektiv måte.
3. Metode for prosessarbeid
I utvikling av prosessrammeverket legger vi til grunn den tilnærming og de erfaringer man har med utvikling av verdens mest utbredte prosessrammeverk – APQC process classification framework.
I arbeidet med prosesser benytter vi de grunnleggende BPM – business process management – metodene og verktøy.
Prosessdiagram følger BPMN 2.0 notasjonen – den mest avendte notasjonen i verden.
Alle kan bruke prosessrammeverket
Arbeidet med kartlegging og beskrivelse av prosesser krever kompetanse, tid og ressurser som mange ikke har. Et mål for utvikling av prosessrammeverket er at det skal kunne brukes av alle som ønsker det. Fordelene er blant annet.
Virksomheten sparer tid og ressurser.
Når alle bruker samme rammeverk utvikler man felles språk, forståelse og metoder som gjør det langt enklere å samarbeide og lære av hverandre.
Det forenkler og forbedrer både opplæring og ledelse av medarbeidere.
Vil du vite mer?
Dersom du vil vite mer om hvordan vi arbeider og hvordan du kan nyttiggjøre deg dette, ta kontakt med Jan Mærøe.
EHF forvaltning og endringshåndtering
Alle delprosesser som er dekket av EHF henger sammen da arbeidet med standarder tar hensyn til den totale anskaffelsesprosessen.
Det europeiske formatet PEPPOL BIS forvaltes og utvikles av Peppol. Formatene PEPPOL BIS og EHF er igjen basert på resultater fra arbeidet til CEN BII, UBL og andre enheter som har blitt gitt mandat til å virke som en koordinerende enhet. Et eksempel på dette er utlysningsskjemaene og nå ESPD som administreres av Publication Office.
Gjennom nasjonal standardisering av meldingsinnholdet i de forskjellige transaksjonene (EHF- Elektronisk Handelsformat) som igjen er koordinert med Europeisk standardisering (PEPPOL BIS formater og andre), vil man utvikle og vedlikeholde innhold og oppsett på en enhetlig måte som dermed reduserer kostnadene for de enkelte virksomhetene betraktelig ved implementering av systemstøtte.
For effektiv kommunikasjon med interessentene i anskaffelsesprosessen, ved endrede behov og regulereringer, forvaltes EHF og BIS etter gitte regler og med fastsatte tidsfrister for endringen. Dette for at alle parter skal høres og at systemleverandørene skal få tid til å implementere endringene. Regler for endringer relatert til endringens natur med forskjellig varslingstid for å gi tid til systemendringer finner du her.
Det er fullt mulig for alle å spille inn ønsker i denne prosessen nasjonalt og internasjonalt- ehf@dfo.no
Digitaliseringsdirektoratet benytter forskjellige kanaler for informasjonsspredning om endringer. Hovedkanalen er Anskaffelser.no samt LinkedIn gruppen "Elektronisk handelsformat- EHF. Offentlige anskaffelser har også en gruppe på Facebook. Den tekniske siden som bærer informasjonen og endringer finner du på Anskaffelser.dev.no.
Vi anbefaler systemleverandører å laste ned vår RSS-feed for å holde seg oppdatert:https://anskaffelser.dev/
Elektronisk Handelsformat (EHF) og prosess
EHF kunngjøre konkurranse prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF kunngjøre konkurranse prosess |
Prosess ID | X311 Kunngjøre konkurranse |
Organisasjon | DFØ-ANS |
Prosess eier | Thor Møller |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.09.15 | Dokument etablert | Petter Vinje |
3. Om prosessen
Kunngjøringsprosessen er en prosess hvor oppdragsgiver kunngjør et skjema knyttet til offentlige anskaffelser på Doffin og eller TED.
4. Brukere og bruksområde
- Prosessen benyttes på alle typer kunngjøringer (se pkt. 13 kommentarer).
- Oppdragsgiver trenger prosessen for å informere om behov for varer og tjenster og resultat av en anskaffelse.
- Leverandører trenger prosessen for å få informasjon og dermed kunne tilby sine varer og tjenster.
5. Formål
Best mulig utnyttelse av offentlige midler gjennom størst mulig konkurranse.
6. Mål
At kunngjøringen blir publisert på Doffin og/eller TED til riktig tid med riktig informasjon.
7. Gevinster
For oppdragsgiver:
- Størst mulig tilfang av tilbydere
- Informasjonsflyt som likebehandler leverandørmarkedet
For leverandør:
- Alle offentlige konkurranser samlet på ett sted.
- Sikre likebehandling for innlevering av tilbud.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
- Doffin = Nasjonal kunngjøringsdatabase for offentlige anskaffelser, lovpålagt å bruke over terskel, frivillig under terskel
- TED = Europeisk kunngjøringsdatabase, lovpålagt å bruke over terskel for norske oppdragsgivere
- KGV = Konkurransegjennomføringsverktøy
9. Startkriterier/forutsetninger
Trigger | Beslutning om å kunngjør konkurranse på Doffin/TED |
Andre forutsetninger | Oppdragsgiver er lovpålagt å benytte KGV verktøy. KGV verktøy må være kompatibel med etablert Doffin prosess. Må ha kompetanse i bruk av KGV system. Lovpålagt å kunngjøre på Doffin og eller TED for noen konkurranser. |
10. Input og leverandører
Input | Avleverende prosess: | Leverandør/avsender - organisasjon | Referanse |
Beslutning om kunngjøring | X2 Avklare behov og forberede konkurranse | Offentlig oppdragsgivere | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Person | O-per | |
Oppdragsgiver | System | O-sys | |
Systemleverandør | Sl | KGV | |
Publiseringstjeneste | Pub | Doffin + TED | |
12. Prosessdiagram

EHF kunngjøre konkurranse prosess (pdf)
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
1. Forbered kunngjøring | O-per | Del-prosess | Inkluderer alle kunngjøringstyper:
| ||
2. Send kunngjøring | O-sys | ||||
3. Validering | Pub | Både teknisk og manuell prosess | |||
4. Send avviksmelding | Pub | ||||
5. Korriger kunngjøring | O-per | ||||
6. Sjekk publikasjonstype | Pub | ||||
7. Oversett tekst til engelsk | Pub | ||||
8. Publiser kunngjøring | Pub | Ted | |||
9. Generer kunngjøringsbekreftelse | Pub | Ted | |||
10. Send kunngjørings-bekreftelse | Pub | Doffin | |||
11. Lagre kunngjøringsbekreftelse | O-sys | ||||
12. Publisere kunngjøring | Pub | Doffin | |||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Kunngjøring publisert | X 314 Søke på kunngjøringer | Leverandør | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Ikke fyller ut kunngjøringsskjemaet riktig. | Lav-middels | Liten-høy | Dersom verktøystøtte benyttes kan man få varsel og redusere risiko for feil. | Opplæring i bruk av system. Redusere bruk av egenproduserte maler. |
Ikke korrekt oversettelse eller manglende godkjennelse av oversettelse | Lav-middels | Liten-høy | Sikre god rutiner og sporing | Etablere en god kvalitetssikringprosess |
Feil utfylling gir dårlig statistikkunderlag for nye konkurranser | Lav-middels | Liten-høy | God systemstøtte | Etablere en god kvalitetssikringprosess |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for skjemaopplæring via systemet. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Når EHF foreligger vil du finne spesifikasjoner her:
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF søk kunngjøring
EHF Søk kunngjøring gjør det mulig for leverandører å sette opp en varslingstjeneste om konkurranser som er av interesse. Det forutsettes at leverandøren har et eget system koblet til PEPPOL eDelivery for å kunne ta en slik funsjonalitet i bruk. De fleste konkurransesystemer har en slik tjeneste i dag men utfordringen er at leverandører må tilknytte seg de ulike tjenestene til de ulike konkurransesystemene. Målet er at leverandøren kan operere en slik tjeneste fra det systemet som velges uavhengig de ulike konkurransesystemene.
Status for formatet
Under planlegging.
Formål og virkemåte: Automatisk søk i kunngjøringsdatabaser
EHF Søk kunngjøring beskriver en prosess som gir leverandører mulighet til å automatisere søk i kunngjøringsdatabaser, for eksempel Doffin, gjennom sitt eget system.
En leverandør kan bruke formatet til å gjøre et elektronisk søk mot databasen basert på utvalgte søkekriteria, og få returnert oversikt over relevante konkurranser. Leverandøren kan utforme søket så det er i henhold til eget vare- og tjenestesortiment.
Formatet gjør det mulig å strukturere meldingene som kommer i retur slik at leverandørens system kan organisere og presentere informasjonen likt hver gang.
Fordeler med å ta i bruk formatet
For oppdragsgivere
- Kunngjøringer som legges ut på publiseringsløsninger vil automatisk bli oppdaget av aktuelle leverandører.
- Innholdet gir leverandør informasjon om hvor ytterligere informasjon om konkurransen finnes. Dermed øker potensialet for at flere leverandører besvarer konkurransen.
For leverandører
- Systemet sikrer at alle kunngjøringer som er relevante blir presentert for leverandør i eget system.
- Informasjon som blir presentert inneholder relevante detaljer om konkurransens innhold.
- Informasjonen kan gjenbrukes i neste prosess der leverandør viser sin interesse overfor oppdragsgiver.
EHF søk kunngjøring prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF søk kunngjøring prosess |
Prosess ID | X314 Søk på kunngjøringer |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.08.17 | Dokument etablert | Petter Vinje |
3. Om prosessen
I denne prosessen søker leverandør sitt system etter interessant kunngjøringer. Dersom søk får treff i publiseringsdatabasen returneres aktuell kunngjøringer til leverandør.
4. Brukere og bruksområde
Leverandør trenger prosesser når han skal søke i publiseringsdatabaser.
5. Formål
Sikre at leverandøren til enhver tid kan få oversikt over kunngjøringer som er interessante.
6. Mål
Automatisert innhenting av kunngjøringer.
7. Gevinster
Oppdragsgiver: Flest mulig leverandører får se kunngjøringen når den publiseres vil kunne bidra til økt antall tilbydere i hver konkurranse.
Leverandør:
- Effektiv måte å få oversikt over alle offentlige anskaffelser – sparer tid og ressurser.
- Leverandør kan gjenbruke informasjon fra kunngjøringen i neste prosess – sikrer riktig informasjonsflyt og økt effektivitet i mottakende prosess.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger | Kunngjøringen |
Andre forutsetninger | Leverandør har satt opp riktig søkekriterier i sitt system. |
10. Input og leverandører
Input | Avleverende prosess: | Leverandør/avsender - organisasjon | Referanse |
Kunngjøringen | EHF kunngjøring prosess | Publiseringsdatabaser som Doffin og TED | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Leverandør | System | L-sys | |
Publiseringstjeneste | System | Pub | |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
1. Systemsøk i publiseringsdatabasebasert på CPV-koder | L-sys | ||||
2. Send forespørsel om kunngjøringer | L-sys | ||||
3. Søk i databasen og samle alle kunngjøringer relatert til CPV | Pub | ||||
4. Organiser kunngjøringer og pakk de sammen i forsendelsekontainer | Pub | ||||
5. Motta alle kunngjøringer som tilhører CPV gruppe | L-sys | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Kunngjøring vist i leverandør system | Enten EHF vis interesse proses eller EHF utsendelse av anskaffelsedokumet prosess | Leverandør | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | |
Behov for systemopplæring |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Når EHF foreligger vil du finne spesifikasjoner her: https://anskaffelser.dev
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF vise interesse
EHF vise interesse lar leverandører standardisere førespurnader til oppdragsgjevar om å få tilsendt konkurransedokument.
Status for formatet
EHF Under planlegging. PEPPOL BIS i produksjon
Føremål og verkemåte: Standardisering av førespurnader om konkurransedokument
Forskrift om offentlege innkjøp sikrar at alle leverandørar skal ha gratis, direkte og uavgrensa tilgang til konkurransegrunnlagsdokumenta (§14-3-1).
Meininga med EHF Vise interesse er at leverandørar via sitt eige datasystem, skal kunne varsle oppdragsgjevar om at dei ønskjer å få tilsendt konkurransedokument.
Oppdragsgjevarar får dermed ei standardisert og strukturert melding inn i sitt konkurranseinnleveringsverktøy. Neste steg i prosessen for oppdragsgjevar blir då å sende ut konkurransedokumenta på ein mest mogleg strukturert måte, så leverandørane opplever oppdragsgjevarane mest mogleg like i sin måte å kommunisere på, samt kunne nyttiggjere seg av den strukturerte konkurranseinformasjonen i sine eigne system.
Fordelar
For oppdragsgjevarar
- Ta i mot alle førespurnader inn i sitt system på ein strukturert og standardisert måte, mellom anna informasjon om kvar ein skal sende innkjøpsdokumenta.
- Sikre at alle leverandørar som har vist interesse får tilsendt dei same dokumenta.
For leverandørar
- Kunne informere oppdragsgjevarar på ein standardisert og strukturert måte, via sitt eige datasystem, om at dei ønskjer å delta i konkurransen.
- Innsparingar som følgje av redusert tidsbruk når formatet blir brukt ved kommunikasjonen mellom ulike system.
Teknisk informasjon om bruk av formatet
EHF vise interesse for anskaffelse prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF Vise interesse for anskaffelse |
Prosess ID | X315 |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.08.14 | Dokument etablert | Petter Vinje |
3. Om prosessenI
Vise interesse er en prosess hvor leverandør sender melding til oppdragsgiver for å vise interesse for en anskaffelse.
4. Brukere og bruksområde
Brukere:
Leverandør: Trenger prosessen for å bli registrert i oppdragsgivers system for derigjennom å bli oppdatert på anskaffelsen.
Oppdragsgiver: Trenger prosessen for å få oversikt over leverandører som er interessert i anskaffelsen.
5. Formål
Gjøre det enkelt for leverandør å vise interesse for anskaffelsen. Og tilrettelegge for en elektronisk samhandling mellom oppdragsgiver og leverandør i anskaffelsen.
6. Mål
Effektivisere informasjonsflyt mellom oppdragsgiver og leverandør for den enkelte anskaffelse.
7. Gevinster
Oppdragsgiver: Maskinelt kan behandle interessenter og derigjennom effektivisere utførelsen av prosessen.
Leverandør: Får rask og riktig informasjon som basis for beslutning om deltagelse i anskaffelsen.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger | Kunngjøring av anskaffelse |
Andre forutsetninger | Oppdragsgiver og leverandører har systemer som støtter den digitale prosessen. |
10. Input og leverandører
Input | Avleverende prosess: | Leverandør/avsender - organisasjon | Referanse |
Informasjon i kunngjøringen | EHF kunngjøringprosess | Oppdragsgiver | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | System | O-sys | |
Leverandør | Person | L-per | |
Leverandør | System | L-sys | |
12. Prosessdiagram

EHF vise interesse for anskaffelse (pdf)
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
1. Lag underlag om melding for å vise interesse | L-per | ||||
2. Send vis interesse for konkurranse | L-sys | ||||
3. Lagre leverandør som har vist interesse i database | O-sys | ||||
4. Motta bekreftelsen | L-sys | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Oversikt for oppdragsgiver over leverandører som har vist interesse. | Utsendelse av anskaffelsesdokumenter dersom leverandør ønsker det. | Oppdragsgiver | |
Kvittering for melding om vist interresse | En ev. Innsendelse av forespørsel om anskaffelsesdokumenter | Leverandør |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | |
Behov for systemopplæring |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://docs.peppol.eu/pracc/
Når EHF foreligger vil du finne spesifikasjoner her: https://anskaffelser.dev/.
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF anskaffelsesdokument
EHF anskaffelsesdokument lar oppdragsgiver lage strukturerte, maskinlesbare konkurransedokumenter.
Status for formatet
I produksjon
Formål og virkemåte: Digitalisere konkurransedokumentene fra oppdragsgiver
Formatet er en start på å kunne gjøre mer og mer av innholdet i konkurranser maskinlesbart. Basert på europeisk standardisering og pilotering vil formatet kunne inneholde viktig informasjon som gjenbrukes av leverandører i deres systemer for innlevering.
Formatet vil gjøre det mulig for leverandører å få informasjon fra konkurransedokumentene inn i sine egne systemer. De kan dermed besvare krav og behov som oppdragsgiver har definert, ved hjelp av strukturerte data.
Formatet tilrettelegger for inkludering av forskjellige meldinger basert på det behov oppdragsgiver har. Veilederen gir informasjon om hvordan sending av overordnet konkurranseinformasjon og hvordan vedlegge standardformater som det europeiske egenerklæringsskjema (ESPD Request) og for ytelsesbeskrivelser via EHF forespørselskatalog (pre-award catalogue request), beskrives og inkluderes. Andre dokumenter som tilhører anskaffelsesdokumentene vil etterhver bli maskinlesbare ved at de blir etablert som EHF.
Fordeler med å ta i bruk formatet
For oppdragsgivere
- Dersom prosessene som går forut for utarbeidelse av konkurransedokumentene er elektroniske, vil oppdragsgiver kunne sende ut konkurransegrunnlag på et maskinlesbart format til alle leverandører som har vist interesse, via sitt konkurransesystem.
- Oppdragsgivers system trenger ikke å vedlikeholde manuelle e-postlister, fordi alle mottakere ligger i felles adresseregister (SML/SMP/ELMA).
- Hvis oppdragsgiver har vurdert at konkurranseinnsendingen skal være kryptert, inkluderes den offentlige nøkkelen leverandørene trenger til å kryptere innsendingen i EHF anskaffelsesdokument.
- Ved at formatet kan inkludere EUs egenerklæringsskjema (ESPD request) i et maskinlesbart format, kan leverandørens system importere skjemaet.
- Det samme gjelder EHF forespørselskatalog, der leverandørens system kan importere og lagre generisk vare- og tjenesteinformasjon fra oppdragsgiver, og inkludere det i sin informasjon ved innlevering av tilbud.
For leverandører
- Ved at leverandør benytter et innleveringssystem har man muligheter til å importere strukturert informasjon og la sitt system pre-fylle informasjon fra oppdragsgivers konkurransedokumenter.
- På en enkelt måte kunne kryptere tilbudet ved at krypteringsnøkkelsen ligger i et strukturert format.
EHF utsendelse av anskaffelsedokument prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF utsendelse av anskaffelsedokument prosess |
Prosess ID | X316 Tilgjengeliggjøre/sende anskaffelsesdokumenter |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.08.19 | Dokument etablert | Petter Vinje |
3. Om prosessen
EHF utsendelse av anskaffelsedokumenter prosess, er en prosess hvor leverandør sender en forespørsel om oppdragsgiver kan sende anskaffelsesdokumentene til sitt system. Oppdragsgivers system sender anskaffelsedokumenten til leverandøren. Leverandør system bekrefter mottak av anskaffelsedokumentene.
4. Brukere og bruksområde
Leverandør har behov for å få informasjon som er maskinlesbart.
Oppdragsgiver trenger prosessen for å effektiv sende ut anskaffelsedokumenter i maskinlesbart format til riktig leverandør(er).
5. Formål
Høyne kvalitet på informasjonsinnhold. Samt tilrettelegge for at leverandør kan effektivisere sine prosesser.
6. Mål
Få en mest mulig optimal prosess som kan stimulere til økt deltakelse.
7. Gevinster
Leverandør:
Enklere å besvare en anskaffelse.
Mer effektive prosesser – spare tid og ressurser.
Sannsynligheten for å vinne anskaffelser øker.
Oppdragsgiver:
Sikre at leverandør mottar og gir riktig informasjon.
Mer effektive prosesser – spare tid og ressurser.
Sikrer økt kvalitet og effektivitet i mottakende prosess(innleveringsprosessen).
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger | Har lest kunngjøringen som de finner interessant. |
Andre forutsetninger | Må ha system som kan motta standard format. |
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Kunngjøringen | Doffin/TED | ||
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | System | o-sys | |
Leverandør | Person | l-per | |
Leverandør | System | l-sys | |
12. Prosessdiagram

EHF utsendelse av anskaffelsesdokumenter (pdf)
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
1. Legg inn kunngjøringsreferanse i system for å kunne be om riktige dokumenter for anskaffelsen | L-per | ||||
2. Forespørsel om anskaffelsedokumenter sent | L-sys | ||||
3. Sjekk kunngjøringsreferanse og klargjør de aktuelle dokumenter for sending | O-sys | ||||
4. Motta anskaffelsedokumenter | L-sys | ||||
5. Klargjør bekreftelse på mottatt forsendelse | L-sys | ||||
6. Bekreftelse sent | L-sys | ||||
7. Lagre mottaksbekreftelse | O-sys | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei |
15. Output og mottaker/bruker
Output | Mottakende prosess: | Mottaker/bruker | Referanse |
Mottatt anskaffelsesdokumenter | Leverandør | ||
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring og systemopplæring. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Når EHF er utviklet vil du finne de her https://anskaffelser.dev/
Lenke: https://docs.peppol.eu/pracc/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF spørsmål og svar
EHF spørsmål og svar lar oppdragsgiver og leverandør sende spørsmål og svar som strukturerte EHF-data, heller enn å bruke e-post.
Status for formatet
Under planlegging.
Formål og virkemåte: Kommunisér via strukturerte EHF-data, ikke på e-post
Det er klare regler for kommunikasjonen i selve konkurransegjennomføringsprosessen. Leverandører som ønsker å få belyst detaljer i anskaffelsesdokumentene skal få svar av oppdragsgiver. Det er et krav om at alle leverandører som deltar i konkurransen får tilsendt spørsmålet og svaret fra oppdragsgiver. Oppdragsgiver må vurdere om spørsmålet fra leverandør er konkurransesensitivt og dermed må redigeres.
Målet med EHF spørsmål og svar er å få denne kommunikasjonen flyttet fra e-post, over til bruk av strukturerte EHF-data, slik at oppdragsgiver og leverandør kan benytte sine egne systemer for mottak av og svar på meldinger via PEPPOL eDelivery og adresseregisteret ELMA.
EHF Spørsmål og svar vil kunne benyttes i konkurransegjennomføringsprosessen og i kontraktsoppfølgingsprosessen
Målet er sikre at kommunikasjonen skjer i henhold til regelverk, lagre kommunikasjonen så den eventuelt kan gjenbrukes i andre konkurranser via eks. chat-roboter og slippe kostbart vedlikehold av e-postlister.
Fordeler med å ta i bruk formatet
For oppdragsgivere
- Unngå at du ikke mottar e-poster fordi du oppgav feil e-post adresse i anbudet.
- Unngå å glemme å informere alle deltakerne om spørsmål og svar underveis i anbudsprosessen.
- La konkurranseverktøyet styre utsendingen av og dokumentere spørsmål og svar.
For leverandører
- Gir mulighet til å benytte sitt eget system for spørsmål og svar relatert til det enkelte anbud og lagre disse for læring.
- Gir trygghet for mottakers adresse ved at de ligger i ett adresseregister (ELMA-SMP)
EHF spørsmål og svar prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF spørsmål og svar prosess |
Prosess ID | |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.07.02 | Dokument etablert | Petter Vinje |
3. Om prosessen
I denne sammenheng har valgt å ta utgangspunkt i den generiske prosessen og beskrive spesielt spørsmål og svar i konkurransegjennomføring.
Spørsmål og svar i konkurransegjennomføring:
Prosessen begynner med at leverandører leser gjenom innholdet i kunngjøringsdokumentene eller anskaffelsesdokumentene og får behov for avklaringer. Leverandør sender spørsmål til oppdragsgiver. Oppdragsgiver mottar spørsmålene, formulerer svar, anonymiserer navn på spørsmålsstiller og innholdet i spørsmålet før dette lagres og sendes alle interessenter til konkurransen.
I alle andre prosesser mottas spørsmål og sendes svar til spørsmålstiller.
4. Brukere og bruksområde
Brukere:
Leverandør og oppdragsgiver har behov for denne prosessen når det er behov for avklaringer.
Bruksområde:
I alle prosesser der det er behov for avklaringer
5. Formål
Sikrer felles forståelse – unngå misforståelser, feil, etc.
6. Mål
Få til effektiv kommunikasjon basert på strukturert informasjon. Gjøre det enklere å dokumentere kommunikasjon. Gjenbruke spørsmål og svar i andre prosesser slik som spørsmål og svar på nettsider. Forenkle og effektivisere Statistikk, Analyse og forbedringsarbeid.
7. Gevinster
Oppdragsgiver: Slipper å vedlikeholde mail-lister – sparer tid og ressurser. Får automatisk en liste over leverandører som deltar i konkurransen slik at du kan sikre at alle får svar, og for ettertiden kan dokumentere det i systemet. Dette reduserer tidsbruk og reduserer/eliminerer risiko for feil. Dokumentasjonen kan benyttes som grunnlag for utarbeidelse av statistikk og i forbedringsarbeid. Fordi informasjonen ligger i systemet tilgjengelig for alle i virksomhetens anskaffelsesavdeling, unngås problemet som oppstår når informasjon lagres lokalt. – for eksempel ved sykdom, ferier, etc
Leverandør: Gi mulighet til å benyttes sitt eget system til spørsmål og svar og lagre dette for egen dokumentasjon og læring. All informasjon om anskaffelsen blir dokumentert og lagret sentralt – enklere for alle å få tilgang til informasjonen og gjenbruke den i nye anskaffelser, ved utarbeidelse av statistikk, forbedringsarbeid, etc.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger | Anskaffelsesdokumenter er mottatt eller kunngjøring funnet på Doffin eller andre avklaringer må bli gjort |
Andre forutsetninger | Begge – leverandør og oppdragsgiver må ha et system som det er gitt opplæring i |
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Kunngjøring | Kunngjøring | Doffin-TED | |
Anskaffelsesdokumenter | Utsendelse av anskaffelsesdokumenter | Oppdragsgivers KGV | |
Andre avklaringer | Alle prosesser i Anskaffelsesprosessen | Oppdragsgiver eller leverandørs systemer som dekker andre deler av prosessen | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Person | o-per | |
Oppdragsgiver | System | o-sys | |
Leverandør | Person | l-per | |
Leverandør | System | l-sys | |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
1. Forbered spørsmål | L-per eller O-per | I konkurransegjennomføring er det som regel leverandør. Mens det i kontraktsoppfølgningen kan være både oppdragsgiver og leverandør som stiller spørsmål. | |||
2. Sende spørsmå | L-sys eller O-sys | Systemspesifikk | |||
3. Besvare spørsmål | L-per eller O-per | Dette er en del-prosess som utføres av en person som benytter et system. Omfanget av prosessen vil variere. | x | NB! I Konkurransegjennomføringsprosessen er det pålagt oppdragsgiver å inkludere leverandørens spørsmål i svaret og at svaret gis alle interessenter i anskaffelsen. Oppdragsgiver må vurdere om spørsmål fra leverandør skal anonymiseres av hensyn til konfidensialitet | |
4. Motta svar | O-sys eller L-sys | Systemspesifikk | |||
5. Lagre spørsmål og svar | O-sys eller L-sys | Systemspesifikk | |||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
3 | Dersom du må anonymisere må du kontrollere at dette er gjort riktig. | Gjøres manuelt | Dersom informasjon som skulle vært anonymisert blir publisert kan det få store konsekvenser for både leverandør og oppdragsgiver. |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Dokumentasjon – spørsmål og svar. | Dette er en generisk prosess som kan benyttes av andre prosesser. | Oppdragsgiver og/eller leverandør. | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
I konkurransegjennomføringsprosessen er det lovpålagt å sende ev. anonymiserte spørsmål og svar til alle interessenter. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
I aktivitet 3 er det risiko for at informasjon ikke blir anonymisert. | Lav/medium | Høy | Ved bruk av system vil risiko reduseres. | System må bygge inn støtte for å minne oppdragsgiver på å anonymisere. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for opplæring i system og offentlige anskaffelser | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Foreløig ikke utviklet EHF. EHF spørsmål og svar vil bli lagt på følgende adresse: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF kvalifisering
Status for formatet
Under utvikling.
Formål og virkemåte: Leverandører kan sende inn kvalifiseringsdokumenter via eget system
I toleddet prosedyre må leverandører kvalifisere seg for å være med i konkurransen. Dette gjelder også i en Dynamisk innkjøpsordning (DPS).
EHF kvalifisering legger til rette for at leverandøren skal kunne gjøre dette via sitt eget system, ved å sende kvalifiseringsdokumenter til oppdragsgiver via PEPPOL eDelivery.
Formatet er tilrettelagt for å inneholde EUs egenerklæringsskjema (ESPD Response) som en egen strukturert fil. Ved utlysning av anbud med begrenset prosedyre, kan dermed en leverandør sende inn både strukturerte og ikke-strukturerte kvalifikasjonsdokumenter. Prosessen ekskluderer ikke andre strukturerte dokumenter hvis dette støtter oppunder oppdragsgivers behov for dokumentasjon.
Prosessen kan også tas i bruk for dynamisk innkjøpsordning (DPS) der ESPD request og response er sentrale elementer i en kvalifisering.
Fordeler med å ta i bruk formatet
For oppdragsgivere
- Dersom du bruker formatene EHF kunngjøring og EHF anskaffelsesdokument, har du standardisert og maskinlesbar informasjon som du kan sende til leverandørene.
- Data du mottar i retur fra leverandører på samme format, kan i sin tur brukes til automatisert evaluering av kvalifikasjonskravene i ditt eget konkurranseverktøy.
For leverandører
- Formatet gjør det mulig å automatisere utfylling av maskinlesbar informasjon sendt fra oppdragsgiver. Eksempel på dette er EUs egenerklæringsskjema (ESPD Request og Response) som kan importere kravene og sende et tilsvar automatisert. Dette vil øke effektiviteten hos tilbyder og dermed senke besvarelseskostnadene.
EHF kvalifisering prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF kvalifiseringsprosess |
Prosess ID | X32 kvalifisere leverandører |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.08.21 | Dokument etablert | Petter Vinje |
3. Om prosessen
Dette er en prosess hvor leverandør sender inn svar på kravene til oppdragsgiver for å kunne kvalifisere seg for anskaffelsen. Dersom han er kvalifisert mottar han en bekreftelse på dette. Hvis ikke kan du rette opp feil og kvalifisere på nytt dersom det er en DPS prosess
4. Brukere og bruksområde
Oppdragsgivere trenger prosessen når de skal redusere antall tilbydere. I DPS benyttes prosessen for å få oversikt over de leverandører man skal sende forespørsler til.
For leverandør er dette en måte å gjøre seg tilgjengelig for oppdragsgiver for å få tilsendt forespørsler i DPS.
5. Formål
Ha mulighet til å redusere antall tilbydere i en anskaffelse. Kvalitetsikre om krav for å kunne delta i en konkurranse er innfridd før selve besvarelse og innsendelse av konkurransedokumenter har funnet sted. Og kunne ha en leverandørdatabase for å kunne sende forespørsler i henhold til DPS. Kunne sjekke krav som er stilt.
6. Mål
Få en digital, effektiv kvalifiseringsprosess.
Likebehandling av alle leverandører.
Sikre tilstrekkelig informasjon for å kunne sjekke bevis i henhold til krav.
7. Gevinster
Oppdragsgiver: Mye mer effektiv prosess – sparer tid og ressurser. Riktig dokumentasjon fra leverandør. Informasjon innhentes kun én gang – «Once only principle». Ved bruk av maskinlesbare formater (EHF) i transaksjonene kan systemet foreta en automatisk evaluering av oppfyllelse av krav stilt i kvalifiseringen. Legger til rette også for en automatisert bevisinnhenting (eBevis prosess) fra offentlige databaser.
Leverandør: Mer effektiv prosess – redusert bruk av tid og ressurser når system automatisk fyller ut de krav som oppdragsgiver stiller. Synliggjøre sin interesse overfor oppdragsgiver. Spesielt ved DPS.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
DPS (Dynamic Purchasing System) = Dynamisk innkjøpsordning
9. Startkriterier/forutsetninger
Trigger | Beslutning om å benytte to-ledded prosedyre eller DPS |
Andre forutsetninger | Kompetanse på prosdyrevalg og bruk av digitale verktøy |
10. Input og leverandører
Input | Avleverende prosess: | Leverandør/avsender - organisasjon | Referanse |
Anskaffelsesdokumenter | X316Tilgjengligjøre/sende anskaffelsesdokumenter | Oppdragsgiver | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle | Forkortelser | Kommentarer |
Oppdragsgiver | Person | O-per | |
Oppdragsgiver | System | O-sys | |
Leverandør | Person | L-per | |
Leverandør | System | L-sys | |
12. Prosessdiagram

EHF kvalifiseringsprosess (pdf)
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
1. Fyll inn tilsendt EHF ESPD request og andre dokumenter som kreves i kvalifiseringen | L-per | ||||
2. Kvalifiseringsdokumenter sent | L-sys | ||||
3. Generer en bekreftelsesmelding | O-sys | ||||
4. Sjekk bevis i offentlige eller private databaser | O-sys/O-per | ||||
5. Kvalifisering mottaksbekreftelse er mottatt | L-sys | ||||
6. Motta respons | L-sys | ||||
7. Kvalifisere på nytt i DPS | L-per | ||||
8. Besvar anskaffelsesdokumenter | L-per | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
4. Sjekk bevis i offentlige eller private databaser | Krav oppdragsgiver har stilt for å kunne kvalifisere seg inn. | Benytte eBevis tjenesten som automatisk sjekker bevis i offentlige databaser. | Unngå blant annet arbeidslivskriminalitet. Og sikre god soliditet i leverandørmassen. |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Leverandører innlag i kvalifiseringsdatabase. | X348 Send inn tilbud. | Oppdragsgiver | |
Leverandører innlag i kvalifiseringsdatabase. | X316Tilgjengligjøre/sende anskaffelsesdokumenter (DPS). | Leverandør | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | |
Behov for systemopplæring |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Format EHF ikke ferdig utviklet. Når den er klar vil den bli publisert her: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF eBevis
EHF Dokumentasjonsbevis lar oppdragsgjevar automatisere innhenting og kontroll av bevis for at kvalifikasjonskrava er oppfylte.
Status for formatet
I produksjon
Føremål og verkemåte: Automatisering av innhenting av bevis
EHF Dokumentasjonsbevis skildrar prosessen der oppdragsgjevar skal sjekke opplysningane leverandør har gjeve opp i konkurransen. Det er oppdragsgjevar sitt ansvar å hente inn bevis for at opplysningane er riktige.
Kjelder for bevis vil typisk vere offentlege databasar, men det kan i tillegg vere leverandørspesifikke bevis som oppdragsgjevar må få direkte frå leverandør. Ved elektronisk førespurnad bør ein bruke same format for førespurnad og retur av bevis.
Fordelar med å ta i bruk formatet
For oppdragsgjevarar
- Oppdragsgjevarar vil kunne få tilgang til kvalifikasjonsdokumentasjon frå offentlege register i sanntid, noko som kan gje store innsparingar.
- Oppdragsgjevarar vil kunne kontrollere dokumentasjonsbevis på ein enklare måte.
- Formatet gjer det mogleg at dokumentasjonsbevisa blir leverte inn på eit standardisert format (EHF), slik at «bevispakka» kan lesast direkte inn i oppdragsgjevar sitt IT-system.
For leverandørar
Leverandørar vil oppnå store innsparingar knytte til tid, sidan dei berre treng å gje samtykke til at bevis blir kontrollerte ved innlevering av skjemaet "ESPD response", i staden for sjølv å hente inn oppdaterte bevis og sende dei inn saman med tilbodet sitt.
Leverandøren vil også få betre oversikt over kva slags bevis som er henta inn av kven, ved at han får gjenpart av dokumentasjonen oppdragsgjevarane har henta inn i Altinn.
Totalt sett vil dette forenkle dagens manuelle og papirbaserte arbeidsflyt monaleg, både for leverandørar og oppdragsgjevarar.
EHF eBevis prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF eBevis prosess |
Prosess ID | |
Organisasjon | DFØ-ANS |
Prosess eier | Hilde Kjølset |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.06.03 | Dokument opprettet | Jan Mærøe |
3. Om prosessen
eBevis eller «Hente bevis» er en prosess der oppdragsgiver digitalt og i sanntid kan innhente bevis/dokumentasjon fra leverandører relatert til den spesifikke anskaffelsen. Bevisene/dokumentasjonen kan gjelde avvisningsgrunner eller kvalifikasjonskrav enten i kvalifikasjons- eller i kontraktsoppfølgningsfasen. Mange av bevisene/dokumentasjonen er basert på det europeiske egenerklæringsskjemaet (ESPD). Beviskilden kan både være offentlige databaser, sertifiseringsdatabaser eller leverandørspesifikke baser.
4. Brukere og bruksområde
Brukere:
Kan brukes av offentlige oppdragsgivere ved alle former for anskaffelsesprosedyre.
Bruksområde:
Kan brukes over og under terskelverdi.
Kan brukes både ved konkurransegjennomføring/kvalifisering og ved kontraktsoppfølging
5. Formål
Hovedformålet er at du skal kontrollere dokumentasjon på at leverandører er kvalifisert jfr. LOA/FOA.
6. Mål
At oppdragsgiver henter inn informasjonen som det offentlige har ansvar for kun én gang – “once-only- principle”
7. Gevinster
Oppdragsgiver: Forenkle og effektivisere innhenting av bevis i anskaffelsesprosessen. Sikre at oppdragsgivers bevisinnhentingsprosess er i henhold til LOA/FOA. Redusert mulighet for at leverandører kan forfalske dokumenter – hentes direkte fra kilden. Enklere dokumentasjonsprosess. Enklere å gjenbruke maskinlesbar informasjon. Enklere kontraktsoppfølging.
Leverandør:Redusere arbeidsbelastning for leverandør ved at oppdragsgiver henter inn dokumentasjon selv fra offentlige eller andre databaser. Enklere for leverandør å formidle leverandørspesifikke beviser.
Systemleverandør: Tilby markedet nye tjenester.
Samfunn: Forebygge arbeidslivskriminalitet. Betydelig effektiviseringsgevinst. Stimulere til seriøsitet i markedet. Enklere kontraktsoppfølging.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger | >Melding eller manuell start. eBevis er en del av kvalifiseringsprosessen og kontraktsoppfølgingsprosessen. For DPS vil prosessen trigges automatisk. For andre anskaffelsesprosedyrer vil det være en person eller system som setter i gang eBevis-prosessen. >Systemteknisk/tidsintervall. eBevis kan også trigges basert på tidsintervall som en del av kontraktsoppfølgingsprosessen. Triggeren vil mest sannsynlig være definert i KGV basert på en risikovurdering per anskaffelse. |
Andre forutsetninger | >EHF ESPD/EHF egenerklæringsskjema skal være fylt ut |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
EHF ESPD; EHF egenerklæring | Innlevering av tilbud og kontraktsoppfølgingsprosessen | Leverandør | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Person | o-per | |
Oppdragsgiver | System | o-sys | |
Leverandør | Person | l-per | |
Leverandør | System | l-sys | |
Leverandør | l | Når aktiviteten kan utføres av person eller system brukes kun l | |
eBevis tjenesten | System | eBT-sys | |
Offentlige beviskilder | System | Off-sys | Omfatter offentlige og leverandørdatabaser |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1. Tolke ESPD, egenerklæringsskjema eller andre krav | o-sys | >Systemet ser på ESPD, egenerklæringsskjema eller andre input til krav og identifiserer hvilke bevis som skal hentes/sjekkes. | |||
2. Forberede eBevis/Get evidence | o-sys | >Lage og sende eBevis melding basert på ESPD, egenerklæringsskjema eller andre input til krav. >Validere i henhold til EHF eBevis | |||
3. Vurdere meldingsinnhold | eBT-sys | >Lese eBevis melding. >Kontrollere at avsender har lov til å innhente bevis. >Definere hvilke bevis som krever samtykke. >For bevis som krever samtykke sende forespørsel om samtykke via Altinn. >For bevis som ikke krever samtykke, sende forespørsel til beviskilde. | x | ||
4. Beslutte samtykke | l-per | >Leverandør tar beslutning om samtykke via Altinn. >Leverandør beslutter Ja til samtykke om at bevis kan hentes via eBevis. >Leverandør beslutter Nei til samtykke forutsetter manuell innlevering av bevis eller at leverandør vurderes avvist . >Svarer ikke | |||
5. Forespørre bevis fra avgivende kilde | eBT-sys | >Sende forespørsel. | |||
6. Henter ut relevante bevis | oFF-sys | >Systemet henter informasjonselementer fra avgivende kilde. | |||
7. Populere EHF eBevis respons | eBT-sys | >Systemet sammenstiller informasjonselementer fra avgivende database og lager EHF eBevis respons. | |||
8. Motta bevis | oFF-sys | >Mottar EHF eBevis respons og presenterer resultatet for bruker, for eksempel et ok-signal. >Arkivere eBevis respons | |||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
3 | >Kontrollere at avsender har lov til å innhente bevis. | Systemet sjekker om leverandør har gitt samtykke | Skal ivareta leverandørs rettigheter. |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Dokumentasjon for kvalifikasjonskrav og avvisningsgrunner | >Vurdering/evaluering av kvalifikasjon i henhold til krav (ikke definert prosess) | >Oppdragsgiver | |
>Kontraktsoppfølgingssystem | |||
16. Sluttkriterier
>Alle definerte bevis må være innhentet og tilgjengeliggjort for neste prosess.
>De som ikke har gitt samtykke har fått purring slik at de formelt sett kan vurderes om de skal avvises.
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
I offentlige eller andre databaser kan bevis innhentes manuelt | >Hvor det ikke finnes bevis i offentlige databaser. >KGV har ikke implementert eBevis tjeneste (støtte for) >Oppdragsgiver har ikke kjøpet modul for eBevis. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Risiko for at leverandør leverer bevis manuelt i stedet for samtykke til utlevering | lav | lav | >Regelverksendring for å muliggjøre uthenting av informasjon uten forhåndssamtykke fra leverandør. | |
Nedetid ut over definerte SLA krav. | lav | middels | >Prosess for avviksmelding hos Brønnøysund registrene. | |
Valideringsfeil | lav | lav | >Kontakt systemleverandør. >Krev at systemleverandør følger forvaltning av format VEFA. | |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://vefa.difi.no/ehf-egov/specs/ehf-get-evidence-1.0.0/
21. Tilleggsinformasjon
Nei
22. Vedlegg
EHF i innleveringsprosessen
Elektronisk innlevering lar leverandør automatisere utfyllingen av anskaffelsesdokumenter basert på utsendelse fra oppdragsgiver. Oppdragsgiver kan automatisk evaluere de strukturerte dokumentene som sendes fra leverandør
Status for formatet
I produksjon
Formål og virkemåte: Automatisering av innlevering av anskaffelsesdokumenter
En innlevering av et tilbud består av en rekke dokumenter. Prosessteget innlevering finnes i alle prosedyrer. Det er oppdragsgiver som generer anskaffelsesdokumentene som danner grunnlaget for leverandørs tilbud. Derfor opererer EHF med recuest (forespørsel) og response (svar) for å skille mellom meldingene som kommer fra oppdragsgiver og leverandør. Innleveringsmeldingen består av en hovedtransaksjon samt andre transaksjoner som beskriver deler av forespørselen. Noen formater er i produksjon og noen er under planlegging. Målet er å redusere antall PDF dokumenter og erstatte de med strukturerte formater. Følgende meldinger kan være representert i en innlevering:
- Hovedtransaksjon (EHF/PEPPOL BIS T005 Tender) med kvitteringsmelding ( EHF/PEPPOL BIS T005 Tender Receipt Notification)
- EHF ESPD response
- EHF Tilbudskatalog
- Kontrakt
- Andre anskaffelsesdokumenter
Fordeler med å ta i bruk formatet
For oppdragsgjevarar
- Oppdragsgiver vil kunne sammenligne tilbud på strukturert dokumentnivå.
- Oppdragsgiver vil kunne automatisk evaluere de dokumenter som er maskinlesbare
- Oppdragsgiver vil kunne lagre og gjenbruke strukturerte dokumenter i andre konkurranser og for dokumentforvalning
- Oppdragsgiver vil kunne sende kvitteringsmeldinger til leverandørs systemer.
For leverandører
- Leverandør vil kunne fylle ut besvarelser basert på lagret informasjon i sitt system og fra anskaffelsesdokumentene som for eksempel EHF forespørselskatalog som inneholder standard klassifiseringskoder på vare og tjenester.
- Leverandøren vil få en bedre oversikt over innleverte tilbud ved at de benytter eget system.
- Leverandøren får kvitteringsmeldinger direkte inn i sitt system som reduserer usikkerhet om innleveringen har gått bra.
Totalt sett vil dette forenkle dagens manuelle og papirbaserte arbeidsflyt, både for leverandører og oppdragsgivere.
EHF tilbudsinnlevering prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF tilbudsinnlevering prosess |
Prosess ID | X351 Ta imot tilbud |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.08.26 | Dokument etablert | Petter Vinje |
3. Om prosessen
Leverandør har fylt ut alle anskaffelsesdokumentert og levert inn tilbud før fastsatt tidsfrist.
4. Brukere og bruksområde
Leverandør trenger prosessen for å tilby sine varer og tjenester i henhold til de krav oppdragsgiver har satt.
Oppdragsgiver trenger prosessen for å ta imot anskaffelsesdokumenter i et maskinlesbart format.
5. Formål
Hovedhensikten er å forbedre eksisterende innleveringsprosess
6. Mål
Få flere tilbydere.
Øke kvalitet på informasjon.
Økt grad av automatisk evaluering – mindre bruk av tid og ressurser.
7. Gevinster
Oppdragsgiver: Riktig informasjon fra leverandør. Ved bruk av EHF i denne prosessen har du mulighet til å foreta automatisk evaluering som igjen sparer tid og ressurser. Og sikrer riktig informasjonskvalitet. Redusert risiko for klager.
Leverandør: Automatisert prosess sikrer kvalitet og effektivitet – sparer tid og ressurser.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger | Mottak av anskaffelsesdokumenter |
Andre forutsetninger | Leverandør har eget system der han kan motta og behandle digitale anskaffelsesdokumenter. |
10. Input og leverandører
Input | Avleverende prosess: | Leverandør/avsender - organisasjon | Referanse |
Anskaffelsesdokumenter | X348 Send inn tilbud | Oppdragsgiver | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle | Forkortelser | Kommentarer |
Oppdragsgiver | Person | O-per | |
Oppdragsgiver | System | O-sys | |
Leverandør | Person | L-per | |
Leverandør | System | L-sys | |
12. Prosessdiagram

EHF tilbudsinnlevering prosess (pdf)
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
1. Besvar de krav og kriterier oppdragsgiver har i anskaffelsesdokumentene | L-per | ||||
2. Tilbud fra leverandør på anskaffelsen er sendt | L-sys | ||||
3. Generer kvitteringsmeldig på mottatt tilbud | O-sys | ||||
4. Motta bekreftelsesmelding og lagre denne | L-sys | ||||
5. Registrere mottaks-tidspunkt | O-sys | ||||
6. Evaluer innsendte tilbud | O-per, O-sys | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei | Kontroll innebygget i system |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Evaluert tilbud | X359 Meddele tildeling av kontrakt | Leverandør | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
For leverandører er det en risiko at de ikke overholder innleveringsfristen. | Lav | Høy | Systemstøtte, varsler. | Leverandør anskaffer systemstøtte med varsling. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | |
Behov for systemopplæring | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke EHF: https://anskaffelser.dev/
Lenke PEPPOL BIS: https://docs.peppol.eu/pracc/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF kontrakt
EHF kontrakt lar oppdragsgjevar og leverandør signere kontrakt elektronisk, på ein sikker og bindande måte.
Status for formatet
Under planlegging.
Føremål og verkemåte: Elektronisk signering av kontrakt
Oppdragsgjevar sender eit utkast til leverandør som les igjennom, signerer med sin elektroniske signatur, og sender ferdig signert kontrakt tilbake til oppdragsgjevar.
Oppdragsgjevar signerer så, og sender signert kontrakt tilbake til leverandør, slik at begge partar har kvart sitt signerte eksemplar lagra.
Fordelar med å ta i bruk formatet
For oppdragsgjevarar
- Elektronisk signert kontrakt gjer prosessen sporbar, og kontraktsinnhaldet kan lagrast og vere sporbart heilt ned på feltnivå i systemet.
- Du kan setje opp systemet til å gje ulike oppfølgingar eller avgrensingsoppgåver, til dømes kor lenge kontrakten varar (setje på varsling god tid i forvegen før avtalen går ut).
- Verdien på kontrakten kan vere kopla opp mot formatet EHF bestilling via kontraktsadministrasjonssystemet. Systemet kan så varsle når maksgrensa for verdien av kontrakten byrjar å nærme seg.
For leverandørar
- Fordelane for leverandør er mykje av det same som for oppdragsgjevar når det gjeld prosessinnsparingar, sporbarheit og lagring.
- Om leverandør tek i bruk eit system som er i høve til dei retningslinjene som er gjevne, og er kopla opp mot infrastrukturen i PEPPOL-nettverket (aksesspunkt, adresseregister ELMA), vil leverandør signere ein avtale på same måte med alle offentlege verksemder, sjølv om verksemdene brukar ulike plattformer.
- Ein treng ikkje vere fysisk til stades eller sende papirbaserte dokument i posten.
EHF katalog
EHF katalog lar oppdragsgiver motta og endre avtalesortiment på en standardisert måte. Det gir også mulighet for bedre oppfølging av avtalen og økt avtalelojalitet.
Status for formatet
I produksjon.
Formål og virkemåte: Sikre at alt kjøp er i henhold til kontrakt
EHF katalog skal gjøre det enklere for både oppdragsgiver og leverandør å inngå avtaler, endre avtalesortiment og avvikle avtaler.
Formatet kan brukes til å motta informasjon om varer og tjenester fra en leverandør det er inngått kontrakt med, på en standardisert måte.
Katalogfamilien består av forespørselskatalog, tilbudskatalog og katalog. Alle tre katalogtyper dekker hver sin del av anskaffelsesprosessen og er harmonisert slik at de henger sammen og man kan overføre data fra en katalogprosess til den neste.
En katalog kan brukes til å
- gjøre avrop på en rammeavtale via et bestillingssystem
- oppdatere avtalesortiment hvis avtale tillater det
- implementere nye avtale på en effektiv måte
- avvikle en avtale på en effektiv måte
Rollene må være definert i organisasjonen
For at prosessene skal fungere, er det viktig at de roller som er definert inn i prosessen er etablert både i oppdragsgivers og leverandørs organisasjon.
Fordeler med å ta i bruk formatet
For oppdragsgivere
- En god katalog som kommer rett inn i bestillingssystemet, vil gjøre det enklere å søke vare eller tjeneste for bestiller.
- Reduserte kostnader i form av mindre tidsbruk og riktigere bestillinger (riktig vare eller tjeneste til riktig pris).
- Oppdateringer vil være sporbare fordi EHF katalog sendes og lagres elektronisk. Man har dermed mulighet å gi innkjøpsavdelingen gode data som grunnlag for nye konkurranser.
- Krav til miljø, sosialt ansvar, produsent og opprinnelsesland, vil sette oppdragsgiver i stand til å følge opp krav fra konkurransen. Den merkeordningen varen eller tjenesten tilhører kan legges ved på linjenivå i katalogen, se siden "Koder for bruk i EHF katalog for merkeordninger - miljø og samfunnsansvar".
- Vare- og tjenesteinformasjon som følger med i katalogen fra leverandøren vil gi god kvalitet i bestillingen. Denne informasjonen kan igjen danne grunnlag for automatisering av matching av faktura.
For leverandører
- Kan presentere sitt sortiment av varer og tjenester på en god måte for bestillere, i bestillerens egen innkjøpsløsning. Det er viktig både med tanke på å forhindre feilbestillinger, en mest mulig effektiv implementering av ny avtale, og en effektiv måte for å holde sortimentet oppdatert hvis avtalen tillater dette.
- Det er også kritisk for leverandør at avtalelojaliteten er maksimal. Det sikres ved at bestiller får god informasjon om varen og tjenesten via bestillingssystemet. Oppdragsgiver på sin side sikrer avtalelojalitet ved å ha klare definisjoner av roller og en god prosessforståelse i egen virksomhet.
EHF katalogprosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF katalog prosess |
Prosess ID | |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.05.20 | Dokument opprettet | Jan Mærøe |
3. Om prosessen
Dette er en prosess hvor en avtaleansvarlig mottar en katalog som viser avtalt sortiment på varer og tjenester på en maskinlesbar måte. Avtaleansvarlige sjekker om varen og tjenester som er beskrevet i katalog er i henhold til avtale. Avtaleansvarlige godkjenner katalog og sprer denne til virksomhetens bestillere. Neste gang det avtaleansvarlig mottar en katalog sjekker systemet den nye katalogen opp mot den gamle og gir en avviksrapport.
4. Brukere og bruksområde
Brukere: Leverandør, avtaleansvarlig - i virksomhet eller hos innkjøpssentral, og bestiller.
Bruksområde: Den kan benyttes ved alle bestillinger av varer og tjenster som kan beskrves på en maskinell måte i form av en katalog. Benyttes når avtalen er inngått og avrop på avtale skal starte.
5. Formål
EHF katalog skal gjøre det enklere for oppdragsgiver og leverandør å: Inngå avtaler. Endre avtalesortiment underveis i kontraktasperioden. Og avvikle avtaler.
6. Mål
At bestilling gjøres i henhold til avtalt sortiment.
7. Gevinster
Oppdragsgiver: Sparer tid. Økt avtalelojalitet som gir økt besparelse på avtalen, økt troverdighet i leverandørmarkedet for neste konkurranse. Sikrer en god implementering av avtalen hos alle bestillere som medfører redusert bruk av tid og økt kvalitet. Økt medarbeidertilfredshet.
Innkjøpssentral: Enklere å sende ut kontrollert katalog til alle medlemmer av innkjøpssamarbeidet og deres bestillingssystemer.
Leverandør: Sparer tid på implementering av avtale. Sikrer at riktig sortiment blir presentert, og slipper å bruke tid på å kontakte bestillere for å presentere ny avtale. for bestillere. . Økt avtalelojalitet – sikrer at man kjøper på avtalt sortiment. Leverandør er sikret at gamle avtaler (fra andre leverandører) fjernes fra system.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei.
9. Startkriterier/forutsetninger
Trigger | Katalogverktøy varsler om ny katalog |
Andre forutsetninger | Organisasjonen må ha definert bestiller med kompetanse på bestillingssystem og avtaleansvarlig med riktig kompetanse på katalogverktøy. Må stille krav om EHF katalog i konkurransegrunnlag og kontrakt (samhandlingsavtale). Leverandør må ha kompetanse til å lage en katalog. Enten via sitt eget system eller en tjenesteleverandør. Må kunne ta imot EHF katalog via PEPPOL eDelivery. |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Innsendt tilbudskatalog | X351 Ta imot tilbud | Leverandør | |
Innsendt katalog | X411 Gjennomføre oppstartsmøte med leverandør | Leverandør | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Person | o-per | |
Oppdragsgiver | System | o-sys | |
Leverandør | Person | l-per | |
Leverandør | System | l-sys | |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1. Oppdater eget vare/tjeneste system med beskrivelser og priser i henhold til kontrakt | l-per | >Legg inn avtale priser i vare- og prissystemet. >Trykk på knappen for eksport av EHF katalog. | x | ||
2. Send Katalog | l-sys | >Katalogen sendes som en EHF XML via PEPPOL eDelivery |
| ||
3. Last opp katalogen i katalogverktøy. Sjekk avviksrapport for endringer i henhold til kontrakt | o-per | Første gang: >Sjekk liste over mottatte kataloger >Gå inn på katalog og sjekk kataloglinjer for varer eller tjenester om de er i henhold til avtale >Når katalog er godkjent huk av for hvilke bestillere som skal motta katalog og tilgjengeliggjør dem for bestillere som skal ha denne type katalog.
Andre gang: >Ved mottatt katalog skjekker systemet om det er avvik mellom den første katalogen og innsendt katalog. >Generer avviksrapport fra system. >Og sjekk om eventuelle avvik er i henholdt til ev. bestemmelser i kontrakt. >Godkjenn katalog >Tilgjengeliggjør for bestillere. >Ev. fjern gammel versjon om ikke systemet har den type funksjonalitet.
|
| ||
4. Motta Katalog Respons | l-sys | >Hvis godkjent er det ok. >Hvis ikke godkjent gå til 5. |
| ||
5. Klargjør katalog for utsendelse til kunder av innkjøpssentralen | o-per | >Send til oppdragsgiver på nytt. |
| ||
6. Klargjør katalog og last den opp i bestillingssystemet | o-per | >Tilgjengeliggjør for bestillere | x | ||
7. Klargjør ny katalog med endret innhold | l-per |
|
| ||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
1 | Systemet kontrollerer om det riktige formatet er brukt | Validatorfunksjon i system | Unngå feil. |
6 | Sjekk via system at katalog er tilgjengelig for bestiller | Via søkemotor | Unngå forsinkelser og gjøre bruk av bedre avtale med en gang. |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Varer og tjenester er tilgjengelig | Ordreprosessen | Bestiller |
|
16. Sluttkriterier
Gammel katalog må være fjernet for å unngå utgått sortiment.
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei | |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei | ||||
19: Behov for støtte
Støtte | Forklaring/Lenker |
Ved spesielle varer/tjenester må kanskje avtaleansvarlige ha støtte fra spesialkompetanse for å kunne godkjenne katalog | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/
21. Tilleggsinformasjon
Lenke til klassifisering av varer og tjenester https://www.gs1.no/support/standardbibliotek/dele/unspsc
22. Vedlegg
Nei
EHF ordre og ordrebekreftelse
EHF ordre og ordrebekreftelse gjør det mulig å standardisere ordreprosessen mellom oppdragsgiver og leverandør.
Status for formatet
I produksjon.
Formål: Standardisere ordreprosessen mellom oppdragsgiver og leverandør
I oppdragsgivers bestillingssystem hentes innholdet til en EHF ordre fra kataloginformasjon, lagrede historiske bestillinger eller via punchout funksjonalitet hvis systemet tilbyr denne tjenesten mot leverandøren.
EHF ordre stiller imidlertid visse krav til informasjonsinnholdet for at orden/bestillingen skal kunne prosesseres. Det er viktig at vare og tjeneste data i ordre/bestillingen er korrekt for at leverandøren som mottar ordren skal kunne importere dataene inn i sitt ordrehåndteringssystem automatisk.
Etter å ha mottatt en ordre, skal leverandøren sende en ordrebekreftelse i retur til oppdragsgiver på samme format, slik at han får kunnskap om hvilke varer og tjenester som blir levert og når de blir levert.
Fordeler med å ta i bruk formatet
For oppdragsgivere
- Foreta en sikker og standardisert bestilling av kontraktsfestede varer og tjenester.
- Økt avtalelojalitet, sporbarhet og kontroll for oppdragsgiveres bestillere.
- Motta en standardisert ordrebekreftelse som er dokumenterbar med de forpliktelser leverandør gir for leveransen.
- Gi mulighet til et elktronisk varemottak for å redusere risiko for svinn og gi ordre oppdatert informasjon for å kunne automatisk matche faktura
- Kunne fange data som kan gjenbrukes i nye anskaffelser.
- Kunne måle innkjøpsmønster når det gjelder miljø og sosialt ansvar, basert på krav i konkurranse og informasjon lagt til i formatet EHF katalog.
For leverandører
- Stalig sektor benytter en enhetlig måte å bestille varer og tjenester på, der leverandør kan importere ordrer automatisk inn i sitt system. Dette vil øke kvaliteten i bestillingene med redusert risiko for returer/feilbestillinger.
- Data fra ordre og ordrebekreftelse kan benyttes for å produsere EHF faktura.
EHF ordreprosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF ordre prosess |
Prosess ID | |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.06.16 | Dokument etablert | Jan Mærøe |
3. Om prosessen
Prosessen starter med at en person/enhet har et behov for varer og/eller tjenster. Behovet beskrives og sendes til en bestiller(kan være samme person som behovshaver). Så søker bestiller opp varer og tjenster i bestillingssystemet basert på katalog og/eller puch-out. Så lagres dette i handlekurven til bestiller. Som påfører den handlekurven konteringsinformasjon(prosjekt, kostnadssted, etc.). Dersom organisasjon har en beløpsgrense der bestilling skal godkjennes, sendes bestillingen til den som har autorisajonsfullmakt. Dersom godkjenner ser at bestillingen må endres sendes den tilbake til bestiller som gjør endringer. Hvis alt er ok sender godkjenner bestilling til leverandør. Er bestillingen under vedtatt beløpsgrense sender bestiller direkte til leverandør.
Leverandør mottar bestillingen og sjekker tilgjengelighet på varen/tjenesten. Leverandør sender ordrebekreftelse med eller uten endringer. Dersom endringer må bestiller ta stilling til de endringer som er kommet – enten ta kontakt med leverandør for å endre bestilling eller kansellere bestilling.
Forskjellen på denne prosessen og avansert ordre er at endring og kansellering kan gjøres via system.
4. Brukere og bruksområde (hvem og når)
Oppdragsgiver med følgende roller: Behovshaver, bestiller og godkjenner.
Leverandør v/den som tar i mot bestillingen/ordre og sender bestillings-/ordrebekreftelsen, eller leverandørsystem som elektronisk importerer bestiling og automatisk genererer ordrebekreftelse basert på tilgjengelighet til varen/tjenesten.
5. Formål
Effektivisering i betydningen redusert bruk av tid, ressurser og økt kvalitet
6. Mål
At oppdragsgiver automatiserer bestilingsprosessen basert på inngåtte avtaler i form av katalog/punch-out.
At leverandør automatiserer prosess for mottak av bestilling/ordre og automatisk kan sende en ordrebekreftelse.
At man automatisk kan matche faktura og ordre/bestilling.
7. Gevinster
For oppdragsgiver: Spart tid og/ev ressurser/kostnader. Økt kvalitet i betydningen ingen feil i utførelsen. Fange data for analyse som kan benyttes i planlegging og oppfølgning av leverandør i avtaleperioden. Som gir mulighet for å bedre kontroll og forbedring av prosesser. Bedre planlegging kan redusere transportbehov som vil gi miljøgevinster.
For leverandør: Få inn bestillingen elektronisk i system og slippe manuelle punching på for eksempel kundesenter og redusere/eliminere feil som krever tid, ressurser. Slippe å sjekke varer/tjenester og sende ordrebekreftelse manuelt – kan krave mye tid og ressurser samt risiko for feil som kan gå ut over kundetilfredshet. Kan dokumentere bestilling fra oppdragsgiver slik at man slipper tvister i ettertid. Oppdragsgiver oppgir presise leveransetider og steder – reduserer transportkostnader og transportbehov som gir miljøgevinster.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger | Organisasjonens behov for varer/tjenster |
Andre forutsetninger | Inngått avtale med leverandører av varer/tjenester. Må ha definert hvem som skal ha bestillerroller i organisasjonen. Må ha definert hvem som skal ha godkjennerrollen i organisasjonen opp mot bestillere. Må ha anskaffet et bestillingssystem og ha en organisasjon som kan benytte det. Må eventuelt ha definert grenser for godkjenning av bestilling. Må ha leverandører som kan sende katalog eller ha satt opp et punch-out system. Leverandørene må ha et system for å motta elektroniske ordre/bestillinger og sende elektroniske ordre/bestillings bekreftelser. Leverandør må kunne påføre faktura bestillingsnummer/ordrenummer. |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Behov | Organisasjon | ||
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Behovshaver | O-beh | |
Oppdragsgiver | Bestiller | O-bes | |
Oppdragsgiver | Godkjenner | O-god | |
Oppdragsgiver | System | O-sys | |
Oppdragsgiver | Person | O-per | |
Leverandør | Person | L-per | |
Leverandør | System | L-sys | |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1. Klargjør handelkurv, påfør konteringsinformasjon og send til godkjenning eller direkte til leverandør | O-bes | ||||
2. Godkjenn ordre | O-god | ||||
3. Send ordre | O-sys | ||||
4. Behandle ordre | L-sys / L-per | ||||
5. Generer en bekreftelse med status avslått | L-sys | ||||
6. Generer en bekreftelse med status delvis bekreftet | L-sys | ||||
7. Generer en bekreftelse med status bekreftet | L-sys | ||||
8. Motta og kontrollere bekreftelse mot ordre | O-sys | ||||
9. Slett ordre i bestillingssystem | O-sys | ||||
10. Oppdater ordre i bestillingssystem | O-sys | ||||
11. Vurder om endringer av ordre kan aksepteres | O-bes | ||||
12. Ta kontakt med leverandør | O-bes | ||||
13. Motta tilbakemelding fra oppdragsgiver. Enten slett ordre eller endre ordrebekreftelse og send på nytt | L-per | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
8 | Kontrollere at det ikke er avvik fra ordre/bestilling | System gir ved avvik en oversikt over hva avviket består i. | Uten tidlig varsel om varen kan leveres eller ikke, vil/kan organisasjonen få problemer som i verste fall kan være livstruende. |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Ordre oppdagert i system | Fakturaprosess | Oppdragsgiver | |
Varer og tjenester | Varemottaksprosessen hos oppdragsgiver | Oppdragsgiver | |
Grunnlag for å allokere varer eller tjenester. | Transport/leveranseprosess | Leverandør | |
16. Sluttkriterier
Nei
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Aktivitet 1 oppdager at det ikke finnes varer/tjenester i bestillingssystem | Må kontakte leverandør manuelt. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Ikke korrekt definert leveransested for varen/tjenesten | Lav | Lav | Legge inn og vedlikeholde korrekte leveranseadresser i bestillingssystem. | Rette feil i system. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring | |
Hvis behovshaver har et behov som er spesielt må bestiller klarlegge hva behovet egentlig er | Kan være behov for opplæring og dialog med faginnstanser i virksomheten |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF avansert ordre
EHF avansert ordre gjør det mulig å standardisere ordreprosessen mellom oppdragsgiver og leverandør.
Status for formatet
I produksjon.
Formål: Standardisere ordreprosessen mellom oppdragsgiver og leverandør
I oppdragsgivers bestillingssystem hentes innholdet til en EHF ordre fra kataloginformasjon, lagrede historiske bestillinger eller via punchout funksjonalitet hvis systemet tilbyr denne tjenesten mot leverandøren.
EHF avansertordre stiller imidlertid visse krav til informasjonsinnholdet for at orden/bestillingen skal kunne prosesseres. Det er viktig at vare og tjeneste data i ordre/bestillingen er korrekt for at leverandøren som mottar ordren skal kunne importere dataene inn i sitt ordrehåndteringssystem automatisk.
Etter å ha mottatt en ordre, skal leverandøren sende en ordrebekreftelse i retur til oppdragsgiver på samme format, slik at han får kunnskap om hvilke varer og tjenester som blir levert og når de blir levert. Oppdragsgiver har mulighet for å kunne sende et forslag på en endret ordre (order change) eller en kanselering av ordren (order cancellation) hvis ikke leverandørens forslag til endring av ordren er akseptabel for oppdragsgiver.
Teknisk informasjon om bruk av formatet
Se gjeldende standarder for EHF avansert ordre (EHF Advanced order)
Fordeler med å ta i bruk formatet
For oppdragsgivere
- Foreta en sikker og standardisert bestilling av kontraktsfestede varer og tjenester.
- Økt avtalelojalitet, sporbarhet og kontroll for oppdragsgiveres bestillere.
- Motta en standardisert ordrebekreftelse som er dokumenterbar med de forpliktelser leverandør gir for leveransen.
- Sende en endring eller kanselering av ordren
- Gi mulighet til et elktronisk varemottak for å redusere risiko for svinn og gi ordre oppdatert informasjon for å kunne automatisk matche faktura
- Kunne fange data som kan gjenbrukes i nye anskaffelser.
- Kunne måle innkjøpsmønster når det gjelder miljø og sosialt ansvar, basert på krav i konkurranse og informasjon lagt til i formatet EHF katalog.
For leverandører
- Stalig sektor benytter en enhetlig måte å bestille varer og tjenester på, der leverandør kan importere ordrer automatisk inn i sitt system. Dette vil øke kvaliteten i bestillingene med redusert risiko for returer/feilbestillinger.
- Data fra ordre og ordrebekreftelse kan benyttes for å produsere EHF faktura.
Dette formatet er basert på det europeiske standardisering OASIS-UBL
EHF avansert ordre prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | Advanced ordering process/avansert ordre prosess |
Prosess ID | |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.04.28 | Jan Mærøe | |
3. Om prosessen
En oppdragsgiver har et behov og sender en ordre til sin leverandør. Leverandøren gir et ordresvar som enten bekrefter hele ordren eller har avvik. Da kan oppdragsgiver ente akseptere avviket, foreta en endring av ordren, eller kansellere ordren.
4. Brukere og bruksområde
Brukere: Oppdragsgiver og leverandør av varer og tjenester. Transportør. (pakkseddel basert på ordre)
Bruksområde: Kan brukes ved vare og tjenestekjøp basert på katalog eller punch-out.
5. Formål
Prosessen hjelper oppdragsgiver og leverandør i å finne riktig varer og tjenester – optimalisere bestillingsprosessen. Sikre dokumentasjon av det oppdragsiver og leverandør gjør. Effektivserer komplekse bestillingsprosesser ved at systemet støtter deg både når det gjelder bestilling, endring, kansellering og bekreftelse. Danner grunnlag for senere prosesser – varemottak, automatisert mottak av faktura. Danner grunnlag for planleggingsfasen.
6. Mål
Gjøre all manuell kommunikasjon overflødig ved at man kommuniserer via systemet.
7. Gevinster
For oppdragsgiver: Ved å bruke et system reduseres tidsbruken. Kan dokumentere alle prosesstrinn som er utført - viktig ved revisjon, kontroll. Du sikrer at bestillingen har den rette kvalitetene – slipper returer. Man kan lage statistikker som kan gjøre planlegging av enklere. Forsyner faktura med bestillingsnummer som gjør fakturamatch mulig.
For leverandører: Sikrer kvalitet i bestillingsprosessen og unngår dermed feil som medfører returer og andre komplikasjon som igjen fører til økt tidsbruk og kostnader.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei.
9. Startkriterier/forutsetninger
Trigger | Prosessen starter når et behov oppstår (trigger). Bestiller får beskjed fra en i organisasjonen om at de trenger noe |
Andre forutsetninger |
|
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Funnet varer og tjenester fra katlog eller punch-out via sin søkemotor | Katalogprosessen, puch-out prosessen. | Internt | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Behovshaver | o-beh | |
Oppdragsgiver | Bestiller | o-bes | |
Oppdragsgiver | Goskjenner | o-god | |
Oppdragsgiver | Avtaleforvalter | o-avf | |
Leverandør | l | ||
Leverandør | Person | l-per | |
Leverandør | System | l-sys | |
12. Prosessdiagram

Prosesstegning for avansert ordre (pdf)
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1 Kontere og godkjenneConnect accounting information | o-bes | >Påfør konteringsinformasjon >Godkjenne | X | ||
2. Send en ny ordre med varer og/eller tjenester eller endre en eksisterende ordre | o-bes |
|
| ||
3 Importer ordre i ordrebehandlingssystem og hent informasjon om varen og/eller tjenster er tilgjengelig | l-sys | Systemspesifikk |
| ||
4. Lag en ordrerespons basert på tilgjengelighet | l-sys | Systemspesifikk |
| ||
5.Send en negativ ordrerespons | l-sys | Systemspesifikk |
| ||
6. Send en ordrerespons uten endringer | l-sys | Systemspesifikk |
| ||
7. Send en ordrerespons med endringer | l-sys | Systemspesifikk |
| ||
8. Motta ordrerespons | o-bes |
| X | ||
9. Prosseser ordrerespons og sammelign med ordre sendt | o-sys | Systemspesifikk | X | ||
10. Lagre ordrerespons | o-sys | Systemspesifikk |
| ||
11. Oppdater ordre sendt med endringer fra ordrerespons | o-sys | Systemspesifikk |
| ||
12. Lagre ordrerespons | o-sys | Systemspesifikk |
| ||
13. Evaluer endringer | o-bes |
|
| ||
14. Forbered kanselering av ordre | o-sys | Systemspesifikk |
| ||
15. Send ordre kanselering | o-sys | Systemspesifikk |
| ||
16. Fjern ordre fra bestillingssystemet | l-sys | Systemspesifikk |
| ||
17. Forbered endringsordre | o-sys | Systemspesifikk |
| ||
18. Send endringsordre | o-sys | Systemspesifikk |
| ||
19. Evaluer oppdragsgivers endringsforslag sendt i endringsordre | l-per |
|
| ||
20. Send en postiv respons | l-sys | Systemspesifikk |
| ||
21. Send en negativ respons | l-sys | Systemspesifikk |
| ||
22. Slett ordre fra systemet | o-sys | Systemspesifikk |
| ||
23. Lagre ordre respons | o-sys | Systemspesifikk |
| ||
24. Oppdater ordre med endringer | o-sys | Systemspesifikk |
|
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
1 | Sjekke verdi i henhold til godkjenningsprosess.. | I henhold til regler i bestillingssystem | Attestering/budsjettfullmakt vedtatt skal følges. |
8 | Sjekk at leverandør har respondert på ordre sendt eller endringsordre sendt. | Sjekk status i ordreoversikt. | For å sikre at prosessen ikke forsinkes unødvendig. |
9 | Kontroller om endring på opprinnelige ordre er akseptabel. | Sjekk om forslag på ny vare og tjeneste er akseptabel. | Sikre at behov blir dekket. (riktig kvalitet, pris) |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Oppdatert ordre klar for mottak | Vare/tjenestemottak | o | |
Grunnlag for mottak av faktura | Fakturaprosess | o | |
16. Sluttkriterier
Leverandør og oppdragsgiver er enig om leveranse av varer/tjeneste.
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Aktivitet 1 Hvis bestiller ikke finner varen eller tjenesten i søkemotoren. | Da må man på manuell behandling. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Får ikke svar fra leverandør | Lav | Kan være kritisk | Manuell kontroll | Ringer, sender mail, etc. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Kun behov for ordinær opplæring i bruk av system. | |
Aktivtet 1: Kan være behov for faglig bistand ved bestilling av spesielle varer og tjenester. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei.
EHF ordreforslag
EHF ordreforslag (EHF Order Agreement) lar oppdragsgjevar dokumentere kjøp av tenester utført i leverandøren sine system eller tenester utført basert på rammeavtalar.
Status for formatet
I produksjon.
Føremål: Dokumentere kjøp av varer eller tenester utan ei forutgåande bestilling
EHF ordreforslag kan brukast i bestillingsprosesser der
- prisar på tenester fastsetjast på bestillartidspunktet
- tenester utførast basert på ein vedlikehalds- eller utviklingsavtale, utan ei forutgåande direkte bestilling
Døme på dette er
- bestilling av billettar i bestillingssystemet til eit flyselskap
- ein røyrleggjar som utbetrar ein lekkasje på ein skole og sender kostnader på materiale og brukt tid i etterkant til oppdragsgjevar
- ein konsulent som rapporterer inn timar brukt for ein avgrensa periode på eit stort prosjekt
Formatet lar leverandør og oppdragsgjevar nytte sine eigne system til å utveksle og lagre strukturerte data i slike tilfelle, og dermed også bruke dataa vidare i kjøpsprosessen tildømes å matche faktura.
Teknisk informasjon EHF Ordreforslag
EHF Order Agreement teknisk spesifikasjon
Fordelar med å ta i bruk formatet
For oppdragsgjevarar
- Får maskinlesbar dokumentasjon på varer og tenester som er kjøpt utan forutgåande bestilling.
- Bruke lagra informasjon til å matche pakksedel og faktura.
For leverandørar
- Kunne bruke sitt eige system mot systemet til ulike oppdragsgjevarar, for stadfesting og innrapportering av utført arbeid og kostnader som må dekkast.
- Kunne gjenbruke informasjonen til å fakturere oppdragsgjevar.
EHF ordreforslag prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF ordreforslag prosess |
Prosess ID | |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.05.11 | Dokument etablert | Jan Mærøe |
3. Om prosessen
I denne prosessen registrerer leverandør informasjon om utført tjeneste eller utført bestilling for oppdragsgiver. Systemet sender et ordreforslag til oppdragsgiver. Oppdragsgiver mottar ordreforslag og lagrer det i sitt system.
4. Brukere og bruksområde (hvem og når)
Prosessen kan benyttes av leverandør og oppdragsgivere.
Oppdragsgiver skal normalt sende en ordre til leverandør før varer og tjenester leveres. Dette kan i mange tilfeller være lite hensiktsmessig – forsinke prosessen med å utføre tjenesten. For eksempel: Det har oppstått en vannlekkasje på en skole hvor det ikke er tid til å vente på en ordre. Det er inngått avtale om vedlikehold hvor det er uhensiktsmessig å be om og vente på en ordre for hver oppgave som skal utføres. Det er tatt en policy beslutning i virksomheten om å bruke reiseselskapets web-side for å reserve plass. Uten en slik løsning ville du kunne tapt reservasjonen før bestillingen når leverandør (sanntids-bestilling).
5. Formål
Når leverandør sender faktura for et hasteoppdrag, må den behandles manuelt. Hensikten med denne prosessen er å sikre at innkomne faktura kan behandles maskinelt og effektivt.
6. Mål
Flest mulig maskinelt behandlede fakturaer, automatch.
7. Gevinster
For leverandør: Dokumentasjon som kan brukes som input til faktura. Gjenbruk av informasjon sparer tid, reduserer feil og som følge av det reduserer kostnader. Ved statusmøter mellom oppdragsgiver og leverandør kan leverandør enkelt dokumentere sine prosesser/arbeid. Noe som sparer partene for tid samt øker tilliten til leverandøren.
For oppdragsgiver: Kunne dokumentere utført oppdrag ved ettersyn/revisjon – sparer tid og skaper tillit. Ved statusmøter blir det enklere å sammenligne informasjon som leverandør fremlegger med egen. Noe som sparer tid og reduserer kostnader. Fakturamatch sparer tid og reduserer risiko for feil. Enkel gjenbruk av strukturert informasjon forenkler planlegging – sparer tid ved nye konkurranser.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei.
9. Startkriterier/forutsetninger
Trigger | Et behov som må løses, for eksempel behov for flyreise, rask reparasjon av vannlekkasje. |
Andre forutsetninger |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
En ansatt eller bestiller reserverer for eksempel en reise. | Oppdragsgiver logger seg på reisesystemet | Oppdragsgiver | |
En vannlekkasje oppstår. | Varslingssystem eller rutinekontroll fra leverandør | Oppdragsgiver | |
Andre eksempler. |
|
|
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Behovshaver | o-beh | |
Oppdragsgiver | Bestiller | o-bes | |
Oppdragsgiver | Goskjenner | o-god | |
Oppdragsgiver | Avtaleforvalter | o-avf | |
Oppdraggiver | System | o-sys | |
Leverandør | l | ||
Leverandør | Person | l-per | |
Leverandør | System | l-sys |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1. Utfør arbeid i henhold til kontrakt og registrer tid og varekostnad | l-per | Situasjonsbestemt. | |||
2. Oppdragsgiver har registrerer informasjon i system eks reise. | l-per | Situasjonsbestemt. | |||
3. Lagre informasjon i system og klargjør forsendelse. | l-sys | Systemspesifikk | |||
4. Send et ordreforslag basert på utført oppgave. | l-sys
| Systemspesifikk
| |||
5. Lagre ordreforslag i system | o-sys | Systemspesifikk | |||
6. Sjekk om ordreforslag er i henhold til kontrakt | o-bes/avf |
| x | ||
7. Kontakt leverandør | o-bes/avf |
| |||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
6 | Sjekk om leveranse er i henhold til kontrakt | Enten kan system brukes opp mot kontrakts arkiv eller manuelt. | Sikre at man får avtalte priser. |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Strukturert informasjon (EHF ordreforslag) lagret i system i påvente av faktura. | Fakturaprosessen (er definert) | Oppdragsgiver/Bestiller |
|
16. Sluttkriterier
Leverandør må inkluderer ordreforslagsnummer i faktura slik at det er mulig for oppdragsgiver å koble ordreforslag mot faktura når den mottas.
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Nei. |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei.
22. Vedlegg
Nei.
EHF punch-out
EHF Punch Out gjev kontroll på komplekse bestillingar ved hjelp av leverandøren sitt system.
Status for formatet
I produksjon.
Formål og virkemåte: Kontrollere at riktig vare eller tjeneste leveres via leverandørs system
EHF punch out skildrar prosessen og meldingsinnhaldet der oppdragsgjevar
- får automatisk tilgang til avtalt sortiment i leverandøren sin nettbutikk, ved å klikke på ei lenkje i sitt eige bestillingssystem
- vel varer og tenester og legg dei i ei handlekorg inne i systemet til leverandøren
- overfører handlekorga tilbake til sitt eige bestillingssystem
Fordeler ved å ta i bruk formatet
For oppdragsgivere
- Høve til å setje saman komplekse varer eller tenester, til dømes ein PC.
- Lagre strukturert informasjon om varer og tenester i bestillingssystemet sitt som dannar grunnlaget for ein ordre/bestilling, til dømes ved utsending av EHF ordre og matching med EHF faktura.
For leverandør
- Informasjon om komplekse varer og tenester kan sendast til oppdragsgjevar sitt bestillingssystem på ein strukturert måte.
- Bestillar sender ordre med leverandøren sin vare- og tenesteinformasjon. Det lar leverandøren importere strukturert ordreinformasjon (EHF ordre) direkte inn i sitt eige system. Informasjonen kan så gjenbrukast ved utsending av ordrestadfesting og faktura.
EHF punch-out prosessen
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF punchout prosess |
Prosess ID | |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.06.02 | Dokument opprettet | Jan Mærøe |
3. Om prosessen
I punch out prosessen logger oppdragsgiver seg inn i sitt bestillingssystem, søker ønsket vare og klikker på lenken til leverandørens nettbutikk (punch out system). Oppdragsgiver søker etter varer og/eller tjenester i leverandørens nettbutikk og legger disse i handlkurv. Når oppdragsgiver har funnet alle varer eller tjenester klikker han på knappen som skal sende handlekurven over til sitt bestillingssystem. Handlekurven lagres i oppdragsgivers system. Neste prosess er ordreprosess.
4. Brukere og bruksområde (hvem og når)
Oppdragsgiver kan benyttes ved kjøp av komplekse varer og/eller tjenester som må skreddersys i leverandørens system, for eksempel konfigurering av PC.
5. Formål
Sikre god maskinlesbar informasjon fra leverandørenes system inn i eget bestillingssystem ved bruk av standard format.
6. Mål
Tilstrekklig informasjon for å kunne sende en EHF ordre
Tilstrekkelig informasjon for å matche EHF faktura med EHF ordre.
Muliggjøre innsamling og bruk av data i analyser.
Synlighet, transparens i bestillingsprosessen.
7. Gevinster
Oppdragsgiver: Økt kvaliltet i informasjonen vil redusere bruk av tid, ressurser og risiko for feil. Ledelsen får mulighet til bedre planlegging og kontroll.
Leverandører: Sparer tid ved at oppdragsgiver benytter leverandørens informasjon i etterfølgende prosesser.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Punch out er det samme som round trip.
9. Startkriterier/forutsetninger
Trigger | Behov for varer og/eller tjenester. |
Andre forutsetninger | Leverandørens bestillingsystem må ha innført punch-out funksjonalitet. Vær oppmerksom på at ved å stille krav om denne prosessen i konkurranser kan ha en konkurransevridende effekt da ikke alle leverandører har ressurser til å utvikle en slik løsning. Bestillere hos oppdragsgivere må være kjent med leverandørens nettbutikk |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Behov | Oppdragsgiver | ||
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Behovshaver | o-beh | |
Oppdragsgiver | Bestiller | o-bes | |
Oppdragsgiver | System | o-sys | |
Leverandør | System | l-sys | |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1. Logg inn i bestillingsystem og klikk punch out | o-bes | ||||
2. Punch out sesjon åpnes baser på innloggingsurl og avtalevarer vises i søkemotor. | l-sys | ||||
3. Fyll handlekurv basert på søkemotorresultat og avslutt handleprosess | o-bes | ||||
4. Forbered forsendelse av varer til oppdragsgivers bestillingssystem. Lagre bestilling i systeme | l-sys | ||||
5. Returner oppdragsgiver til sitt eget bestillingssystem og lukk sesjonen i systemet | l-sys | Her må en såkalt hook-url benyttes | |||
6. Handlekurv mottas i bestillingssystemet til oppdragsgiver | o-sys | ||||
7. Lagre varer i bestillingssystemet og klargjør for forsendelse av EHF ordre | o-sys | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Varer lagret i oppdragsgivers bestillingssystem | Ordreprosess (er definert) | Oppdragsgiver/system | |
16. Sluttkriterier
Varer og tjenester må være i henhold til avtale.
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei | |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei | ||||
19: Behov for støtte
Støtte | Forklaring/Lenker |
Opplæring i bruk av leverandørers systemer. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF pakkseddel
EHF pakkseddel gjør det mulig for oppdragsgiver å kontrollere at rett vare eller tjeneste er mottatt, og at det betales for riktig vare eller tjeneste.
Status for formatet
I produksjon.
Formål og virkemåte: Kontrollere at riktig vare eller tjeneste leveres
Kontroll med leveranser er viktig for både oppdragsgivere og leverandører. Begge parter må være trygge på at leveransen stemmer med bestillingen, og at det betales for riktig vare eller tjeneste. Formatet EHF pakkseddel kan hjelpe begge parter med kontrollen, ved at leveransen blir dokumentert elektronisk.
For leveranse av fysiske varer er det viktig at varemottakerrollen er definert hos oppdragsgiver. Varen kan bli levert et annet sted enn der den ble bestilt fra, og mottaker av varen kan være en annen enn bestiller.
Et eksempel er en skole: Bestiller sitter på kontoret og en vaktmester tar i mot varene. Dermed bør vaktmesteren være definert som varemottaker og må registrere varene inn i systemet.
Vareinformasjon fra EHF pakkseddel kan benyttes som underlag for denne kontrollen. Varemottaket vil også fungere som en referanse for ordre og benyttes ved match av EHF faktura.
EHF pakkseddel kan også benyttes som en bekreftelse på utført tjenesteoppdrag, der bestiller vil sjekke om for eksempel en konsulent eller vikar har vært tilstede og utført oppgaven i henhold til tilsendt pakkseddel.
Fordeler ved å ta i bruk formatet
For oppdragsgivere
- Få kontroll på leveransene.
- Klargjøre eget system for automatisert matching av EHF faktura.
- Ved elektronisk mottak (registrere restlevering, ukurans og brekkasje): Bedre grunnlag for å følge opp leverandør på levereransekvalitet i henhold til kontrakt på jevnlige statusmøter.
- Få definert rollebeskrivelsen varemottaker og tildele oppgaven til personer i organisasjonen.
- Redusere avvik på faktura ved at den reelle leveransen registreres, så feilfakturering ikke forekommer.
For leverandør
- Pakkseddel er som regel den siste oversikten over leveransen av varer som leverandør tar ut. Det vil si at restinger og andre ting som avviker fra bestilling er luket ut, slik at man har en reell oversikt over de varer som faktisk sendes til oppdragsgiver. Elektronisk pakkseddel sendes som regel over til transportør. Dersom EHF pakkseddel sendes til oppdragsgiver samtidig, vil begge parter være koordinert.
- For leverandør er det en fordel at oppdragsgiver sjekker varene i henhold til EHF pakkseddel for å unngå tvister der bestiller ikke har mottatt varene, eller at man påstår ukuranse og brekkasje som kan ha skjedd internt hos oppdragsgiver.
- For tjenesteleveranser er det en fordel for konsulent eller innleid personell, som vikarer, å kunne sende inn en bekreftelse på utført arbeid, slik at faktura er klarert før den sendes og sjekkes. Dermed flyttes kontrollen tidligere i prosessen slik at man unngår kreditering.
EHF mottaksprosessen
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF vare og tjenestemottak prosess |
Prosess ID | |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.05.28 | Dokument etablert | Jan Mærøe |
3. Om prosessen
Dette er en prosess hvor oppdragsgiver mottar og registrerer inn et korrekt mottak av varer og/eller tjenester. Systemet oppdatere opprinnelig bestilling med hva som er levert for derigjennom å kunne automatisk matche en faktura.
4. Formål
Pakkseddel gjør det mulig for oppdragsgiver å kontrollere at riktig vare og/eller tjenester er mottatt. For derigjennom sikre korrekt utbetaling i henhold til bestilling.
Fange statistikk på leveransepresisjon fra leverandør.
5. Mål
Målet er å helautomatisere behandlingen av faktura.
Ikke betale for noe som ikke er levert
6. Gevinster
For oppdragsgivere vil gevinst være å unngå utbetalinger for manglende leveranser – redusere kostnader. Reduserer risiko for at varer ikke blir levert som kan være virksomhetskritisk, eks helsesektoren. Reduserer tidsbruk i prosesser knyttet til dokumentasjon og arkivering. Bestilling oppdateres for automatisk match av faktura – sikrer en effektiv fakturaprosess. Ved elektronisk mottak, der pakkseddel gir en elektronisk dokumentasjon på leveranse, kan oppdragsgiver følge opp leverandørens leveransekvalitet (restlevering, ukurans og brekkasje) for problemløsning/forbedring.
Leverandør får dokumentert at leveranse er gjennomført på riktig sted, til riktig tid – kan redusere risiko for tvister om varen er levert på riktig sted, med riktig kvalitet, antall osv.
Totalt sett bidrar koordineringen til en mer effektiv verdikjede – samhandling mellom oppdragsgiver, leverandør og transportør.
For tjenesteleveranser er det en fordel for den som yter tjenesten å kunne sende inn en bekreftelse på utført arbeid slik at faktura er klart av oppdragsgiver før den sendes. Dermed flyttes kontrollen tidligere i prosessen slik at man reduserer risiko for kreditering – reduser bruk av tid og kostnader.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
7. Brukere og bruksområde (hvem og når)
Oppdragsgiver v/vare- og tjenestmottak. Brukes der bestilling er sendt via et bestillingssystem.
8. Definisjoner/forkortelser
Ingen
9. Startkriterier/forutsetninger
Trigger | Bestilling mottatt fra oppdragsgiver. |
Andre forutsetninger | Etablere et elektronisk varemottak i sitt bestillingssystem. Oppdragsgiver må definere en varemottakerrolle og tildele denne til personer som får opplæring i hvordan man foretar elektronisk varemottak. |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID | Leverandør/avsender - organisasjon | Referanse |
Bestilling | Oppdragsgiver | ||
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Bestiller | o-bes | |
Oppdragsgiver | Varemottaker | o-var | |
Leverandør | |||
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1. Plukke varer og allokerer ressurser. |
|
|
| ||
2. Genererer EHF pakkseddel |
|
|
| ||
3. Utføre oppdrag |
|
|
| ||
4. EHF pakkseddel sent |
|
|
| ||
5. Lagre EHF pakkseddel i system |
|
|
| ||
6. Motta varer eller sjkk utført oppdrag |
| >Motta varer eller sjekk utført oppdrag >Registrer i system. | x | ||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
6 | Bestiller sjekker om leveranser fra bestillingen er registrert i systemet. | Sjekk pakkseddel status. | Sikre at ordre er i henhold til den faktura som kommer – automatch kan gjennomføres. |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Mottatte varer og tjenester registert i system. | System | Oppdragsgiver | |
16. Sluttkriterier
Korrekt leveranser er registrert i systemet.
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Ingen |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Hvis varemottaker ikke vet om det er farlig gods i leveransen kan det være fare for liv og helse. | Liten | Høy | Følge anvisninger som EHFpakkseddel gir for risikoprodukter. | Leverandør må merke risikoprodukter. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Ingen ut over systemstøtte | |
Opplæring i utførelse av prosess. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF fakturering
EHF fakturering 3.0 sikrer automatisk, rask og sikker utbetaling. Formatet er obligatorisk ved fakturering i staten.
Status for formatet
I produksjon.
Formål og virkemåte: Standardisering av utbetaling og matching mot ordre
Faktura og en eventuell kreditnotatransaksjon er den siste transaksjonen i bestillingsprosessen og danner informasjonsgrunnlaget for utbetaling til leverandør av varer og tjenester.
Bruker din virksomhet allerede EHF katalog og EHF ordre, har du strukturert informasjon som kan gjenbrukes når du skal sende elektronisk faktura på formatet EHF fakturering 3.0 til opdragsgiver. Dermed gir leverandøren oppdragsgiver mulighet til automatisk å matche faktura mot ordre, og reduserer dermed sjansene for at utbetalinger blir forsinket, utbetaling skjer til feil leverandør. Samtidig effektiviserer virksomheten sin prosess og øker kvaliteten.
EHF faktura er obligatorisk ved fakturering i staten:
- Se Referansekatalogen for hvilke lovkrav som gjelder
- Forskrift
Fordeler ved å ta i bruk formatet
For oppdragsgivere
- En EHF Fakturering 3.0 gir oppdragsgiver mulighet til å kunne prosessere meldingen elektronisk intern, og kunne validere og arkivere den.
- En elektronisk faktura gir en enklere prosess for internflyt og godkjennelse, som igjen reduserer mulige forsinkelsesrenter for virksomheten.
- Har oppdragsgiver tatt i bruk et bestillingssystem med formatet EHF ordre, har oppdragsgiver mulighet for å godkjenne de økonomiske forpliktelsene før bestilling er gjort, og sende leverandør bestillingsnummer. Faktura kan dermed matches mot ordren og godkjennes maskinelt.
- Samlet fører dette til vesentlig reduksjon av prosesskostnader, reduserer feil og øker sporbarheten.
For leverandører
- Den store gevinsten for en leverandør er at man kan sende faktura til alle offentlige oppdragsgivere på ett format, via samme infrastruktur.
- Da oppdragsgiver kan automatisere prosesseringen av faktura, vil utbetalingen kunne komme raskere enn ved manuell fakturabehandling.
- Ved mottak av EHF ordre gjennbruke informasjon fra ordre i å lage EHF fakturering.
EHF faktura og kreditnota prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF faktura og kreditnota prosess |
Prosess ID | |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.06.02 | Dokument opprettet | Jan Mærøe |
3. Om prosessen
I denne prosessen lager leverandør en faktura for varer han har sendt eller tjenester han har utført, som sendes til oppdragsgiver.
Oppdragsgiver sjekker faktura mot bestilling. Hvis faktura er lik bestilling/orderen som er sendt kan faktura betales automatisk – uten manuell behandling.
Hvis faktura ikke er i samsvar med bestilling må oppdragsgiver kontrollere og eventuelt kreve at leverandør retter opp feil og eventuelt sender en kreditering.
4. Brukere og bruksområde (hvem og når)
Offentlige oppdragsgiver må benytte EHF faktura se Referansekatalogen for IT-standarder: https://www.digdir.no/digitale-felleslosninger/digitale-anskaffelser/1486
5. Formål
Effektivisere fakturabehandling – spare tid. Samt kunne dokumentere utbetaling fra offentlige virksomheter.
6. Mål
Korrekt faktura opp mot bestilling og i henhold til avtale.
7. Gevinster
Oppdragsgiver:
- Ved å eliminere den manuelle faktureringsprosessen kan virksomhetene spare mye tid og ressurser.
- Fordi faktura finnes imaskinlesbart format er det enklere å gjennomføre bokettersyn/revisjon.
- Fordi faktura er grunnlag for utbetaling til leverandør kan utbetalingsprosessen også effektiviseres.
- Hvis det er feil på faktura kan den også effektivisere kreditteringsprosessen.
- En elektronisk faktura reduserer også risiko for morarenter ved for sen utbetaling.
Leverandører:
- Reduserer risiko for sen betaling av varer og tjenester fra oppdragsgiver.
- Faktura danner grunnlag for purreprosessen som kan settes opp automatisk i leverandørens systemer ved overskridelse av innbetalingsdato.
- Fakturaen danner også grunnlag for en effektiv krediteringsprosess ved feil.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger | EHF ordre, abonnement eller annen form for bestilling (for utenlandske leverandører PEPPOL BIS) |
Andre forutsetninger | Nei |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Ordre | Ordreprosessen (definert) | Oppdragsgiver/bestiller | |
Abonnement | Fakturaprosess til leverandør | Leverandør |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | System | l-sys | |
Oppdragsgiver | Bestiller | o-bes | |
Leverandør | System | l-sys | |
Leverandør | Person | l-per |
12. Prosessdiagram

EHF faktura og kreditnota prosesstegning (pdf)
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1. Generere faktura basert på bestilling fra oppdragsgiver for leveranse av varer/tjenester | l-sys | ||||
2 Send faktura | l-sys | ||||
3 Motta faktura | o-sys | ||||
4. Sjekk faktura mot bestilling | o-sys | x | |||
5. Sjekk avvik. Sjekk om utbetaling har funnet sted | o-bes | x | |||
6. Kontakt leverandør å be om kreditering av hele fakturaen og be de sende en ny faktura med korrekt beløp | o-bes | ||||
7. Kontakt leverandør: be om kreditnota på hele fakturaen og be de sende en korrekt faktura og betale tilbake hele utbetalingen. Be om kreditnota på deler av fakturaen. Be leverandør betale tilbake delbeløpet. | o-bes | ||||
8. Behandle forespørselen og klargjør for kreditnota og/eller utbetaling av beløp | l-per | x | |||
9. Generer kreditnota med referanse til utsendt faktura | l-sys | ||||
10. Send kreditnota | l-sys | ||||
11. Motta kreditnota | o-sys | ||||
12. Oppdater eller utligne faktura mot kreditnota i regnskapssystemet | o-sys | ||||
13. Klargjør utbetaling til leverandør | o-sys | ||||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
4 | Maskinell kontroll av informasjon i faktura opp mot ordre | System | For å redusere risiko for feilutbetaling |
5 | Sjekk avvik. Sjekk om utbetaling har funnet sted | Manuelt | For å redusere risiko for feilutbetaling |
8 | Behandle forespørselen og klargjør for kreditnota og/eller utbetaling av beløp | Manuelt/System | For å redusere risiko for feilutbetaling |
Ved oppsett av abonnements mottak sjekke at referansenummer er korrekt opp mot gjeldende beløpsgrense | System | For å effektivisere fakturaprosessen | |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Grunnlag for utbetaling | Payment prosess/utbetalingsprosess | Regnskapssystem hos oppdragsgiver | |
16. Sluttkriterier
Kvitteringsmelding fra paymentsystem
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei | |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Feilutbetaling | Lav | Høy | Elektronisk match av ordre eller abonnements ordning | Sikre at alle fakturaer har et bestillings/abonnements nummer. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Systemopplæring for oppdragsgivere og leverandør. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
EHF gjennomfakturering prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | |
Prosess ID | |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
0,5 | |||
3. Om prosessen
ss
4. Brukere og bruksområde (hvem og når)
ss
5. Formål
ss
6. Mål
ss
7. Gevinster
ss
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
ss
9. Startkriterier/forutsetninger
Trigger | |
Andre forutsetninger |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | Behovshaver | o-beh | |
Oppdragsgiver | Bestiller | o-bes | |
Oppdragsgiver | Goskjenner | o-god | |
Oppdragsgiver | Avtaleforvalter | o-avf | |
Leverandør | |||
12. Prosessdiagram
ss
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1. | |||||
2. | |||||
3. | |||||
4. | |||||
5. | |||||
6. | |||||
7. | |||||
8. | |||||
9. |
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
16. Sluttkriterier
ss
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
19: Behov for støtte
Støtte | Forklaring/Lenker |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/
21. Tilleggsinformasjon
ss
22. Vedlegg
ss
EHF purring
EHF purring lar leverandøren automatisere purring av oppdragsgiver ved manglende betaling. Formatet gir også mulighet for å matche purring mot faktura.
Status for formatet
I produksjon.
Formål og virkemåte: Automatisere purring ved manglende betaling
Dersom en leverandør ikke har mottatt betaling i tide, kan han bruke formatet EHF purring til å purre oppdragsgiver.
I Lov om inkassovirksomhet og annen inndriving av forfalte pengekrav (inkassoloven), § 3 a. Elektronisk kommunikasjon, legges det til rette for elektronisk kommunikasjon:
"Krav i eller i medhold av denne loven om at meddelelser til skyldneren skal gis skriftlig, er ikke til hinder for bruk av elektronisk kommunikasjon dersom meddelelsen er sendt på en betryggende måte".
Formatet et anbefalt i henhold til Referansekatalogen
Fordeler ved å ta i bruk formatet
For oppdragsgivere
- Når du mottar purring elektronisk på formatet EHF purring, får du maskinlesbare referanser til EHF faktura som er innsendt av leverandør tidligere. Dermed kan oppdragsgiver spore opp den aktuelle fakturaen i eget datasystem, og spore prosessen for utbetaling til leverandør. Har utbetalingen stoppet, kan du sende melding om utbetaling på nytt.
For leverandører
- Mulighet for å automatisere prosessen med å purre oppdragsgivere, ved at EHF purring utløses automatisk ved manglende betaling.
EHF purring prosess
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF purring prosess |
Prosess ID | |
Organisasjon | Digitaliseringsdirektoratet |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.05.29 | Opprette dokument | Jan Mærøe |
3. Om prosessen
Før purreprosessen begynner har leverandør sendt en faktura til oppdragsgiver og lagret forfallsdato for betaling i sitt øknomisystem/kundeoppfølgingssystem. Purreprosessen begynner når forfallsdato passeres uten at systemet har regitrert innbetaling for den aktuelle faktura. Leverandørs system oppretter en EHF purring og sender denne til oppdragsgivers system. EHF purring inneholder referanse til den aktuell faktura slik at oppdragsgiver lett kan finne denne. Basert på mottatt purring starter oppdragsgiver en ny utbetalingsprosess..
Hvis EHF purring inneholder purregebyr må oppdragsgiver også sikre utbetaling av dette.
4. Brukere og bruksområde (hvem og når)
Brukere: Leverandør og oppdragsgiver.
Når: Ved for sen betaling av innsendt faktura.
5. Formål
Unngå manuelle purrerutiner som kan være tid- og kostnadskrevende
6. Mål
At purring kan utføres elektronisk mellom leverandør og oppdragsgiver
7. Gevinster
Leverandør: Sparer tid ved at systemet genererer en purremelding ved manglende betaling fra oppdragsgiver (etter forfallsdato på den opprinnelige fakturaen). Spart tid skjer ved at system tar utgangspunkt i utsendt orginalfaktura når purring lages. Dettesikrer riktig informasjon(kvalitet) i purringen.
Oppdragsgiver: Sparer tid ved at purring referer til innsendt/mottatt orginalfaktura. Sikrer at orginalfakturainformasjon er riktig. Muliggjør automatisert sjekk om orginalfaktura er godkjent og utbetalt eller at purringen skal godkjennes og utbetales.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Forfallsdato: Den datoen oppdragsgiver må ha betalt fakturaen på.
9. Startkriterier/forutsetninger
Trigger | Ikke mottatt betaling før fallsdatoen på en faktura i leverandørs system trigger purreprosessen (forfallsdato + 14 dager). |
Andre forutsetninger | Leverandør må ha et system som sjekker forfallsdato + 14 dager, på en faktura mot mottatt betaling. Gjøres ofte i et økonomisystem |
10. Input og leverandører
Input | Avleverende prosess: Navn på prosess + ID dersom den er definert og navngitt. Hvis ikke, la den stå tom | Leverandør/avsender - organisasjon | Referanse |
Melding om ikke innebetalt faktura | Systemspesifikk (ID er normalt det opprinnelige faktuanummert + forfallsdatoen) | Leverandør | |
11. Deltakere
Beskrivelse av roller finner du her:
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
Oppdragsgiver | System | o-sys | |
Oppdragsgiver | Person | o-per | |
Leverandør | System | l-sys | |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Beskrivelse | KP (x) | Kommentar |
1. Fakturasystem generer en EHF purring | l-sys | Systemspesifikk | |||
2. Send purring på utsendt faktura | l-sys | Systemspesifikk | |||
3. Undersøk årsak til at utbetaling ikke har funnet sted | o-per | Delprosessen består av to aktiviterer. Den ene er å finne årsaken til at utbetaling ikke har funnet sted og og iverksette riktig tiltak | |||
4. Generer utbetaling og send til betalingsmottaker | o-sys | Systemspesifikk | |||
14. Kontrollpunkter og målinger
Akt. nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig |
Nei | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Utbetaling til leverandør | Payment prosess | Leverandør | |
Leverandør varslet om manglende faktura | Leverandør | ||
Leverandør varslet om at utbetaling er underveis | Leverandør | ||
16. Sluttkriterier
Leverandør: At innbetaling for utsendt orginalfaktura og purring er registrert og bokført i leverandørs system.
Oppdragsgiver: Undersøker hva som var årsaken til at utbetaling ikke fant sted og utbredrer eventuelle feil
17. Unntak/spesielle hensyn
Hvor | Unntak - betingelser og endring |
Nei | |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Nei | ||||
19: Behov for støtte
Støtte | Forklaring/Lenker |
Nei | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke: https://anskaffelser.dev/
21. Tilleggsinformasjon
https://lovdata.no/dokument/SF/forskrift/1989-07-14-562
Alle regninger skal ha en forfallsdato, det vil si at kunden må betale fakturaen innen denne fristen. På grunn av at man bruker purring for å minne kunden på en manglende innbetaling, kan purring også kalles betalingspåminnelse.
Regler for purring og purregebyr:
- Man kan sende ut en purring 14 dager etter den opprinnelige betalingsfristen, for å minne kunden på at regningen ikke er betalt.
- Når man først må sende ut en purring, kan man legge til et gebyr for å måtte sende ut denne. Da kalles det purregebyr. Hvor stort gebyr man kan kreve, og andre regler for utsendelse av purringer, reguleres av Inkassoforskriften.
I Norge kan man kun kreve gebyr på utsendelse av to purringer. Det kan kreves renter fra betalingsfristen på den opprinnelige regningen, til forfall på purringen. Det gebyret som kan kreves inn, kan være lik en tidel av den gjeldende inkassosatsen når det sendes ut en purring. Per 01.01.2014 er maksimumsgebyret for purrenota kr 64,- (10% av Inkassogebyr). Purringen må ha en betalingsfrist på minst 14 dager.
Fra purring til inkasso
Dersom en regning ikke betales innen forfallsdatoen, kan man velge å sende et inkassovarsel direkte i stedet for purring. Man kan også sende ut inkassovarsel etter at purringen er sendt. Hvis inkassovarselet ikke betales innen 14 dager, kan saken sendes til inkasso. Inkasso vil si å inndrive gjeld, som ofte gjøres av et inkassobyrå.
22. Vedlegg
Nei
X5 Støtteprosesser
X51 Digitale støtteprosesser
X511 EHF Utvikle og forvalte standardformat
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF utvikle og forvalte standard format |
Prosess ID | X511 Utvikle og forvalte standard format |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.11.26 | Dokument etablert | Petter Vinje |
3. Om prosessen
Prosessen beskriver hvilke aktiviteter, som må og kan utføres i hvilken rekkefølge, av hvilke personer/organisajsoner/systemer, hver gang det skal utvikles og forvaltes et standard format.
4. Brukere og bruksområde
- Prosjektleder:
- Alle som leder denne type utviklingsprosjekter skal/kan benytte prosessen i
-- Planlegging: Identifiser og avklare hvilke aktiviteter det er behov for.
-- Organisering: Tilrettelette og organisere arbeidet.
-- Ledelse: Veilede, coach, motivere deltakerne.
-- Kontroll: Følge opp milepælene, iverksette tiltak ved avvik.
-- Læring og utvikling: Fordi utvikling og forvaltning er en prosess må de som skal forbedre prosessen ha oversikt over prosessen.
- Prosjektdeltakere:
- Alle som deltar i prosjektet skal være kjent med og benytte prosessen og de metoder, verktøy som er beskrevet der. Gjør det enklere å forstå hvilke aktiviteteter man har ansvar for, hvordan disse skal utføres, hvem man skal samarbeide med.
- Prosjekteier/programeier:
- Avhengig av prosessen for å sikre at alle prosjekter gjennomføres på en like god måte.
- Offentlig virksomhet
- Er avhengig av prosessen for å dokumentere sin praksis i interne prosessverktøy og sikre at prosjekter utføres på en riktig og effektiv måte.
- Er avhengig av prosessen for å kunne forbedre og utvikle seg. Uten prosessfokus er det ikke mulig å utvikle organisasjon eller virksomhet.
- Systemleverandører, oppdragsgivere, leverandører:
- Det er mange elementer i prosessen som systemleverandører, oppdragsgiver og andre kan benytte i eget arbeid.
- HR-funksjoner/endringsledelse:
- HR er avhengig av prosessen i sitt arbeid med rekruttering og utvikling av medarbeidere og organisasjon. Endringsledelse er avhengig av prosessen for å avdekke behov for endringer i en så tidlig fase som mulig – øke mulighetene for vellykket endring og gevinstrealisering.
- Markedsfunksjonen:
- Er avhengig av prosessen for å identifisere behov/muligheter for å iverksette markedstiltak i en tidlig fase.
5. Formål
Sikre at utvikling og forvaltning av standard formater forbedres og gjennomføres på en mest mulig effektiv måte.
6. Mål
- Til enhver tid ha en oppdatert prosessdefinisjon.
- Benytte prosessdefinisjonen i planlegging, organisering, ledelse og kontroll av alle prosjekter.
- Benytte prosessdefinisjonen i rekruttering, opplæring og utvikling av prosjektledere og deltakere.
- Benytte prosessdefinisjonen i forbedring og utvikling av organisasjonen.
- Sikre at kompetanse dokumenteres slik at risiko for problemer ved sykdom og fravære reduseres.
7. Gevinster
Bruk av prosessdefinisjoner er en ubetinget fordel for alle som bidrar til og skal bruke standardiserte formater.
- Enklere: Bruk av prosessen som sjekkliste gjør det enklere å planlegge og gjennomføre prosjekter.
- Raskere: Ved å følge prosessen reduseres unødvendig bruk av tid. Prosjekter kan gjennomføres raskere – økt produktivitet.
- Bedre: Ved å følge prosessen vil kvaliteten på leveranser bli jevnt sett høyere – reduserer uønskede variasjoner. Enklere, raskere og bedre arbeid gir økt bruker og medarbeidertilfredshet.
- Rimeligere: Bedre kvalitet og mer effektive prosesser reduserer ressursbruk.
- Mer attraktiv: Enklere, raskere, bedre og rimeligere prosesser gjør oss mer attraktive som organisasjon for brukere og ansatte.
- Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
- Prosess: En systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål.
- Effektivitet: Prosessen benytter ikke mer ressurser enn det som er nødvendig for å produsere format med ønsket kvalitet.
- Produktivitet: Antall formater som utvikles i en bestemt tidsperiode.
- Kvalitet: Er her det samme som kvalitet på informasjonen – at den er komplett og nøyaktig – oppfyller brukerens behov – ikke måtte bruke ekstra tid, ressurser på å finne, rette, legge til informasjon som mangler.
9. Startkriterier/forutsetninger
Trigger | Prosessdefinisjonen tas i bruk når prosjekt er besluttet igangsatt. |
Andre forutsetninger | Ledelsen må tilrettelegge og sikre at alle prosjekter følger prosessen. Kultur for å arbeide prosessorientert. |
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Beslutning m/prosjektgrunnlag | Ledelse | Prosjekteier | |
11. Deltakere
Beskrivelse av roller finner du: https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
DFØ ANS | Prosjekteier | PE | |
DFØ ANS | Prosjektleder | PL | |
DFØ ANS | Prosjektdeltakere | PD | |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL benyttes når det er behov for å angi at aktiviteten utføres av en systemleverandør. Som regel er det ikke behov for å angi hvilke rolle som utfører aktiviteten hos systemleverandør. | |
Ev andre | Ev. andre | Man kan også legge til roller dersom det er hensiktsmessig. | |
12. Prosessdiagram

13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
X5111 | Analysere behov og mulighet | PL | Lenke til delprosess | ||
X5112 | Utvikle teknisk veileder | PL | Lenke til delprosess | ||
X5113 | Forvalte standard formater | PL | Lenke til delprosess | ||
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
Ingen | Prosessen kontrolleres ved bruk av sjekklister og oppfølgningsmøter. | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Et format som blir utviklet og vedlikehold og publisert på anskaffelser.dev.no | Systemleverandører | ||
Et format som blir utviklet og vedlikehold og publisert på anskaffelser.dev.no | Oppdragsgivere | ||
Et format som blir utviklet og vedlikehold og publisert på anskaffelser.dev.no | Leverandører | ||
Et format som blir utviklet og vedlikehold og publisert på anskaffelser.dev.no | Alle andre som har behov/ønske om å informasjon om prosessen og format. |
16. Sluttkriterier
Utviklingsfasen avsluttes når høring er avsluttet. Forvaltningsfasen avsluttes når formatet publiseres i ny versjon og gammel format fjernes.
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
X5111 Analysere behov og mulighet | I tilfeller hvor prosessen er mer omfattende og praksis varierer vil erfaringsmessig hele WS1 medgå til å kartlegg og diskutere hvordan prosessen ser ut. Et arbeid som kan være krevende både for de som skal ha workshop og delta. Et alternativ til dette er å be deltakerne fylle ut et excelark hvor de beskriver sine oppgaver og svarer på noen spørsmål med et oppfølgningsintervju i etterkant. Fordelen med det er at de som skal arrangere workshopen får oversikt over situasjonen og kan være bedre forberedt til WS1. Fordelen for deltakerne er at de allerede har reflektert over egen situasjon. Fordelen for alle er at man kan gjennomføre en bedre WS i betydningen at man kan bruke mer tid på gode diskusjoner og avklaringer og redusere behov for ytterligere WS. |
X5112 Utvikle teknisk veileder | Aktivitet 7 og 8 er avhengig av prosjekt. Noen ganger er syntaks definert. Andre ganger må den lages. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Deltakerne benytter ikke/avviker fra prosessen. | Høy | Lav-høy | Kontrollere at prosessen benyttes. | Eskalere, varsle, informere om konsekvensene. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Prosjektleder vil ha behov for opplæring og støtte i prosessen og hvordan den skal/kan brukes. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Resultatet av prosessen vil publiseres her: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Her finner du et Gantdiagram som omhandler analyse og teknisk utvikling
X5111 EHF Analysere behov og mulighet
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF Analysere behov og mulighet |
Prosess ID | X5111 Analysere behov og mulighet |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.11.26 | Dokument etablert | Petter Vinje |
3. Om prosessen
Prosessen X5111 Analysere behov og mulighet er den første av de tre del-prosessene i X511 Utvikle og forvalte standard format. Prosessen begynner når beslutning om prosjekt er tatt. Og beskriver alle aktiviteter knyttet til planlegging og analyse av behov/mulighet for format – grunnlaget for de som skal utvikle teknisk veileder.
4. Brukere og bruksområde
Programeier, prosjektleder, deltakere har behov for prosessen når:
- Prosjektet skal planlegges.
- Behov og mulighet for bruk av standard format skal identifiseres og avklares.
- Besluttning om utvikling og eventuelt videre arbeid skal tas.
5. Formål
Sikre kvalitet og effektivitet i utvikling av teknisk veileder.
6. Mål
- Sikre at alle som deltar i prosjektet blir involvert og informert så godt og tidlig som mulig.
- Sikre at brukernes behov blir ivaretatt og riktig format utviklet.
- Sikre at alternative løsninger blir vurdert og mest hensiktsmessig løsning valgt.
- Sikre at de som utvikler teknisk veileder får den informasjonen de må ha for å kunne utvikle formatet på en effektiv måte.
- Sikre at behov for markedsføringstøtte og endringsledelse er forstått og planlagt i god tid.
7. Gevinster
Alle som eier, ledere, deltar i prosjektet vil ha følgende fordeler.
- Enklere, raskere og bedre planlegging – grunnlag for effektiv utvikling og bruk av utviklingsressurser.
- Tidlig involvering og informasjon bidrar til økt tilfredshet og motivasjon hos deltakerne.
- Tidlig involvering av HR, markedsfunksjon reduserer risiko for at viktige tiltak knyttet til endring og markedsføring ikke iverksettes tidlig nok.
- De som skal utvikle tekniske veiledere får den informasjon de må ha for effektiv utvikling.
- Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
- Prosess: En systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål.
- Effektivitet: Prosessen benytter ikke mer ressurser enn det som er nødvendig for å produsere format med ønsket kvalitet.
- Produktivitet: Antall formater som utvikles i en bestemt tidsperiode.
9. Startkriterier/forutsetninger
Analyseprosessen starter når beslutning om prosjekt er tatt.
Trigger | Beslutning om prosjekt. |
Andre forutsetninger | Ledelsen må tilrettelegge og sikre at alle prosjekter følger prosessen. Kultur for å arbeide prosessorientert |
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Beslutning m/prosjektgrunnlag | Ledelse | Prosjekteier | |
11. Deltakere
Beskrivelse av roller finner du her: https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
DFØ ANS | Prosjekteier | PE | |
DFØ ANS | Prosjektleder | PL | |
DFØ ANS | Prosjektdeltakere | PD | |
DFØ ANS | Prosessansvarlig | PRA | |
DFØ ANS | Formatansvarlig | FA | |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL benyttes når det er behov for å angi at aktiviteten utføres av en systemleverandør. Som regel er det ikke behov for å angi hvilke rolle som utfører aktiviteten hos systemleverandør. | |
Ev andre | Ev andre | Man kan også legge til roller dersom det er hensiktsmessig. |
12. Prosessdiagram

Lenke til prosessdiagram i Excel
Dersom du har visio og ønsker å bruke/redigere diagrammet.
- Høyre-klikke på diagrammet
- Klikk "Visio-objekt"
- Klikk "Redigier" eller Åpne" diagram i visio.
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
Starte prosjekt |
| ||||
1. Lage prosjektgrunnlag: | PE | Sjekkliste >Målbilde: >Hvordan skal aktørene benytte produktet? >Hvordan passer produktet inn i anskaffelsesprosessen? >Hvilke kontrollmekanismer skal etableres? >Krav til statistikkinnsamling? >Krav til metode? >Krav til gjennomsiktighet? >Hva er utenfor scope (avgrensninger)? >Resultat: >>Hvilke del-produkter skal produseres? >>Hvilke bi-produkter skal produseres? >>Hvilke brukere har de ulike del-/bi-produktene? >>Hvilke krav stilles til implementerere? >>Hvilken funksjonalitet stilles det krav om? >>Annet? | Mal | ||
2. Lage forslag til mandat | PL | Mal | |||
3. Godkjenne mandat | PE | ||||
4. Lage forslag til prosjektplan | PL | Mal | |||
5. Godkjenne prosjektplan | PL | ||||
6. Planlegge og gjennomføre Kick-off | PL | >Excel oppgavearke | |||
7. Planlegge WS1 og fortsette arbeidet med utvikling av informasjonsmodell og fylle ut maler | PL | >Excel oppgaveark >Undersøke om muligheter for pilotering av standard format. | |||
8. Ev. Gjennomføre kartlegging og intervju | PRA | >Lage AS-IS prosessmodell | >Excel oppgaveark mal >Presentasjons eksempel med spørsmål | ||
9. Beskrive nåsituasjon: AS-IS | PRA | >Kartlegge forventninger >Kartlegge AS-IS situasjon | >Prosessrammeverk >BPMN 2.0 notasjon >Sjekkliste | ||
10. Gjennomføre WS1 AS-IS | PL | >Sjekkliste >Eksempler | |||
11. Beskrive fremtidig situasjon for brukere og interessenter | PRA | >Forventning og krav til format og prosess. >Endringsbehov >Gevinstmuligheter | >Sjekkliste | ||
12. Planlegge WS2 og videreføre arbeid med utvikling av informasjonsmodell og maler, TO-BE prosessmodell, Use case | PL | >Informasjonsmodell >Prosessmodell >Use Case >Fylle ut maler | >Maler >Eksempler | ||
13. Gjennomføre WS2 Fremtidig situasjon | PL | Dersom det ikke er behov for en WS2 bør det likevel holdes et avsluttnings-/informasjonsmøte. | |||
14. Lage analyserapport | PL | I tilfellet det kun blir WS1 kan arbeidet med å sluttføre rapporten påbegynnes etter aktivitet 10. med eventuell gjennomgang i et avsluttningsmøte. | |||
15. Godkjenne analyserapport | PE | ||||
14. Kontrollpunkter og målinger
I denne prosessen vil bruk av sjekklister og oppfølgningsmøte være tilstrekkelig som kontroll og oppfølgning.
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
Kontroll sikres ved bruk av sjekklister og oppfølgningsmøter. | ||||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Analyserapport | X5112 Utvikle teknisk veileder | DFØ ANS | |
16. Sluttkriterier
Rapport fra analysefasen må være godkjent før neste prosess kan påbegynnes
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
Aktivitet 8. | Dersom det er behov/fordel at deltakerne forbereder seg til noe før WS1 anbefales det at de gis en oppgave med eventuelle oppfølgningsmøter. Dersom det er behov for å lage prosesskart anbefaler vi at dette forberedes, gjøres her, ikke i WS1 fordi det kan ta mye tid fra viktige diskusjoner. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Avviker fra prosessen | Høy | Lav-høy | Prosjektleder må kontrollere at prosessen følges. | Prosessen tillater avvik i de tilfeller det er hensiktsmessig. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for opplæring i utførelse av prosess. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Sluttresultatet, en EHF, publiseres her: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
X5112 EHF Utvikle teknisk veileder
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF Utvikle teknisk veileder |
Prosess ID | X5112 Utvikle teknisk veileder |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.12.02 | Dokument etablert | Petter Vinje |
3. Om prosessen
Prosessen beskriver alle aktiviteter som må/kan utføres i utvikling av teknisk veileder/standard format.
4. Brukere og bruksområde
- DFØ ANS trenger prosessen for å dokumentere hvordan de arbeider med utvikling av veileder/standard format.
- Programleder/eier trenger prosessen for å sikre at alle prosjekter utvikler veiledere/standard formater med samme effektivitet og kvalitet. Samt forbedrer disse.
- Prosjektleder trenger prosessen for å forsikre seg om at de som utvikler teknisk veileder/standard format har den nødvendig kompetansen, og arbeider på den riktige måten.
- De som utvikler teknisk veileder/standard format trenger prosessen for å forstå hvordan disse skal utvikles.
5. Formål
Sikre en mest mulig effektiv utvikling av teknisk veileder/standard format.
6. Mål
- Til enhver tid ha oppdatert prosessdefinisjon som speiler beste praksis og ivaretar utviklernes behov for informasjon om prosess, leveranser, etc.
- Redusere utviklingstid for de som skal utvikle systemer/tjenester.
- Skape interoperabilitet mellom ulike systemer.
- Bruke prosessdefinisjonen som grunnlag forbedrings- og utviklingsarbeid.
7. Gevinster
- Enklere. For de som skal utvikle standard formater blir det enklere å lære og utføre sine oppgaver.
- Raskere. Når de som skal utvikle forstår og følger prosessen vil utviklingen gå raskere.
- Bedre. Når de som skal utvikle veilederen kan arbeider raskt og riktig får vi også en jevnere, bedre kvalitet.
- Rimeligere. Når de som utvikler kan gjennomføre raskere og bedre utviklingsprosesser vil vi redusere ressursbruk og kostnader – øke produktivitet.
- Mer attraktive: enklere, mer effektiv arbeid med høyere kvalitet på leveranser gjør oss mer attraktive for ansatte og brukere.
- Risiko: Standardiserte prosesser reduserer risiko for problemer ved sykdom, jobbskifte, fravær.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
- Prosess: En systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål.
- Effektivitet: Prosessen benytter ikke mer ressurser enn det som er nødvendig for å produsere format med ønsket kvalitet.
- Produktivitet: Antall formater som utvikles i en bestemt tidsperiode.
- Kvalitet: Er her det samme som kvalitet på informasjonen – at den er komplett og nøyaktig – oppfyller brukerens behov – ikke måtte bruke ekstra tid, ressurser på å finne, rette, legge til informasjon som mangler.
9. Startkriterier/forutsetninger
Trigger | Når analyserapport er godkjent. |
Andre forutsetninger |
|
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Beslutning m/prosjektgrunnlag | Ledelse | Prosjekteier | |
Analyserapport | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
Use case | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
Rolle og prosessdiagram | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
Spesifikasjoner | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
Forretningsregler | X5111 EHF Analyse av behov og mulighet | Prosjektleder | |
11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
DFØ ANS | Prosjekteier | PE | |
DFØ ANS | Prosjektleder | PL | |
DFØ ANS | Prosjektdeltakere | PD | |
DFØ ANS | Prosessansvarlig | PRA | |
DFØ ANS | Formatansvarlig | FA | |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver. | |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL benyttes når det er behov for å angi at aktiviteten utføres av en systemleverandør. Som regel er det ikke behov for å angi hvilke rolle som utfører aktiviteten hos systemleverandør. | |
12. Prosessdiagram

Lenke til prosessdiagram i Excel
Dersom du har Visio og ønsker å bruke/redigere diagrammet:
- Høyre-klikke på diagrammet i Excel
- Klikk "Visio-objekt"
- Klikk "Redigier" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Før | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
A | 1. Gjennomgå eksisterende standarder | >CEN >PEPPOL | ||||
A | 2. Definere forretningsregler | >Bruk kravmalen som er fylt ut i analysefasen | ||||
2 | 3. Definere datamodell | >Bruk meldingsdokumentet og kravsdokumentet fylt ut i analysefasen | ||||
A | 4. Velge eller opprette repo på Github | >GitHub | ||||
1 | 5.Benytte eksisterende kodelister eller lage nye kodelister | >ISO stanadarder >Se Post-Award kodeliser >Se Pre-Award kodelister | ||||
1,5 | 6. Undersøke syntaks muligheter | >Bruke meldingsmalen, blir fylt ut i analysefasen >Bruke AnsBL til å forme syntaksen, hvis ikke UBL eller annen syntaks kan brukes | ||||
1,2,3,5,6 | 7. Lage syntaksbinding mot eksisterende syntaks | >UBL >XML >Riktig namespace >Elementer og attributter >Kodeliste >Regler | ||||
1,2,3,4,5,6 | 8. Lage syntaks og syntaksbinding for ikke eksisterende syntaks | >AnsBL >XML >Riktig namespace >Elementer og attributter >Kodeliste >Regler | ||||
2,7,8 | 9. Lage og teste regler Schematron | >Forretningsregler >Bruke kravmalen, blir fylt ut i analysefasen. >Teksteditor | ||||
5,7,8,9 | 10. Lage eksempelfil | >Syntaksbindingen >Teksteditor (Atom, …) | ||||
5,7,8,9,10 | 11. Lage snippets | >Asciidoc - som referanse >Syntaksbindingen - som tagger | ||||
A | 12. Lage spesifikasjon | |||||
12 | 13. Skrive introduksjon og bakgrunn for formatet | >Asciidoc >Bruke prosjektbeskrivelsesmalen, blir fylt ut i analysefasen | ||||
5,7,8,9,10,11,13 | 14. Beskrive de viktige aspektene ved formatet (ferdig spesifikasjon) | >Asciidoc >Syntaksbindingen/meldingsmalen fra analysefasen | ||||
A | 15. Lage usecase | >Asciidoc >Bruk use case malen, blir fylt ut i analysefasen | ||||
A | 16. Lage rolle og prosessdiagram | >BPMN 2.0 >UML | ||||
5,7,8,9,10 | 17. Lage change log og releasenote | >Asciidoc: Skriv endringer som har blitt gjort | ||||
5,7,8,9 | 18. Etablere validatorstøtte | >Schematron filer | ||||
18 | 19. Etablere 0.9 versjon | Sjekkliste: - Eksempelfilene validerer, - Syntaks, - Visningen av snippetsene, - Eksempler i syntaksen uten bugs, - Schematron regler, - Tittel, - Versjonsnummer, - Visningen av lenkene, - Rekkefølgen av innholdet i guiden, - Visning av bildene, - Rollediagram, - Prosessdiagram | ||||
19 | 20. Sende ut på review | >anskaffelser.dev | ||||
20 | 21. Gjennomgang av høringssvar | >SuperOffice (ehf@dfo.no) >GitHub (Issue) | ||||
21 | 22. Implementering av høringssvar | >Oppdatere formatet >Teste endringene | ||||
22 | 23. Sende format ut på offisielt review | >anskaffelser.dev | ||||
23 | 24. Gjennomgang av høringssvar | >SuperOffice (ehf@dfo.no) >GitHub (Issue) | ||||
24 | 25. Implementering av høringssvar | >Oppdatere formatet >Teste endringene | ||||
25 | 26. Lage erfaringsnotat | >Dokumentere prosess | ||||
8,9 | 27. Lage identifikatorer | >Etter retningslinjer fra Peppol | ||||
27 | 28. Søke Peppol om godkjenning av identifikatorer | >Peppol eDelivery | ||||
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
Ingen | Prosessen kontrolleres ved hjelp av sjekklister, oppfølgingsmøter, validator. | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Teknisk veileder (EHF) | Brukernes prosesser | Oppdragsgiver Leverdører Systemleverandører | |
Gyldig Syntaks (dokumentinstans) | Brukernes prosesser | Oppdragsgiver Leverdører Systemleverandører |
16. Sluttkriterier
Prosessen er ferdig når høringen er gjennomført og høringssvarene implementert.
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
Aktivitet 7 og 8 | Avhengig av prosjektet. Noen ganger definert syntaks, andre ganger må vi lage. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Avviker fra prosessen | Lav | Lav-høy | Prosjektleder må kontrollere at prosessen følges | Prosessen tillater avvik i de tilfeller det er hensiktsmessig. Dersom det oppstår ikke hensiktsmessige avvik, må Prosjektleder kartlegge årsaken og iverksette tiltak. Dersom avviket representerer en forbedring, bør prosessdefinisjonen oppdateres og endring kommuniseres. |
19: Behov for støtte
Støtte | Forklaring/Lenker |
De som skal gjennomføre prosessen må få opplæring, veiledning og støtte i arbeidet. | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Resultatet av prosessen (EHF) publiseres her: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
22.1 Gant diagram
Diagrammet beskriver hovedaktivitetene og rekkefølgen i utvklingsfasen. Lys grønn indikerer når de kan påbegynnes.
5112 Gantdiagram

X5113 EHF Forvalte standard format
Prosess Definisjon Dokument (PDD) DIFI ANS ATS
1. Informasjon
Prosess navn | EHF Forvalte standard format |
Prosess ID | X5113 Forvalte standard format |
Organisasjon | DFØ-ANS |
Prosess eier | Jan Mærøe |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | 2020.12.03 | Dokument etablert | Petter Vinje |
3. Om prosessen
Prosessen beskriver alle aktiviteter som må eller kan utføres i forvaltning av standard format. Etter teknisk utvikling overtar forvaltningsorganisasjonen ansvaret for formatet.
4. Brukere og bruksområde
- DFØ ANS trenger prosessen for å dokumentere forvaltningsprosessen.
- DFØ trenger prosessen for å sikre at ønsker fra brukerne blir ivaretatt på en god måte.
- DFØ ANS trenger prosessen for sikre at kompetanse i forvaltning av standard format utvikles/blir i virksomhet og kan overføres til andre – unngå problemer som oppstår ved skifte, fravær.
- DFØ ANS trenger prosessen for å kunne forbedre, utvikle forvaltningen av standard format.
- Deltakerne i forvaltning av standard format trenger prosessen for å forstå, planlegge og gjennomføre sine oppgaver på en koordinert måte.
5. Formål
Sikre at standardformat forvaltes på en rask, effektiv og riktig måte.
6. Mål
- Implementere endringsønsker og tilrettelegge for en kvalitetsmessig og effektiv implementering av endringer i de ulike systemene.
7. Gevinster
Alle som eier, ledere, deltar og skal bruke resultatet av bedre prosesser vil ha en fordel, gevinst av denne prosessen.
- Brukerne: Endringsønsker blir ivaretatt. Ny funksjonalitet/tjenester utvikles i systemer.
- DFØ ANS: Relevant og attraktiv for markedet.
- Oppdragsgivere: Effektiv kvalitetsmessig implementering i deres systemer.
- Leverandører: Effektiv kvalitetsmessig implementering i deres systemer.
- Systemeleverandører: Effektiv kvalitetsmessig implementering i deres systemer.
- Samfunnet: Enklere å operasjonalisere politiske beslutninger.
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
- Prosess: En systematisk serie med aktiviteter rettet mot oppnåelse av ett eller flere mål.
- Effektivitet: Prosessen benytter ikke mer ressurser enn det som er nødvendig for å produsere format med ønsket kvalitet.
- Produktivitet: Antall formater som utvikles i en bestemt tidsperiode.
- Informasjonskvalitet: Kvaliteten på informasjonen som mottas. 100% informasjonskvalitet vil si at informasjonen er komplett og riktig slik at de som mottar den kan utføre sine oppgaver/aktiviteter på en riktig og effektiv måte – ikke måtte bruke ekstra tid, ressurser på å finne, rette, legge til informasjon som mangler.
9. Startkriterier/forutsetninger
Trigger | Innkommende endringsønsker |
Andre forutsetninger |
|
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
Endringsønske | Peppol BIS, formel kanal | ||
Endringsønske | GitHub | ||
Endringsønske | EHF@DFO.no | ||
11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
DFØ ANS ATS | EHF team | EHF-T | |
Oppdragsgiver | O | O benyttes når man kun ønsker å angi at denne aktivitetene utføres av oppdragsgiver | |
Leverandør | L | Angir at aktivitet utføres av en leverandørorganisasjon. | |
Systemleverandør | SL | SL benyttes når det er behov for å angi at aktiviteten utføres av en systemleverandør. Som regel er det ikke behov for å angi hvilke rolle som utfører aktiviteten hos systemleverandør. | |
12. Prosessdiagram

Lenke til prosessdiagram i Excel
Dersom du har Visio og ønsker å bruke/redigere diagrammet:
- Høyre-klikke på diagrammet i Excel
- Klikk "Visio-objekt"
- Klikk "Redigier" eller Åpne" diagram i Visio.
13. Aktiviteter
ID | Før | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
1. Sjekke endringsønsker | >Via release not Peppol BIS >GitHub >EHF@DFO.no | Forskjellen på minor og major er tidsforløpet i varsling og implementering av ny versjon | ||||
1 | 2. Vurder endringsomfanget | Om det er bug,minor eller major | ||||
2 | 3. BUG: Analyser hva som må gjøres. Iverksette tiltak | |||||
3 | 4. BUG:Dokumenter endring | For bruk i release note og dokumenter endring i change log | ||||
4 | 5. BUG: QA (Kvalitetssikring) | |||||
5 | 6. BUG: Oppdater i eksisterende EHF veileder(e) | |||||
6 | 7. BUG: Sette i produksjon | Etter denne aktiviteten er retting utført i veileder og endring publisert | ||||
2 | 8. M/M:Analyser og planlegg det som må utvikles | |||||
8 | 9. Utvikling av endring | (Syntaks, kodelister, schematronregler) | ||||
9 | 10. Oppdatere EHF veileder(e) | |||||
10 | 11. QA (Kvalitetssikring) | |||||
11 | 12. Etablere release note og change log | |||||
12 | 13. Send ut melding til alle brukere. | Om den forestående endringen med informasjon om høringens startdato og sluttdato. Varsler hvilken dato ny versjon trer i kraft | ||||
13 | 14. Korriger endring hvis det er feil. Hvis ikke send melding om at vi er uenig i kommentaren | Hvis det kommer kommentarer på endring. | ||||
14 | 15. Publiser ny versjon | |||||
15 | 16. Varsle markedet om fjerning av gammelt format | |||||
16 | 17.Gi melding til Digitalisereringsdiretoratet | Om å slette mulighet for nyregistrering av gammelt format i ELMA og slettingsdato av gammel versjon | ||||
17 | 18. Fjerne mulighet for nyregistrering av gammel versjon i ELMA | |||||
18 | 19. Fjerne gammel versjon fjernet fra ELMA | |||||
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
Ingen | Prosess kontrolleres ved bruk av sjekklister. | |||
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
Pilot candidate | Mottaker/brukers egne prosesser | Systemleverandør | Benyttes når markedet/prosessen er umodent, fordel med pilot. |
Release candidate (RC) 1,2,.. | Mottaker/brukers egne prosesser | Systemleverandør | Benyttes når markedet/prosessen er umodent. |
Oppdatert versjon | Mottaker/brukers egne prosesser | Systemleverandør | |
16. Sluttkriterier
- Når høringen er gjennomført og høringssvarene implementert. Publisere ny versjon.
- Når mulighet for registrering av gammel versjon er fjernet i ELMA (SMP).
- Gammel versjon er fjernet fra ELMA (SMP).
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
Dersom markedet ikke har implementert ny versjon | Må gammel versjon leve inntil antall transaksjoner av ny versjon har nådd kritisk masse. Fastsettes av leder. |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
Avviker fra prosessen | Lav | Medium-Høy | Markedet gir tilbakemelding om ev. avvik | Gå tilbake til relevant prosessteg. |
Endring medfører så høy kostnader at systemleverandører ikke implementerer. | Lav | Høy | Markedet gir tilbakemelding | |
19: Behov for støtte
Støtte | Forklaring/Lenker |
Behov for prosessopplæring. | |
Behov for teknisk opplæring | |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
Lenke til informasjonsside: https://anskaffelser.dev/postaward/g3/announcement/
Release management: https://anskaffelser.dev/postaward/g2/policy/release-management/
Lenke til tekniske spesifikasjoner: https://anskaffelser.dev/
21. Tilleggsinformasjon
Nei
22. Vedlegg
Nei
X512 EHF implementeringsprosess av digitale løsninger i virksomheten
Prosess Definisjon Dokument (PDD) DFØ ANS ATS
1. Informasjon
Prosess navn | EHF implementeringsprosess av digitale løsninger i virksomheten |
Prosess ID | X5211 EHF implementeringsprosess av digitale løsninger i virksomheten |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | Dokument etablert | ||
3. Om prosessen
4. Brukere og bruksområde
5. Formål
6. Mål
7. Gevinster
Oppdragsgiver:
Leverandør:
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger |
|
Andre forutsetninger |
|
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
16. Sluttkriterier
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
19: Behov for støtte
Støtte | Forklaring/Lenker |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
21. Tilleggsinformasjon
22. Vedlegg
X5121 EHF implementeringsprosess av digitale løsninger i virksomheten-analyse
Prosess Definisjon Dokument (PDD) DIFI ANS ATS
1. Informasjon
Prosess navn | EHF implementeringsprosess av digitale løsninger i virksomheten- analyse |
Prosess ID | X EHF implementeringsprosess av digitale løsninger i virksomheten- analyse |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | Dokument etablert | ||
3. Om prosessen
4. Brukere og bruksområde
5. Formål
6. Mål
7. Gevinster
Oppdragsgiver:
Leverandør:
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger |
|
Andre forutsetninger |
|
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
16. Sluttkriterier
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
19: Behov for støtte
Støtte | Forklaring/Lenker |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
21. Tilleggsinformasjon
22. Vedlegg
X5122 EHF implementeringsprosess av digitale løsninger i virksomheten- implementering
Prosess Definisjon Dokument (PDD) DIFI ANS ATS
1. Informasjon
Prosess navn | EHF implementeringsprosess av digitale løsninger i virksomheten- implementering |
Prosess ID | X EHF implementeringsprosess av digitale løsninger i virksomheten- implementering |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | Dokument etablert | ||
3. Om prosessen
4. Brukere og bruksområde
5. Formål
6. Mål
7. Gevinster
Oppdragsgiver:
Leverandør:
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger |
|
Andre forutsetninger |
|
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
16. Sluttkriterier
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
19: Behov for støtte
Støtte | Forklaring/Lenker |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
21. Tilleggsinformasjon
22. Vedlegg
X5123 EHF implementeringsprosess av digitale løsninger i virksomheten- forvaltning
Prosess Definisjon Dokument (PDD) DIFI ANS ATS
1. Informasjon
Prosess navn | EHF implementeringsprosess av digitale løsninger i virksomheten- forvaltning |
Prosess ID | X5211 EHF implementeringsprosess av digitale løsninger i virksomheten- forvaltning |
Organisasjon | DFØ-ANS |
Prosess eier | |
Henvendelser | Jan Mærøe |
2. Historikk
Versjon | Dato | Endring | Forfatter/Rolle |
1.0 | Dokument etablert | ||
3. Om prosessen
4. Brukere og bruksområde
5. Formål
6. Mål
7. Gevinster
Oppdragsgiver:
Leverandør:
Samfunnsgevinst: Enten redusert bruk av ressurser og/eller økt produktivitet - utføre andre/flere oppgaver
8. Definisjoner/forkortelser
Nei
9. Startkriterier/forutsetninger
Trigger |
|
Andre forutsetninger |
|
10. Input og leverandører
Input | Avgivende prosess: | Leverandør av input | Referanse |
11. Deltakere
Beskrivelse av roller finner du her:https://www.anskaffelser.no/innkjopsledelse/organisering-roller-og-ansvar
Organisasjon | Rolle (ved behov) | Forkortelser | Kommentarer |
12. Prosessdiagram
13. Aktiviteter
ID | Aktiviteter i prosesskart | Ansvar | Aktivitetsbeskrivelse | KP (x) | Kommentar |
14. Kontrollpunkter og målinger
Aktivitet nr. | Hva som skal kontrolleres, måles | Hvordan det skal gjøres | Hvorfor det er nødvendig | |
15. Output og mottaker/bruker
Output | Mottakende prosess: Navn på prosess. Dersom prosessen har et navn og en ID sett inn dette. | Mottaker/bruker | Referanse |
16. Sluttkriterier
17. Unntak/spesielle hensyn
Del-prosess, aktivitet | Unntak/hensyn |
18. Risiko
Risiko | Sannsynlighet | Alvorlighet | Metode | Tiltak |
19: Behov for støtte
Støtte | Forklaring/Lenker |
20. Lenke til EHF/PEPPOL BIS Spesifikasjon.
21. Tilleggsinformasjon
22. Vedlegg