OIOUBL Scenariebeskrivelse

OIOUBL Scenariebeskrivelse OIOUBL Udvidet Indkøbsproces for selvstændige bilag Scenariepakke: SIMATT S08 Version 1.0 UBL 2.0 Published under Creative Commons license, attribution 2.5

Dokumenthistorik Revisioner Revision Dato Ændringer Forfatter Ændringsmarkering WD 0.1 08. Maj 2008 First Draft Version (based on UBL 2.0 draft) ARJ No Forfattere Navn Initialer Organisation Email Allan Rennebo Jepsen ARJ Logica A/S allan.jepsen@logica.com Status: Godkendt Side 2 af 40

Ophavsrettigheder Ophavsrettighederne for denne udgivelse følger reglerne i Creative Common, Navngivning 2.5: Det er tilladt at: fremstille bearbejdede værker ud fra dette dokument fremstille eksemplarer og gøre dokumentet tilgængeligt for almenheden benytte dokumentet i kommerciel henseende under betingelse af tydelig kildehenvisning til denne udgivelse fra IT- og Telestyrelsen. Læs mere om rettighederne på http://creativecommons.org/licenses/by/2.5/deed.da. Status: Godkendt Side 3 af 40

Indholdsfortegnelse 1. Introduktion...6 1.1 Formål og målgruppe... 6 1.2 Sådan bruges dette dokument... 6 1.3 Forudsætninger... 7 1.4 Referencer... 7 2. Brug af Selvstændigt bilag...8 2.1 Emneområde... 8 2.2 Beskrevne Scenarier... 8 2.3 Anvendelse af OIOUBL-profiler... 9 3. Bestilling af installation hos El leverandør...12 3.1 Resumé af scenariet... 12 3.2 Scenariets karakteristika... 12 3.3 Scenariets kontekst... 12 3.3.1 Anvendte dokumenter... 12 3.3.2 Kundeparter... 13 3.3.3 Leverandørparter... 13 3.4 Aktivitetsdiagram for scenariet... 13 3.5 Detaljeret beskrivelse af primære aktiviteter... 14 3.5.1 Forespørgsel på tilbud... 14 3.5.2 Modtage forespørgsel om tilbud... 15 3.5.3 Opret tilbud... 15 3.5.4 Modtage tilbud... 16 3.5.5 Det videre forløb... 16 3.6 Interne processer og fordele ved elektronisk dokumenthåndtering... 16 3.6.1 TilbudsKundePart... 16 3.6.2 TilbudsLeverandørPart... 17 3.7 Eksempler... 17 3.7.1 Forretningsobjekter... 17 4. Leverance af standard software (Digital levering)...33 4.1 Resumé af scenariet... 33 4.2 Scenariets karakteristika... 33 4.3 Scenariets kontekst... 33 4.3.1 Anvendte dokumenter... 33 4.3.2 Kundeparter... 33 4.3.3 Leverandørparter... 34 4.4 Aktivitetsdiagram for scenariet... 34 4.5 Detaljeret beskrivelse af primære aktiviteter... 35 Status: Godkendt Side 4 af 40

4.5.1 Elektronisk levering... 35 4.5.2 Modtagelse af levering... 35 4.5.3 Kvittering fra kunde... 35 4.5.4 Det videre forløb... 35 4.6 Interne processer og fordele ved elektronisk dokumenthåndtering... 36 4.6.1 KundePart... 36 4.6.2 LeverandørPart... 36 4.7 Eksempler... 36 4.7.1 Forretningsobjekter... 36 Status: Godkendt Side 5 af 40

