Dette dokumentet beskriver Elektronisk Handelsformat (EHF) for utveksling av ordreinformasjon elektronisk mellom handelspartnere. Dokumentet er utarbeidet som en del av satsingen til Direktoratet for forvaltning og IKT (Difi) innen standardisering av elektronisk handelsprosesser.

Dette dokumentet en høringsutgave av EHF Ordreprosess 1.0.13. Inntil dokumentet kommer i endelig utgave kan endringer gjort fra forrige versjon endres og at det kan komme mye endringer basert på tilbakemelding.

Denne versjonen av dokumentet forventes å være obligatisk fra 10. desember 2019.

Følg med på Difi sin portal VEFA for hvilke datoer som gjelder for denne versjonen.

Innmelding av feil og mangler
Dersom du finner feil eller mangler i dokumentet ber vi om at det det meldes inn på Github Issues. Dersom man ikke allerede har bruker på Github kan man opprette bruker gratis.

Innledning

Bakgrunn og målsetning

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

Regjeringa meiner auka bruk av elektroniske løysingar er viktig for å forbetre og effektivisere offentleg innkjøp. Bruk av elektroniske løysingar kan redusere tidsbruken ved offentlege innkjøp, auke konkurransen og leggje til rette for innkjøp som er meir gjennomsiktige og lettare kan etterprøvast. Ved å bruke mindre tid og pengar på innkjøp frigjer ein ressursar som kan brukast til både fornying av offentleg sektor og meir velferd. Målet med å innføre elektroniske løysingar er å medverke til betre, enklare og sikrare innkjøp.

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

Definisjon av åpen standard:
En åpen standard kjennetegnes ved at den er anerkjent og vil bli vedlikeholdt av en ikke-kommersiell organisasjon, og det løpende utviklingsarbeidet foregår på basis av beslutningsprosesser som er åpne for alle interesserte parter. Standarden er publisert og dokumentasjonen er tilgjengelig, enten gratis eller til en ubetydelig avgift. Det må være tillatt for alle å kopiere, distribuere og bruke standarden gratis eller for en ubetydelig avgift. Den intellektuelle rettighet knyttet til standarden (eks. patenter) er gjort ugjenkallelig tilgjengelig, uten royalty. Det er ingen forbehold om gjenbruk av standarden.

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

Målgruppe

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

  • Kapittel 1 til 5 er rettet mot faglig personell

  • Kapittel 6 til 8 (vedlegg) er rettet mot teknisk personell

Dokumentstruktur

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

Ikrafttredelse

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

1. Endringslogg

1.1. Konsekvenser av implementinger av denne versjonen

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

1.1.1. Registrering i ELMA

Alle som er registrert i ELMA for mottak av EHF Ordreprosess 1.0, vil kunne motta 1.0.13 uten endringer i ELMA.

1.2. Versjon 1.x

Versjon 1.0.13 (10.12.2019)

Sak Beskrivelse Type

-

Oppdaterte lenker til Github.

Guide

Versjon 1.0.12 (27.02.2019)

Sak Beskrivelse Type

-

Feilretting i syntaks har medført oppdaterte grunnleggende valideringsregler.

Syntaks

Valideringsregler som er ventet å trigge feil i neste release: Alle grunnleggende valideringsregler (EHF-TXX-BXXXXX).

Versjon 1.0.11 (15.11.2018)

Sak Beskrivelse Type

-

Flyttet eksempelfilene inn i en eksempelfil-pakke. Vedlegget er oppdatert med ny lenke.

Guide

-

Bytte ut utlisting av valideringsregler med lenker til alle relevante valideringsregler.

Guide

-

Legge til "grunnleggende" valideringsregler som er automatisk generert basert på syntaks. Reglene er identifisert med 'EHF-T01-BXXXXX' for ordre og 'EHF-T76-BXXXXX' for ordrerespons hvor 'XXXXX' er et løpenummer.

Validator

Valideringsregler som er ventet å trigge feil i neste release: Alle grunnleggende valideringsregler (EHF-TXX-BXXXXX).

Versjon 1.0.10 (12.09.2018)

Sak Beskrivelse Type

#267

Legge til et manglende ord i "Profiler og meldinger"-seksjonen.

Guide

Versjon 1.0.9 (15.11.2017)

Sak Beskrivelse Type

#230

Oppdatere regel EHF-COMMON-R011 (F) til å trigge feil.

Validator

#229

Benytte PEPPOL BIS sin Schematron som kilde i prosjetet for å forenkle vedlikehold og økt transparens.

Validator

#233

Oppdatert kapittel om validering så det reflerterer bruk av EHF Common.

Guide

#245

Legge til informasjon om nye MVA-kategorier tilgjengelig i neste release.

Guide

Versjon 1.0.8 (14.09.2017)

Sak Beskrivelse Type

#215

Fikse kontekst for en del regler for å oppnå høyere kvalitet.

Validator

