OIOUBL Scenariebeskrivelse OIOUBL Udvidet Indkøbsproces for Tilbud Scenariepakke: ADVQUO S09 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 90
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 90
Indholdsfortegnelse 1. Introduktion...7 1.1 Formål og målgruppe... 7 1.2 Sådan bruges dette dokument... 7 1.3 Forudsætninger... 8 1.4 Referencer... 8 2. Definition af OIOUBL tilbudsproces...9 2.1 Emneområde... 9 2.2 Beskrevne scenarier... 9 2.3 Anvendelsen af OIOUBL-profiler... 9 3. Bestilling af installation hos El leverandør...14 3.1 Resumé af scenariet... 14 3.2 Scenariets karakteristika... 14 3.3 Scenariets kontekst... 14 3.3.1 Anvendte dokumenter... 14 3.3.2 Kundeparter... 15 3.3.3 Leverandørparter... 15 3.4 Aktivitetsdiagram for scenariet... 15 3.5 Detaljeret beskrivelse af primære aktiviteter... 16 3.5.1 Forespørgsel på tilbud... 16 3.5.2 Modtage Forespørgsel på tilbud... 17 3.5.3 Opret tilbud... 17 3.5.4 Modtage tilbud... 18 3.5.5 Det videre forløb... 18 3.6 Interne processer og fordele ved elektronisk tilbudshåndtering... 18 3.6.1 TilbudsKundePart... 18 3.6.2 TilbudsLeverandørPart... 19 3.7 Eksempler... 19 3.7.1 Forretningsobjekter... 20 4. Bestilling af computere hos Delcomputer...35 4.1 Resumé af scenariet... 35 4.2 Scenariets karakteristika... 35 4.3 Scenariets kontekst... 35 4.3.1 Anvendte dokumenter... 35 4.3.2 Kundeparter... 35 4.3.3 Leverandørparter... 36 4.4 Aktivitetsdiagram for scenariet... 36 4.5 Detaljeret beskrivelse af primære aktiviteter... 37 Status: Godkendt Side 4 af 90
4.5.1 Forespørgsel på tilbud... 37 4.5.2 Modtage Forespørgsel på tilbud... 37 4.5.3 Opret tilbud... 37 4.5.4 Modtage tilbud... 38 4.5.5 Det videre forløb... 38 4.6 Interne processer og fordele ved e-handel... 38 4.6.1 TilbudsKundePart... 38 4.6.2 TilbudsLeverandørPart... 39 4.7 Eksempler... 39 4.7.1 Eksempel 2... 39 5. Uopfordret tilbud om kursus hos Madsamarbejdet...50 5.1 Resumé af scenariet... 50 5.2 Scenariets karakteristika... 50 5.3 Scenariets kontekst... 50 5.3.1 Anvendte dokumenter... 50 5.3.2 Kundeparter... 50 5.3.3 Leverandørparter... 51 5.4 Aktivitetsdiagram for scenariet... 51 5.5 Detaljeret beskrivelse af primære aktiviteter... 51 5.5.1 Opret tilbud... 52 5.5.2 Modtage tilbud... 52 5.5.3 Det videre forløb... 52 5.6 Interne processer og fordele ved e-handel... 52 5.6.1 TilbudsKundePart... 52 5.6.2 TilbudsLeverandørPart... 53 5.7 Eksempler... 53 5.7.1 Eksempel 3... 53 6. Tilbud på fødevarer fra Madsamarbejdet (Punchout)...58 6.1 Resumé af scenariet... 58 6.2 Scenariets karakteristika... 58 6.3 Scenariets kontekst... 58 6.3.1 Anvendte dokumenter... 58 6.3.2 Kundeparter... 58 6.3.3 Leverandørparter... 59 6.4 Aktivitetsdiagram for scenariet... 59 6.5 Detaljeret beskrivelse af primære aktiviteter... 59 6.5.1 Besøg på leverandørs system... 60 6.5.2 Forespørg om tilbud... 60 6.5.3 Opret tilbud... 60 Status: Godkendt Side 5 af 90
6.5.4 Modtage tilbud... 60 6.5.5 Det videre forløb... 60 6.6 Interne processer og fordele ved e-handel... 61 6.6.1 TilbudsKundePart... 61 6.6.2 TilbudsLeverandørPart... 61 6.7 Eksempler... 61 6.7.1 Eksempel 4... 62 7. Afvisning af Forespørgsel på tilbud - Forkert leverandør...66 7.1 Resumé af scenariet... 66 7.2 Scenariets karakteristika... 66 7.3 Scenariets kontekst... 66 7.3.1 Anvendte dokumenter... 66 7.3.2 Kundeparter... 67 7.3.3 Leverandørparter... 67 7.4 Aktivitetsdiagram for scenariet... 67 7.5 Detaljeret beskrivelse af primære aktiviteter... 68 7.5.1 Forespørgsel på tilbud... 68 7.5.2 Modtage Forespørgsel på tilbud... 68 7.5.3 Afvisning af Forespørgsel på tilbud... 68 7.6 Eksempler... 68 7.6.1 Eksempel 5... 69 8. Afvisning af tilbud - For dyrt...76 8.1 Resumé af scenariet... 76 8.2 Scenariets karakteristika... 76 8.3 Scenariets kontekst... 76 8.3.1 Anvendte dokumenter... 76 8.3.2 Kundeparter... 77 8.3.3 Leverandørparter... 77 8.4 Aktivitetsdiagram for scenariet... 77 8.5 Detaljeret beskrivelse af primære aktiviteter... 78 8.5.1 Forespørgsel på tilbud... 78 8.5.2 Modtage Forespørgsel på tilbud... 78 8.5.3 Opret tilbud... 78 8.5.4 Modtage tilbud... 79 8.5.5 Afvisning af tilbud... 79 8.6 Eksempler... 79 8.6.1 Eksempel 6... 79 Status: Godkendt Side 6 af 90
1. Introduktion Dette dokument beskriver forretningsscenarier vedrørende scenariepakken OIOUBL Tilbudsproces baseret på UBL 2.0-forretningsdokumenter. Dokumentet er et af seks dokumenter, der beskriver andre indkøbsprocesser. Under ref.nr. 2 kan du se en oversigt over disse dokumenter og en generel introduktion til OIOUBL Indkøbsscenarier. Se ref.nr. 1 for en oversigt over OIOUBL-pakken og ref.nr. 5 for UBL 2.0-specifikationen. 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. 1.2 Sådan bruges dette dokument Scenariebeskrivelsen er inddelt i følgende logiske afsnit: Generel introduktion En definition af OIOUBL Simpel tilbudsproces Et antal relaterede scenariebeskrivelser, herunder eksempler på XML-instansfiler. Beskrivelse af udvalgte interne processer og fordele ved ehandel Kapitel 2.3 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 ehandelsdokumenter 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 7 af 90
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 8 af 90
2. Definition af OIOUBL tilbudsproces 2.1 Emneområde OIOUBL tilbudsproces vedrører behandlingen af forespørgsler på tilbud samt håndtering af det resulterende tilbud.. Normalt vil en kunde have et ønske om at modtage tilbud fra en leverandør på en given ydelse, således at kunden kan sammenholde tilbud fra flere leverandører, og derved vælge det mest hensigtsmæssige tilbud. Denne scenariebeskrivelse dækker også håndtering af Punchout, hvor tilbudsdokumentet anvendes i kommunikationen mellem sælger og købers it-systemer. Dette dokument forholder sig ikke til selve bestillingen der kan foretages med udgangspunkt i et givent tilbud. Dette håndteres separat i dokumentation af ordreprocessen. Den køberinitierede tilbudsproces har følgende karakteristika: En given kunde forespørger en given leverandør om tilbud på en given ydelse Leverandøren afgører om der skal fremsendes tilbud Leverandøren fremsender et tilbud til den forespørgende kunde Kunden afgører om tilbudet skal accepteres Der er behov for Simple tilbudsprocesser når kunden ønsker at modtage tilbud på en given ydelse. Dette dokument indeholder beskrivelser af de forskellige måder, som OIOUBL Simpel Tilbudsproces kan gennemføres 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 Bestilling af computere hos Delcomputer Happy day-scenariet 5 Uopfordret tilbud om kursus fra Madsamarbejdet Happy day-scenariet 6 Tilbud på fødevarer fra Madsamarbejdet (Punchout) Happy day-scenariet 7 Afvisning af Forespørgsel på tilbud - Forkert leverandør Fejlscenarie 8 Afvisning af tilbud - For dyrt Fejlscenarie 2.3 Anvendelsen af OIOUBL-profiler Som beskrevet i Ref. 2 + 3, håndterer OIOUBL de forskellige kompleksitetsniveauer ved hjælp af et sæt forskellige profiler. Status: Godkendt Side 9 af 90
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 tilbudsproces anvender bl.a. følgende OIOUBL-profiler: Scenariets titel Bestilling af el-installation til skolekøkken Bestilling af computere hos Delcomputer Uopfordret tilbud om kursus fra Madsamarbejdet Tilbud på fødevarer fra Madsamarbejdet (Punchout) Afvisning af Forespørgsel på tilbud - Forkert leverandør Afvisning af tilbud - For dyrt Profil Procurement-QuoSim + Procurement-AttQuo Procurement-QuoSim Procurement-QuoBas Procurement-QuoAdv Procurement-QuoSim Procurement-QuoSim Når disse profiler anvendes, er aktørerne begrænset til Kunde (Customer) og Leverandør (Supplier) med følgende roller 1 : Køber og Sælger Køber har altid rollen som TilbudsKundePart (Originator Customer Party) Sælger har altid rollen SælgerLeverandørPart (Seller Supplier Party) Der indgår følgende forretningsdokumenter: Forespørgsel på tilbud (RequestForQuotation) Tilbud (Quotation) Applikationsmeddelelse (Application Response) Profilerne omfatter følgende forretningsprocesser: Profil Procurement-QuoSim Procurement-QuoBas Procurement-QuoAdv Beskrivelse Formålet med denne proces er at standardisere den mest typiske form for forespørgsel på tilbud med efterfølgende tilbud. Formålet med denne proces er at standardisere den mest typiske form for uopfordret tilbud. Da denne profil åbner mulighed for at kunden kan modtage uønsket reklame, er profilen valgfri. Formålet med denne proces er at standardisere den mest typiske form for tilbud baseret på kundens forespørgsel i leverandørens system. 1 En rolle svarer til en UBL 2.0-partterm, se Ref. 4 + 5 for yderligere oplysninger. Status: Godkendt Side 10 af 90
Følgende fire illustrationer viser de forskellige processer. act Procurement-QuoSim BuyerCustomerParty Create RequestForQuotation RequestForQuotation SellerSupplierParty Process RequestForQuotation Start Quotation Process Handle Reject [Reject] [Accept] Accept or Reject RequestForQuotation Process Quotation Quotation Create Quotation Accept or Reject Quotation [Reject] Handle Reject [Accept] Create Order Figur 1, Profilen Procurement-QuoSim Status: Godkendt Side 11 af 90
act Procurement-QuoSim + AttQuo BuyerCustomerParty Create RequestForQuotation AttachedDocument AttachedDocument SellerSupplierParty Pickup AttachedDocuments Start Quotation Process Split of the RequestForQuotation process in documents: * ArrachedDocument * RequestForQuotation RequestForQuotation Receiv e RequestForQuotation When RequestForQuotation and all attached documents are received, the RequestForQuotation is processed Process RequestForQuotation Handle Reject [Reject] [Accept] Accept or reject quotation Receiv e AttachedDocuments AttachedDocument AttachedDocument Create quotation Receive Quotation Quotation Split of the Quotation process in documents: * ArrachedDocument * Quotation Process Quotation When Quotation and all attached documents are received, the Quotation is processed Accept or reject quotation [Accept] [Reject] Handle Reject Create order Figur 2, Profilen Procurement-QuoSim + Procurement-AttQuo Status: Godkendt Side 12 af 90
act Procurement-QuoBas BuyerCustomerParty SellerSupplierParty Process Quotation Quotation Create Quotation Initiate Quotation Quotation Rejected [Reject] [Accept] Accept or reject Quotation Create order Figur 3, Profilen Procurement-QuoBas act Procurement-QuoAdv BuyerCustomerParty SellerSupplierParty Visit Supplier System Request a Quotation Start Punchout Process Quotation Quotation Create Quotation Accept or Reject Quotation [Accept] [Reject] Handle Reject Create order Figur 4, Profilen Procurement-QuoAdv Status: Godkendt Side 13 af 90
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. Til at beskrive dette scenarie anvendes den avancerede udgave af forespørgsel på tilbud processen. 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 Forespørgsel på tilbud hvor der benyttes AttachedDocument som del af forespørgslen. 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 Alle elementer indgår i dette scenario. 3.3.1 Anvendte dokumenter Følgende forretningsdokumenter anvendes i dette scenario: Forespørgsel på tilbud (RequestForQuotation) Tilbud (Quotation) Bilag (AttachedDocument) Status: Godkendt Side 14 af 90
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 modtage og afsende elektroniske dokumenter. Leverandøren identificeres ved hjælp af det entydige CVR-nummer. 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 15 af 90
Figur 5 3.5 Detaljeret beskrivelse af primære aktiviteter Nedenfor beskrives hver af de primære aktiviteter, der vises i aktivitetsdiagrammet (figur 6). 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 16 af 90
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 på tilbud Leverandøren modtager Forespørgsel på tilbud direkte i deres ERP system. Her valideres det at alle de dokumenter 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 Kundeoplysninger (OriginalCustomerParty) Status: Godkendt Side 17 af 90
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 tilbudshå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 Identifikation af leverandører Når forespørgsel på tilbud håndteres ved brug af elektronisk tilbudshåndtering giver det kunden mulighed for let at identificere og sende materiale til samarbejdspartnerei et format der er juridisk bindende. 3.6.1.2 Sammenligning mellem behov og tilbud Da der er indbygget et link mellem forespørgsel på tilbud og tilbud kan det beskrevne ønske og det fremsendte tilbud let sammenlignes. 3.6.1.3 Validering af om alle dokumenter er medsendt Da der både Forespørgsel på 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 på tilbud. Kunden kan validere om leverandøren har fremsendt alle de dokumenter der er relateret til et tilbud. Status: Godkendt Side 18 af 90
3.6.1.4 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. 3.6.1.5 Statistik på leverandøren Når en kunde benytter elektronisk tilbudshåndtering bliver det muligt for kunden at vurdere om leverandøren er en attraktiv samarbejdspartner. Hvis en leverandør eksempelvis afviser at give tilbud på 9 ud af 10 forespørgsler om tilbud giver det kunden god mulighed for at vurdere om samarbejdsaftalen skal fortsætte, eller om man skal lede efter nye leverandører. 3.6.1.6 Oprettelse af ordre Oprettelse af en ordre på baggrund af et elektronisk tilbud er en forholdsvis simpel proces, da ordregrundlaget i høj grad kan hentes fra det elektronisk modtagede tilbud. 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.6.2.2 Sammenligning mellem tilbud og ordre Ved at tilbudet er fremsendt elektronisk i et juridisk bindende format bliver det lettere for leverandøren at validere om ordren stemmer overens med det fremsendte tilbud. 3.6.2.3 Statistik på kunde En leverandør kan let samle statistik på hvor mange ordrer en kunde afgiver sammenlignet med antallet af forespørgsler på tilbud. Det betyder at leverandøren let kan gennemskue hvor attraktiv kunden er at arbejde sammen med, hvilket igen har betydning for hvor god en aftale man kan tillade sig at indgå med kunden. 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 Status: Godkendt Side 19 af 90
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 Profile OIOUBL-2.1 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 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 2 Status: Godkendt Side 20 af 90
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 Contact 12345678 Søren Sørensen SellerSupplierParty CustomerAssignedAccount LEV00123 Party Endpoint DK44332211 PartyIdentification DK44332211 Party El-Let A/S PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode- Status: Godkendt Side 21 af 90
1.1 Street Elvej BuildingNumber 22 City Valby PostalZone 2500 Country IdentificationCode DK PartyTaxScheme Company DK44332211 DK:SE TaxScheme 63 schemeagency 320 urn:oioubl:id:taxschemeid-1.1 Moms PartyLegalEntity Registration Company El-let A/S DK44332211 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 Status: Godkendt Side 22 af 90
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 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 3 Status: Godkendt Side 23 af 90
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 DK44332211 PartyIdentification DK44332211 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 Status: Godkendt Side 24 af 90
PartyLegalEntity Registration Company El-let A/S DK44332211 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 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 4 Status: Godkendt Side 25 af 90
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 DK44332211 PartyIdentification DK44332211 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 DK44332211 Attachment EmbeddedDocumentBinaryObject dqwd mimecode application/msword Status: Godkendt Side 26 af 90
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 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 5 Status: Godkendt Side 27 af 90
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 DK44332211 DK:SE TaxScheme 63 schemeagency 320 urn:oioubl:id:taxschemeid-1.1 Moms PartyLegalEntity Registration Company El-let A/S DK44332211 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 Status: Godkendt Side 28 af 90
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 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 Status: Godkendt Side 29 af 90
DeliveryTerms SpecialTerms 1% reduktion i kontraktsummen pr. dags forsinkelse jf. SKI kontrakt QuotedMonetaryTotal LineExtensionAmount 225000.00 currency TaxExclusiveAmount 56250.00 currency TaxInclusiveAmount 281250.00 currency PayableAmount 281250.00 currency 3.7.1.10 QuotationLine Class Field Attribute Value Note 1 Note Diverse materialer LineItem 1 LineExtensionAmount 150000.00 currency TotalTaxAmount 37500.00 currency Item Description Diverse materialer som beskrevet i fremsendt dokumentation Diverse materialer 3.7.1.11 QuotationLine Class Field Attribute Value Note 2 Note Arbejdstid LineItem 2 Quantity 150 unitcode HUR LineExtensionAmount 75000.00 currency TotalTaxAmount 18750.50 currency Price PriceAmount 500.00 currency BaseQuantity 1 Status: Godkendt Side 30 af 90
unitcode HUR Item Description Arbejdstid til montage Arbejdstid 3.7.1.12 Selvstændigt bilag 1 til tilbud (AttachedDocument) 3.7.1.13 AttachedDocument Class Field Attribute Value Note 6 UBLVersion 2.0 Customization Profile OIOUBL-2.1 Procurement-AttSim-1.0 schemedatauri prn:profileid-1.0 UU XSG123 935GSTR9-G4G5-WQ4G-32FG- 43AG4G52S633 IssueDate 2008-04-25 IssueTime Note 11:32:26.0Z Svar på arkitekttegning language da-dk DocumentType tiff language da-dk ParentDocument ParentDocumentTypeCode QIY2345 Quotation SenderParty 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 6 Status: Godkendt Side 31 af 90
Country IdentificationCode DK PartyLegalEntity Registration Company El-let A/S DK44332211 ReceiverParty 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 Attachment EmbeddedDocumentBinaryObject dqwd mimecode image/tiff 3.7.1.14 Selvstændigt bilag 2 til tilbud (AttachedDocument) 3.7.1.15 AttachedDocument Class Field Attribute Value Note 7 UBLVersion 2.0 7 Status: Godkendt Side 32 af 90
Customization Profile OIOUBL-2.1 Procurement-AttSim-1.0 schemedatauri prn:profileid-1.0 UU XSG321 235G5EW6-NXR6-H5S4-4Y66- S4HDSFR462R6 IssueDate 2008-04-25 IssueTime Note 11:32:26.0Z Materialebeskrivelse language da-dk DocumentType pdf language da-dk ParentDocument ParentDocumentTypeCode QIY2345 Quotation SenderParty Endpoint DK44332211 PartyIdentification DK44332211 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 DK44332211 ReceiverParty Endpoint 5798000416604 schemeagency 9 GLN PartyIdentification 5798000416604 Status: Godkendt Side 33 af 90
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 Attachment EmbeddedDocumentBinaryObject dqwd mimecode application/pdf Status: Godkendt Side 34 af 90
4. Bestilling af computere hos Delcomputer 4.1 Resumé af scenariet Dette scenario beskriver, hvordan en simpel tilbudsproces kan håndteres. I dette eksempel tages der udgangspunkt i at en kommune skal bestille nye standard computere fra Delcomputer. Den proces der anvendes til at udføre dette er den simple version af forespørgsel på tilbud. Der er her tale om en simpel proces hvor både forespørgsel på tilbud og tilbud ikke er afhængige af selvstændige dokumenter. Gentofte Kommune identificeres ved hjælp af et EAN-lokationsnummer. Vi beskriver kun Happy Day-scenariet. 4.2 Scenariets karakteristika Dette specifikke scenario har følgende karakteristika: En forespørgsel på tilbud Et modsvarende tilbud Der er tale om et tilbud på fysiske varer, hvorfor der kan refereres til specifikke varenumre. Sekretærer på skolen har rollen som Køber (Buyer Customer Party). Dette scenario omhandler en simpel Forespørgsel på tilbud En større hardware leverandør 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 Kunden med efterfølgende tilbud fra Leverandøren. Der er ikke nødvendigvis overensstemmelse mellem Forespørgsel på tilbud og Tilbud Dette er Happy day-scenariet. 4.3 Scenariets kontekst Følgende elementer indgår ikke i dette scenario: Relaterede dokumenter (AttachedDocument) Applikationsmeddelelse (Application Response) 4.3.1 Anvendte dokumenter Følgende dokumenter indgår i scenariet: Forespørgsel på tilbud (RequestForQuotation) Tilbud (Quotation) 4.3.2 Kundeparter Oprindelig kunde (Originator Customer Party): Gentofte Kommune, Økonomiservice Status: Godkendt Side 35 af 90
Att. Sille Schyberg Bernstorffsvej 161 2920 Charlottenlund EAN: 5798000416604 Dette er et eksempel på kommunens centrale indkøbsafdeling. Afdelingen benytter et ERP-system, der kan sende og modtage elektroniske dokumenter. Køber identificeres ved hjælp af et standard-eanlokationsnummer og eventuelt en kontostrengkode. 4.3.3 Leverandørparter Sælger (Seller Supplier Party): Delcomputer A/S Arne Jacobsens Allé 15 2300 København S CVR: 18296799 Dette er et eksempel hvor Delcomputer, optræder som sælger. Sælger identificeres ved hjælp af det unikke CVR-nummer. Sælgerens ERP-system kan sende og modtage elektroniske dokumenter. 4.4 Aktivitetsdiagram for scenariet Det viste scenariediagram viser aktivitetsforløbet og anvendelsen af dokument-instanser for de involverede parter. Sekundære aktiviteter vises med stiplet ramme. Figur 6 Status: Godkendt Side 36 af 90
4.5 Detaljeret beskrivelse af primære aktiviteter Nedenfor beskrives hver af de primære aktiviteter, der vises i aktivitetsdiagrammet (figur 7). En primær aktivitet er kendetegnet ved, at den ligger inden for scenariebeskrivelsens emneområde og samtidig betragtes som ekstern (ikke en intern proces). 4.5.1 Forespørgsel på tilbud Når det er identificeret hvor mange computere der skal bestilles tilbud på, oprettes en Forespørgsel på tilbud (RequestForQuotation). Denne forespørgsel består af følgende dokument: Forespørgsel på tilbud (RequestForQuotation) Kunden skal i forbindelse med fremsendelse af forespørgsel på tilbud levere følgende forretningsoplysninger i selve forespørgslen: Kundeoplysninger (OriginalCustomerParty) Leverandøroplysninger (SellerSupplierParty) Ovenstående dokument fremsendes med en linje pr. delelement der ønskes tilbud på (RequestForQuotationLine). I det konkrete tilfælde vil følgende linjer optræde: Modelnummer på computer med tilhørende antal Modelnummer på tilhørende skærm med tilhørende antal Modelnummer på mus med tilhørende antal Modelnummer på tastatur med tilhørende antal Disse oplysninger giver leverandøren mulighed for at oprette en tilbudsforespørgsel i deres interne itsystem til brug for udarbejdelse af tilbud. Notér at licenser til software er ikke medtaget i tilbudsforespørgslen, da kunden har direkte samarbejdsaftaler med softwareleverandørerne. Da Gentofte Kommune har indgået en SKI aftale med Delcomputer, skal reference til SKI kontrakten medsendes. 4.5.2 Modtage Forespørgsel på tilbud Leverandøren modtager Forespørgsel på tilbud direkte i deres ERP system. Her valideres det om tilbudet er udformet korrekt. Leverandøren forholder sig herefter til om man ønsker at afgive tilbud på basis af de oplysninger kunden har fremsendt. 4.5.3 Opret tilbud Når det er identificeret hvilke hvilken pris kunden skal betale for de pågældende varer, oprettes et tilbud (Quotation). Denne forespørgsel består af følgende dokument: Tilbudet (Quotation) Til selve tilbudet tilføjes en QuotationLine for hvert ønskede varenumre. I det konkrete tilfælde vil følgende linjer optræde: Modelnummer på computer med tilhørende antal Modelnummer på tilhørende skærm med tilhørende antal Modelnummer på mus med tilhørende antal Status: Godkendt Side 37 af 90
Modelnummer på tastatur med tilhørende antal 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 Kundeoplysninger (OriginalCustomerParty) Leverandøroplysninger (SellerSupplierParty) Samlet 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 Gentofte Kommune har indgået en SKI aftale med Delcomputer, skal reference til SKI kontrakten medsendes. 4.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. Med den Simple tilbudsproces vil det dog være muligt at foretage en automaticeret validering af tilbudet, for at afgøre om tilbudet er identisk med forespørgsel på tilbud. 4.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. 4.6 Interne processer og fordele ved e-handel Graden af de fordele der høstes ved brug af e-handel hænger direkte 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. 4.6.1 TilbudsKundePart 4.6.1.1 Indkøbsstyring Ved at have elektronisk styring af tilbudsprocessen, er det muligt at centralt styre hvilke produkter der bliver indkøbt. I tilfældet med en computer bliver det muligt at oprette en vare i Gentofte Kommunes ERP system der hedder Computer. Når der så bestilles en Computer er det centralt defineret hvilken computer der bliver leveret, og med hvilket tilbehør. En sådan styring giver mulighed for attraktive rabatordninger med leverandørerne. 4.6.1.2 Sammenligning mellem behov og tilbud Da der er indbygget et link mellem forespørgsel på tilbud og tilbud kan det beskrevne ønske og det fremsendte tilbud let sammenlignes. Status: Godkendt Side 38 af 90
4.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. 4.6.1.4 Statistik på leverandøren Når en kunde benytter elektronisk tilbudshåndtering bliver det muligt for kunden at vurdere om leverandøren er en attraktiv samarbejdspartner. Hvis en leverandør eksempelvis afviser at give tilbud på 9 ud af 10 forespørgsler om tilbud giver det kunden god mulighed for at vurdere om samarbejdsaftalen skal fortsætte, eller om man skal lede efter nye leverandører. 4.6.1.5 Oprettelse af ordre Oprettelse af en ordre på baggrund af et elektronisk tilbud er en forholdsvis simpel proces, da ordregrundlaget i høj grad kan hentes fra det elektronisk modtagede tilbud. 4.6.2 TilbudsLeverandørPart 4.6.2.1 Generelle fordele Leverandøren har stort set samme fordele som kunden, da der også er fuld gennemsigtighed for leverandøren. 4.6.2.2 Produktions-/Lagerstyring Ved at kunden styrer hvilke produkter der bliver bestilt, vil leverandøren opleve at modtage større identiske ordre. Det giver leverandøren bedre mulighed for at forcaste salget af en given vare, og dermed justere produktionen/lagerbeholdningen mere hensigtsmæssigt. 4.6.2.3 Sammenligning mellem tilbud og ordre Ved at tilbudet er fremsendt elektronisk i et juridisk bindende format bliver det lettere for leverandøren at validere om ordren stemmer overens med det fremsendte tilbud. 4.6.2.4 Statistik på kunde En leverandør kan let samle statistik på hvor mange ordrer en kunde afgiver sammenlignet med antallet af forespørgsler på tilbud. Det betyder at leverandøren let kan gennemskue hvor attraktiv kunden er at arbejde sammen med, hvilket igen har betydning for hvor god en aftale man kan tillade sig at indgå med kunden. 4.7 Eksempler Eksemplerne på XML-dokument-instanser findes som selvstændige XML-filer og er ikke indeholdt i dette dokument. 4.7.1 Eksempel 2 En del af computerne på Gentofte rådhus trænger til at blive udskiftet. Sille Schyberg skal i den forbindelse sørge for at indhente tilbud fra Delcomputer så man i forvaltningen kan tage stilling til om ordren kan gennemføres under dette års budget. Følgende handlinger udføres: 1. Sille Schyberg identificere at der er behov for at få udskiftet 35 computere. 2. Sille Schyberg opretter en tilbudsforespørgsel i Gentofte Kommunes ERP system. Status: Godkendt Side 39 af 90
3. Tilbudsforespørgslen sendes automatisk til Delcomputer. 4. Delcomputer behandler forespørgslen i deres interne ERP system. 5. Delcomputer sender elektronisk et tilbud til Sille Schyberg 6. Sille Schyberg kan nu umiddelbart se om tilbudet kan accepteres i indeværende år 7. Sille Schyberg konverterer tilbudet til en ordre og sender ordren til Delcomputer I de følgende tabeller finder du de forretningsobjekter, der er vigtige for dette eksempel. Forespørgsel på tilbud (RequestForQuotation): 4.7.1.1 RequestForQuotation Class Field Attribute Value Note 8 UBLVersion 2.0 Customization Profile OIOUBL-2.1 Procurement-QuoSim-1.0 schemeagency 320 urn:oioubl:id:profileid-1.2 CopyIndicator UU G867B False 93T5G3G5-HYA3-7267-BVG3- GS46SW44WG53 IssueDate 2008-04-19 IssueTime Note PricingCurrencyCode 11:32:26.0Z Bestilling af computer OriginatorCustomerParty Party Endpoint 5798000416604 schemeagency 9 GLN PartyIdentification 5798000416604 schemeagency 9 GLN Party Gentofte Kommune PostalAddress AddressFormatCode StructuredDK listagency 320 8 Status: Godkendt Side 40 af 90
list urn:oioubl:codelist:addressformatcode- 1.1 Street Bernstorffsvej BuildingNumber 161 City Charlottenlund PostalZone 2920 Country IdentificationCode DK PartyTaxScheme Company DK12345678 DK:SE TaxScheme 63 schemeagency 320 urn:oioubl:id:taxschemeid-1.1 Moms PartyLegalEntity Registration Company Gentofte Kommune DK12345678 Contact 12345678 Sille Schyberg SellerSupplierParty CustomerAssignedAccount LEV00123 Party Endpoint DK18296799 PartyIdentification DK18296799 Party Delcomputer A/S PostalAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode- 1.1 Street Arne Jacobsens Allé BuildingNumber 15 City København S PostalZone 2300 Status: Godkendt Side 41 af 90
Country IdentificationCode DK PartyTaxScheme Company DK18296799 DK:SE TaxScheme 63 schemeagency 320 urn:oioubl:id:taxschemeid-1.1 Moms PartyLegalEntity Registration Company Delcomputer A/S DK18296799 Delivery DeliveryAddress AddressFormatCode StructuredDK listagency 320 list urn:oioubl:codelist:addressformatcode- 1.1 Street Bernstorffsvej BuildingNumber 161 City Charlottenlund PostalZone 2920 AddressLine Line 1. sal AddressLine Line IT-afdelingen Country IdentificationCode DK RequestedDeliveryPeriod StartDate 2008-05-06 StartTime 09:30:47.0Z EndDate 2008-05-10 EndTime 09:30:47.0Z DeliveryTerms SpecialTerms 1% reduktion i kontraktsummen pr. dags forsinkelse jf. SKI kontrakt Contract ContractDocumentReference SKI123456 IssueDate 2006-01-01 Status: Godkendt Side 42 af 90
4.7.1.2 RequestForQuotationLine Class Field Attribute Value Note 1 Note Computer LineItem DELL1052665 Quantity 35 unitcode NIU Item Description Stationær computer Dell PrecisionTM T3400 4.7.1.3 RequestForQuotationLine Class Field Attribute Value Note 2 Note Skærm LineItem DELL2363463 Quantity 35 unitcode NIU Item Description Fladskærm FP/BL 1908WFP 4.7.1.4 RequestForQuotationLine Class Field Attribute Value Note 3 Note Mus LineItem DELL2367452 Quantity 35 unitcode NIU Item Description Mus Dell Quietkey USB-tastatur, sort - Dansk (QWERTY) 4.7.1.5 RequestForQuotationLine Class Field Attribute Value Note 4 Note Tastatur LineItem DELL8436783 Status: Godkendt Side 43 af 90