Online OIOUBL Dokumentation


Introduktion til Bekendtgørelse

Bekendtgørelsen om OIOUBL elektronisk regning er trådt i kraft mandag den 12. april 2010

Bekendtgørelsen kan findes på Lovtidende og kan findes på nedenstående link:

Bekendtgørelsen om OIOUBL elektronisk regning

Bekendtgørelsen om OIOUBL omfatter i alt fire OIOUBL dokumenter, som vedrører fakturering:

- Faktura

- Kreditnota

- Rykker

- Forretningskvittering (Application Response).

Der er to profiler, som de offentlige myndigheder skal understøtte i henhold til bekendtgørelsen: Procurement-BilSim og NES Profile 5 Basic Billing.

NES Profile 5 BasicBilling profilen består af dokumenterne Faktura og Kreditnota.

Det er den profil, der kommer tættest på det nuværende format for OIOXML elektronisk regning.

NES Profile 5, skal bruges i de tilfælde, hvor den leverandør som sender en faktura/kreditnota ikke har teknisk mulighed for at modtage en forretningskvittering.

Procurement-BilSim Profilen består af dokumenterne Faktura, Kreditnota, Rykker og Forretningskvittering. Såfremt både den offentlige myndighed og leverandøren understøtter Procurement-BilSim, skal denne anvendes.

Download Profilbeskrivelse over profiler i bekendtgørelsen

Introduktion til OIOUBL

Dette er en introduktion til OIOUBL version 2.02 frigivet af IT- og Telestyrelsen september 2009.

En samlet pakke over alle dokumenter, guidelines, kodelister etc. kan hentes via nedenstående link:

Download alle OIOUBL 2.02 dokumenter i PDF version

Bemærk at scenariebeskrivelser og scenarieeksempler vil blive opdateret i løbet af 1. halvår af 2012.

OIOUBL indeholder standarder for alle væsentlige forretningsdokumenter til understøttelse af handelsprocessen fra katalog til faktura. Pakken indeholder både vejledende og normative beskrivelser, samt eksempler på brug af forretningsdokumenterne. OIOUBL pakken indeholder de forretningsdokumenter som understøtter den såkaldt basale indkøbsproces, som alle, også de mindre virksomheder og små offentlige institutioner, forventes at kunne understøtte (se også afsnittet om Profiler). Det drejer sig om følgende 15 forretningsdokumenter:

  • Katalogforespørgsel
  • Katalog
  • Sletning af katalog
  • Opdatering af katalogelement
  • Opdatering af katalogpriser
  • Ordre
  • Simpel Ordrebekræftelse
  • Ordreannullering
  • Faktura
  • Kreditnota
  • Rykker
  • Applikationsmeddelelse

Herudover indeholder pakken også beskrivelser af en række ekstra forretningsdokumenter til understøttelse af mere avancerede ordreprocesser: -Ordreændring -Ordrebekræftelse -Kontoudtog.

Generelt om OIOUBL

OIOUBL er en dansk tilpasning af den internationale standard UBL 2.0 fra standardiseringsorganet OASIS (Organization for the Advancement of Structured Information Standards) til danske forretningskrav. De dokumenter, der er medtaget i OIOUBL, og som udgør en delmængde af UBL 2.0 dokumenterne, er udvalgt i samråd med Sektorstandardiseringsudvalget for e-handel. De umiddelbare fordele ved brugen af OIOUBL dokumenterne er standardiseringen af forretningsdokumenterne til forskellig brug. UBL 2.0 standarden er en fleksibel standard, der understøtter de fleste forretningsmæssige behov, og eftersom det er en international standard, kan dokumenterne anvendes på tværs af landegrænser. Fordelene ved at anvende OIOUBL er muligheden for at opbygge fuldt automatiserede indkøbsflow, hvor de elektroniske dokumenter kan valideres og matches automatisk, og dermed medvirke til besparelser på de medarbejderressourcer, der normalt anvendes til manuel behandling af forretningsdokumenter.

Relationen mellem OIOUBL og UBL 2.0

OIOUBL er som nævnt en delmængde af UBL 2.0, hvilket betyder, at UBL 2.0 indeholder en lang række forretningsdokumenter udover dem, som indgår i OIOUBL, fx. på transportområdet. Disse forretningsdokumenter er fuldt kompatible med OIOUBL dokumenterne og kan bruges i sammenhæng med disse. Der findes dog ikke danske vejledninger og guidelines til disse dokumenter. Specifikationerne i OIOUBL er baseret direkte på skemaerne i UBL 2.0. Der er med andre ord ikke genereret specifikke skemaer til OIOUBL. Det skal i den forbindelse bemærkes, at der i OIOUBL af forretningsmæssige årsager er ekskluderet enkelte elementer fra UBL 2.0 skemaerne. Det er elementer, som ikke er vurderet anvendelige i Danmark enten pga. specifik dansk lovgivning, eller fordi de ikke giver mening at anvende i en dansk kontekst. De udeladte elementer vil således ikke være at finde i beskrivelserne, og hvis de pågældende felter tages i anvendelsen, vil de ikke kunne passere den validator, som IT- og Telestyrelsen offentliggør i tilknytning til skemaerne.

