peppol online ws. 4 and 5 cenbii transactions in peppol

www.peppol.eu

PEPPOL is an EU co-funded project CIP-ICT PSP-2007 No 224974

PEPPOLBII Transactions in PEPPOLMartin Forsberg, Ecru Consulting


The PEPPOL project

Pilot A objective: Enabling EU-wide public eProcurement

50% EU contribution for achieving interoperability

Coordinated by the Norwegian Agency for Public Management and eGovernment (Difi)

Consortium and scope:

18 beneficiaries from 12 countries

Total budget 30,8 M€

8 work packages, <1.600 person months and 10 M€ on sub-contractors

Project start up: 1 May 2008, duration 48 months*

*Current project duration is 42 months (+6 months extension subject to European Commission's approval)

The PEPPOL project is the result of the European Competitiveness and Innovation Programme (CIP) ICT Policy Support Programme (ICTPSP) 2007 and 2009 Call for Proposals


Any supplier (incl. SMEs) in the EU can communicate electronically with any European contracting authority for all procurement processes.

The PEPPOL Vision

3


eProcurement


CENBII Transactions in PEPPOL


Workshop vision

The CEN/BII Workshop vision is that all organizations, independently of public or private nature, size, or nationality, must be enabled to make electronic business in an efficient and effective manner and with low transaction costs.

2


Workshop mission

The CEN/BII Workshop mission is to spread and facilitate the use of eProcurement standards by suppliers and buyers, including public administrations, by:

supporting the convergence of commonly applied international standards of electronic procurement;

providing a general framework for the organizational and semantic levels of the electronic documents;

identifying the requirements for the eProcurement standards of interoperable tools;

providing organizational support to ensure the maintenance and governance for those requirements.

3


BII objective

Business Interoperability Interfaces for electronic

Procurement in Europe - BIIThe objective of the work in BII is to

“provide a basic framework for interoperability in pan-European electronic transactions, expressed as a set of technical specifications that are compatible and cross-refer to relevant standards in order to ensure global interoperability.”

Interoperability is defined by the European Interoperability Framework,version 2 as “the ability of information and communication technology (ICT) systems and of the business processes they support to exchange data and to enable the sharing of information and knowledge”

8

European Interoperability Framework, version 2

BII

4


BII2 currently have 24 organizations from 9 different countries registered as workshop participants

These organizations have so far nominated 68 experts to contribute to our work.

BII2 workshop Key Facts and Figures

Type of organization Number of participants

National stakeholder 7

National or international organisation 10

IT-provider, supplier, etc. 9


2007 2008 2009 2010 2011 2012

Q1

Q2

Q3

Q4

Q1

Q2

Q3

Q4

Q1

Q2

Q3

Q4

Q1

Q2

Q3

Q4

Q1

Q2

Q3

Q4

Q1

Q2

Q3

Q4

Production

PEPPOL

PEPPOL + BII = true

The timeline of PEPPOL and BII2 are synchronized so that BII could benefit from the lessons learned in PEPPOL before publishing the results from BII2.

10

BII1 BII2

Production pilotTest pilot

PoC

BII profiles

Joint work

Lesonslearned

13


BII addresses the whole eProcurement process

The specifications provided by BII support the whole procurement process

from publication of the Prior Information Notice through to the final Invoice.

Based on, and supports, relevant EU directives

116


Profile key components

Business process

The behaviour of two or more Business Partners in order to achieve a common business goal.

Process could be sourcing, ordering or billing

Collaboration

Business collaboration describes in detail the choreography of message exchange between two or more involved partners. Business partners take part in a business collaborations by playing an authorized role in it.

Can be linked together to form business processes (such as dispute invoice, order cancellation)

Transaction

A business transaction is used to inform/synchronize/request the trading partner of an event. (Submit order, request delivery, request qoute)

The transaction defines a set of data (information entities), relevant to the activity

Syntax message

A electronic message containing marked up information entities

class Metamodel Class diagr...

Profile

Business Process Business partner

Authrized Role

Business Transaction

Business Collaboration

Business rules

Transaction Data Model

Syntax message

Information Element

Process rules

Information constraints

Syntax element

+carries 1..*

+Mapsto

1..*

+Commitsto1..*

+Commits

2

+Governs0..*

+Contains 1..*

+Used in

1..*

+Requires

1..*

+Participatein

1..*

+Carriedout by

1..*

+Is part of

1..*

+Contains

1..*

+Is playedby

1

+Acts in 1..*

+Implementedby1..*

+Impelements

1..*

+Usedin

1..*

+uses

1..*

+ispart of1

+contains

1..*

+Is acomponent of

1..*

+Defineschoreography of

1..*

1..*

+Governs

1..*

0..*

+Governs

0..*

+Contains 0..*

+Used in 1..*

+is constrainedby

0..*

+applies to

1..*

+Carried out by

2

+Participatein1..*

BII03 Ordering

BII04 Invoice only

BII05 Billing

BII06 procurement

Profile migration

Ordering Invoicing Dispute resolution

Invoicing

Ordering

Dispute resolutionInvoicing

OrderingSimple reply Line reply

Counter offer reply Invoicing Dispute

Dispute resolution Dispatch

BII19 - Advanced Procurementx x x x x x x

BII13 - Advanced Procurement with dispatch

x x x x x x x x

Many profiles

Catalogues, statement, ofl.• BII01 - Catalogue only • BII02 - Catalogue update • BII17 - Multi party catalogue • BII16 - Catalogue deletion • BII23 - Invoice only with dispute • BII09 - Customs Bill • BII15 - Scanned Invoice • BII18 - Punch-out • BII20 - Customer Initiated Sourcing • BII21 - Statement

Tendering, support tools• BII10 - Tender Notification • BII11 - Qualification • BII12 - Tendering Simple • BII14 - Prior Information Notice • BII22 - Call for Tender

• BII24 - Attachment Document • BII25 - Status Request • BII26 - Retrieve Business Document


PEPPOL BIS? What is that?

The set of formal requirements for ensuring interoperability of pan-European Public eProcurement are specified as PEPPOL Business Interoperability Specifications (BIS).

PEPPOL uses extensions i.e. adds Business Rules, to meet the PEPPOL specific Legal and Organisational Requirements

A BIS is a guideline that specifies how a CEN/BII profile should be implemented in the PEPPOL context


Documentation


Online resources

CENBII Profiles and supporting documentationhttp://www.cen.eu/cwa/bii/specs/

PEPPOL BIS and supporting documentationhttp://www.peppol.eu/work_in_progress/wp5-einvoicing/results

Online validation toolhttp://www.invinet.org/recursos/conformance/invoice-validation.html

http://www.cen.eu/cwa/bii/specs/



http://www.peppol.eu/work_in_progress/wp5-einvoicing/results



http://www.invinet.org/recursos/conformance/invoice-validation.html

http://www.invinet.org/recursos/conformance/invoice-validation.html


Validation of XML messages

Make money

Good relations

Follow laws

Simplify work

Be faster, more agile

Be productive

Need automated invoice matching

Need to route information to the

correct person

Need to get a response on an

order

Need to know the delivery address

Need to know when to deliverNeed to have tax

information

Trading Partner Goals

Requirements on the electronic collaboration so that goals can be fulfilled

Can be defined and enforced by business rules

Total amount should be the sum of the line amounts

The Invoice must refer to the order

The Invoice must be issued after

deliveryThe supplier must

accept or reject the order

The delivery date must be stated

Make money

Good relations

Follow laws

Simplify work


Be productive



correct person

Need to get a response on an order


Need to know when to deliver

Need to have tax information

Total amount should be the sum of the line

amounts


The Invoice must be issued after delivery

The supplier must accept or reject the

order


Trading Partner Goals

Requirements on the electronic collaboration so that goals can be fulfilled

Can be defined and enforced by business rules

Business rules can be expressed in many ways

class Class Model

Fore cast

- GT IN- Supplier- Store Chain- Promoti onCode- Delivery Start Date Wholesaler- Delivery End Date Wholesaler- Delivery Start Date Store- Ordering Unit- Promotion Forecast Quantity- Confirmed Promotion Forecast Quantity- Total Forecast Quantity- Confirmed Total Forecast Quantity- Purchase Forecast Quantity- Confirmed Purchase Forecast Quantity

Forecas t Line

- Line Number: int

Foreca st Information

Forecast Header

- Foreca st ID- Issue Date- Sender??- Receiver??

UML or CCTS Data models (relationships, cardinalities)

act Activ ity diagram

Econom ic OperatorPurchasing Authori ty

Create andsend order

Order Receiv e andprocess order

Create & sendorder response

simple

OrderRespo nseSim pleReceiv e & process

Order ResponseSimple

Cancel OrderWait forDeliv ery

Continueprocessing

order

Create andsend Inv oice

Invo iceReceiv e &

processInv oice

Arrange payment

Create and sendApplicationResponse

Appl ication Response Receiv e and processApplication Response

Create and sendCredit Note

Create & sendInv oice (+1)

Receiv e andprocess Inv oice

(+1)

Arrangepayment

Invo ice

Credi t Note

Credi tNote Create andsend Credit

Note

Create & sendInv oice

Receiv e &process Credit

Note

Receiv e &processInv oice


note

Arrangepayment

Invo ice

Accept order

Invoice/Orderm atch - accept

Invoice/Orderm ism atch re ject

Underc harge

Order re jected Order a ccepted

Reject order

Overc harge

Process diagramsBusiness term names, definitions and data types.

Regular descriptive text

Guiding texts for rules that are not sutable for formal descriptions

Make mone

y

Good relatio

ns

Follow

laws

Simplify

work


Be product

ive



correct person

Need to get a response on an

order


Need to know when to deliver

Need to have tax information

Total amount should be the sum of the line amounts


The Invoice must be issued after delivery

The supplier must accept or reject the

order


class Class Model

Fore cast

- GT IN- Supplier- Store Chain- Promoti onCode- Delivery Start Date Wholesaler- Delivery End Date Wholesaler- Delivery Start Date Store- Ordering Unit- Promotion Forecast Quantity- Confirmed Promotion Forecast Quantity- Total Forecast Quantity- Confirmed Total Forecast Quantity- Purchase Forecast Quantity- Confirmed Purchase Forecast Quantity

Forecas t Line

- Line Number: int

Foreca st Information

Forecast Header

- Foreca st ID- Issue Date- Sender??- Receiver??

act Activ ity diagram

Economic OperatorPurchasing Authori ty

Create andsend order

Order Receiv e andprocess order

Create & sendorder response

simple

OrderRespo nseSimpleReceiv e & process

Order ResponseSimple

Cancel OrderWait forDeliv ery

Continueprocessing

order

Create andsend Inv oice

Invo iceReceiv e &processInv oice

Arrange payment

Create and sendApplicationResponse

Application Response Receiv e and processApplication Response

Create and sendCredit Note

Create & sendInv oice (+1)

Receiv e andprocess Inv oice

(+1)

Arrangepayment

Invo ice

Credit Note

Credi tNote Create andsend Credit

Note

Create & sendInv oice


Note

Receiv e &processInv oice


note

Arrangepayment

Invo ice

Accept order

Invoice/Ordermatch - accept

Invoice/Ordermismatch reject

Undercharge

Order rejected Order a ccepted

Reject order

Overcharge

Regular descriptive text

Business rules expressed in various formats

An actual XML-message can be tested/validated against business rules using several techniques

XSD Schemas Schematron, Stylesheet rules

Executable tools

Business rules

Requirements

Goals

CENBII Profiles and Transactions

UBL XM

L Schema *

BII Schematron

PEPPOL Schem

atron

National Schem

atron

PEPPOL BIS

National additional rules

* For PEPPOL - Currently only UBL, can be additional in the future

Company(schematron)

Industry(schematron)

National (schematron)

Profile required information (schematron)

Core document (schematron)

Technical structure(schema)

Layered validations

Profile compliance

Extensionmethodology Based on agreement


Schematron

• Schematron can be used to perform more advanced and dynamic checks than XML Schema

• Calculations, dependency rules, check sums, code validation

• The Schematron rules can be executed as is by tools

• Or they can be transformed into XSLT. The XSLT is then applied to the XML-instance file.

Schematron and XML Schemas should be used in combination

• XML Schema to test structure and format

• Schematron to test calculations and dependencies

PEPPOL technical components

Access point

Application Interface

Application Interface

ApplicationAccess point

ValidationTransformation LIMEInterface

Validation TransformationLIMEInterface

Following BII Profiles

Following BII Profile

OtherInterface

OtherInterface

STARTSML

SMP

SMP


Provider Agreements and Governance


ContractingAuthority

EconomicOperator

AP

SMPSMP

SML

AP

CoordinatingAuthority

RegionalAuthority

Regionaldomain

Regionaldomain

Two levels of governance

Provides European wide governance for:the PEPPOL Technical Standards

the PEPPOL Service Specifications

the PEPPOL SML

the PEPPOL Agreements

Provides regional governance for:the implementation and use of the transport infrastructure

the legal framework for specific AP and SMP agreements

specific requirements applicable within a domain


PEPPOL Transport Infrastructure Agreements

The aim of the PEPPOL Transport Infrastructure Agreements is to regulate the roles and responsibilities of the actors involved in the governance and operation of the PEPPOL transport infrastructure.

Three separate agreements with a common set of annexes.1. Contact points

2. Definitions

3. Service and Service Levels

4. Technical Standards

5. Regional domain and its specific services and service levels

6. Change Procedures

7. The PEPPOL Governance Model and model agreements


Key principles

Inspired by other initiatives, but reflects the uniqueness of the PEPPOL initiative:

An open community where interoperability is achieved through common specification and not point-to-point agreements.

The PEPPOL Transport Infrastructure Agreements provides governance for the PEPPOL Transport Infrastructure based on:

a European wide coordination over all common components of the transport infrastructure;

a regional coordination and supervision of the implementation and use of the transport infrastructure within a domain; and

open and transparent provision of SML, SMP and AP services based on a common set of agreements as well as common definition of services and service levels.


Service Levels

Access Points

98,5% availability during business hours94% availability during the remaining time

SMP

98,5% availability during business hours94% availability during the remaining time

Defined contact points

Reporting to Regional Authority in case of major faults (more than 4 hours down-time)

It is free for providers to deliver higher levels of availability (and charge for the added value to their customer). It is not allowed to charge other APs participants/customers. See more details about this in the provider agreements.

PEPPOL is free from roaming-charges between AP's and SMP's


Questions…

PEPPOL is an EU co-funded project CIP-ICT PSP-2007 No 224974www.peppol.eu

eProcurementwithout borders in Europe

www.peppol.eu

peppol online ws. 4 and 5 cenbii transactions in peppol

Technology

public management

euwide public eprocurement50

eu contribution

european competitiveness

egovernment dificonsortium

norwegian agency

peppolmartin forsberg

countriestotal budget