Proposal for a Revised Technical Framework for UN/CEFACT

1. Proposal for aRevised Technical Framework for UN/CEFACT eProcurement impact

2. 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 • eProcurement 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 • European eInvoicing community (e.g. CEN/BII) develops … • European core Invoice Data Model • European business requirements, rules and semantics

3. UN/CEFACT Revised Technical Framework Proposal

4. creating a ‘core’ semantic referencefor eBusiness ‘core’ ‘community of use’ business processes Used in components and code lists Used in structures Used in syntax expressions Used in

5. Defining the ‘core’ 1. Union of all usages (A,B,C,D,E,F,G) • Everything everyone wants: • complex to understand • complex to maintain (harmonize) • enables compliance of legacy/current solutions • compliance does not ensure interoperability G community community E F A B C D community 2. Designed set (A,C,F,Z) • What we think everyone needs: • creates yet another standard • challenges compliance of legacy/current solutions • compliance ensures interoperability commuity A F C Z

6. Defining the ‘core’ 3. Intersection of all usages (F) • What everyone uses: • simple to understand • easier to maintain • encourages compliance of legacy/current solutions • compliance ensures (limited) interoperability F can evolve towards 4. Intersection of common usage (B,C,F,G) • What many use: • still simple to understand • harder to maintain (harmonize) • enables compliance to subsets by legacy/current solutions • compliance does not ensure interoperability G C F B

7. communities of use… • Trading environments around specific: • business domains, • industry groups, • regions, • governments, • technologies or • commercial service models • Communities contain smaller communities • No organization exists in only one community • members overlap • communities form webs not hierarchies • They are identified by context • requirements defined by business rules • May support disparate implementations by members

8. communities specify their ownimplementation guides • Business processes • Establish context of use • Document requirements • Invoice, Freight Invoice, Utility Invoice, Bill, etc, etc. • Process determines function NOT name of document • Business rules (incl. code lists) • “In cases when invoices are issued in other currencies than the national currency of the seller, the seller may be required to provide information about the VAT total amount in his national currency.” • Syntax • EDIFACT, X12, ASN.1, XML • Formats • XML vocabularies (UBL, GS1, OAGi, XBRL, ISO20022)

9. a revised technical framework for UN/CEFACT Requirements for Trade Facilitation Core Interoperable Foundation Library Trade Agreements Published in International Laws WTO/UN recommendations Trade Facilitation Recommendations ‘core’ business processes Based on standard repository schema ‘core’ components ‘core’ structures syntax expressions of models messaging protocols XML EDIFACT

10. communities may have different implementations Governance Communities Implementations UN/CEFACT Conformance to core semantics Conformance to community semantics Agriculture Domain Cross Border Agriculture domain Core Interoperable Foundation Library

11. using common semantics Used by Communities UN/CEFACT semantic foundation ‘UBL common library’ ‘identifier’ ‘date’ ‘currency’ ‘rate’ Tax Category Rate ‘CCL based on CCTS 2.01’ Building Flatroof Percent ‘party’ ‘location’ ‘item’ ‘document’ ‘period’ ‘address’ ‘BII invoice transaction model’ Postal Address Postal Address ‘ISO 20022 Financial Invoice’

12. assurances of conformity • Communities issue statements of self conformance • no certification • It is assumed that the industry will police itself and that most communities will determine that it is in their own best interests to make truthful and accurate claims. • Sample: • “This specification is in conformity to the UN/CEFACT Core Interoperable Foundation Library in that it uses the following generic components… • All new components introduced in this specification are defined in reference to these generic components and are consistent with them.”     

13. registry of community specifications European Commission Joinup Registry IMS Global Learning Consortium IVI Consortium Community Specifications

14. ISO 20022 Registry

15. European eInvoicing example What it could look like

16. 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

17. 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’

18. 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

19. 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

20. 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

21. European eInvoicing example How it could work

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

23. 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

24. 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

25. UN/CEFACT Revised Technical Framework Potential Impact on e-procurement programme of Work

26. potential impact on eProcurementPoW • 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 • UN/CEFACT eProcurement domain  ‘global version of CEN/BII’ 

27. 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

28. 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

29. 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

30. potential impact on Cross Industry Invoice • Publications of CII will become community specifications • Documents, syntax and formats are created by communities of use • UN/CEFACT Library is ‘core’ rather than ‘cross industry’ • Community requirements drive demand • Should be based on CIFL • Would be published in UN/CEFACT registry • Core Component Libraries (based on either CCTS 3.0 and 2.01) will also become community specifications • They are libraries used by specific communities to support legacy implementations • Should be based on CIFL • Would be published in UN/CEFACT registry • Each governance community approves its own specifications • Can claim self conformance to UN/CEFACT foundational library • Similar to industry groups within ISO 20022 project or CEN CWAs

31. 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 • eProcurement 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 • European eInvoicing community (e.g. CEN/BII) develops … • European core Invoice Data Model • European business requirements, rules and semantics