OIOUBL og OIOXML elektronisk regning

Fakturadokumentet i OIOUBL er en videreudbygning af det format for en elektronisk regning, som indgår i Bekendtgørelsen om information i OIOXML elektronisk regning til brug for elektronisk afregning med offentlige myndigheder. OIOUBL er nemlig baseret på UBL 2.0, som er en nyere version af den standard, som ligger bag OIOXML elektronisk regning, nemlig UBL 0.7. Fakturaen i OIOUBL giver de samme anvendelsesmuligheder som OIOXML elektronisk regning samt en hel del flere. Der vil fra IT- og Telestyrelsen blive udviklet værktøjer til mapping mellem UBL version 0.7 og 2.0, præcis som der i dag findes værktøjer til mapping mellem UBL version 0.7 og 1.0.

OIOUBL og North European Subset

OIOUBL er som nævnt koordineret med de øvrige nordiske lande samt Storbritannien i et samarbejde kaldet ”North European Subset” (NES),som er et initiativ, hvor de involverede lande samarbejder omkring indhold og brug af elektroniske forretningsdokumenter, baseret på UBL 2.0 standarden. OIOUBL er udformet, så den kan fungere i samspil med de guidelines og profiler, som forefindes i North European Subset. Der er enkelte forskelle mellem de to implementeringer, som fremgår af listen over forskelle mellem NES og OIOUBL, se reference I03. For mere information om NES generelt, se www.nesubl.eu.

Indhold i OIOUBL-pakken

OIOUBL pakken indeholder en række forskellige elementer som beskrives i det følgende. Materialet findes i en dansk og en engelsk version.

Det fælles klassebibliotek

Rygraden i OIOUBL er guidelinen for det fælles Klassebibliotek (Ref G30). Biblioteket indeholder generelle beskrivelser af samtlige af de klasser, som indgår i de forskellige forretningsdokumenter. Filosofien bag biblioteket er ønsket om så høj grad af genanvendelse som muligt af de forskellige komponenter. De typer, som informationselementerne i hver klasse refererer til, er beskrevet i guidelinen for datatyper (ref. G29). Klasser, der anvendes ens i alle forretningsdokumenterne, er alene beskrevet i det fælles klassebibliotek (Ref. G30).

Dokumentguidelines

For hvert enkelt af de 15 forretningsdokumenter, fra katalog til kontoudtog, er der udarbejdet en dokumentguideline, som beskriver dokumentet som en overordnet klasse, indeholdende de elementer og klasser fra klassebiblioteket (Ref G30), der indgår i den pågældende klasse. Hvis der er elementer og klasser, som anvendes anderledes end beskrevet i Klassebiblioteket, vil det være udspecificeret i den pågældende dokumentguideline.

Tværgående guidelines

Herudover findes der en række tværgående guidelines, som beskriver udvalgte klassers anvendelse på tværs af forskellige forretningsdokumenter. Årsagen til, at de pågældende klasser har fået en speciel guideline er, at de enten er komplicerede at anvende og derfor kræver en uddybende forklaring, eller at de skal bruges forskelligt i de enkelte forretningsdokumenter og de forskellige profiler, dvs. de er kontekstafhængige. I det følgende er uddybet et par af de klasser og felter, som har væsentlig betydning for forståelsen af OIOUBL.

Party

Til hvert enkelt OIOUBL dokument er der defineret to obligatoriske parter, nemlig den part der afsender dokumentet, og den der skal modtage dokumentet. Herudover kan et dokument indeholde flere andre parter, der har betydning for behandling af indholdet i dokumentet. Parterne har forskellige navne i de forskellige dokumenter. Det er et udtryk for de forskellige roller, de indtager i forretningsprocessen. F.eks. hedder kunden i en ordre ”BuyerCustomerParty” og en debitor i en faktura ”AccountingCustomerParty”. Begge parter er af typen ”CustomerParty”, idet ”Buyer” og ”Accounting” er et udtryk for rollen hos kunden. Til en part skal der angives såvel en identifikation af parten som en angivelse af den juridiske virksomhed. F.eks. kan en part anvende et EAN-nummer til identifikation og et CVR-nummer til angivelse af den juridiske enhed. På denne måde kan der administreres forskellige enheder inden for samme juridiske virksomhed.

EndpointID

EndpointID er en entydig identifikation af det sted, hvor det elektroniske dokument skal afleveres. EndpointID skal angives for de to parter, der udveksler dokumentet og kan angives for de øvrige parter, der har betydning for indholdet af dokumentet. EndpointID skal registreres i de etablerede adresseregister, således at modtageren entydigt kan bestemmes. IT -og Telestyrelsen etablerer i efteråret 2007 et fælles tværoffentligt adresseregister (UDDI), som også kan indeholde endpoints for private virksomheder. Læs mere på adressen: www.softwareborsen.dk/projekter/softwarecenter/serviceorienteret-infrastruktur.

Kodelister

