What it could look like

1. European eInvoicing example What it could look like

2. europeaneInvoicingexample eInvoice Governance Communities Implementations UN/CEFACT Focus on this Profiles BII UN/CEFACT Procurement domain Core Interoperable Foundation Library Profiles BusinessObjects Message definition ISO 20022 Universal financial industrymessagescheme

3. using a ‘core’ semantic referencefor eInvoicing a European Profile ‘core’ ‘billing process’ ‘Supplier initiated Invoice’ business process models Used in data models and code lists ‘identifier’ ‘date’ ‘currency’ ‘rate’ ‘common procurement library’ Used in ‘party’ ‘location’ ‘item’ ‘document’ ‘period’ ‘address’ data structures ‘invoice transaction requirements’ Used in CORE European INVOICE data model ? syntax expression ‘address type’ ‘invoice syntax mapping’ Used in ‘address details’

4. maintained by ‘core’ models UN/CEFACT Procurement domain ‘supplier initiated Invoice’ business process models Used in data models and code lists ‘identifier’ ‘date’ ‘currency’ ‘rate’ UN/CEFACT Bureau Programme Support Used in ‘party’ ‘location’ ‘item’ ‘document’ ‘period’ ‘address’ UN/CEFACT Bureau Programme Support data structures Used in XML format UN/CEFACT Bureau Programme Support Used in ‘address type’ ‘address details’ EDIFACT format Used in

5. The role of CEN/BII specifications • BII is defining core information requirement models • the set of information elements sufficient to cater for the generally expressed business requirements applicable throughout the European market. • BII offers an approach to e-Invoicing interoperability within Europe. BII

6. maintained by the CEN/BII European Profile business process models ‘billing process’ CEN/BII Used in data models and code lists ‘common procurement library’ UN/CEFACT and OASIS UBL Used in data structures ‘invoice transaction requirements’ Used in CEN/BII CORE European INVOICE data model ? XML format CEN/BII ‘invoice format mapping’ Used in

7. European eInvoicing example How it could work

8. using ‘core’ semantics Can we speak in English ?

9. a human analogy • English is the business language of the global village but we risk getting lost in translation. • Foundation library is large, complex and ambiguous • Globishis a ‘core’ controlled vocabulary for humans • A “lingua franca” or bridging language. • A “core” English. • Provides a semantic reference. • Globishallows you to: • Communicate in English, using only 1500 words. • Employ simple, but standard grammatical structure. • Learn enough pronunciation and spelling for 1500 words only. • Lead a conversation in business anywhere in the world. • Agree common semantics. • Continue to speak local languages within each community.

10. using a ‘core’ semantic reference Globish* Dictionary Globish-Hungarian Dictionary what we say to each other (regardless of native language) tartozol nekem 100 $ “you owe me $100” Globish-Italian Dictionary For a German to communicate with an Italian they use agreed phrases based on Globish Dictionary Globish-German Dictionary tu mi debba 100 $ du schuldest mir 100 $ semantically equivalent

11. UN/CEFACT Core Interoperable Foundation Library European Invoice Semantics CORE European INVOICE data model ? European Common Invoice requirements UBL Invoice Financial Invoice Cross Industry Invoice semantically equivalent

12. Globish Semantic References Globish* Dictionary Globish phrase Hungarian sentence For a German to communicate with an Italian they use agreed phrases based on Globish Dictionary German sentence Italian sentence

13. UN/CEFACT Core Interoperable Foundation Library European Invoice Semantics European Common Invoice requirements UBL Invoice For a community using Financial Invoice to exchange with a community using UBL Invoice - they use European Invoice phrases based on CIFL Financial Invoice Cross Industry Invoice

