Deltagere: Referat af konstituerende møde i domænekomiteen for e-handel den 30. maj 2005 klokken

Transkript

1 Referat 1 Deltagere: Christian Christiansen, Itst (formand) Mikkel Hippe Brun, Itst Peter Borresen, Itst (ref.) Helle Schade, VTU Carsten Pedersen, Finansstyrelsen (stedfortræder for Stig Korsgaard) Jens Mailand Hansen, KL Jesper Petersen, Amtsrådsforeningen Michael Thalander, Københavns Amt Lars Sønderby, Århus kommune Anders Jørgensen, Progrator Lene Luerser, brancheorganisationen for Medicoindustrien Per Erlingsen, Oracle (stedfortræder for Peter Scharstein) Vibeke Møller, PBS Lars Frelle Petersen, Itst Annette Poulsen, Journalist Per Kilsholm, EAN Danmark Michael Rønne, Odense Kommune Jens Peter Jensen, IBM Danmark Morten Brohoved, IBM Danmark Bjarne Emig, Dansk standard Leif Hagen Christiansen, Københavns Amt Bjarne Willingshøj, Dansk Postordre Handel Jan Søgaard; CSC juni 2005 IT- og Telestyrelsen Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Christian Christensen Telefon E-post cc@itst.dk Referat af konstituerende møde i domænekomiteen for e-handel den 30. maj 2005 klokken Dagsorden: 1. Velkomst og introduktion af medlemmer 2. Baggrunden for domænekomitéens dannelse 3. Det fælles offentlige standardiseringsarbejde 4. UBL og UNSPSC historien 5. Kommissoriet 6. UBL fremtiden 7. UNSPSC fremtiden 8. Leveranceplan Arbejdsform og mødeplan 10. Evt.

2 2 Punkt 2 og 3: Baggrunden for domænekomitéens dannelse Christian Christensen orienterede om baggrunden for at styringen af standardiseringen af e-handel løftes ud af XML-komiteen: E-handels komiteens arbejde er så omfattende, at det kræver selvstændig fokus. E-handel omfatter private aktører i højere grad end noget andet projekt under OIOXML. Der er derfor behov for større indflydelse for private aktører. Mål om, at private også kan få nytte af standardiseringsarbejdet. Se slides på Punkt 4: UBL og UNSPSC - historien Mikkel Hippe Bruun ridsede historien op om e-handelsgruppen og UBL i Danmark. Se slides. IT- og Telestyrelsen Side 2 I forbindelse med diskussionerne af besparelsespotentialet i det offentlige gjorde Jens Meiland Hansen opmærksom på, at der findes en nyere rapport end KPMG rapporten, baseret på et mere præcist datagrundlag. Rapporten er udarbejdet af Pricewaterhouse og Deloitte. Det blev drøftet, hvilken indsats der sker på europæisk plan. Mikkel Hippe Brun orienterede om, at der er blevet samlet krav op i regi af IDABC. Disse er blevet afleveret til UBL, og vil blive brugt som input til næste version af UBL. Carsten Pedersen spurgte til det uhensigtsmæssige i en satsning alene på UBL. Mikkel Hippe Brun svarede, at domænekomitéens kommissorium gælder et år ad gangen, og at UBL er valgt fordi det pt. er det bedste på markedet, og fordi vi har mulighed for at få stor indflydelse på de fremtidige versioner. Men det blev understreget, at det er op til komiteen at stille forslag til et skift, hvis dette vurderes påkrævet på et tidspunkt. Helle Schade orienterede om, hvorfor UNSPSC version er blevet valgt som grundlag for kategorisering af elektroniske varekataloger i Danmark. Oversættelser af kodelister er i gang under ledelse af EAN Danmark og frigives 1. juli i år. Per Kiilsholm, EAN Danmark supplerede med kommentarer om, hvorledes versionsstyringen kommer til at foregå. Det er en længere proces med at finde ud af, hvornår et versionsskift mest hensigtsmæssigt skal foregå. Der arbejdes på at koordinere indsatsen med de omkringliggende lande. Indtil videre har Norge har valgt at satse på den samme version af UNSPSC, og Sverige er tæt på at træffe samme beslutning. Kommissoriet Christian Christensen orienterede og præciserede, at e-handelsstandardisering både drejer sig om forretningskrav for handelsmeddelelser og katalogmeddelelser.

3 3 KL påpegede behovet for valideringsværktøjer og opfordrede til at lave et dokument på sider til at samle erfaringerne op fra arbejdet med de den elektroniske faktura. Århus kommune ønskede en bedre proces en den der havde været i forbindelse med faktura. Han fandt, at det har været en frygtelig start, hvor der har været en måned uden man vidste hvor regningerne befandt sig. Opbakning har manglet fra private parter. I det fremtidige arbejde er det derfor afgørende, at vi får større ejerskab og medansvar fra de private organisationer. Christian Christensen orienterede om, at der vil blive lavet en kommunikationsplan, hvor også mulighederne for at kommunikere budskaberne fra domænekomitéens arbejde til ebusiness kredsen, der er nedsat af Videnskabsministeriet med henblik på at styrke ebusiness hos SMV erne. Denne gruppe repræsenterer i høj grad en stor del af kunderne til domænekomitéens arbejde. UBL- fremtiden IT- og Telestyrelsen Side 3 Mikkel Hippe Brun fortalte om initiativet og den danske indsats i UBL 2.0 (se slides). KL efterlyste kvitteringer for regninger. Hertil kunne Peter Borresen fortælle, at Vans operatørerne er i gang med at lave en ebms kvittering og i UBL 2.0 kommer der en regnings afvisning og betalings meddelelse, som der kan tages udgangspunkt i. Mikkel Hippe brun gennemgik de tre elementer i elektroniske kataloger. Katalogstandarden skal bygge på allerede eksisterende arbejde f.eks. Xcbl, og AMKAT. Per Kiilsholm ønskede at vide, om der var tale om en Bruger til Katalog eller Katalog til Katalog standard. Mikkel Hippe anførte at det primært handler om Bruger til Katalog,, men at der ligger synkroniseringsstandarder i UBL som kan bruge som udgangspunkt for Katalog til Katalog standard. Århus kommune spurgte til, hvor avanceret meddelelserne bliver. Der er et behov for at synliggøre overfor brugerne (f.eks. en daginstitution), at der er prisforskel i forhold til levering og mængde. Mikkel Hippe Brun fortalte, at standarden kan det hele, men at det er inden for denne kreds opgave at skære til, så vi får det vigtigste med. KL opfordrer til et rent skift, således alle meddelelsestyper holdes på samme version. En holdning der var generel opbakning til i kredsen. Bordrunde, forventninger. Afslutningsvis blev der summeret op på medlemmernes forventninger og holdninger til det kommende arbejde.