1. Introduktion 1.1 Formål og målgruppe Formålet med dette dokument er at fremme brugen af UBL 2.0 til indkøbsprocesser i Danmark ved at tilbyde beskrivelser af typiske OIOUBL-forretningsscenarier. En normativ specifikation af OIOUBL finder du i OIOUBL Retningslinjer (Ref. 4) og specifikationen OASIS Universal Business Language 2.0 (Ref. 5). Den væsentligste fokus sættes på offentlige indkøb, men specifikationerne kan også anvendes i den private sektor. Vi har fokuseret på, hvordan UBL kan bruges til at optimere indkøbsprocessen med et udvidet antal elektroniske dokumenter. Målgruppen er tekniske specialister og domænespecialister, der er ansvarlige for implementering af e-indkøb, udviklere og projektledere med ansvar for implementering af ERPsystemer, workflow-systemer og andre beslægtede systemer på det danske marked. Det er vores ydmyge håb, at scenariebeskrivelserne i dette dokument kan fungere som inspiration for UBL-brugere i alle lande og på denne måde fremme brugen af UBL på verdensplan. Denne scenariepakke har til formål at beskrive standarden for elektronisk udveksling af selvstændige bilag, i et juridisk bindende format. 1.2 Sådan bruges dette dokument Scenariebeskrivelsen er inddelt i følgende logiske afsnit: Generel introduktion En definition af processen for OIOUBL Selvstændigt Bilag Et antal relaterede scenariebeskrivelser (Use cases), herunder eksempler på XML-instansfiler. Beskrivelse af udvalgte interne processer og fordele ved ehandel Kapitel 2.5 indeholder en oversigt over, hvilke forretningsscenarier der beskrives i dette dokument. I forbindelse med forretningsscenarier er det vigtigt at skelne mellem eksterne og interne processer. De eksterne processer beskriver, hvordan selvstændige bilag udveksles mellem forskellige eksterne parter, mens interne processer beskriver, hvordan en given organisation eller virksomhed håndterer disse eksterne dokumenter. Normalt udløser de eksterne dokumenter (eller burde udløse) en eller flere interne procedurer, og indholdet af de eksterne dokumenter får vital betydning for disse procedurer. Forretningsprocesser (eller -aktiviteter) klassificeres på følgende måde gennem dokumentet: Primære aktiviteter (eksterne processer inden for det definerede emneområde) Sekundære aktiviteter (eksterne processer uden for det definerede emneområde og de interne processer) Primære aktiviteter er af natur generiske og vil blive beskrevet som sådan. Disse aktiviteter er dokumentets hovedfokus. Dog vil udvalgte interne processer blive beskrevet på basis af vore observationer. Afsnittene med eksempler er beregnet som en hjælp til at lette implementeringsprocessen for at minimere antallet af implementeringsfejl og misfortolkninger af dokumentinstanser. Status: Godkendt Side 6 af 40

1.3 Forudsætninger Det forudsættes, at læseren har kendskab til følgende: Begrebet UBL 2.0-parter (Ref.nr. 5) OIOUBL-profilspecifikationen (Ref.nr. 3) OIOUBL-scenarieklassifikationen (Ref.nr. 2) 1.4 Referencer Ref.nr. Dokument-id Version Titel 1 I01 V1.0 Oversigt over OIOUBL-pakker 2 S01 V1.0 Introduktion til OIOUBL Indkøbsscenarier 3 G26 V1.0 OIOUBL-profilspecifikation 4 I01 V1.0 Introduktion til OIOUBL Retningslinjer 5 V1.0 Specifikationen OASIS Universal Business Language 2.0 Status: Godkendt Side 7 af 40

2. Brug af Selvstændigt bilag 2.1 Emneområde Selvstændigt bilag vedrører elektronisk kommunikation af diverse dokumenter mellem to parter. Selvstændigt bilag benyttes til elektronisk udveksling af ehandelsdokumenter, i et juridisk bindende format. Dette kan anvendes til mange forskellige formål lige fra fremsendelse af bilag til kommentering der senere skal indgå i et tilbud, til fremsendelse af elektronisk leverancer (f.eks. software). Dette dokument har ikke til formål at forholde sig til, hvordan det fremsendte dokument anvendes af modtager. For at gøre beskrivelsen mere anvendelig vil scenarierne der er inkluderet i dette dokument dog i et vist omfang forholde sig til de omliggende processer. Selvstændigt bilag har følgende karakteristika: En forretningspart sender et bilag eller en elektronisk leverance til en anden forretningspart Selvstændigt bilag kan afsendes af alle parter der afsender forretningsdokumenter under OIOUBL Selvstændigt bilag kan modtages af alle parter der afsender forretningsdokumenter under OIOUBLSelvstændigt bilag er et dokument der kan anvendes som tillæg til andre OIOUBL forretningsdokumenter. For hvert hovedforretningsområde oprettes en særskilt profil, så man som afsender og modtager kan angive og kontrollere i hvilke forretningsprocesser, man understøtter brugen af selvstændigt bilag. Dette dokument indeholder beskrivelser af de forskellige måder, som Selvstændigt bilag kan anvendes på ved hjælp af rammeværket UBL 2.0. Følgende emner beskrives: De involverede forretningsparter De involverede forretningsprocesser og deres indbyrdes sammenhænge De forretningsdokumenter, der skal udveksles De forretningsregler, der gælder for disse forretningsdokumenters indhold og struktur 2.2 Beskrevne Scenarier For OIOUBL Simpel tilbudsproces er der defineret et antal scenarier (use-cases), der beskrives i detaljer. Et scenario afspejler et fast sæt karakteristika inden for det definerede emneområde. Følgende scenarier beskrives i dette dokument: Kapitel Scenariets titel Beskrivelse 3 Bestilling af el-installation til skolekøkken Happy day-scenariet 4 Levering af standard software Happy day-scenariet Status: Godkendt Side 8 af 40

