1. European eInvoicing example
What it could look like

2. european eInvoicing example
eInvoice Governance
Communities
UN/CEFACT
Implementations
Focus on this
Profiles
UN/CEFACT
Procurement domain
BII
Core Interoperable
Foundation Library
Profiles
BusinessObjects
ISO 20022
Universal financial industry message scheme
Message definition

3. using a ‘core’ semantic reference for eInvoicing
a European Profile
‘Supplier
initiated
Invoice’
business process models
‘billing process’
Used in
‘identifier’
‘date’
‘currency’
‘rate’
data models
and code lists
‘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
UN/CEFACT
Bureau Programme Support
‘identifier’
‘date’
‘currency’
‘rate’
Used in
‘party’
‘location’
‘item’
‘document’
‘period’
‘address’
UN/CEFACT
Bureau Programme Support
data structures
Used in
XML format
UN/CEFACT
Bureau Programme Support
‘address type’
Used in
‘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. CORE European INVOICE data model ?
the CEN/BII European Profile
maintained by
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
‘invoice
format
mapping’
CEN/BII
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
Globish is a ‘core’ controlled vocabulary for humans
A “lingua franca” or bridging language.
A “core” English.
Provides a semantic reference.
Globish allows 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. European Invoice Semantics
UN/CEFACT
Core Interoperable
Foundation Library
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. European Invoice Semantics
UN/CEFACT
Core Interoperable
Foundation Library
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:ID schemeID="GLN" schemeAgencyID="9"> </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:IdentificationCode listID="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
<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns:xsi="
xsi:schemaLocation="urn:swift:xsd:tsin tsin xsd"
xmlns:ciflc="urn:un:unece:uncefact:data:draft:CIFLComponents" xmlns:cifls="urn:un:unece:uncefact:data:draft:CIFLStructures”
xmlns="urn:swift:xsd:tsin ”>
<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>
Use of Core Interoperable Foundation Library
Extension of cifls:Address
NB. not valid syntax 

16. European eInvoice exchange
UN/CEFACT
Core Interoperable
Foundation Library
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. Potential Impact on UN/CEFACT programme of Work
UN/CEFACT Revised Technical Framework
Potential Impact on UN/CEFACT programme 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?
UN/CEFACT
Governance Communities
(stakeholders of libraries)
Implementations
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
UN/CEFACT Projects (approved by Bureau)
Sectoral PDA
Agriculture Domain
eCert
Crop Data Sheet
E-Lab
Agriculture Domain
BRSs developed as Profiles and approved by projects
Registered with self conformance in a UN/CEFACT repository
Published as UN/CEFACT Deliverables for Information
Core Interoperable
Foundation Library
Supply Chain PDA
Procurement Domain
CI-*
CEFM
eTendering

21. what happens to current RSMs?
UN/CEFACT
Governance Communities
Implementations
(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: UN/CEFACT impact:
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 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 UNeDocs project

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
Specifications
used
UN/CEFACT Publications
Communities produce
Testing conformance
to specifications
Process
Business process
ISO ? (UMM)
Int. Business Processes Reference Models*
Self conformance
Semantics
Core Components
ISO ?
(CCTS, UCM)
ISO 9735 (EDIFACT)
Core Component Library**
EDIFACT DED
ISO TC 154, UN/CEFACT
Business Information Entities***
Customized Library(s), MIGs
ISO TC 154,
UN/CEFACT
Content constraints
(DTTS, UCM)
UNECE Code lists
other Code lists
Qualified data types, business rules
Structure
Document Structures
(CDTS, UCM)
EDIFACT UNSMs
‘core’ document structures
Message Library(s)
Syntax
Formats
OASIS UBL NDR
OASIS genericode
EDIFACT DED, Code lists and UNSMs
XML libraries
genericodes
Schemas, XML artifacts, MIGs
Commercial, financial, logistics and regulatory information supply chains – the ‘core’ processes
** Aggregate Core Components (ACCs) only – the ‘core’ components
*** The ‘common’ components for a community of use.
NB. Some communities may be projects within UN/CEFACT

48. NEXT STEPS

49. Schedule

50. Summary simple, pragmatic and facilitative… and achievable
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