14. Sample BII (UBL) Invoice Document <?xml version="1.0" encoding="UTF-8"?> <Invoice xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDatatypes-2" xmlns:ccts="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-2” xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:ciflc="urn:un:unece:uncefact:data:draft:CIFLComponents" xmlns:cifls="urn:un:unece:uncefact:data:draft:CIFLStructures" xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-3"> <cac:AccountingSupplierParty> <cac:PartyName> <cbc:Name>Salescompany ltd.</cbc:Name> </cac:PartyName> <cac:PostalAddress> <ciflc:IDschemeID="GLN" schemeAgencyID="9">1231412341324</ciflc:ID> <cbc:Postbox>5467</cbc:Postbox> <ciflc:StreetName>Main street</ciflc:StreetName> <cbc:BuildingNumber>1</cbc:BuildingNumber> <ciflc:CityName>Big city</ciflc:CityName> <cbc:PostalZone>54321</cbc:PostalZone> <cbc:CountrySubentityCode>RegionA</cbc:CountrySubentityCode> <cifls:Country> <ciflc:IdentificationCodelistID="ISO3166-1" listAgencyID="6”>DK</ciflc:IdentificationCode> </cifls:Country> </cac:PostalAddress> </Invoice> Use of Core Interoperable Foundation Library Extension of cifls:Address NB. not valid syntax 

15. Sample Financial Invoice Document Use of Core Interoperable Foundation Library <?xml version="1.0" encoding="UTF-8"?> <Document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:swift:xsd:tsin.004.001.01 tsin.004.001.01.xsd" xmlns:ciflc="urn:un:unece:uncefact:data:draft:CIFLComponents" xmlns:cifls="urn:un:unece:uncefact:data:draft:CIFLStructures” xmlns="urn:swift:xsd:tsin.004.001.01”> <FinInvc> <Buyr> <PtyId> <Nm>Finnish Timber Ltd</Nm> <PstlAdr> <AdrTp>BIZZ</AdrTp> <ciflc:StreetName>Timber street 3</ciflc:StrtNm> <PstCd>00100</PstCd> <ciflc:City>Helsinki</ciflc:City <ciflc:County>FI</ciflc:Country> </PstlAdr> <CtryOfRes>FI</CtryOfRes> </PtyId> </Buyr> </FinInvc> </Document> Extension of cifls:Address NB. not valid syntax 

16. UN/CEFACT Core Interoperable Foundation Library European eInvoice exchange PEPPOL Community European Common Invoice requirements For a banking community member to exchange invoices with a Spanish organization- they can transform documents using European Invoice semantics (defined by CEN-BII), based on UN/CEFACT CIFL Spanish Community Banking Community semantically equivalent

17. UN/CEFACT Revised Technical Framework Potential Impact on UN/CEFACTprogramme of Work

18. potential impact on programme of work • UN/CEFACT projects will develop Profiles • ‘Deliverables for Information’ rather then ‘Standards’ • ‘core’ industry rather than ‘cross’ industry • Generic semantics rather than documents, syntax or formats • Similar, but not same as BRS and RSM • Processes, rules and requirements • Formalized business rules • Semantic reference models • Other activities… • Develop guidelines • Assist in implementation support • Develop UNECE Recommendations • Such as Recommendations to use certain specifications or standards • As with EDIFACT, Layout Key, Codes, etc.. • Attract more business expertise

19. what happens to current libraries? Governance Communities (stakeholders of libraries) Implementations UN/CEFACT Core Components Library 2.01 Community A Core Interoperable Foundation Library Core Components Library 3.0 Community B UN/EDIFACT Community C UNTDED-ISO7372 Community D Note: libraries are developed and approved by communities of use

20. what happens to current BRSs? UN/CEFACT Projects (approved by Bureau) UN/CEFACT • Sectoral PDA • Agriculture Domain • eCert • Crop Data Sheet • E-Lab • BRSs developed as Profiles and approved by projects • Registered with self conformance in a UN/CEFACT repository • Published as UN/CEFACT Deliverables for Information Agriculture Domain Core Interoperable Foundation Library • Supply Chain PDA • Procurement Domain • CI-* • CEFM • eTendering

21. what happens to current RSMs? Governance Communities Implementations UN/CEFACT (stakeholders of current deliverables) community • Agriculture Industry Group • eCert (RSM) • Crop Data Sheet (RSM) A Agriculture Domain Core Interoperable Foundation Library Core Components Library 2.01 • Procurement Industry Group • CII (RSM) • CEFM (RSM) • eTendering (RSM) community X Core Components Library 3.0 • Specific technical specifications (such as RSM and Schemas) are developed and approved by governance communities • May be registered in a UN/CEFACT repository under a self conformance statement as publications based on UN/CEFACT foundation library