2.3 Anvendelse af OIOUBL-profiler Som beskrevet i Ref. 2 + 3, håndterer OIOUBL de forskellige kompleksitetsniveauer ved hjælp af et sæt forskellige profiler. OIOUBL-profiler gør det muligt for forretningsparter at blive enige om et givent implementeringsniveau af UBL 2.0-modellen, hvorfor det er muligt at begynde på det simple niveau og senere udbygge til en mere avanceret model. Profilerne identificeres med et unikt id i hver instans af forretningsdokumenterne, og ved at angive et bestemt id, forpligter forretningsparten sig til at følge de regler og det dokumentforløb, der er defineret for dette profil-id. En OIOUBL-profil er sammensat af en eller flere forretningsprocesser, der genbruges (byggesten) i forskellige profiler. Profilerne er struktureret i fire niveauer. Profilniveau Beskrivelse UBL-anvendelse Basal Forretningsprofiler på basalt niveau Basal UBL-anvendelse Simpel Forretningsprofiler på startniveau Simpel UBL-anvendelse Udvidet Forretningsprofiler på næste niveau Begrænset UBL-anvendelse Avanceret Forretningsprofiler på højeste niveau Fuld UBL-anvendelse OIOUBL Selvstændigt Bilag anvender bl.a. følgende OIOUBL-profiler: Scenariets titel Bestilling af el-installation til skolekøkken Levering af standard software Profil Procurement-AttQuo Procurement-AttFulR Når disse profiler anvendes i dette dokuments scenariebeskrivelser, er aktørerne begrænset til Modtager (ReceiverParty) og Afsender (Sender) med følgende roller 1 : Afsender og Modtager Afsender har altid rollen som AfsenderPart (SenderParty) Modtager har altid rollen som ModtagerPart (ReceiverParty) Som tillæg til de profiler der er beskrevet i dette dokument, er følgende profiler tilgængelige: Profil Procurement-AttCat Procurement-AttOrd Beskrivelse Formålet med denne proces er at standardisere elektronisk kommunikation af juridiske filer relateret til katalogprocessen. Denne profil anvendes for katalogprocessen på samme måde som Procurement-AttQuo anvendes for tilbudsprocessen. Formålet med denne proces er at standardisere elektronisk kommunikation af juridiske filer relateret til ordreprocessen. Denne profil anvendes for ordreprocessen på samme måde som Procurement-AttQuo anvendes for tilbudsprocessen. 1 En rolle svarer til en UBL 2.0-partterm, se Ref. 4 + 5 for yderligere oplysninger. Status: Godkendt Side 9 af 40

Profil Procurement-AttBil Procurement-AttPay Beskrivelse Formålet med denne proces er at standardisere elektronisk kommunikation af juridiske filer relateret til faktureringsprocessen. Denne profil anvendes for tilbudsprocessen på samme måde som Procurement-AttQuo anvendes for tilbudsprocessen. Formålet med denne proces er at standardisere elektronisk kommunikation af juridiske filer relateret til betalingsprocessen. Denne profil anvendes for tilbudsprocessen på samme måde som Procurement-AttQuo anvendes for tilbudsprocessen. Der indgår følgende forretningsdokumenter: Selvstændigt bilag (AttachedDocument) De beskrevne profiler omfatter følgende forretningsprocesser: Profil Procurement-AttQuo Procurement-AttFul Beskrivelse Formålet med denne proces er at standardisere elektronisk kommunikation af juridiske filer relateret til tilbudsprocessen. Formålet med denne proces er at standardisere elektronisk kommunikation af elektroniske leverancer. Følgende illustration viser processen for selvstændigt bilag relateret til Quotation processen. act Procurement-AttQuo SenderParty ReceiverParty Create AttachedDocument for RequestForQuotation or Quotation AttachedDocument Process AttachedDocument Start Attachment process End process Figur 1, Profilen Procurement-AttQuo Status: Godkendt Side 10 af 40