#222

Bytte ut en del regler med regler i EHF Common.

Validator

#222

Legge til regelen NOGOV-T01-R023 (W) og NOGOV-T01-R024 (W) for å understøtte implisitt funksjonalitet.

Validator

Valideringsregler som er ventet å trigge feil i neste release: EHF-COMMON-R011
Mapping of rules in EHF Common for EHF Order
New rule Description Old rule

Document in general

EHF-COMMON-R001 (F)

Document MUST not contain empty elements.

NOGOV-T01-R006 (F)

EHF-COMMON-R002 (F)

Document MUST not contain empty elements.

NOGOV-T01-R006 (F)

EHF-COMMON-R003 (W)

Document SHOULD not contain schema location.

New rule

EHF-COMMON-R004 (F)

Document MUST have a syntax identifier.

NOGOV-T01-R012 (F)

Validation of Norwegian organization numbers

EHF-COMMON-R010 (F)

MUST be a valid Norwegian organization number. Only numerical value allowed

NOGOV-T01-R009 (F)

EHF-COMMON-R011 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

New rule

EHF-COMMON-R012 (F)

A VAT number MUST be valid Norwegian organization number (nine numbers) followed by the letters MVA.

NOGOV-T01-R011 F

EHF-COMMON-R013 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

NOGOV-T01-R010 F

EHF-COMMON-R014 (F)

An endpoint identifier scheme MUST have the value 'NO:ORGNR'.

NOGOV-T01-R008 (F)

Validation of tax

EHF-COMMON-R020 (F)

Tax categories MUST be one of the follwoing codes: AA E H K R S Z

NOGOV-T01-R022 (F)

Formating validation

EHF-COMMON-R030 (F)

A date must be formatted YYYY-MM-DD.

NOGOV-T01-R007 (F)

Validation of other identifiers

EHF-COMMON-R040 (W)

Invalid GLN number provided.

New rule

Code lists

EHF-COMMON-R100 (W)

Attachment is not a recommended MIMEType.

NOGOV-T01-R021 (W)

Mapping of rules in EHF Common for EHF Order Response
New rule Description Old rule

Document in general

EHF-COMMON-R001 (F)

Document MUST not contain empty elements.

NOGOV-T76-R010 (F)

EHF-COMMON-R002 (F)

Document MUST not contain empty elements.

NOGOV-T76-R010 (F)

EHF-COMMON-R003 (W)

Document SHOULD not contain schema location.

New rule

EHF-COMMON-R004 (F)

Document MUST have a syntax identifier.

NOGOV-T76-R007 (F)

Validation of Norwegian organization numbers

EHF-COMMON-R010 (F)

MUST be a valid Norwegian organization number. Only numerical value allowed

NOGOV-T76-R003 (F)

EHF-COMMON-R011 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

New rule

EHF-COMMON-R012 (F)

A VAT number MUST be valid Norwegian organization number (nine numbers) followed by the letters MVA.

Ignored

EHF-COMMON-R013 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

Ignored

EHF-COMMON-R014 (F)

An endpoint identifier scheme MUST have the value 'NO:ORGNR'.

NOGOV-T76-R002 (F)

Validation of tax

EHF-COMMON-R020 (F)

Tax categories MUST be one of the follwoing codes: AA E H K R S Z

NOGOV-T76-R011 (F)

Formating validation

EHF-COMMON-R030 (F)

A date must be formatted YYYY-MM-DD.

NOGOV-T76-R001 (F)

Validation of other identifiers

EHF-COMMON-R040 (W)

Invalid GLN number provided.

New rule

Code lists

EHF-COMMON-R100 (W)

Attachment is not a recommended MIMEType.

Ignored

Versjon 1.0.7 (15.05.2017)

Sak Beskrivelse Type

#207

Oppdaterte validatorfiler for PEPPOL BIS fra OpenPEPPOL.

Validator

#196

Erstatte OP-T01-R008 med NOGOV-T01-R022 (F). Erstatte OP-T76-R008 med NOGOV-T76-R011 (F).

Validator

#203

Beskrivelse av anbrekksvarer.

Guide

#206

Oppdatere lenker i 3.6 og kodelister.

Guide

Versjon 1.0.6 Feilretting (13.12.2016)

Sak Beskrivelse Type

#192

Fjerne EHF Core for order og ordrebekreftelse.

Validator

Versjon 1.0.6 (15.11.2016)

Sak Beskrivelse Type

#166

Samkjøre kapittel 5.3 med EHF Faktura og kreditnota.

Guide

#183

Fjerne del av punkt 3 under 5.4.3.

Guide

#169

Rette mindre feil i eksempelfiler for ordre og ordrebekreftelse.

Vedlegg

#167

Rette regel NOGOV-T01-R021 (W) så den trigger.

Validator

#169

Oppdatere NOGOV-T01-R009 (F), NOGOV-T01-R010 (F) og NOGOV-T01-R011 (F) til også å kontrollere kontrollsiffer på organisasjonsnummer.