22. summary • (proposed) Revised Technical Framework: • Standardize on semantics not syntax or formats • UN/CEFACT ‘core’ semantics establish foundation for interoperability • Communities of use create their own implementations • Process, components, structures, documents and syntax • Statement of conformance • Registry of conformant specifications published by UN/CEFACT • UN/CEFACT is a facilitator of interoperability between communities • UN/CEFACT impact: • UN/CEFACT projects will develop… • Profiles for eProcurement processes • Business requirements, rules and semantics • Published as Deliverables for Information • Recommendation for use of standards • Communities (e.g. CEN/BII) develops … • European core Invoice Data Model • European business requirements, rules and semantics

23. UN/CEFACT Revised Technical Framework What needs to happen

24. ISO/PDTR 18689 Technical Report • Scope • Terms and definitions • Symbols and abbreviated terms • Scope of involved organizations • Current work programs • Identified issues • Analysis • The "Open Data Interchange Framework” • Recommendations

25. Scope • This Technical Report identifies technical specifications and standards that are being maintained, developed or given consideration in work programmes of UN/CEFACT and ISO/TC 154 and strategies that respond to stakeholder requirements for the open interchange of structured data in support of administration, commerce and trade. This may include work from Standards Development Organizations (SDOs) other than ISO and the United Nations Economic Commission for Europe (UNECE).

26. Areas of Activity Classification Matrix

27. Areas of Standardization matrix

28. Tools: Techniques and Methodologies

29. Tools: Naming and Design Rules

30. Tools: Interoperability

31. Information: Data Dictionaries and Models

32. Information: Document Definitions

33. Information: Message Protocols/Syntax

34. Activities: Business Process Models

35. Activities: Profiles

36. Guidance: Business Requirements

37. Guidance: Usage Guidelines

38. Guidance: Interoperability Requirements

39. Identified Issues • ISO TS 15000 Parts 1-4 are out of date with OASIS standards • Gap in maintenance, harmonization and validation procedures for dependent work items • Need to improve public communication to user communities • Perceived lack of collaboration between ECE/IEC/ISO/ITU • Limited awareness and/or acceptance of UN/CEFACT and ISO/TC 154 deliverables • Need to improve collaboration on digital signature interoperability • Restricted availability of Postal Addressing Specifications for use in eBusiness • Need to improve the timing of UN/EDIFACT directory and code list releases • Confusion on multiple versions of Core Component Technical Specification • Lack of full alignment of TDED, EDED, CCL 2.01 and CCL 3.0 • Need to clarify JTC 1/SC 32/WG 1 Scope and Work Program • Overlap of ISO/TC 8 deliverables with UN/CEFACT deliverables • Lack of published semantic reference models for Trade Facilitation • Ambiguous status of the UNeDocsproject

41. Methodology & Technology Requirements • How to design ‘core’ • Development methodology • ‘tools’ • What to build • Content of ‘core’ libraries • ‘information’ • How to use ‘core’ • Guidelines for customization • ‘activities’ • Guidelines for implementation • ‘guidelines’ • Different skills • Different audience • Different governance

42. Areas of Standardization Responsibilities Communities of Use

43. Open Data Interchange Framework

44. Applying ODIF to the CIFL

45. Additional Work Items for ISO

46. Additional Work Items for UN/CEFACT

47. Filling out the technical framework

48. NEXT STEPS

49. Schedule

50. Summary • Technical Framework: • Focus on ‘core’ standards • Collaborate with SDOs to provide supporting methodologies and technologies • Strengthen maintenance for EDIFACT • Organizational: • More business than technology • More maintenance than development • Focus on meeting real market requirements • Strategic: • Interoperability foundation for communities of use (Single Windows, Public Procurement, Finance, regional, industry, etc…) • Not doing everything, but ensuring everything is done. • Not what we were, but what we can be. • simple, pragmatic and facilitative… and achievable