Følgende illustration viser processen for selvstændigt bilag relateret til Fulfilment processen. act Procurement-AttFul SupplierSellerParty CustomerBuyerParty Prepare delivery for send Initiate digital delivery Create AttachedDocument associated to Order or Inv oice AttachedDocument Process AttachedDocument Evalutate delivery Handle Reject Receiv e ApplicationResponse ApplicationResponse [No] Is delivery according to agreement? [Yes] Handle Delivery Figur 2, Profilen Procurement-AttFul Status: Godkendt Side 11 af 40

3. Bestilling af installation hos El leverandør 3.1 Resumé af scenariet En kommuneskole skal have oprettet nyt skolekøkken. I den forbindelse skal der laves elektriske installationer så ovne, mv. kan blive tilsluttet. En pedel på skolen får til opgave at indhente tilbud fra en større El leverandør på en total el-leverance. Der er her tale om en kompleks proces hvor der sendes selvstændige dokumenter mellem parterne og hvor dokumenterne indgår som en del af tilbudsprocessen. De væsentlige i dette scenarie er ikke selve tilbudsprocessen, men den måde de selvstændige dokumenter anvendes på. Dog er hele tilbudsprocessen beskrevet for at skabe en bedre helhedsforståelse. Dette er Happy day-scenariet. 3.2 Scenariets karakteristika Dette specifikke scenario har følgende karakteristika: En forespørgsel på tilbud Et uddybende tilbud Der er tale om et tilbud på totalenterprise, hvorfor der ikke kan refereres til specifikke varenumre. Pedellen på skolen har rollen som Køber (Buyer Customer Party). Dette scenario omhandler en avanceret forespørgsel om tilbud En større elektrikervirksomhed har rollen som Leverandør. Kunde og Leverandør kan udveksle XML-dokument-instanser via deres netværksudbydere. Der er ikke tale om en ordre, men alene forespørgsel på et tilbud fra Køber med efterfølgende tilbud fra Leverandøren. Der anvendes AttachedDocument i forbindelse med forespørgsel på tilbud hvorfor der skal refereres til alle vedhæftede dokumenter i RequestForQuotation dokumentet. Der anvendes AttachedDocument i forbindelse med afgivelse tilbud hvorfor der skal refereres til alle vedhæftede dokumenter i Quotation dokumentet. Dette er Happy day-scenariet. 3.3 Scenariets kontekst Dette scenarie følger beskrivelsen for QuotationSimple profilen, og indeholder alle dertil hørende dokumenter. Desuden gør scenariet brug af AttachedDocument. 3.3.1 Anvendte dokumenter Følgende forretningsdokumenter anvendes i dette scenario: Forespørgsel på tilbud (RequestForQuotation) Tilbud (Quotation) Selvstændigt bilag (AttachedDocument) Status: Godkendt Side 12 af 40

3.3.2 Kundeparter Oprindelig kunde (Originator Customer Party): Frigade Skole Att. Søren Sørensen Frigadevej 1 8210 Århus V CVR: 11223344 EAN: 5798000416642 Dette er et eksempel på en fiktiv skole der har hjemme i Århus. Skolen bruger et ERP-system, der kan modtage og afsende elektroniske dokumenter. Skolen identificeres ved hjælp af et standard-eanlokationsnummer (EAN). 3.3.3 Leverandørparter Sælger (Seller Supplier Party): El-let Att. Lene Olsen Elvej 22 2500 Valby CVR: 44332211 Dette er et eksempel på en privat el-leverandør. Leverandøren anvender et ERP-system, der kan sende elektroniske ordrebekræftelser og fakturaer. Leverandøren identificeres ved hjælp af det entydige CVRnummer. 3.4 Aktivitetsdiagram for scenariet Det viste scenariediagram viser aktivitetsforløbet og anvendelsen af XML-dokument-instanser for de involverede parter. Sekundære aktiviteter vises med stiplet ramme. Status: Godkendt Side 13 af 40