Validator

#169

Oppdatere NOGOV-T76-R003 (F) til også å kontrollere kontrollsiffer på organisasjonsnummer.

Validator

#179

Oppdaterte validatorfiler for PEPPOL BIS fra OpenPEPPOL.

Validator

#66

Legge til EHF Core for order og ordrebekreftelse.

Validator

#167

Endre autorativ kilde for valideringsregler fra XSLT til Schematron for NOGOV-T01.

Validator

#177

Endre autorativ kilde for valideringsregler fra XSLT til Schematron for NOGOV-T76.

Validator

Versjon 1.0.5 (15.09.2016)

Sak Beskrivelse Type

#149

Konvertere guiden til Asciidoctor-format.

  • Justere kapittel 1 så det er mer likt andre guider.

  • Justere kapittel 3 så det er mer likt andre guider.

  • Flytte 6.1.1-8 til 6.1-8, flytte 6.2 til 6.9.

  • Fjerne kapittel 7 til fordel for GEFEG-visning tilgjengelig på VEFA.

  • Flytte kapittel 8 til kapittel 7.

  • Flytte kapittel 9 til kapittel 8.

  • Presentasjoner og illustrasjoner er endret grunnet nytt format.

Guide

Versjon 1.0.4 (23.05.2016)

Validator endringer:
  • Korrigering av reglene BII2-T01-R011 og R017

Forfatter:
  • Siw Meckelborg, Edisys Consulting AS

Versjon 1.0.3 (01.09.2015)

Validator endringer:
  • Nye valideringsartefakter fra PEPPOL og BII, oppgradering til XSLT/xPath 2.0

  • Tomme elementer vil medføre feilmelding, ikke advarsel som tidligere, gjelder regel NOGOV-T01-R006 og NOGOV-T76-R010.

Forfatter:
  • Siw Meckelborg, Edisys Consulting AS

Versjon 1.0.2 (03.03.2015)

Validator endringer:
  • Validering av alle påkrevde og anbefalte felt.

  • Validering av ulike datatyper (organisasjons-nummer, dato o.l)

  • Validering av at EndpointID kun kan være organisasjonsnummer.

Editorielle endringer:
  • Lagt til regel ID i meldingstabellen

  • Tydeliggjøring i kapittel 2.1

  • Tydeliggjøring av avhengige felt (D)

Forfatter:
  • Siw Meckelborg, Edisys Consulting AS

Versjon 1.0.1 (02.09.2014)

Endringer:
  • Endret krav og feiltype for DocumentCurrencyCode i kapittel 8

  • Endret kodeliste, vedlegg 3

  • Beskrevet bruk av kode ZZZ for PartyID i kapittel 6.1.1

  • Lagt til nytt kapittel 3.3

  • Lagt til regler for currencyID, mimeCode, Endpoint Identifier scheme og Party identifier scheme.

  • Lagt til regel for å sikre korrekt bruk av ProfileID

Forfatter:
  • Edisys Consulting AS

Versjon 1.0 (25.09.2013)

Godkjent

Forfatter:
  • Edisys Consulting

2. Elektronisk HandelsFormat (EHF)

2.1. Om EHF

EHF er en forkortelse for Elektronisk handelsformat.

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

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

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

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

EHF forvaltes og vedlikeholdes av Difi.

2.2. Konsistent informasjonsinnhold

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

2.3. Tomme elementer

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

Bruk av tomme elementer er, som forklart over, ikke tillatt i EHF.

2.4. Meldingstransport

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

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

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

2.5. Profiler og meldinger

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

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

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

Profil Dokumenttyper

Kun faktura (bii04)

Faktura

Kun kreditnota (biixx)

Kreditnota

Faktura og kreditnota (bii05)

Faktura, Kreditnota

Faktura, kreditnota og purring (biixy)

Faktura, Kreditnota, Purring

Ordre og faktura (bii06)

Ordre, Ordrebekreftelse, Faktura, Kreditnota

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

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

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

<cbc:CustomizationID>urn:www.cenbii.eu:transaction:biitrns10:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0:extended:urn:www.difi.no:ehf:faktura:ver2.0</cbc:CustomizationID>

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

<cbc:CustomizationID>urn:www.cenbii.eu:transaction:biitrns10:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0</cbc:CustomizationID>
Det presiseres at dersom begge aktørene er hjemmehørende i Norge, skal EHF customizationID benyttes. PEPPOL BIS bør kun benyttes dersom en av partene er utenlandske.

2.6. Bruk av samhandlingsavtaler

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

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

2.7. Versjonshåndtering

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

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

Hovedversjon

En ny hovedversjon vil bli varslet minimum fem måneder før denne publiseres. Etter at den nye hovedversjonen er publisert vil det være en implementasjonstid på minimum tolv måneder før denne vil bli obligatorisk.

