Proposal for aRevised

Technical Framework for UN/CEFACT

eProcurement impact1

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 semantics2

REVISED TECHNICAL FRAMEWORK PROPOSAL

UN/CEFACT

3

Used in

Used in

Used in

Used in

‘core’ ‘community of use’

business processes

components and code lists

structures

syntax expressions

creating a ‘core’ semantic referencefor eBusiness

4

1. Union of all usages(A,B,C,D,E,F,G)

2. Designed set(A,C,F,Z)

communitycommunity

community

AB C

D

EF

G

AC

Z

F

Everything everyone wants:X complex to understandX complex to maintain

(harmonize) enables compliance of

legacy/current solutionsX compliance does not ensure

interoperability

What we think everyone needs:X creates yet another standardX challenges compliance of

legacy/current solutions compliance ensures interoperability

commuity

Defining the ‘core’

3. Intersection of all usages(F)

F

4. Intersection of common usage(B,C,F,G)

B

CF

G

What everyone uses: simple to understand easier to maintain encourages compliance of

legacy/current solutions• compliance ensures

(limited) interoperability

What many use: still simple to understand• harder to maintain (harmonize) enables compliance to subsets by

legacy/current solutionsX compliance does not ensure

interoperability

can evolve towards

Defining the ‘core’

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 members7

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)

8

a revised technical framework for UN/CEFACT

International Laws

WTO/UN recommendations

‘core’ business processes

‘core’ components

‘core’ structures

Trade Agreements

messaging protocols

Trade FacilitationRecommendations

Requirements for Trade Facilitation

Core Interoperable Foundation Library

Based on standard

repository schema

syntax expressions of models

EDIFACTXML

Published in

9

Governance Communities Implementations

Agriculture Domain

UN/CEFACT

communities may have different implementations

Cross BorderAgriculture domain

Core Interoperable Foundation Library

Conformanceto core semantics

Conformanceto community semantics

10

UN/CEFACT semantic foundation

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

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

‘BII invoice transaction model’

‘UBL common library’

‘CCL based on CCTS 2.01’

‘ISO 20022 Financial Invoice’

Used by Communities

using common semantics

Tax Category Rate

Building Flatroof Percent

Postal Address

Postal Address

11

assurances of conformity

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

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

12

registry of community specifications

IVI Consortium

IMS Global Learning Consortium

European Commission Joinup Registry

Community Specifications

13

ISO 20022 Registry

14

WHAT IT COULD LOOK LIKEEuropean eInvoicing example

15

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

16

Used in

Used in

Used in

Used in

‘core’

17

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 format18

The role of CEN/BII specifications

19

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 ?

20

HOW IT COULD WORKEuropean eInvoicing example

21

using ‘core’ semantics

Can we speak in English ?

22

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

23

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

24

POTENTIAL IMPACT ON E-PROCUREMENT PROGRAMME OF WORK

UN/CEFACT Revised Technical Framework

25

potential impact on eProcurement PoW

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

26

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 27

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

28

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)

29

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

30

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 semantics31