Figur 3 3.5 Detaljeret beskrivelse af primære aktiviteter Nedenfor beskrives hver af de primære aktiviteter, der vises i aktivitetsdiagrammet (figur 3). En primær aktivitet er kendetegnet ved, at den ligger inden for denne scenariebeskrivelses formål og samtidig betragtes som ekstern (ikke en intern proces). 3.5.1 Forespørgsel på tilbud Forespørgsel på tilbud er her tænkt som en proces, hvor information om ønsker til tilbudet bliver sendt til leverandøren som selvstændige bilag. Følgende dokumenter sendes til leverandøren: Selve forespørgslen (RequestForQuotation) Arkitekttegning (AttachedDocument) Beskrivelse af krav til el-installation (AttachedDocument) Status: Godkendt Side 14 af 40

Her refererer de to dokumenter af typen AttachedDocument til forretningsdokumentet RequestForQuotation samtidig med at RequestForQuotation refererer til de to dokumenter af typen AttachedDocument. Ved at der refereres begge veje bliver det muligt for leverandøren at validere om alle dokumenter er modtaget. I forbindelse med fremsendelse af AttachedDocuments optræder Køber som Afsender og Sælger som Modtager. Kunden skal i forbindelse med fremsendelse af forespørgsel på tilbud levere følgende forretningsoplysninger i selve forespørgslen: Kundeoplysninger (OriginalCustomerParty) Leverandøroplysninger (SellerSupplierParty) Disse oplysninger giver leverandøren mulighed for at oprette en tilbudsforespørgsel i deres interne itsystem til brug for udarbejdelse af tilbud. Da Frigade Skole har indgået en SKI aftale med El-let, skal reference til SKI kontrakten medsendes, sammen med leveringsoplysninger og -betingelser. 3.5.2 Modtage forespørgsel om tilbud Leverandøren modtager forespørgsel om tilbud direkte i deres ERP system. Her valideres det at alle de dokuemnter der er relateret til forespørgslen om tilbud er modtaget. Leverandøren forholder sig herefter til om man ønsker at afgive tilbud på basis af de oplysninger kunden har fremsendt. I Happy Day scenariet bliver der afgivet tilbud. 3.5.3 Opret tilbud Når arbejdet med at udforme et tilbud til kunden er gennemført, oprettes et tilbud der kan sendes til kunden. Tilbudet er her tænkt som en proces, hvor beskrivelser relateret til tilbudet bliver sendt til kunden som selvstændige bilag. Følgende dokumenter sendes til kunden: Selve tilbudet (Quotation) Tegning af løsningen i forhold til arkitekttegning og krav til el-installation (AttachedDocument) Beskrivelse af materialevalg (AttachDocument) Her refererer de to dokumenter af typen AttachedDocument til forretningsdokumentet RequestForQuotation samtidig med at RequestForQuotation refererer til de to dokumenter af typen AttachedDocument. Ved at der refereres begge veje bliver det muligt for leverandøren at validere om alle dokumenter er modtaget. Til selve tilbudet tilføjes en QuotationLine for hvert benyttede varenummer, samt de mandetimer der skal anvendes. I forbindelse med fremsendelse af AttachedDocuments optræder Sælger som Afsender og Køber som Modtager. Leverandøren skal i forbindelse med fremsendelse af tilbud levere følgende forretningsoplysninger i selve forespørgslen: Reference til den modtagne Forespørgsel på tilbud Status: Godkendt Side 15 af 40

