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 forretningsdokumenter:

Katalogforespørgse
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.

Introduktion til Bekendtgørelse

Bekendtgørelsen om OIOUBL elektronisk regning trådte i kraft 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 gamle 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.

Generelt om OIOUBL

OIOUBL er en dansk tilpasning af den internationale standard UBL 2.0/UBL2.1 fra standardiseringsorganet OASIS (Organization for the Advancement of Structured Information Standards) til danske forretningskrav. 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.1

OIOUBL er en delmængde af UBL 2.1, hvilket betyder, at UBL 2.1 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/UBL 2.1. 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 anvendelse, vil de ikke kunne passere den validator, som Digitaliseringsstyrelsen offentliggør i tilknytning til skemaerne.

OIOUBL og Peppol BIS

En række europæiske lande har sammen med EU-kommissionen udviklet en infrastruktur til udveksling af e-handelsdokumenter, som er meget lig NemHandel og går under navnet Peppol. I OpenPeppol anvender man Peppol BIS, som er en europæisk tilpasning af UBL 2.1.

I OIOUBL adopteres løbende dokumenter og profiler fra PeppolBIS. Det kan enten være dokumenter, som ikke er med i OIOUBL f.eks. ForsendelsesAdvis, eller Peppol BIS pendanter til allerede eksisterende OIOUBL dokumenter, som tages med som led i den løbende migrering mellem NemHandel og Peppol. Der adopteres direkte fra Peppol, og der udarbejdes derfor ikke separat dokumentation og værktøjer, men henvises til Peppols leverancer på www.peppol.eu >

OIOUBL og North European Subset

OIOUBL er udviklet i koordination med de øvrige nordiske lande samt Storbritannien i et samarbejde kaldet ”North European Subset” (NES), som var et initiativ, hvor de involverede lande samarbejdede 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 NES. Der er enkelte forskelle mellem de to implementeringer, som fremgår af listen over forskelle mellem NES og OIOUBL, se reference I03.

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. Hvis man ønsker at modtage OIOUBL dokumenter via NemHandel skal EndpointID registreres i det etablerede adresseregister NemHandelsregistret, således at modtageren entydigt kan bestemmes.

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.

Scenarieeksempler og beskrivelser er kun vejledende og til inspiration. Der kan være kommet små ændringer i forhold til online-validatoren siden de blev lavet.