WHAT IT COULD LOOK LIKEEuropean eInvoicing example

1

eInvoice Governance Communities

ImplementationsUN/CEFACT

european eInvoicing example

UN/CEFACTProcurement

domainCore Interoperable Foundation Library BII

Profiles

Profiles

BusinessObjects

ISO 20022Universal financial industry message scheme

Message definition

Focus on this

2

Used in

Used in

Used in

Used in

‘core’

3

a European Profile

business process models

data models and code lists

data structures

syntax expression

‘Supplier initiated Invoice’

‘identifier’‘date’‘currency’‘rate’

‘party’‘location’‘item’‘document’‘period’‘address’

‘commonprocurementlibrary’

‘billing process’

‘invoice syntax mapping’

‘address type’

‘invoice transaction requirements’

CORE European INVOICE

data model ?

using a ‘core’ semantic referencefor eInvoicing

‘address details’

‘core’ models‘supplier initiated Invoice’

‘identifier’‘date’‘currency’‘rate’

‘party’‘location’‘item’‘document’‘period’‘address’

‘address type’

UN/CEFACTProcurement

domain

UN/CEFACTBureau

Programme Support

UN/CEFACTBureau

Programme Support

UN/CEFACTBureau

Programme Support

maintained by

Used in

Used in

Used in

Used in

business process models

data models and code lists

data structures

XML format

‘address details’ Used in

EDIFACT format4

The role of CEN/BII specifications

5

BII

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

the CEN/BII European Profile

‘invoice transaction requirements’

‘billing process’

‘invoiceformatmapping’

CEN/BII

UN/CEFACTand

OASIS UBL

CEN/BII

CEN/BII

maintained by

Used in

Used in

Used in

Used in

business process models

data models and code lists

data structures

XML format

‘commonprocurementlibrary’

CORE European INVOICE

data model ?

6

HOW IT COULD WORKEuropean eInvoicing example

7

using ‘core’ semantics

Can we speak in English ?

8

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

a human analogy

9

Globish-ItalianDictionary

Globish* Dictionary

using a ‘core’ semantic reference

Globish-HungarianDictionary

“you owe me $100”

du schuldest mir 100 $tu mi debba 100 $

tartozol nekem 100 $

Globish-German Dictionary

what we say to each other

(regardless of native

language)

For a German to communicate

with an Italian they use agreed

phrases based on Globish

Dictionary

semantically equivalent10

UBL Invoice

Cross Industry Invoice Financial Invoice

UN/CEFACTCore Interoperable Foundation Library

European Invoice Semantics

European Common Invoice requirements

CORE European INVOICE

data model ?

semantically equivalent

11

Hungarian sentence

Italian sentenceGerman sentence

Globish Semantic References

Globish phrase

Globish* Dictionary

For a German to

communicate with an

Italian they use agreed

phrases based on Globish

Dictionary

12

UBL Invoice

Cross Industry Invoice Financial Invoice

UN/CEFACTCore Interoperable Foundation Library

European Invoice Semantics

European Common Invoice requirements

For a community using

Financial Invoice to exchange

with a community using UBL

Invoice - they use European

Invoice phrases based on CIFL

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></cac:PostalAddress>

</Invoice>

Use of Core

Interoperable

Foundation Library

Extension of

cifls:Address

NB. not valid syntax 14

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></Document>

Use of Core

Interoperable

Foundation Library

Extension of

cifls:Address

NB. not valid syntax 15

PEPPOL Community

Banking Community

UN/CEFACTCore Interoperable Foundation Library

European eInvoice exchange

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 CIFLSpanish Community

semantically equivalent

16

POTENTIAL IMPACT ON UN/CEFACTPROGRAMME OF WORK

UN/CEFACT Revised Technical Framework

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

Governance Communities(stakeholders of libraries)

Implementations

Core Components Library 2.01Community

Core Components Library 3.0

Community

UN/EDIFACTCommunity

UNTDED-ISO7372 Community

A

B

what happens to current libraries?

D

C

UN/CEFACT

Core Interoperable Foundation Library

Note: libraries are developed and approved by communities of use 19

UN/CEFACT Projects (approved by Bureau)

Agriculture Domain

what happens to current BRSs?UN/CEFACT

Core Interoperable Foundation Library

Sectoral PDAAgriculture Domain

• eCert • Crop Data Sheet• E-Lab

Supply Chain PDAProcurement Domain• CI-*• CEFM • eTendering

• BRSs developed as Profiles and approved by projects

• Registered with self conformance in a UN/CEFACT repository

• Published as UN/CEFACT Deliverables for Information

20

Governance Communities Implementations

Agriculture Domain

Core Components

Library 3.0

community

community

A

X

what happens to current RSMs?UN/CEFACT

Core Interoperable Foundation Library

Agriculture Industry Group• eCert (RSM)• Crop Data Sheet (RSM)

Procurement Industry Group

• CII (RSM)• CEFM (RSM)• eTendering (RSM)

Core Components Library 2.01

• 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

(stakeholders of current deliverables)

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

WHAT NEEDS TO HAPPENUN/CEFACT Revised Technical Framework

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 Issues1. ISO TS 15000 Parts 1-4 are out of date with OASIS standards2. Gap in maintenance, harmonization and validation procedures for dependent work

items3. Need to improve public communication to user communities4. Perceived lack of collaboration between ECE/IEC/ISO/ITU5. Limited awareness and/or acceptance of UN/CEFACT and ISO/TC 154 deliverables6. Need to improve collaboration on digital signature interoperability7. Restricted availability of Postal Addressing Specifications for use in eBusiness8. Need to improve the timing of UN/EDIFACT directory and code list releases9. Confusion on multiple versions of Core Component Technical Specification10. Lack of full alignment of TDED, EDED, CCL 2.01 and CCL 3.011. Need to clarify JTC 1/SC 32/WG 1 Scope and Work Program12. Overlap of ISO/TC 8 deliverables with UN/CEFACT deliverables13. Lack of published semantic reference models for Trade Facilitation14. 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

• ‘activities’– Guidelines for implementation

• ‘guidelines’

• Different skills

• Different audience

• Different governance

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

Specificationsused

UN/CEFACT Publications

Communities produce

Testing conformance to specifications

Process Business process ISO 15000-? (UMM)

Int. Business Processes Reference Models*

Self conformance

Semantics 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 listsother Code lists

Qualified data types, business rules

ISO TC 154, UN/CEFACT

Structure Document Structures ISO 15000-? (CDTS, UCM)ISO 9735 (EDIFACT)

EDIFACT UNSMs‘core’ document structures

Message Library(s) ISO TC 154, UN/CEFACT

Syntax Formats ISO 9735 (EDIFACT)OASIS UBL NDROASIS genericode

EDIFACT DED, Code lists and UNSMsXML librariesgenericodes

Schemas, XML artifacts, MIGs

Self conformance

Filling out the technical framework

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