Kundeoplysninger (OriginalCustomerParty) Leverandøroplysninger (SellerSupplierParty) Beløb for tilbudet Disse oplysninger giver kunden mulighed for at oprette et modtaget tilbud i deres interne it-system til brug for udarbejdelse af en ordre. Da Frigade Skole har indgået en SKI aftale med El-let, skal reference til SKI kontrakten medsendes, sammen med tilbudets gyldighed, leveringsoplysninger og -betingelser. Desuden skal der tilføjes en QuotationLine for hver hovedpost i tilbudet. 3.5.4 Modtage tilbud Køber modtager tilbud fra Sælger elektronisk via en netværksudbyder. Denne proces kan være mere eller mindre automatiseret. Når køber modtager et tilbud fra leverandøren skal køber gennemgå tilbudet i detaljer, da tilbud og Forespørgsel på tilbud ikke nødvendigvis stemmer overens. 3.5.5 Det videre forløb Når kunden har taget stilling til om tilbudet skal accepteres, kan ordreprocessen initieres. Det er herefter valgfrit hvilken ordreproces man ønsker at anvende, når både kunde og leverandør understøtter den valgte proces. 3.6 Interne processer og fordele ved elektronisk dokumenthåndtering Graden af de fordele der høstes ved brug af elektronisk tilbudshåndtering hænger i høj grad sammen med graden af integration mellem en organisations eksterne og interne processer. Formålet med dette kapitel er at fokusere på og beskrive de mulige fordele, der kan opnås ved at indbygge elektroniske dokumentforløb i organisationens interne processer. 3.6.1 TilbudsKundePart 3.6.1.1 Fleksibilitet i forhold til leverandører Der er høj grad af fleksibilitet i forhold til kommunikation med leverandøren. Dermed kan selv meget komplekse processer understøttes. 3.6.1.2 Validering af om alle dokumenter er medsendt Da der både forespørgsel om tilbud og tilbud indeholder reference til de dokumenter der er fremsendt tidligere i forløbet, kan det automatisk valideres om alt er medsendt korrekt. For kunden betyder det: Der sendes en fejlmeddelelse fra leverandøren hvis denne ikke har modtaget alle dokumenter tilknyttet Forespørgsel om tilbud. Kunden kan validere om leverandøren har fremsendt alle de dokumenter der er relateret til et tilbud. 3.6.1.3 Fuld historik Hvis kunden vælger at oprette en ordre på basis af et tilbud er der fuld historik mellem tilbudsprocessen og ordreprocessen. Det betyder at historikken forud for en ordre er veldokumenteret såfremt der skulle opstå en tvist mellem kunden og leverandøren. Ved at anvende et juridisk format for udveksling af dokumenter, vil de fremsendte dokumenter kunne anvendes som del af tilbud/forespørgsel på tilbud. Status: Godkendt Side 16 af 40

3.6.1.4 Mindre behov for gennemlæsning Ved at bilag til tilbud og forespørgsel på tilbud fra start fremsendes i et juridisk format, er det ikke nødvendigt for kunden at gennemlæse bilag til tilbud igen når det endelige tilbud modtages. Referancen i tilbudsdokumentet sikrer at bilagene ikke har ændret sig i forhold til tidligere i processen. 3.6.2 TilbudsLeverandørPart 3.6.2.1 Generelle fordele Leverandøren har stort set samme fordele som kunden, da der også er fuld gennemsigtighed for leverandøren. 3.7 Eksempler Søren Sørensen er ansat som pedel på Frigade Skole. Her ønsker skolebestyrelsen at undersøge hvad det vil koste at indrette skolekøkkenet mere hensigtsmæssigt, da det gamle er forældet og nedslidt. Da Søren Sørensen tidligere har koordineret lignende opgaver, bliver det besluttet at han skal sørge for at der bliver indhentet tilbud fra diverse leverandører. Søren Sørensen starter med at få en arkitekt til at tegne indretningen af det nye skolekøkken og udarbejde de tilhørende beskrivelser. En af de leverandører der skal indhentes tilbud fra er El-let. Det er tilbudsprocessen med El-let der vil blive beskrevet her. Dette betyder, at følgende trin gennemføres: 1. Søren udarbejder sammen med arkitekten de dokumenter der skal bruges for at indhente tilbud fra El-let 2. Søren opretter en forespørgsel på tilbud med tilhørende bilag 3. Bilagene og forespørgsel på tilbud fremsendes til El-let 4. El-let gennemlæser tilbudsforespørgslen og udarbejder beskrivelser af hvordan man vil løse opgaven. 5. El-let udarbejder et tilbud med tilhørende bilag til Frigade Skole og sender det til Søren 6. Søren modtager et tilbud fra El-let og præsenterer det for skolebestyrelsen sammen med tilbud maler, køkkenfirma, mv. 7. Skolebestyrelsen vælger at arbejde videre med projektet da økonomien ser fornuftig ud. 8. Søren opretter efterfølgende en ordre og sender den til El-let 3.7.1 Forretningsobjekter I de følgende tabeller finder du de forretningsobjekter, der er vigtige for dette eksempel. 3.7.1.1 Forespørgsel på tilbud (RequestForQuotation) 3.7.1.2 RequestForQuotation Class Field Attribute Value Note 2 UBLVersion 2.0 Customization OIOUBL-2.1 2 Status: Godkendt Side 17 af 40