Difi ønsker å forankre alle hovedversjoner i forskrift om IT standarder i offentlig sektor.

Underversjon

En ny underversjon vil varsles minimum tre måneder før publiseringsdato og skal være obligatorisk i bruk etter 5 måneder.

Alle underversjoner skal være bakoverkompatible. To måneder etter at den nye underversjonen er obligatorisk vil all støtte for den tidligere versjonen (validator og veiledere) bli fjernet.

Revisjon

En revisjon er i prinsippet en feilretting av siste underversjon. Denne vil kun bli varslet ved publisering og anbefales implementert så raskt som mulig.

3. Definisjoner

Faktura

Faktura er et dokument som regnskapsmessig stadfester et salg mellom en selger og en kjøper. Fakturaen utstedes av selgeren og kjøperen får i oppdrag å betale denne

Katalog

Katalog er et dokument som brukes for å beskrive en vare eller tjenestes egenskaper.

Kreditnota

En kreditnota er et dokument som opphever hele eller deler av en faktura som allerede er sendt. Kreditnota skal ha en tydelig henvisning til hvilken faktura den gjelder for.

Ordre

Ordre er et dokument som brukes for å bestille en vare eller tjeneste.

Ordrebekreftelse

Ordrebekreftelse er et dokument som brukes for enten å bekrefte eller avvise en ordre. En ordrebekreftelse kan være på hodenivå eller linjenivå.

Leverandør

En person eller et firma som leverer en vare eller en tjeneste på egne eller andres vegne.

Selger

Person eller organisasjon som har til oppgave på egne eller andres vegne å slutte en avtale eller kontrakt om overdragelse av et produkt, en vare eller tjeneste mot et avtalt vederlag til en kjøper.

Kunde

Person eller organisasjon som overtar råderett over en vare eller tjeneste mot betaling, for en bestemt pris.

Kjøper

Person eller organisasjon som kjøper en vare eller en tjeneste på egne eller på andres vegne. I Prosjektveiviseren er det brukt begrepet Bestiller.

Rekvirent

Person eller organisasjon som initierer et ønske om en bestilling. Kan også angis som endelig sluttmottaker.

UBL

UBL (Universal Business Language) er et sett av XML-formater (XML Schema) for elektronisk utveksling handelsdokumenter som bl.a. katalog, ordre og faktura. Gjeldende versjon som brukes for ordre er 2.1.

BII2

BII (Business Interoperability Interfaces) er et subset av UBL med de dokumenter og det innhold som kreves for elektronisk samhandling i offentlig sektor i Europa. Omfatter ikke egne XML Schema.
BII2 er en videreføring av BII1.

Schematron validering

Kontroll av en melding mot et sett av definerte forretningsregler. Disse kommer i tillegg til syntaks som sjekkes mot XML Schema.

4. Prinsipper og forutsetninger

Dette kapitlet beskriver de prinsipper og forutsetninger som ligger til grunn for bruk av EHF ordreprosess. Dette er i hovedsak basert på tilsvarende beskrivelser i profil CEN BII2 28 Ordering.

4.1. Generelt om ordremeldingene

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

4.2. Funksjoner og roller

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

Funksjoner og roller

4.3. Profiler og meldinger

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

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

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

CustomizationID er en streng uten mellomrom. Under er det lagt til mellomrom i CustomizationID for å lette lesbarheten. Husk å fjerne mellomrom før bruk.

4.3.1. Profil 28 - Ordre

ProfileID

urn:www.cenbii.eu:profile:bii28:ver2.0

Type CustomizationID Rolle

Ordre

urn:www.cenbii.eu:transaction:biitrns001:ver2.0 :extended:urn:www.peppol.eu:bis:peppol28a:ver1.0 :extended:urn:www.difi.no:ehf:ordre:ver1.0

Leverandør

Ordrebekreftelse

urn:www.cenbii.eu:transaction:biitrns076:ver2.0 :extended:urn:www.peppol.eu:bis:peppol28a:ver1.0 :extended:urn:www.difi.no:ehf:ordrebekreftelse:ver1.0

Oppdragsgiver

4.4. Ordreprosess

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

Ordreprosessen kan beskrives som følgende arbeidsflyt:

  1. En kjøper sender en ordre til selger med ønske om levering av varer eller tjenester. Ordren kan inneholde artikler (varer eller tjenester) med artikkelnummer, eller artikler med fritekst-beskrivelse.

  2. Ordren kan referere til en kjøpsavtale eller en rammeavtale hvor tilhørende kjøpsbetingelsene gjøres gjeldene, alternativt så gjelder betingelsene som kjøper har spesifisert i ordren.

  3. Selger mottar ordren og kontrollerer om denne er på riktig format og er korrekt utfylt. Alternativt må selger informere kjøper om at ordren ikke kan prosesseres.

  4. Selger prosesserer ordren og sender en ordrebekreftelse til kjøper med resultatet av denne.

    1. Ordren kan aksepteres i sin helhet med en positiv ordrebekreftelse og en avtale om leveranse anses som inngått.

    2. Ordren kan aksepteres med endringer på en eller flere ordrelinje. Håndtering av denne type situasjoner bør være beskrevet i Kjøpsavtalen eller Samhandlingsavtalen men kan også kreve en manuell tilbakemelding fra kjøper til selger om videre håndtering.

    3. Ordren kan avvises i sin helhet med en negativ ordrebekreftelse som innebærer at det ikke inngås noen avtale om leveranse av varer eller tjenester.

  5. I tilfeller hvor kjøper har mottatt en negativ ordrebekreftelse (c), så kan det startes en ny ordreprosess hvor årsaken til avvisningen blir hensyntatt.

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