4 4 Bjarne Willingshøj: Postordrehandel er noget, som breder sig mellem flere brancher og på tværs af landegrænser. Forventer bedre værktøjer til at håndtere den stigende e-handel. Jesper Kervin Petersen: Den kommende arbejde ser spændende og velstruktureret ud, og de bakker op. Vil gerne bidrage med erfaringer fra Medico projektet. Michael Thalander: : Håber på at køre UBL 1.0 i test i amterne mhp at inddrage erfaringerne i det fremtidige standardiseringsarbejde. så det kan være frontløber og pilot for test af UBL 1.0. Lars Søderby : Store organisationer som os, får kun succes med e-handel, hvis vi har de rette data. Pt. kan systemerne ikke alt det de skal, fordi vi mangler de rette data i de rette formater. Der er god grund til en ambitiøs tidsplan, som vi bør holde fast i. Anders Jørgensen: God dialog især omkring skift af versioner. Godt initiativ. Læringspunkter, vi kan arbejde videre med. Stor indflydelse i det private og offentlige. Versionsskift. Hvordan og hvornår. IT- og Telestyrelsen Side 4 Vibeke Møller: Stor interesse i at være tæt på beslutningerne om hvilke meddelelser, der skal bruges. Kan bidrage med erfaringer. Jan Søgaard: CSC kan bidrage med erfaringer, i kraft af deres mange kasketter som VANS, systemleverandør mv. Per Kiilsholm: Synes der er for lille repræsentation fra den private sektor, fordi det er en stor udfordring af få de private virksomheder med. Se på, hvad der i dag kører i de private virksomheder i dag. Der bør være en match mellem det private og vores fremtidige planer. Michael Breuning: Odense Kommune støtter disse standardiseringsinitiativer. Et skridt til større åbenhed og større konkurrence. Håber på at lære noget af deltagelsen. Jens Meiland: Glad for den gode kommunerepræsentation og glad for at vi har fået et forum til at drøfte tingene, så vi kan få en mere gnidningsfri implementering. Rart at det er praktisk og ikke for højtsvævende. Carsten Pedersen: Finansrådet vil gerne være behjælpelige, når det offentlige spørger om standarder. Spørgsmålet er om vi med UBL satser på den rigtige hest. Christian Christensen: Rundede mødet af med at understrege at det er en stor opgave, vi har taget på os. Det er væsentligt, at vi kommunikerer ud, hvad der er vi laver og hvem der får gavn af vores arbejde. Standardiseringsarbejdet og det tekniske skal gå hånd i hånd med forretningen.

5 Notat 5 Domænekomitéen for ehandel Kopi: Sagen Mødeplan for ehandelsgruppen og Domænekomitéen for ehandel august 2005 Standarddagsorden 1. Velkomst 2. Godkendelse af dagsorden og referat 3. Meddelelser 4. Rapporter fra relaterede grupper (DK/Udland) 5. Drøftelsespunkter 6. Beslutningspunkter 7. Evt. 8. Næste møde IT- og Telestyrelsen IT- Strategisk Kontor Sagsbehandler Christian Christensen Telefon Telefax E-post cc@itst.dk Sagsnr Dagsorden ehandelsgruppen møde d. 22. august kl Velkomst 2. Godkendelse af dagsorden og referat 3. Meddelelser 4. UBL status og gennemgang fra face-to-face i Ottawa v/plb (O) 5. Dansk kataloginitiativ workshops d. 9. august og 15./16. august 6. Orientering fra VANS (O) a. ebms b. Trafik og validering 7. Godkendelse af notat vedr. handelsprocessen v/plb (B) a. Med henblik på indspil til Domænekomiteen 8. Godkendelse af notat vedr. priser og beløb v/plb (B) 9. Status på erfaringer med udvidet Schematron validering v/brs (D) 10. Evt. 11. Næste møde

6 6 Dagsorden Domænekomiteen for ehandel møde d. 1. september kl Velkomst 2. Godkendelse af dagsorden og referat 3. ARF s vision for ehandel og de afledte forretningskrav. 4. Præsentation af oplæg fra sekretariatet til højniveau forretningskrav og efterfølgende plenumdrøftelse af forretningskravene 5. Gruppedrøftelser af forretningskravene og den afledte prioritering af dele af handelsprocessen og de dertil knyttede dokumenter. Der tages udgangspunkt i UBLs Business Proces Model og sekretariatets supplerende materiale herom. 6. Opsamling på gruppedrøftelser i plenum 7. Evt. 8. Næste møde 8. november 2005 Dagsorden ehandelsgruppen møde d. 24. oktober kl Velkomst 2. Godkendelse af dagsorden og referat 3. Meddelelser 4. Godkendelse af notat vedr. erfaringer fra implementering af OIOXML elektronisk regning (B) 5. Evt. 6. Næste møde IT- og Telestyrelsen Side 2 Dagsorden Domænekomiteen for ehandel møde d. 8. november kl Velkomst 2. Godkendelse af dagsorden og referat 3. Meddelelser fra sekretariatet, herunder VTU s arbejde i UBL TC og CEN, orientering fra e-business kredsen 4. Oplæg fra universitetsverdenen om perspektiverne for ehandel for dansk erhvervsliv (D) 5. Beslutning om forretningskrav for den elektroniske handelsproces om hvilke meddelelser, der bør indgå i en dansk UBL (B) 6. Opfølgning på Katalog workshops (O) 7. Kommunikationsaktiviteter 8. Evt. 9. Næste møde 19. december 2005 Dagsorden Domænekomiteen for ehandel møde d. 19. december kl Velkomst 2. Godkendelse af dagsorden og referat 3. Meddelelser fra sekretariatet, herunder VTU s arbejde i UBL TC og CEN, orientering fra e-business kredsen 4. Dansk lokalisering og dokumentation af UBL 2.0 (D) a. Oplæg om principper for lokalisering fra sekretariatet 5. Kommunikationsaktiviteter 6. Evt. 7. Næste møde 20. marts 2006