Profile Procurement-QuoSim-1.0 schemedatauri prn:profileid-1.0 CopyIndicator UU G867B false 8D076867-AE6D-439F-8281-5AAFC7F4E3B1 IssueDate 2008-04-19 IssueTime Note PricingCurrencyCode 11:32:26.0Z El enterprise til skolekøkken DKK AdditionalDocumentReference UU XSG123 95F38254-XP9V-455F-2576-5BCFC7F4E3B1 AdditionalDocumentReference UU XSG321 55DEY645-NY76-435F-4431-9D6382GT3254 OriginatorCustomerParty Party Endpoint 5798000416604 schemeagency 9 GLN PartyIdentification 5798000416604 schemeagency 9 GLN Party Frigade Skole PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode- 1.1 Street Frigadevej BuildingNumber 1 City Århus V PostalZone 8210 Country IdentificationCode DK PartyTaxScheme Company DK11223344 DK:SE Status: Godkendt Side 18 af 40

TaxScheme 63 schemeagency 320 urn:oioubl:id:taxschemeid-1.1 Moms PartyLegalEntity Registration Company Frigade Skole DK11223344 Contact 12345678 Søren Sørensen SellerSupplierParty CustomerAssignedAccount LEV00123 Party Endpoint PartyIdentification Party El-Let A/S PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode- 1.1 Street Elvej BuildingNumber 22 City Valby PostalZone 2500 Country IdentificationCode DK PartyTaxScheme Company DK:SE TaxScheme 63 schemeagency 320 urn:oioubl:id:taxschemeid-1.1 Moms PartyLegalEntity Status: Godkendt Side 19 af 40

Registration Company El-let A/S Contact 1234 Lene Olsen Telephone 32323232 Delivery DeliveryAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode- 1.1 Street Frigadevej BuildingNumber 3 City Århus V PostalZone 8210 AddressLine Line 1. sal Country IdentificationCode DK RequestedDeliveryPeriod StartDate 2008-06-29 StartTime 09:30:47.0Z EndDate 2008-07-29 EndTime 09:30:47.0Z DeliveryTerms SpecialTerms 1% reduktion i kontraktsummen pr. dags forsinkelse jf. SKI kontrakt Contract ContractDocumentReference SKI123456 IssueDate 2006-01-01 3.7.1.3 RequestForQuotationLine Class Field Attribute Value Note 1 Note Totalenterprise LineItem 1 Quantity 1 unitcode EA Status: Godkendt Side 20 af 40

Item Description Da skolekøkkenet på Frigade Skole skal renoveres, ønskes tilbud på den totale elenterprise El installation i skolekøkken 3.7.1.4 Selvstændigt bilag 1 til forespørgsel på tilbud (AttachedDocument) 3.7.1.5 AttachedDocument Class Field Attribute Value Note 3 UBLVersion 2.0 Customization Profile OIOUBL-2.1 Procurement-AttSim-1.0 schemedatauri prn:profileid-1.0 UU QIY1234 95F38254-XP9V-455F-2576-5BCFC7F4E3B1 IssueDate 2008-04-19 IssueTime Note 11:32:26.0Z Arkitekt tegning language da-dk DocumentType PDF language da-dk ParentDocument ParentDocumentTypeCode G867B RequestForQuotation SenderParty Endpoint 5798000416604 schemeagency 9 GLN PartyIdentification 5798000416604 schemeagency 9 GLN Party Frigade Skole PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode-1.1 Street Frigadevej BuildingNumber 1 3 Status: Godkendt Side 21 af 40

City Århus V PostalZone 8210 Country IdentificationCode DK PartyLegalEntity Registration Company Frigade Skole DK11223344 ReceiverParty Endpoint PartyIdentification Party El-let A/S PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode-1.1 Street Elvej BuildingNumber 22 City Valby PostalZone 2500 Country IdentificationCode DK PartyLegalEntity Registration Company El-let A/S Attachment EmbeddedDocumentBinaryObject Dqwd mimecode application/pdf 3.7.1.6 Selvstændigt bilag 2 til forespørgsel på tilbud (AttachedDocument) 3.7.1.7 AttachedDocument Class Field Attribute Value Note 4 UBLVersion 2.0 4 Status: Godkendt Side 22 af 40