Ordreprosses

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

5. Beskrivelse av utvalgte deler

Det fins ingen formelle krav til innholdet i en ordre i forhold til norsk regelverk. Innholdskravene er derfor basert på gjeldende praksis og det som er angitt i UBL 2.1 og i profil CEN BII28 Ordering. I tillegg vil krav til innhold verifiseres mot det som brukes i utvalgte deler av privat sektor. Videre er innholdskravet også sett i sammenheng med innhold i EHF Faktura og EHF Katalog.

Kapittel 6.1 og 6.2 beskriver utvalgte deler av EHF Ordre og Ordrebekreftelse. Det som er beskrevet er innhold som er påkrevd eller som er spesielt viktige i forhold til bruk i det norske markedet. En del av innholdet i kapittel 6.1 vil være relevant for begge meldingene. I kapittel 6.2 er det kun med elementer som gjelder for Ordrebekreftelse.

5.1. Roller og aktører

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

Scheme ID Scheme Agency

GLN

GS1

NO:ORGNR

Enhetsregisteret ved Brønnøysundregisterne

NO:VAT

Enhetsregisteret ved Brønnøysundregisterne

ZZZ

Unknown issuer agency

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

Kjøper (BuyerCustomerParty)

Den juridiske person eller organisasjonen som kjøper en vare eller tjeneste. Kjøper er obligatorisk informasjon i EHF

Rekvirent (OriginatorCustomerParty)

Den person som har identifisert et behov og som ordren er generert på vegne av. Dette vil i de fleste tilfeller være sluttbruker eller endelig sluttmottaker.

Fakturamottaker (AccountingCustomerParty)

Den juridiske person eller organisasjon som skal motta fakturaen som skal sendes på grunnlag av ordren. Fakturamottaker er valgfri informasjon i EHF. Dersom denne ikke er oppgitt er fakturamottaker samme som kjøper.

Selger (SellerSupplierParty)

Den juridiske person eller organisasjon som mottar en bestilling. Selger er obligatorisk informasjon i EHF

Eksempel på utfylling av leverandørinformasjon på hodenivå i en EHF ordremelding.
<cac:SellerSupplierParty>
        <cac:Party>
                <cbc:EndpointID schemeID="NO:ORGNR">938752655</cbc:EndpointID>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="ZZZ">12345</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>Medical</cbc:Name>
                </cac:PartyName>
                <cac:PostalAddress>
                        <cbc:CityName>Oslo</cbc:CityName>
                        <cbc:PostalZone>0585</cbc:PostalZone>
                        <cac:Country>
                                <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
                        </cac:Country>
                </cac:PostalAddress>
                <cac:Contact>
                        <cbc:Name>Nils Nilsen</cbc:Name>
                        <cbc:Telephone>22150510</cbc:Telephone>
                        <cbc:ElectronicMail>post@medical.no</cbc:ElectronicMail>
                </cac:Contact>
        </cac:Party>
</cac:SellerSupplierParty>
Eksempel på utfylling av kjøperinformasjon på hodenivå i en EHF ordremelding.
<cac:BuyerCustomerParty>
        <cac:Party>
                <cbc:EndpointID schemeID="NO:ORGNR">931186755</cbc:EndpointID>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="GLN">7080000985134</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>Helseforetak</cbc:Name>
                </cac:PartyName>
                <cac:PostalAddress>
                        <cbc:StreetName>Sinsenveien 40</cbc:StreetName>
                        <cbc:CityName>Oslo</cbc:CityName>
                        <cbc:PostalZone>0501</cbc:PostalZone>
                        <cac:Country>
                                <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
                        </cac:Country>
                </cac:PostalAddress>
                <cac:PartyTaxScheme>
                        <cbc:CompanyID>9311867455MVA</cbc:CompanyID>
                        <cac:TaxScheme>
                                <cbc:ID>VAT</cbc:ID>
                        </cac:TaxScheme>
                </cac:PartyTaxScheme>
                <cac:PartyLegalEntity>
                        <cbc:RegistrationName>Helseforetak AS</cbc:RegistrationName>
                        <cbc:CompanyID schemeID="NO:ORGNR">931186755</cbc:CompanyID>
                        <cac:RegistrationAddress>
                                <cbc:CityName>Oslo</cbc:CityName>
                                <cac:Country>
                                <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
                                </cac:Country>
                        </cac:RegistrationAddress>
                </cac:PartyLegalEntity>
                <cac:Contact>
                        <cbc:ID>3150bdn</cbc:ID> (1)
                        <cbc:Name>Ole Olsen</cbc:Name>
                        <cbc:Telephone>23055000</cbc:Telephone>
                        <cbc:ElectronicMail>post@helseforetak.no</cbc:ElectronicMail>
                </cac:Contact>
        </cac:Party>