Et andet væsentligt element i OIOUBL er kodelister. Kodelister bruges i udbredt grad i UBL 2.0 til at administrere en række fastdefinerede udfaldsrum inden for et givent fagområde, f.eks. valutakoder og landekoder. Målet er at opnå fuld automatisk behandling af fremsendte data og mulighed for på forhånd at lægge tjek ind i diverse IT-systemer, med henblik på kun at acceptere koder inden for de tilladte udfaldsrum og dermed mindske behovet for manuelle arbejdsgange. Såfremt der er mulighed for at angive mere end en værdi i et kode- eller ID-felt er der anvendt kodelister. Kodetyper anvendes helt specifikt til at afgrænse tilladte værdier for et element (BBIE) blandt en liste af muligheder. OIOUBL opererer med fire typer af koder: l Statiske koder, der er indlejret i standarden. l Offentlige kendte koder, der kan opdateres, f.eks. ISO 4217. l OIOUBL definerede koder, der kan opdateres, f.eks. TaxSchemeID l Bilateralt aftalte koder Til den danske OIOUBL tilpasning er der udarbejdet en række kodelister, f.eks. TaxSchemeID , som bruges til angivelse af pligtkoder i forbindelse med skatter og afgifter. I alle situationer, hvor der er defineret brug af offentligt kendte kodelister eller OIOUBL kodelister, skal listenavnet angives i forbindelse med brugen af koden. Denne definering anvendes til at skelne mellem koder, der tilhører OIOUBL standarden og bilateralt aftalte koder. I visse situationer er der givet mulighed for at anvende flere forskellige kodelister i et element. Det er f.eks. muligt i forbindelse med angivelse af identifikation af en partner og endpoints . Her kan der f.eks. angives CVR, SE, DUNS m.fl. I disse tilfælde er det defineret, hvilken forkortelse der specificerer den angivne kodeliste.

Profiler

Der lægges i OIOUBL op til anvendelsen af profiler, med det formål at sender og modtager af forretningsdokumenterne kan angive, hvilke dokumenter de kan understøtte og forventer at modtage i en given kontekst. En Profil er en overordnet beskrivelse af en eller flere sammenhørende forretningsprocesser, hvor der i hver process indgår et eller flere dokumenter. En profil fastlægger rammerne for gennemførelse af en forretningstransaktion, herunder, hvilken rolle en part (Party) indtager i forretningsprocessen hvilke dokumenter en given part skal kunne henholdsvis sende og modtage. samt hvilke processer parterne skal understøtte. Profilerne I OIOUBL er udarbejdet på grundlag af den overordnede forretningsmodel for UBL 2.0 Profilerne er udarbejdet med udgangspunkt i en logisk afgrænsning af, hvilke forretningsdokumenter der er naturligt sammenhørende, og hvilke der skal kunne understøttes på et givet niveau. Opdelingen i niveauer har taget udgangspunkt i, at den elektroniske forretningsproces skal understøtte såvel den simple forretningsproces som den mere avancerede. Der findes tre såkaldte minimumsprofiler i OIOUBL, som udgør mindstekravet for de offentlige kunder og deres leverandører, som ønsker at anvende OIOUBL. De tre profiler vedrører simpel fakturering (Procurement BillSim), et simpelt ordre til faktura flow (Procurement OrdSimR-BillSim) og basal katalogudveksling (Catalogue CatBas). Herudover er der en minimumsprofil, som den offentlige organisation skal tilbyde at understøtte, hvis deres leverandører ønsker at modtage katalogforespørgsler elektronisk (Catalogue CatSim) I den tværgående guideline for profiler (Ref. G26) findes en uddybende beskrivelse af de forskellige profiler og deres anvendelse.

Scenariebeskrivelser

Et vigtigt element i OIOUBL er scenariepakkerne. De har til formål at illustrere indkøbsprocessen set fra et forretningsperspektiv og vise, hvordan disse processer kan implementeres med brug af OIOUBL-dokumenterne. Ved udarbejdelsen af OIOUBL har erfaringen vist, at det er alt for kompliceret at udarbejde en beskrivelse af indkøbsprocessen som én samlet proces. Der findes ganske enkelt for mange mulige kombinationer i anvendelsen af dokumenterne. I stedet har løsningen været at beskrive disse muligheder i form af scenarier. Scenarierne kan ses som beskrivelser af, hvordan afsender og modtager forventes at reagere i de situationer, der beskrives i scenariet. Scenariepakkerne komplimenterer de øvrige elementer i OIOUBL pakken og er i modsætning til disse ikke normative for brugen af OIOIUBL. Som det fremgår af introduktionen til de seks scenariebeskrivelser (Ref. S01) er der udarbejdet i alt seks scenariepakker som dækker følgende områder:

  • Basale indkøbsforløb (Ref. S03)
  • Avancerede Ordrer (Ref. S02)
  • Komplekse leveringer (Ref. S05)
  • Indkøb i komplekse Organisationer (Ref. S06)
  • Komplekse betalingsprocesser (Ref. S07)
  • Udveksling af kataloger (Ref. S04)

Der er udarbejdet en række xml-eksempler til de forskellige scenariebeskrivelser og de forskellige udfaldsrum i hvert scenarie.

Download Introduktion som PDF