Customization Profile OIOUBL-2.1 Procurement-AttSim-1.0 schemedatauri prn:profileid-1.0 UU QIY4321 55DEY645-NY76-435F-4431-9D6382GT3254 IssueDate 2008-04-19 IssueTime Note 11:32:26.0Z Arkitektens Beskrivelse language da-dk DocumentType doc language da-dk ParentDocument ParentDocumentTypeCode G867B RequestForQuotation SenderParty Endpoint 5798000416604 schemeagency 9 GLN PartyIdentification 5798000416604 schemeagency 9 GLN Party Frigade Skole PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode-1.1 Street Frigadevej BuildingNumber 1 City Århus V PostalZone 8210 Country IdentificationCode DK PartyLegalEntity Registration Company Frigade Skole DK11223344 ReceiverParty Endpoint PartyIdentification Status: Godkendt Side 23 af 40

Party El-let A/S PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode-1.1 Street Elvej BuildingNumber 22 City Valby PostalZone 2500 Country IdentificationCode DK PartyLegalEntity Registration Company El-let A/S Attachment EmbeddedDocumentBinaryObject dqwd mimecode application/msword 3.7.1.8 Tilbud (Quotation) 3.7.1.9 Quotation Class Field Attribute Value Note 5 UBLVersion 2.0 Customization Profile OIOUBL-2.1 Procurement-QuoSim-1.0 schemedatauri prn:profileid-1.0 CopyIndicator UU QIY2345 false 4D07786B-DA6D-439F-82D1-6FFFC7F4E3B1 IssueDate 2008-04-25 IssueTime Note 11:32:26.0Z El enterprise til skolekøkken language da-dk ValidityPeriod StartDate 2008-05-01 5 Status: Godkendt Side 24 af 40

EndDate 2008-05-06 RequestForQuotationDocumentReference UU G867B 93T5G3G5-HYA3-7267-BVG3- GS46SW44WG53 IssueDate 2008-04-19 AdditionalDocumentReference UU XSG123 935GSTR9-G4G5-WQ4G-32FG- 43AG4G52S633 AdditionalDocumentReference UU XSG321 235G5EW6-NXR6-H5S4-4Y66- S4HDSFR462R6 SellerSupplierParty CustomerAssignedAccount LEV00123 Party Endpoint DK12345678 PartyIdentification DK12345678 Party El-Let A/S PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode- 1.1 Street Elvej BuildingNumber 22 City Valby PostalZone 2500 Country IdentificationCode DK PartyTaxScheme Company DK:SE TaxScheme 63 schemeagency 320 urn:oioubl:id:taxschemeid-1.1 Moms Status: Godkendt Side 25 af 40

PartyLegalEntity Registration Company El-let A/S Contact 1234 Lene Olsen Telephone 32323232 OriginatorCustomerParty Party Endpoint 5798000416604 schemeagency 9 GLN PartyIdentification 5798000416604 schemeagency 9 GLN Party Frigade Skole PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode- 1.1 Street Frigadevej BuildingNumber 1 City Århus V PostalZone 8210 Country IdentificationCode DK PartyTaxScheme Company DK11223344 DK:SE TaxScheme 63 schemeagency 320 urn:oioubl:id:taxschemeid-1.1 Moms PartyLegalEntity Registration Company Frigade Skole DK11223344 Status: Godkendt Side 26 af 40

Contact 12345678 Søren Sørensen Delivery DeliveryAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode- 1.1 Street Frigadevej BuildingNumber 3 City Århus V PostalZone 8210 AddressLine Line 1. sal Country IdentificationCode DK RequestedDeliveryPeriod StartDate 2008-06-29 StartTime 09:30:47.0Z EndDate 2008-07-29 EndTime 09:30:47.0Z DeliveryTerms SpecialTerms 1% reduktion i kontraktsummen pr. dags forsinkelse jf. SKI kontrakt QuotedMonetaryTotal LineExtensionAmount 225000.00 currency DKK TaxExclusiveAmount 56250.00 currency DKK TaxInclusiveAmount 281250.00 currency DKK PayableAmount 281250.00 currency DKK 3.7.1.10 QuotationLine Class Field Attribute Value Note 1 Note Diverse materialer LineItem 1 LineExtensionAmount 150000.00 Status: Godkendt Side 27 af 40