</cac:BuyerCustomerParty>
1 Contact/ID er anbefalt å fylle ut siden dette feltet er påkrevd i EHF Faktura. Dette er en utvidelse i forhold til CEN BII.

5.2. Produktidentifisering

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

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

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

Eksempel på utfylling i en EHF ordremelding hvor man benytter både selgers ID og standard ID (GTIN)
<cac:Item
  ...
  <cac:SellersItemIdentification>
    <cbc:ID>541706</cbc:ID>
  </cac:SellersItemIdentification>
  <cac:StandardItemIdentification>
    <cbc:ID schemeID ="GTIN">05449000035882</cbc:ID>
  </cac:StandardItemIdentification>
  ...
</cac:Item>

5.3. Produktnavn og -beskrivelse

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

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

Eksempel på EHF Ordre
<cac:Item>
  <cbc:Name>TUNFISK I VANN 6 BX Á 1880 MILLIGRAM</cbc:Name>
  ...
</cac:Item>

5.4. Kvantum og bestillingsmengder

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

Følgende kvantum er mulig å angi:

Element Beskrivelse

Priskvantum (BaseQuantity)

Kvantum som en pris gjelder for

Ordrekvantum (Quantity)

Angir det antall eller volum som en ordrelinje omfatter

Eksempel på en EHF ordrelinje med kvantum 120 liter (cbc:Quantity) og hvor prisen er angitt per liter (BaseQuantity)
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="LTR" unitCodeListID="UNECERec20”>120</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="NOK">6000</cbc:LineExtensionAmount>
<cbc:TotalTaxAmount currencyID="NOK">1500</cbc:TotalTaxAmount>
<cbc:PartialDeliveryIndicator>false</cbc:PartialDeliveryIndicator>
<cbc:AccountingCostCode>ProjectID123</cbc:AccountingCostCode>
<cac:Price>
         <cbc:PriceAmount currencyID="NOK">50</cbc:PriceAmount>
        <cbc:BaseQuantity unitCode="LTR" unitCodeListID="UNECERec20”>1</cbc:BaseQuantity>
</cac:Price>

5.5. Priser

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

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

  • Nettopris etter rabatt og tillegg. Nettopris betyr i denne sammenheng pris uten MVA.

  • Rabatter og tillegg.

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

Eksempel på utfylling av prisinformasjon i EHF ordre (Nettopris)
<cac:Price>
        <cbc:PriceAmount currencyID="NOK">50</cbc:PriceAmount> (1)
        <cbc:BaseQuantity unitCode="LTR" unitCodeListID="UNECERec20”>1</cbc:BaseQuantity>
</cac:Price>
1 Attributt "currencyID" viser valuta med kode NOK.

5.6. Vedleggshåndtering

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

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

Andre anbefalinger:

Koding

Base64

Dokumentformat

MIME typer anbefales:

  • Pdf – applikasjon / pdf

  • TXT – tekst / txt

  • GIF – image / gif

  • TIFF – image / tiff

  • JPEG, JPG – image / jpeg

  • PNG – image / png

Størrelse

5MB

Beskrivelse av vedlegg