7 7 Dagsorden Domænekomiteen for ehandel møde d. 20. marts 2006 kl Velkomst 2. Godkendelse af dagsorden og referat 3. Meddelelser fra sekretariatet, herunder VTU s arbejde i UBL TC og CEN, orientering fra e-business kredsen 4. Erfaringer fra ARF med henblik på udrulning af UBL 2.0 (D) 5. Dansk lokalisering og dokumentation af UBL 2.0 (B) a. Beslutningsoplæg fra sekretariatet 6. Kommunikationsaktiviteter 7. Evt. 8. Næste møde 19. juni 2006 Dagsorden Domænekomiteen for ehandel møde d. 19. juni 2006 kl Velkomst 3. Godkendelse af dagsorden og referat 4. Meddelelser fra sekretariatet, herunder VTU s arbejde i UBL TC og CEN, orientering fra e-business kredsen 5. Kommunikationsaktiviteter 6. Evt. 7. Næste møde XX.XX 2006 IT- og Telestyrelsen Side 3 Punkter til behandling: ebms Sektorerfaringer og tilpasninger Schematron validering Eksempler på UBL 2.0 meddelelser Værktøjer Kodelister Referenceimplementationer Dokumentation (DKLC) Lokaliserede schemaer OCES MOMS UBL lokaliseringsdokument

8 Notat 8 Funktionelle krav som SKAL med 10. august 2005 Ministeriet for Videnskab, [K5] Standarden skal specificere de basale/nødvendige elementer, til identifikation af leverandør og vare [K6] Det basale katalog skal kunne udvides med ekstra elementer. Datamodellen skal med andre ord være specifik på det, der kan lade sig gøre nu, men generisk omkring elementer, der ikke kan specificeres på forhånd. Teknologi og Udvikling Bredgade København K Telefon Telefax E-post vtu@vtu.dk Netsted CVR-nr [K7] En kategori i et katalog skal kunne tilknyttes et fast antal attributter Attributter er egenskaber som f.eks. vægt, højde, længde og holdbarhedsdato. [K8] En vare skal være tilknyttet en kategori. Der skal til én kategori kunne knyttes flere varer. IT-politisk kontor Helle Schade-Sørensen Telefon Telefax E-post hss@vtu.dk [K9] Kravet er slettet og bygget sammen med K8 [K11] Til en vare skal der knyttes en pris for en angiven enhed og bestillingsenhed. Årsagen til at både enhed og bestillingsenhed er medtaget er for at tage højde for varer, der bestilles som antal stk (bestillingsenhed), men efterfølgende faktureres efter den faktiske vægt (enhed). Hvis man ønsker at tilbyde en mere attraktiv pris for et større kvantum af den samme vare, skal kataloget indeholde et nyt varenummer med den samme vare, men i et andet kvantum (f.eks. en kasse mælk vs. et bur mælk vs. en lastbil mælk) jfr. k 25 [K12] Til en vare skal der kunne refereres til billeder og andre dokumenter. [K16] Et katalog skal indeholde information om katalogid

9 9 Eksempler på informationer i katalgid er; dato, gyldighed, sprog, aftale, UNSPSC version, juridiske aspekter. [K19] Til et katalog skal der knyttes information om i hvilken periode, kataloget er gældende [K20] Til en vare skal der knyttes information om i hvilken periode den er gældende (og evt. under hvilke betingelser). [K21] Det skal være muligt at opdatere al relateret information til en specifik vare herunder den tilknyttede kategori. Det skal afklares, om det er alle informationer knyttet til varen, som skal fremsendes (dvs. at man principielt genfremsender et katalog med kun den vare) eller man kan nøjes med at fremsende de enkelte ændrede elementer. Tjek EAN-Danmarks regler om definition af en record. Ministeriet for Videnskab, Teknologi og Udvikling [K22] Et katalog skal kunne indeholde kundespecifikke nettoprisoplysninger. Kobling til k16 oplysning om gældende rammeaftale og dermed prisaftaler kan fremgå at katalogid. [K23] Man skal kunne opdatere prisinformationerne uden at skulle ændre hele resten af kataloget Man skal med andre ord kunne nøjes med at aflevere en prisfil [K25] Det skal være muligt at angive et varehierarki. Det skal være muligt at angive at den pågældende vare er en delmængde af en anden vare f.eks. en cola, er en delmængde af en kassecola etc. 2

10 Notat 10 Funktionelle krav som MÅSKE skal med 10. august 2005 Ministeriet for Videnskab, [K10] En vare skal kunne referere til andre nødvendige varer i kataloget, der skal anvendes samtidig med. Det skal afgrænses, hvad der menes med reference. Teknologi og Udvikling Bredgade København K Telefon Telefax E-post vtu@vtu.dk [K13] Katalogstandarden skal præcisere format og standardopløsning for associerede billeder. En model for udveksling af billeder skal præciseres. Netsted CVR-nr Der var stor uenighed omkring dette krav. IT-politisk kontor Helle Schade-Sørensen [K18] Alle beskrivende tekster og navne (varebeskrivelser, kategoritekster, attributnavne mv.) skal kunne specificeres på flere sprog. Telefon Telefax E-post hss@vtu.dk Dette krav vil alternativt kunne understøttes ved at publicere separate kataloger på de respektive sprog.

