European eInvoicing example
WHAT IT COULD LOOK LIKE
1
european eInvoicing example
UN/CEFACT
Core Interoperable
Foundation Library
eInvoice Governance
Communities
UN/CEFACT
Procurement
domain
ISO 20022
Universal financial industry
message scheme
Implementations
BII
Message definition
2
using a ‘core’ semantic reference
for eInvoicing a European Profile
‘core’
‘Supplier
initiated
Invoice’
‘identifier’
‘date’
‘currency’
‘rate’
‘party’
‘location’
‘item’
‘document’
‘period’
‘address’
‘address
type’
‘address
details’
business process models
Used in
data models
and code lists
Used in
data structures
Used in
‘billing
process’
‘common
procurement
library’
‘invoice
transaction
requirements’
syntax expression
Used in
‘invoice
syntax
mapping’
3
maintained by
‘core’ models
UN/CEFACT
Procurement
domain
‘supplier
initiated
Invoice’
UN/CEFACT
Bureau
Programme
Support
‘identifier’
‘date’
‘currency’
‘rate’
UN/CEFACT
Bureau
Programme
Support
UN/CEFACT
Bureau
Programme
Support
‘party’
‘location’
‘item’
‘document’
‘period’
‘address’
business process models
Used in
data models
and code lists
Used in
data structures
Used in
XML format
‘address
type’
Used in
‘address
details’
EDIFACT format
Used in
4
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
• BII offers an approach to eInvoicing interoperability
within Europe.
5
the CEN/BII European Profile
business process models
Used in
data models
and code lists
Used in
‘billing
process’
‘common
procurement
library’
maintained by
CEN/BII
UN/CEFACT
and
OASIS UBL
data structures
Used in
‘invoice
transaction
requirements’
CEN/BII
XML format
Used in
‘invoice
format
mapping’
CEN/BII
6
European eInvoicing example
HOW IT COULD WORK
7
using ‘core’ semantics
Can we
speak in
English ?
8
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.
9
using a ‘core’ semantic reference
Globish* Dictionary
Globish-Hungarian
Dictionary
tartozol nekem 100 $
“you owe me $100”
Globish-Italian
Dictionary
Globish-German
Dictionary
tu mi debba 100 $
semantically equivalent
du schuldest mir 100 $
10
European Invoice Semantics
UN/CEFACT
Core Interoperable
Foundation Library
European Common Invoice
requirements
11
Globish Semantic References
Globish* Dictionary
Globish phrase
12
European Invoice Semantics
UN/CEFACT
Core Interoperable
Foundation Library
European Common Invoice
requirements
13
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">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:IdentificationCode listID="ISO3166-1"
listAgencyID="6”>DK</ciflc:IdentificationCode>
</cifls:Country>
14
NB.
not
valid
syntax

</cac:PostalAddress>
Sample Financial Invoice Document
<?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>
15
</Document>
NB. not valid syntax 
European eInvoice exchange
UN/CEFACT
Core Interoperable
Foundation Library
European Common Invoice
requirements
16
UN/CEFACT Revised Technical Framework
POTENTIAL IMPACT ON
UN/CEFACT
PROGRAMME OF WORK
17
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
18
what happens to current libraries?
UN/CEFACT
Core Interoperable
Foundation Library
Governance Communities
(stakeholders of libraries)
Core Components
Library 2.01
Community
Core Components
Library 3.0
Community
UN/EDIFACT
Community
UNTDED-ISO7372
Community
Note: libraries are developed and approved by communities of use
Implementations
A
B
C
D
19
what happens to current BRSs?
UN/CEFACT
Core Interoperable
Foundation Library
UN/CEFACT Projects (approved by Bureau)
Sectoral PDA
Agriculture Domain
Agriculture Domain
• eCert
• Crop Data Sheet
• E-Lab
Supply Chain PDA
Procurement 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
• CI-*
• CEFM
• eTendering
20
what happens to current RSMs?
UN/CEFACT
Governance Communities
Implementations
(stakeholders of current deliverables)
community
Core Interoperable
Foundation Library
Agriculture Industry Group
Agriculture Domain
• eCert (RSM)
• Crop Data Sheet (RSM)
Core
Components
Library 2.01
Procurement Industry
Group
• CII (RSM)
Core
Components
Library 3.0
A
community
X
• CEFM (RSM)
• eTendering (RSM)
• 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
21
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
22
UN/CEFACT Revised Technical Framework
WHAT NEEDS TO HAPPEN
23
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
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).
Areas of Activity Classification Matrix
Areas of Standardization matrix
Tools: Techniques and Methodologies
Tools: Naming and Design Rules
Tools: Interoperability
Information: Data Dictionaries and
Models
Information: Document Definitions
Information: Message Protocols/Syntax
Activities: Business Process Models
Activities: Profiles
Guidance: Business Requirements
Guidance: Usage Guidelines
Guidance: Interoperability
Requirements
Identified Issues
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
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 UNeDocs project
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
• Different skills
• Different audience
• Different governance
• ‘activities’
– Guidelines for implementation
• ‘guidelines’
41
Areas of Standardization Responsibilities
Communities of
Use
Open Data Interchange Framework
Applying ODIF to the CIFL
Additional Work Items for ISO
Additional Work Items for UN/CEFACT
Filling out the technical framework
Process
Semantics
Structure
Syntax
Communities
produce
Testing
conformance
to specifications
Specifications
used
UN/CEFACT
Publications
Business process
ISO 15000-?
(UMM)
Int. Business
Processes
Reference Models*
Self
conformance
Core Components
ISO 15000-?
(CCTS, UCM)
ISO 9735 (EDIFACT)
Core Component
Library**
EDIFACT DED
ISO TC 154,
UN/CEFACT
Business Information
Entities***
ISO 15000-?
(CCTS, UCM)
ISO 9735 (EDIFACT)
EDIFACT DED
Customized
Library(s), MIGs
ISO TC 154,
UN/CEFACT
Content constraints
ISO 15000-?
(DTTS, UCM)
ISO 9735 (EDIFACT)
UNECE Code lists
other Code lists
Qualified data
types, business
rules
ISO TC 154,
UN/CEFACT
Document Structures
ISO 15000-?
(CDTS, UCM)
ISO 9735 (EDIFACT)
EDIFACT UNSMs
‘core’ document
structures
Message
Library(s)
ISO TC 154,
UN/CEFACT
Formats
ISO 9735 (EDIFACT)
OASIS UBL NDR
OASIS genericode
EDIFACT DED, Code
lists and UNSMs
XML libraries
genericodes
Schemas, XML
artifacts, MIGs
Self
conformance
NEXT STEPS
Schedule
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