Det anbefales å gi en god beskrivelse av hva slag vedlegg det gjelder. Kodelisten DocumentTypeCode anbefales brukt og beskrivelsen gjøres i feltet: ubl:Order/`cac:AdditionalDocumentReference/cac:DocumentReference/cbc:DocumentType.
Elementet benyttes kun til å gi en beskrivelse av vedleggets innhold eller type dokument/vedlegg.

Eksempel på innebygd vedlegg i en EHF ordremelding.
<cac:AdditionalDocumentReference>
  <cbc:ID>Ordredetaljer.pdf</cbc:ID>
  <cbc:DocumentType>Orderdetaljer</cbc:DocumentType>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="applikasjon/pdf">PD94bWwgdm… +PC9PcmRlcj4=</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

5.7. Miljømerking, sosialt ansvar og økologisk

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

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

Eksempel på utfylling av Miljømerking i EHF Ordre
<cac:AdditionalItemProperty>
  <cbc:Name>EnvironmentMarking</cbc:Name>
        <cbc:Value>FSC</cbc:Value>
</cac:AdditionalItemProperty>

5.8. Tilleggsegenskaper

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

Eksempler på egenskaper som kan spesifiseres
  • Farge

  • Vekt

Eksempel på angivelse av tilleggsegenskaper i en EHF ordremelding
<cac:Item>
  <cbc:Description>God pensel for panel</cbc:Description>
  <cbc:Name>Pensel 20 mm</cbc:Name>
  <cac:SellersItemIdentification>
    <cbc:ID>SItemNo011</cbc:ID>
  </cac:SellersItemIdentification>
  ...
  <cac:AdditionalItemProperty>
    <cbc:Name>Hair color</cbc:Name>
    <cbc:Value>Black</cbc:Value>
  </cac:AdditionalItemProperty>
  <cac:AdditionalItemProperty>
    <cbc:Name>Width</cbc:Name>
    <cbc:Value>20mm</cbc:Value>
  </cac:AdditionalItemProperty>
</cac:Item>

5.9. Anbrekkskode

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

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

Eksempel på angivelse av anbrekkskode
  <cac:AdditionalItemProperty>
    <cbc:Name>DU</cbc:Name>
    <cbc:Value>Anbrekk</cbc:Value>
  </cac:AdditionalItemProperty>
</cac:Item>

5.10. EHF Ordrebekreftelse

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

  • Ordrebekreftelsen må referere til den opprinnelige bestillingen

  • Selger kan akseptere eller avvise ordren i sin helhet

  • Ordrebekreftelsen kan inneholde en forklaring på en avvisning

  • Selger kan akseptere eller avvise ordrelinjer

  • Dersom selger aksepterer/avviser på linjenivå må alle linjer returneres i ordrebekreftelsen

  • Linjene i ordrebekreftelsen må referere til tilsvarende linje i ordren

  • Referanse mellom linjer i ordrebekreftelsen og ordren må være 1 til 1

  • Følgende felt er mulig å endre i ordrebekreftelsen. Hva som faktisk skal kunne endres må avtales i den merkantile avtalen eller samhandlingsavtalen.

    • Kvantum

    • Leveringstidspunkt

    • Erstatningsvare

    • Pris

  • Ved avvisning eller endring må ordrebekreftelsen inneholde kontaktinformasjon til selger

5.10.1. Responskode

Responskoden angir selgers evne til å etterkomme bestillingen og må angis enten på hode- eller linjenivå i ordrebekreftelsen. Responskodene som benyttes er basert på tilsvarende koder fra Edifact.

Retningslinjer for utfylling
  • Responskode må være utfylt både på hodenivå og linjenivå.

  • Dersom responskode mangler vil hele ordrebekreftelsen bli avvist.

  • Responskode kan ha 3 ulike verdier: 27 (Rejected) 29 (Accepted), og 30 (Accepted with amendment/change).

Tabell 1. Responskode utfylt på hodenivå
Responskode Behandling

27

Hele ordren er avvist. Linjer kan sendes, men informasjon på hodenivå vil overstyre linjeinformasjon.

29

Hele ordren er akseptert. Linjer kan sendes, men informasjon på hodenivå vil overstyre linjeinformasjon.

30

Ordren er akseptert med endringer. Alle linjer må sendes.

Eksempel på angivelse av reponskode på hodenivå i en EHF ordrebekreftelse:
<cbc:ID>34</cbc:ID>
<cbc:IssueDate>2012-10-01</cbc:IssueDate>
<cbc:IssueTime>12:30:00</cbc:IssueTime>
<cbc:OrderResponseCode listID="UNCL1225">30</cbc:OrderResponseCode>
<cbc:Note>Changes in 2 orderlines</cbc:Note>
Tabell 2. Responskode utfylt på linjenivå
Responskode Behandling

27

Ordrelinjen er avvist i sin helhet.

29

Ordrelinjen er akseptert uendret.

30

Ordrelinjen er akseptert med endringer.

Eksempel på angivelse av responskode på linjenivå i en EHF ordrebekreftelse. Avvisning av en ordrelinje som er avvist
<cac:OrderLine>
        <cac:LineItem>
                <cbc:ID>1</cbc:ID>
                <cbc:LineStatusCode listID="UNCL1225">27</cbc:LineStatusCode>
                <cbc:Quantity unitCode="EA" unitCodeListID="UNECERec20”>0</cbc:Quantity>
                <cac:Item/>
        </cac:LineItem>
</cac:OrderLine>

5.10.2. Referanse til bestillingen

Referanse til opprinnelig bestilling gjøres på hodenivå og eventuelt på linjenivå dersom det sendes linjer.

Eksempel på angivelse av ordrereferanse på hodenivå i en EHF ordrebekreftelse
<cbc:ID>12</cbc:ID>
<cbc:IssueDate>2012-10-01</cbc:IssueDate>
<cbc:IssueTime>12:30:00</cbc:IssueTime>
<cbc:OrderResponseCode listID="UNCL1225">30</cbc:OrderResponseCode>
<cbc:Note>Changes in 1 orderline</cbc:Note>
<cac:OrderReference>
        <cbc:ID>34</cbc:ID>
</cac:OrderReference>
Eksempel på angivelse av ordrereferanse på linjenivå i en EHF ordrebekreftelse
<cac:OrderLine>
        <cac:LineItem>
                <cbc:ID>2</cbc:ID>
                <cbc:LineStatusCode listID="UNCL1225">29</cbc:LineStatusCode>
        </cac:LineItem>
        <cac:OrderLineReference>
                <cbc:LineID>2</cbc:LineID>
        </cac:OrderLineReference>
</cac:OrderLine>

5.10.3. Endringer på ordren

Når selger aksepterer en ordrelinje med endringer skal Responskode «Accepted with change» angis både på hode- og linjenivå. I tillegg må aktuelt element som endres og ny verdi sendes.

Det kan gjøres endringer på følgende elementer:

  • Kvantum

  • Leveringstidspunkt (kan endres både på hode- og linjenivå)

  • Pris

  • Erstatningsvare

Eksempel på endring av kvantum i en EHF Ordrebekreftelse
<cac:OrderLine>
        <cac:LineItem>
                <cbc:ID>1</cbc:ID>
                <cbc:LineStatusCode listID="UNCL1225">30</cbc:LineStatusCode>
                <cbc:Quantity unitCode="EA" unitCodeListID="UNECERec20">18</cbc:Quantity>
                <cac:Item/>
        </cac:LineItem>
</cac:OrderLine>
Eksempel på erstatningsvare i en EHF Ordrebekreftelse
<cac:OrderLine>
        <cac:LineItem>
                <cbc:ID>2</cbc:ID>
                <cbc:LineStatusCode listID=" UNCL1225">30</cbc:LineStatusCode>
                <cac:Item>
                        <cbc:Name>Wet tissues</cbc:Name>
                        <cac:SellersItemIdentification>
                                <cbc:ID>SItemNo011</cbc:ID>
                        </cac:SellersItemIdentification>
                </cac:Item>
        </cac:LineItem>
        <cac:SellerSubstitutedLineItem>
                <cbc:ID>2</cbc:ID>
                <cac:Item>
                        <cbc:Name>Wet tissues</cbc:Name>
                        <cac:SellersItemIdentification>
                                <cbc:ID>SItemNo012</cbc:ID>
                        </cac:SellersItemIdentification>
                        <cac:StandardItemIdentification>
                                <cbc:ID schemeID="GTIN">05449000035882</cbc:ID>
                        </cac:StandardItemIdentification>
                        <cac:CommodityClassification>
        <cbc:ItemClassificationCode listID="UNSPSC">675634</cbc:ItemClassificationCode>
                        </cac:CommodityClassification>
                </cac:Item>
        </cac:SellerSubstitutedLineItem>
</cac:OrderLine>

6. Validering

For å oppnå optimal fleksibilitet blir EHF dokumenter validert på ulike nivåer og med ulikt fokus. Pyramiden under illustrerer valideringshierarkiet:

Valideringspyramide

6.1. Valideringsprinsipper

Nivåer i valideringsprosessen:

  1. Validering av syntaks mot UBL XML Schema, for eksempel:

    • Tagnavn og eventuelle attributter må være korrekt skrevet og i riktig rekkefølge i henhold til UBL.

    • Alle obligatoriske tagnavn ihht UBL må være inkludert.

    • Innholdet i et element må ha lovlig verdi i henhold til type definisjon.

  2. Validering mot CEN BII for å sikre at meldingen er i henhold til internasjonale krav, for eksempel:

    • Lovlige koder for valuta, land, avgifter etc.

    • Logiske sammenhenger mellom informasjonselementer som at startdato må komme før sluttdato, subtotaler må summeres til korrekt totalsum, test på at faktorer som skal multipliseres får korrekt produkt etc.

  3. Validering mot PEPPOL (EU) regelverk

  4. Validering mot EHF Common som inneholder regler felles for alle dokumenttyper som inngår i EHF.

  5. Validering mot EHF regler og norsk lovverk, for eksempel:

    • Organisasjonsnummer må fylles ut for selger.

    • Deres referanse må være utfylt.

    • Adresse, postnr og sted må være utfylt for kjøper.

6.2. Dynamisk validering

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

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

6.3. Valideringsregler per ProfileID og CustomizationID

6.5. Valideringstjenesten

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

7. Vedlegg

Vedlegg A: Strukturtabell

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

Vedlegg B: Meldingstabell

Vedlagt er komplett meldingstabell for aktuelle meldinger.

Vedlegg C: Kodelister

Gjeldende kodelister for EHF:

Vedlegg D: UBL 2.1

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

Ved validering vil syntaksvalidering gjøres mot aktuelle schema.

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

Vedlegg E: Schematron

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

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

Vedlegg F: Eksempelfiler

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