11 Notat 11 Funktionelle krav som IKKE skal med 10. august 2005 Ministeriet for Videnskab, [K14] Varebeskrivelser skal kunne typograferes og indeholde eksterne links. F.eks. skal ord kunne fremhæves med fed eller kursiv. Typografering, som det kendes fra HTML er tilstrækkelig. [K15] Et varekatalog skal kunne referere til et eksternt stylesheet til præsentation af kataloget. Standarden skal specificere, hvordan programmel til håndtering af det elektroniske katalog skal opføre sig, hvis det eksterne stylesheet ikke er tilgængeligt. [K17] En vare skal kunne knyttes til flere produktkategorier [K24] Det skal være muligt at opdatere kategoristrukturen i et katalog. Teknologi og Udvikling Bredgade København K Telefon Telefax E-post vtu@vtu.dk Netsted CVR-nr IT-politisk kontor Helle Schade-Sørensen Telefon Telefax Dette krav er ikke medtaget, da manipulation af en kategoristruktur er relativt kompleks at understøtte. Kan klares ved at genfremsende et helt nyt katalog med den nye struktur. E-post hss@vtu.dk

12 Note 12 Kopi: Outcome of Danish workshop on High Level Business Requirements and Functional Requirements for a Catalogue document submission to UBL 1 Introduction A Danish workshop on High Level Business Requirements and Functional Requirements for at Catalogue document submission to UBL was held on August 9 th participants were registered for the workshop with participation from suppliers, electronic marketplaces, ERP-vendors, catalogue solution providers, buyers from the public sector (municipalities, regions and state) and buyers from the private sector. 2 High level business requirements [K1] Basic catalogues August 2005 National IT and Telecom Agency Office of Strategic IT Responsible Mikkel Hippe Brun Phone Fax mhb@tst.dk Private companies and public authorities must be able to create, send and receive basic catalogues for standardized products and services with electronic marketplaces and other business partners with a minimum number of technological and administrative barriers. Explanation: The goal is to create end-user critical mass in use of the standard. [K2] Advanced use of basic catalogues Private companies and public authorities must be able to use a basic catalogue as the foundation for a more advanced use. [K3] Attractive target for off-the-shelf business software The catalogue standard must be developed with exactly the functionality that makes it an attractive export- and import format for relevant off-the-shelf business software. (I.e. spreadsheet applications, document editors, ERP-systems, catalogue and product management systems etc.) Explanation: The goal is to create supplier and system vendor critical mass in use of the standard. [K4] Support a 100% electronic procurement process

13 13 The standard must contain the necessary information in order to support at 100% electronic procurement process. Explanation: The electronic catalogue must be sufficient as the only tool for both buyer and supplier in order to proceed in the electronic procurement process. 3 Use cases and actors 3.1 Actors The following actors has been identified: Catalogue supplier Customer Electronic marketplace Transactions passes through an electronic marketplace.products are associated with prices in the catalogues. Electronic data pool / repositories Contains information related to products with or without price information. Data pools are not relays for transaction. A data pool may supplement an electronic marketplace. National IT and Telecom Agency Side Use cases The following use cases has been identified: Request a catalogue Reject a request for a catalogue Create catalogue Modify catalogue (insert, update delete individual products) Delete catalogue Positive receipt Negative receipt Notify about changes to catalogue Catalogue supplier Customer Electronic marketplace Data pool / repository Catalogue supplier Customer Electronic marketplace Data pool / repository X Create Create Create Modify Modify Modify Delete Delete Delete Reject request Request catalogue Positive receipt Negative receipt Positive receipt Negative receipt Positive receipt Negative receipt X Notify about changes Notify about changes Request Positive receipt Negative receipt X Request catalogue Request catalogue Request catalogue X

14 14 4 Functional requirements (Business rules) Structural rules [K5] Supplier and products 1 must be identified The standard must specify the basic /necessary elements in order to identify a supplier and a product. [K6] It must be possible to associate attributes with categories It must be possible to associate a category in a catalogue with a specified set of attributes [K7] A product may have a price per unit and an order unit I must be possible to associate a price and a unit and an order unit. National IT and Telecom Agency Side 3 Explanation: This is needed because products may be ordered in pieces but may be billed by the delivered weight. Furthermore the same product may be sold in different packages with different prices per unit. [K8] A product can reference pictures and documents It must be possible to make reference to pictures and other documents from a product. [K9] A catalogue must contain metadata that identifies the catalogue A catalogue must contain metadata like catalogue id, version, language, contract, taxonomy, and taxonomy version, juridical aspects. [K10] A catalogue may have a valid period It must be possible to specify a period in which a catalogue is valid. [K11] A product may have a valid period It must be possible to specify a period in which a product in a catalogue is valid. Semantic rules [K12] The basic catalogue must be extensible It must be possible to extend the basic catalogue with extra elements. 1 Product is synonymous with service in the following.

15 15 Explanation: The data model should be specific about elements that are common to all catalogues, but must contain a generic mechanism that allows for extra elements to be added. [K13] Products relates to categories It must be possible to associate one or more products to a category. [K14] Customer specific prices It must be possible to relate the prices in a catalogue to a particular customer. [K15] A product may be part of another product It must be possible to indicate that a product is part of another product. I.e. a coke may be part of a box of cokes. Usage rules National IT and Telecom Agency Side 4 [K16] A product may be updated It must be possible to update all relevant information about a product (including its associated category). Question: Should all information related to the product be sent when it is updated? [K17] Prices can be updated independently of other catalogue information It must be possible to update prices independently of other catalogue information. Explanation: it must be possible to exchange a simple file relating product ID s with new prices. 5 Candidate functional requirements (business rules) The following requirements are candidates to be included in a catalogue specification, but may fall for the 80/20 rule. [K18] A product may refer to other relevant or necessary products It must be possible to reference other necessary products in the catalogue that are needed in combination with a product. [K19] Graphic formats and graphics exchange methods must be specified The catalogue standard must specify how graphics are exchanged, what graphics formats are allowed and at what resolution (if applicable). [K20] Texts may be specified in several languages

16 16 It must be possible to specify all text fields in several languages (product descriptions, product names, attribute names etc.) Explanation: Publishing separate catalogues in the different languages could alternately support this requirement. National IT and Telecom Agency Side 5

17 17 Proposal for an Extended Procurement Process for UBL 2.0 Page 1 of 22

18 18 Version Author Date Change 0.1 Peter L. Borresen, Initial version Danish National IT and Telecom agency. 0.2 Peter L. Borresen Diagram updated according to input from OGC and Stephen Green. 0.3 Peter L. Borresen Selfbilling updated 0.4 Peter L. Borresen Diagrams updated 0.5 Peter L. Borresen Swimlanes updated in diagrams 0.6 Tim McGrath Editorial fixes, incorporated TBG1 terminology and definitions. 0.7 Tim McGrath Fulfilment diagram updated Reformatted pages Changed document title 0.8 Tim McGrath Amended Billing diagrams to show incorrect invoice handling. Split Fulfilment into two. 0.9 Tim McGrath Amended Use Case Added Catalogue Managing Party Combined Fulfilment diagrams Modified Billing diagrams. 1.0 Tim McGrath Corrected use case model Corrected receives in table 2.1 Removed Buyer from sourcing model Clarified 3.2 model Enlarged 3.3 model Corrected 3.5 swimlanes Added Submit/Receive to 3.6 table. Page 2 of 22

19 19 Content 1 Background Use Case Model Party definitions Process model Sourcing Catalogue provision Customer initiated sourcing Punchout Ordering Fulfilment Billing Traditional Billing Billing using Credit Notes Billing using Debit Notes Self Billing Self Billing using Credit Notes Self Billing using Self Billing Credit Notes Payment Statement of Account Document overview...20 Page 3 of 22

20 20 1 Background This document describes the proposed extended procurement process model for UBL 2.0. The document is the result of discussions between various European Government e-procurement groups: UK Government (Office of Government Commerce), Danish Government (National IT and Telecom Agency), Norwegian Government (to be completed as appropriate), Swedish Government (Svefaktura project), European Commission (DG Enterprise). It also incorporates ideas and comments from: The OASIS Tax XML technical committee ( The UN/CEFACT International Trade and Business Processes Group: TBG1 ( Page 4 of 22

21 21 2 Use Case Model ud Use Case Catalogue Managing Party Sourcing Cataloque prov ision Originator Party Buyer initiated sourcing Punchout Ordering Buyer Party Seller Party Fulfilment with Despatch Advice Fulfilment with Receipt Advice Supplier Fulfilment Despatch Party Delivery Party Customer Self Billing with self billing credit note Billing with credit note Billing with debit note Self billing with credit note Billing Creditor Payment Payee Party Debtor «extend» Statement of Account Page 5 of 22

22 Party definitions In UBL a party is defined as an individual, a group or a body having a role in a business function. In the procurement process model there will always be two business functions, that of Customer and Supplier. Both involve roles which may be provided by different parties. The following table contains a description of the proposed roles for parties. Business function Customer Role Description Example Synonyms Sends Receives Catalogue Managing The party receiving a catalogue. Catalogue items may never be ordered, so the recipient of the catalogue is not an Originator or a Buyer. Customer Originator The party that had the original demand for the goods and/or services and therefore initiated the procurement transaction. The Originator participates in preordering activity either through RFQ and Quotation or by receiving a Quotation as a response to a punchout transaction on a marketplace or Seller s website. If the Originator subsequently places an Order, the Originator adopts the role of Buyer. The Originator is the typically the contact point for queries regarding the original requirement and can be referred to in an Order Change, Order Cancellation or Order Response. Customer Buyer The party that purchases the goods or services on behalf of the Originator. The Buyer can be referred to in Order Responses, Despatch Advice, Invoice, Self Billed Invoice, Credit Note, and Account Statement. Customer Delivery The party to whom goods should be delivered. The Delivery Party can be the same as the Originator. The Delivery Party An organization has a central office for maintaining catalogues of approved items for purchase. If an employee requests a computer, the employing company may become the Buyer but the employee is the Originator. They need to receive information about the order. A company may delegate the task of purchasing to a specialized group to consolidate orders and gain greater discounts. If a municipality buys a wheelchair for a citizen, the wheelchair must be delivered to the citizen (the Delivery Party). Central Catalogue Party, Purchasing Manager Order Point Consignee, Delivery Point, Destination Party, Receiver, Recipient Request for Quotation Order, Order Change, and Order Cancellation Receipt Advice Catalogue Quotation Order Response Despatch Advice Page 6 of 22

23 23 Business function Role Description Example Synonyms Sends Receives must be referred to at line item level in RFQ, Quotation, Order, Order change, Order Cancellation and Order Response. The Delivery Party may be referred to at line level in Invoice, Self Billed Invoice, Credit Note and Debit Note. The Delivery Party may be stipulated in a transport contract. Customer Debtor The party responsible for making settlement relating to a purchase and resolving billing issues using a Debit Note. The Debtor must be referred to in an Order and may be referred to in an Order Response. In a Self Billing scenario, the Debtor is responsible for calculating and issuing tax invoices. Supplier Seller The party responsible for handling Originator and Buyer services. The Seller party is legally responsible for providing the goods to the buyer. The Seller party receives and quotes against RFQs and may provide information to the Buyer s requisitioning process through Catalogues and Quotations. In such cases the citizen may be notified before delivering the wheelchair. If a kindergarten buys some toys they may be the Originator, Buyer and Delivery Party but the municipality may play the role of Debtor - they are going to pay for it. The organization that sells wheelchairs to municipalities. Invoicee, Accounts Payable Sales Point, Provider, Customer Manager In a traditional Billing scenario: Debit Note, Account Response and Remittance Advice In a Self Billing scenario: Self Billed Invoice, Self Billing Credit Note and Remittance Advice Catalogue, Quotation, Order Response, Order Response Simple In a traditional Billing scenario: Invoice, Credit Note and Statement of Account. In a Self Billing scenario: Credit Note, Account Response and Statement of Account RFQ, Order, Order Change, and Order Cancellation Supplier Despatch The party where goods are to be collected from. The Despatch Party may be stipulated in a transport contract. Supplier Creditor The party who claims the payment and is responsible for resolving billing issues and arranging settlement. The wheelchair Supplier may store chairs at a local warehouse. The warehouse will actually despatch the chair to the Delivery Party. The local warehouse is then the Despatch Party. There are cases where the Creditor is not the Seller party. For example, factoring where the invoicing is outsourced to Despatch Point Shipper, Sender, Consignor Accounts Receivable, Invoice Issuer Despatch Advice In a traditional Billing scenario: Invoice, Credit Note and Statement of Account. Receipt Advice In a traditional Billing scenario: Debit Note, Account Response and Remittance Advice. In a Self Billing Page 7 of 22

24 24 Business function Role Description Example Synonyms Sends Receives Supplier Payee The party to whom the Invoice is paid. Transportation Carrier The party providing transport services. Transportation Freight Forwarder The party arranging the carriage of goods including connected services and/or associated formalities on behalf of a consignor or consignee. The Freight Forwarder may also be the Carrier. another company. The Creditor may not be the party to be paid due to changes in the organisation, e.g. company mergers. Either the Buyer or the Despatch Party may engage a trucking company to deliver the wheelchair. The trucking company is then the Carrier. The Buyer or the Despatch Party may have a contract with a transport company to arrange all their transport needs. This company may then engage the trucking company to transport the wheelchair. The trucking company is still the Carrier and the transport company is the Freight Forwarder. Accounts Receivable Freight Hualier, Shipper, Ships Agent, Shipping Company, Airline, Rail Operator, Road Haulier Shipping Agent, Broker, Courier In a Self Billing scenario: Credit Note, Account Response and Statement of Account scenario: Self Billed Invoice, Self Billing Credit Note and Remittance Advice Remittance Advice Page 8 of 22

25 25 3 Process model The following sections describe each business collaboration (use case) in more detail. Note that these are indicative and demonstrative examples only and are not mandatory processes for the use of these documents. These processes provide a context for the use of the documents required. 3.1 Sourcing There are three kinds of sourcing: Catalogue provision. Buyer initiated sourcing. Punchout The Seller, the Originator or the Buyer can initiate sourcing Catalogue provision Catalogue provision is the case where a Seller sends information regarding items available for purchase to a potential customer. Because it is only a potential customer, the role that receives this is always the Catalogue Managing Party. ad Catalogue provision Catalogue Managing Party Seller Party From Marketing Receive Catalogue Catalogue Send Catalogue Note that Objects in pink are documents that are new to UBL. Page 9 of 22

26 Customer initiated sourcing Customer initiated sourcing is the case where the Originator asks for a quotation. cd Sourcing Customer Intitiated Originator Party Seller Party Send request for Quotation Request for Quotation Receive request for quotation Receive quotation Quotation Send quotation Punchout Punchout applications are a technological innovation whereby an Originator is able to directly access a Seller's application from within their own procurement application. They leave ("punch out" from) their system and interact with the Seller's catalogue to locate and order products, while their application transparently gathers pertinent information. Whilst conceptually the punchout request is a form of Request for Quote, the exchange transaction is tightly coupled to the specific catalogue application and considered outside the scope of UBL 2.0. ad Sourcing punch out Originator Party Seller Party Initiate a punchout session Transaction accessing Seller's catalogue application Build shopping basket Receive quotation Quotation Send shopping basket Page 10 of 22

27 Ordering Ordering is the collaboration that creates a contractual obligation between the Seller and the Buyer. ad Ordering Buyer Party Seller Party Place Order Order Receive Order Receive Response Order Response Simple The status of items may be ambiguous with this response. For more accurate reconciliation a complete response is required. Reject Order rejected modified process order Order Response Add Detail accepted update order? change Order Response Simple Accept Order cancel Change Order Order Change Change Order Cancel Order Order Cancellation Cancel Order Accept Order The status of items may be ambiguous with this response. For more accurate reconciliation a complete response is required. Note that Objects in cream colour are documents that are defined in UBL 1.0. Page 11 of 22

28 Fulfilment Fulfilment is the collaboration in which the goods or services are transferred from the Despatch Party to the Delivery Party. In common practice, fulfilment is either supported by a proactive Despatch Advice from the Despatch Party or by a reactive Receipt Advice from the Delivery Party. If the Customer is not satisfied with the goods or services, they may then cancel or change the order (see section 3.2 Ordering). The Seller may have a fulfilment (or customer) service dealing with anomalies. cd Fulfilment Delivery Party Despatch Party Receive Order Item(s) physical movement of goods Despatch Order Item(s) Receive Despatch Advice Despatch Advice Send Despatch Advice Adjust supply status Check status of Item(s) to Ordering Send Receipt Advice Receipt Advice Receive Receipt Advice Adjust Order Determine Action Accept Items Page 12 of 22

29 Billing In the Billing collaboration a request is made for payment for goods or services that have been ordered, received or consumed. In practice, there are several ways in which goods or services can be billed. For UBL 2.0 we propose the following methods: Traditional Billing o Using credit note o Using debit note Self Billing (also known as billing on receipt) o Using credit note o Using self billing credit note Traditional Billing Traditional billing is where the supplier invoices the customer when the goods are delivered or the services provided. In this case, the invoice can be created at the time of despatch or when the Delivery Party acknowledges that the goods have been received (using a Receipt Advice). When there are discrepancies between the Despatch Advice, Receipt Advice and/or the Invoice and the goods actually received, or the goods are rejected for quality reasons, the customer may send an Account Response or a Debit Note to the supplier. The supplier may then issue a Credit Note or another Invoice as required. A Credit Note or Debit Note may also be issued in the case of retrospective price change. Credit Notes or Debit Notes may be also issued after the Billing collaboration (as part of the Payment collaboration). Page 13 of 22

30 Billing using Credit Notes When using Credit Notes the supplier (in their role as Creditor) is responsible for specifying the tax requirements. ad Billling with credit note Debtor Creditor Receive Invoice Invoice Raise Invoice [initial charges or under charged] Receive Credit Note Credit Note Raise Credit Note [over charged] Reconcile Charges [incorrect information] [incorrect charges] [accept credit] Reconcile Charges Send Account Response Account Response Receive Account Response Validate Response [accept charges] [no action required] Page 14 of 22

31 Billing using Debit Notes When using Debit Notes, both the supplier (as Creditor) and the customer (as Debtor) are responsible for providing taxation information. ad Billing with debit note Debtor Creditor Receive Invoice Invoice Raise Invoice [initial charges or under charged] Reconcile Charges Send Account Response Account Response Receive Account Response Reconcile Charges [over charged] [no action required] [agree to charges] Raise Debit Note Receive Debit Note Debit Note Page 15 of 22

32 Self Billing A self billing process is where a customer invoices themselves, in the name and on behalf of the supplier, and provides the supplier with a copy of the self billed invoice 1. Therefore the supplier still has the role of Creditor and the Debtor is still the customer Self Billing using Credit Notes If the supplier finds that the self billed invoice is incorrect, e.g. wrong quantities, wrong prices, or if the goods have not been invoiced at all, they may send an Account Response or a Credit Note to the customer. The customer may then verify whether the adjustment is acceptable or not and consequently issue another self billed invoice or a self billing credit note. ad Self Billing With Credit Note Debtor Creditor Raise Self Billed Invoice Self Billed Invoice Receiv e Self Billed Invoice [under charged or incorrect information] Receive Account Response [under charged] Reconcile Charges [no action required] [incorrect charges] Reconcile Charges [accept credit] Account Response Send Account Response Validate Invoice [incorrect information] [accept charges] [accept charges] Receive Credit Note Credit Note [over charged] Raise Credit Note 1 Where a customer knows what was ordered from a specific supplier, what prices were agreed and what was actually delivered, there is no real business need for an invoice to be issued by the supplier, before paying what is due. There are, however, some very basic recommendations which need to be fulfilled before self billing can be implemented, since the legal provisions for this method of invoicing do vary from country to country. Some countries are very flexible and encourage self billing. In other countries, self billing is only allowed with specific restrictions and in other countries, self billing is not allowed at all. Under self billing arrangements, it is mandatory that the customer receives a Despatch Advice to identify the goods being despatched. Only goods accepted by the customer are invoiced. Page 16 of 22

33 Self Billing using Self Billing Credit Notes When using Self Billing Credit Notes, the customer is raising the Self Billing Credit Note in the name and on behalf of the supplier. Therefore the supplier (as Creditor) and the customer (as Debtor) are still both responsible for providing taxation information. ad Self Billing With Self Billed Credit Note Debtor Crditor Raise Self Billed Invoice Self Billed Invoice Receive Self Billed Invoice [under charged] Receive Account Response Account Response Send Account Response [discrepancy in charges] Reconcile Charges [no action required] [accept charges] Reconcile Charges [over charged] [accept charges] Raise Self Billing Credit Note Self Billing Credit Note Receive Self Billing Credit Note Page 17 of 22

34 Payment The payment collaboration is where the Payee (who is most often the Creditor) is notified of any funds transferred against the account of the Debtor using a Remittance Advice. ad Payment Debtor Creditor Payee Authorize Payment Remittance Adv ice Receive Advice Notify Payee Notify of Payment Remittance Adv ice Receive advice Page 18 of 22

35 Statement of Account A Statement of Account can be used to notify the Debtor of the status of the billing. ad Statement of Account Debtor Creditor Receive Statement of Account Statement of Account Generate Statement of Account Page 19 of 22

36 Document overview The following table describes the documents used in each collaboration. Document Purpose Use case(s) involved. Catalogue A document that contains a list of goods or services that can be purchased. Note: this is not a full electronic catalogue document. It contains only the details necessary for populating an order. Request for Quotation Quotation Order Order Response Order Response Simple Order Change A document to request pricing and availability information about goods or services. A document to specify pricing and availability information about goods or services A document that contains information directly relating to the economic event of ordering products. A document responding to the customer to indicate detailed responses against a single Order. A document responding to the customer to indicate simple acceptance or rejection of the entire Order. A document that contains information directly relating to Submitter Role Sourcing Seller Catalogue Managing Sourcing Originator Seller Receiver Role Sourcing Seller Originator Ordering Buyer Seller Ordering Seller Buyer Ordering Seller Buyer Ordering, Fulfilment. Buyer Seller Page 20 of 22

37 37 Order Cancellation Despatch Advice Receipt Advice Invoice Self Billed Invoice Credit Note Debit Note Self Billing Credit Note the economic event of changing an Order. A document that Ordering, Buyer Seller advises either party Fulfilment. of the cancellation of an Order. A document that Fulfilment Despatch Delivery describes the content of goods shipped. A document that Fulfilment Delivery Despatch advises the goods received and accepted by the buyer. A document claiming Billing Creditor Debtor payment for goods or services supplied under conditions agreed between the supplier and the customer. In most cases this document describes the actual financial commitment of goods or services ordered from the supplier. A document provided Billing Debtor Creditor by a customer, in the name and on behalf of the supplier, describing the claim for payment for goods or services supplied under conditions agreed between the supplier and the customer. A document for a Billing Creditor Debtor supplier to specify a reduced payment. A document for a Billing Debtor Creditor customer to specify a reduced payment. A document for a Billing Debtor Creditor customer to specify a reduced payment in a Self Billing environment. Page 21 of 22

38 38 Account Response A document to notify of discrepancies in charges. Billing In a traditional Billing scenario: Debtor In a traditional Billing scenario: Creditor Statement of Account Remittance Advice To list the financial transactions between customer and supplier and notify of their status. A document to specify that funds have been transferred from the customer to the supplier. In a Self Billing scenario: Creditor In a Self Billing scenario: Debtor Billing Creditor Debtor Payment Debtor Creditor and/or Payee Page 22 of 22

39 Notat 39 Sektorstandardiseringsudvalget for ehandel Kopi: Oplæg: Vision, pejlemærker og forretningsmæssige krav til en kommende standard til understøttelse af en basal indkøbsproces Baggrund 25. august 2005 IT- og Telestyrelsen IT-strategisk Kontor For at sikre, at ehandelsgruppen under sektorstandardiseringsudvalget for ehandel (SSU) arbejder med specifikationen af det rigtige sæt af meddelelser, er det nødvendigt, at SSU opstiller en vision, et sæt af pejlemærker samt et antal forretningsmæssige og evt. funktionelle krav til en simpel indkøbsproces. Sagsbehandler Mikkel Hippe Brun Telefon Telefax Formålet med dette dokument er at give et antal bud på sådanne krav, som kan danne grundlag for en diskussion i SSU. E-post mhb@itst.dk Vision og pejlemærker Under vision og pejlemærker er det meningen, at SSU skal formulere en retning for standardiseringsinitiativet. Følgende spørgsmål kan guide formuleringen af visionen: Hvor vil vi gerne se Danmark om 7 år på ehandelsområdet? Hvad er det for nogle fordele som vi til den tid har høstet? Hvem har glæde af det der er sket? Hvad er min organisations vision for ehandel? [Vision] Handel i den offentlige og private sektor er om 7 år fuldt understøttet af informationsteknologi. Papirbaserede handelsprocesser med deraf følgende manuel genindtastning af data, er erstattet af elektronisk udveksling af data. Store såvel som små virksomheder og offentlige myndigheder høster fordelene ved de nye muligheder. [Vision] Om 7 år er det lettere og billigere at sende forretningsdokumenter elektronisk i handlen mellem det offentlige og den private sektor. [Pejlemærke 1] Ultimo 2006 skal der foreligge en færdig specifikation / OIOXML standard, som understøtter en basal indkøbsproces.

40 40 [Pejlemærke 2] Medio 2007 skal den basale indkøbsproces være implementeret i samhandlen mellem den offentlige og private sektor. [Pejlemærke 3] Ultimo 2008 skal 35% af den private samhandel ske med udgangspunkt i en elektronisk udveksling af forretningsdokumenter. [Pejlemærke 4] Ultimo 2012 skal 85% af den private samhandel ske med udgangspunkt i en elektronisk udveksling af forretningsdokumenter. NB. Dette ses som en indfrielse af visionen. Dvs. at 85% dækning svarer til fuld understøttelse. Forretningsmæssige krav Forretningsmæssige krav er meget overordnede i deres natur. Følgende spørgsmål kan guide formuleringen af de forretningsmæssige krav: IT- og Telestyrelsen Side 2 Hvilke forretningsdokumenter er nødvendige i den offentlige sektor? Hvilke forretningsdokumenter er nødvendige i den private sektor? Hvilke principper skal guide valget af forretningsdokumenter? [Krav 1] Virksomheder og offentlige myndigheder skal med færrest mulige teknologiske, administrative og økonomiske barrierer kunne udarbejde, sende og modtage basale elektroniske forretningsdokumenter som understøtter en basal indkøbsproces. Kvalificering: Målet er, at standard IT-systemer, som sælges som hyldevarer, skal understøtte de relevante forretningsdokumenter. Dette forudsætter, at barriererne som skal overvindes er små samt at efterspørgslen er stor. [Krav 2] Samlingen af handelsdokumenter skal udvælges med henblik på at være netop det nødvendige og tilstrækkelige sæt af meddelelser som understøtter en basal og effektiv indkøbsproces i den offentlige og private sektor og mellem den offentlige og private sektor. Kvalificering: For hver ekstra meddelelse, der inkluderes i samlingen af handelsdokumenter stiger implementeringsomkostningerne og dermed barriererne for systemleverandører. F.eks. findes der en meddelelse, der hedder self billed invoice (køber-genereret regning). Denne type meddelelse anvendes typisk ved afregning af forbrug på f.eks. kopimaskiner eller frankeringsmaskiner. Det kan indvendes, at scenariet kan håndteres ved at køber sender en elektronisk ordre på det faktiske forbrug, som automatisk resulterer i en faktura, som automatisk kan cleares mod den afsendte regning, og derefter anvises. Udfra dette ræsonnement er en kombination af en elektronisk ordre og en elektronisk regning det nødvendige og til-

41 41 strækkelige. Der skal mao. være det rette forhold mellem funktionalitet, økonomi og forretningsmæssig gevinst. [Krav 3] Alle kendte og hyppigt forekommende samhandelsscenarier mellem den offentlige og private sektor skal være dækket af de udvalgte forretningsdokumenter. [Krav 4] Den danske standard skal i vides muligt omfang basere sig på den international standard således at grænseoverskridende handel er mulig. Kvalificering: Den investering som den private og offentlige sektor tager i implementeringen af elektroniske handelsdokumenter skal i vides muligt omfang kunne genbruges til grænseoverskridende samhandel. Den danske lokalisering skal tage hensyn til dette krav. IT- og Telestyrelsen Funktionelle krav (udarbejdes af ehandelsgruppen) Side 3 De funktionelle krav er mere detaljerede, og underbygger de forretningsmæssige krav. Funktionelle krav kan f.eks. inddeles i følgende grupper: Semantiske regler (Definition af begreber i forhold til hinanden) Strukturelle regler (Sammenhæng mellem elementer) Regler knyttet til anvendelsen (Privilegier hvem må hvad) Regler knyttet til præsentationen Syntaktiske regler (UBL skal anvendes) Regler knyttet til behandlingen af meddelelser (Når en meddelelse modtages skal følgende ske.) Regler knyttet til instanser (F.eks. priser kan ikke være negative..) [Krav 5] Varer skal kunne bestilles af en anden part end den part der skal modtage og evt. betale for varerne. [Krav 6] Regninger skal kunne sendes til og betales af en anden part end den part der har bestilt varerne, og den part som overtager det juridiske ejerskab til varerne. [Krav 7] Handelsdokumenterne skal kunne udvides med branche- /sektorspecifikke data.