Electronic Data Interchange

Electronic Data Interchange

188.422 E-Commerce Technologien

Philipp Liegl

Agenda

2

EDI motivation and definition

EDI standards

UN/EDIFACT: syntax and directories

EDI: chances and pitfalls

MIG: message implementation guide

Outlook

EDI for everyone?

3

Business

Administration

Consumer

A2A

B2C

C2C

B2B

A2C

B2A

Different forms of data exchange

4

Direct and vocal

Usually during a face-to-face communication

Mimic and gestural expression underpin the communication procedure

Common context

Vocal using a transport channel

e.g. via radio or mobile phones

focus on the spoken word

Using scripture

letters, books etc.

»

EDI in this context?

The goal of Electronic Data Interchange – Exchange of business related data independent of software, hardware and communication protocols.

Application

Application

User

User

User

Application

Email

IM

SMS

…

XML messages

Web Forms

…

EDIFACT

UBL

SWIFT

CIDX

…

B2C vs. B2B

6

B2CServer dominates the business processConsumer reacts on the flyB2BApplications must interact with each otherApplications must follow an agreed business process (UMM)business document structure (CCTS)

6

B2C – Client-Server Computing

7

Messaging Layer

Presentation Layer

Web

Application

Server

Databases

ERP Systems

Legacy Applications

Persistence Layer

Client

HTTP request

HTTP response

Business Layer

B2B Application Computing

Messaging Layer

Document Layer

Business Layer

B2B Application Server

Messaging Layer

Document Layer

Business Layer

B2B Application Server

SOAP request over

HTTP, SMTP, ...

Common Process Logic

Databases

ERP Systems

…

Persistence Layer

Common Document Logic

Databases

ERP Systems

…

Persistence Layer

Agenda

9

EDI motivation and definition

EDI standards

UN/EDIFACT: syntax and directories

EDI: chances and pitfalls

MIG: message implementation guide

Outlook

EDI – define a format for the exchange of information between applications

10

EDI

EDI standards

11

A

B

C

D

E

EDI standards

12

A

B

C

D

E

A

B

C

D

E

Standard

Format

EDI standards

13

Syntax rules which define the allowed characters and their order of occurrenceCodes (a vocabulary of allowed values)Message design defining the structure of information

EDI standards cont'd

14

industry specific

industry independent

regional

international

ANSI X.12

ODETTE

SWIFT

UN/EDIFACT

Is every standard an EDI standard?

15

6d803ef64568e0191a85500f103ec39<items><item>Book</item></items>1010111101011000010100111110011101010\BPR*C*77.77*C*ACH*CTX*01*234056789*DA*0099109999* MSH|^~\&||GA0000||VAERS PROCESSOR|20010331605||ORU^RO1|20010422GA03|T|2.3.1|||AL|

ANSI X.12

HL7

EAN

XML

Standards are defined on many different levels and in

many different domains, however not every standard is an EDI standard.

base-16

binary

EDI and OSI

16

http://www.telecommunications-tutorials.com

United Nations Electronic Data Interchange for Administration, Commerce, and Transport – UN/EDIFACT

17

UN/CEFACT =

United Nations Center for Trade Facilitation and Electronic Business

The United Nations and e-Business?

18

To maintain international peace and securityTo develop friendly relations among nations To achieve international co-operation

The organization of UN/CEFACT

19

United Nations

International

Court of Justice

SecurityCouncil

GeneralAssembly

Economic AndSocial Council

TrusteeshipCouncil

Secretariat

WTO (Trade)

WHO (Health)

WBG (Bank)

WCO (Customs)

UN/ECE

…

UN/CEFACTCentre for the Facilitation of Procedures and Practicesin Administration, Commerce and Transport

TMGTechniques and Methodologies Group

TBGInternational Trade & Business Processes Group

ICGInformation ContentManagement Group

LGLegal Group

ATGApplied Technologies Group

UN/CEFACT Forum

Committee for the Development of Trade,Industry and Enterprise Development

The organization of UN/CEFACT cont'd

1 February 2008

International Trade

and Business

Processes Group

Applied Technology

Group

Information Content

Management Group

Techniques and

Methodologies Group

Legal Group

Domains:

Accounting & Audit - Agriculture - Architecture, Engineering & Construction - Business Process Analysis - Customs -

eGovernment - Electronic Trade Documents - Environmental Management - Finance - Harmonization - Health Care -

Insurance - International Trade Procedures - Social Services - Statistics Collection and Reporting - Supply Chain -

Transport - Travel, Tourism and Leisure

Plenary Chair

___________________Bureau

FMGForumManagement Group

UNECE

Secretariat

UN/CEFACT Forum

UN/CEFACT Plenary

The International Trade & Business Process Groups (TBGs)

Ministry of International Commerce, Rome

21

Known standards from UN/CEFACT

22

UN/EDIFACT

ebXML

UMM & CC

UN Layout Key

The UN Layout Key

23

Agenda

24

EDI motivation and definition

EDI standards

UN/EDIFACT: syntax and directories

EDI: chances and pitfalls

MIG: message implementation guide

Outlook

The four pillars of EDIFACT

25

EDI

Syntax

Data

elements

Messages

UN/EDIFACT

D

ata

exchange

Segments

UN/EDIFACT

26

Syntax

Rules for the definition of a message structure

Standardized codes

Data elements

Smallest data unit

Segments

Groups of related data elements

Messages

Ordered sequence of segments

Defines a business transaction

Common paper vs. EDIFACT standard

27

Predefined formFields of the formChoices/EnumerationsContext specific groups of fields and compartmentsLogical grouping between the different groupsIdentification using a fixed form text

EDI message

Data

element

Coded data elements

Segments

Segment

groups

EDI syntax

EDIFACT specifics

28

Hierarchically structured

Data element identification

Delimiter based

Data fields with fixed length

Mandatory and conditional status of data elements and segments

EDIFACT subsets

29

EDIFICE

EDITRANS

ODETTE

EDITEX

EDITEC

ETIS

CEFIC

EDIFURN

EDIFOR

EDIGAS

EANCOM

30

Batch

EDIFACT at a glance

Batch vs. interactive EDIFACT

31

Batch interchanges

Like a letter: stand-alone, includes related topics relevant to the addressee

May invite a reply at a later date

Have control sequences that begin with "UN" such as

UNA, UNB, UNG, UNH, UNT, UNE, and UNZ

Interactive interchanges

Like a telephone conversation

Addressing topics in sequence

Have control segment that begin with "UI" such as

UIB, UIG, UIH, UIT, UIE, and UIZ.

There is no UIA segment corresponding to the batch UNA segment.

See "

Interactive EDI – IT and commerce in the 21

st

century

" by A.P. Barrett for a deeper discussion (available in the IEEE library)

Simple Data Elements – specified in EDED

32

Change indicators

a plus sign (+) for an addition

an asterisk (*) for an amendment to structure

a hash sign (#) for changes to names

a vertical bar (|) for changes to text for descriptions and

notes

a minus sign (-) for marked for deletion (within either

batch or interactive messages)

a letter X (X) for marked for deletion (within both batch

and interactive messages)

Usage indicators

[B] = used in batch messages only

[I] = used in interactive messages only

[C] = common usage in both batch and interactive messages

Simple Data Elements

33

3164 City Name [C] (= both batch & interactive)

Desc

: Name of a city

Repr

: an..35

Example: Vienna

2380 Date or time or period text [C]

Desc

: The value of a date, a date and time, a time or of a period in a specified representation.

Repr

: an..35

Example: Date the invoice arrived

Example: 20081212

2031 Time variation quantity [I] (= interactive only)

Desc

: To specify a time variation.

Repr

: n..3

Example: 1

Simple Data Elements with Code Lists

34

2379 Date or time or period format code

Desc

: Code specifying the representation of a date, time or period.

Repr

: an..3

Example: 2

Code Values:

2 DDMMYY Calendar date: D = Day; M = Month; Y = Year.

3 MMDDYY Calendar date: M = Month; D = Day; Y = Year.

204 CCYYMMDDHHMMSS Calendar date including time with seconds: C=

Century;Y

=Year; M=

Month;D

=

Day;H

=

Hour;M

=

Minute;S

=Second.

[…]

Composite Data Element

35

C507 DATE/TIME/PERIOD

Desc

: Date and/or time, or period relevant to the specified date/time/period type.

010 2005 Date or time or period function code qualifier M an..3

020 2380 Date or time or period text C an..35

030 2379 Date or time or period format code C an..3

C507 example

36

3:120499:2

3

= Invoice document issue date time

120499 = 12. April 1999

2 = DDMMYY Calendar date: D = Day; M = Month; Y = Year

5:990412:101

5 = A period of time when saleable stocks are expected to cover demand for a product.

990412 = 12. April 1999

101 = YYMMDD Calendar date: Y = Year; M = Month; D = Day.

37

NAD NAME AND ADDRESS010 3035 PARTY FUNCTION CODE QUALIFIER M 1 an..3 020 C082 PARTY IDENTIFICATION DETAILS C 1 3039 Party identifier M an..35 1131 Code list identification code C an..17 3055 Code list responsible agency code C an..3 030 C058 NAME AND ADDRESS C 1 3124 Name and address description M an..35 3124 Name and address description C an..35 3124 Name and address description C an..35 3124 Name and address description C an..35 3124 Name and address description C an..35 040 C080 PARTY NAME C 1 3036 Party name M an..35 3036 Party name C an..35 3036 Party name C an..35 3036 Party name C an..35 3036 Party name C an..35 3045 Party name format code C an..3 050 C059 STREET C 1 3042 Street and number or post office box identifier M an..35 3042 Street and number or post office box identifier C an..35 3042 Street and number or post office box identifier C an..35 3042 Street and number or post office box identifier C an..35 060 3164 CITY NAME C 1 an..35 070 C819 COUNTRY SUBDIVISION DETAILS C 1 3229 Country subdivision identifier C an..9 1131 Code list identification code C an..17 3055 Code list responsible agency code C an..3 3228 Country subdivision name C an..70 080 3251 POSTAL IDENTIFICATION CODE C 1 an..17 090 3207 COUNTRY IDENTIFIER C 1 an..3

Segment

Segment example

38

Buyer: Institute of Software Technology and Interactive Systems, Vienna University of TechnologyFavoritenstraße 9-11/188-31040 Vienna, AustriaNAD+BY++Institute of Software Technology:and Interactive Systems:Vienna University of Technology:Favoritenstraße 9-11/188-3:1040 Vienna, Austria’NAD+BY+++Institute of Software Technology:and Interactive Systems:Vienna University of Technology+Favoritenstraße 9-11/188-3+ Vienna++1010+AT’

Segments are assembled to messages.

Segment Groups

39

Aggregating

several

segments

to

groups

0160 ----- Segment

group

3 ------------------ C 99---------+|

0170

RFF

Reference M 1 ||

0180

DTM

Date/time/

period

C 5----------+|

Possible examples:

RFF-DTM-DTM-DTM-DTM-RFF-DTM-DTM

RFF

RFF-RFF-RFF

40

0010 UNH Message header M 1 0020 BGM Beginning of message M 1 0030 DTM Date/time/period M 35 0040 PAI Payment instructions C 1 0050 ALI Additional information C 5 0060 IMD Item description C 999 0070 FTX Free text C 99 0080 GIR Related identification numbers C 10 0090 ----- Segment group 1 ------------------ C 9999--------+0100 RFF Reference M 1 |0110 DTM Date/time/period C 5-----------+0120 ----- Segment group 2 ------------------ C 99----------+0130 NAD Name and address M 1 |0140 LOC Place/location identification C 99 |0150 FII Financial institution information C 5 | |0160 ----- Segment group 3 ------------------ C 99---------+|0170 RFF Reference M 1 ||0180 DTM Date/time/period C 5----------+| |0190 ----- Segment group 4 ------------------ C 5----------+|0200 DOC Document/message details M 1 ||0210 DTM Date/time/period C 5----------+| |0220 ----- Segment group 5 ------------------ C 5----------+|0230 CTA Contact information M 1 ||0240 COM Communication contact C 5----------++

Segment table message typeORDERS

Trigger Segments

Branching Diagram ORDERS

41

Order

42

Institute of Software Technology and Interactive SystemsVienna University of TechnologyFavoritenstraße 9-11/188-3A-1040 Wien

Hardware & Software GmbHWiedner Hauptstraße 12/81040 Wien

Bestellnr.: 123321 Bestelldatum: 12. März 1999 Lieferdatum: 3. Mai 1999Agent: Hugo Heuschreck

EAN-Nummer Artikel Menge Einh. ÖS/Einh. ÖS Gesamt34567892189 Sun-Workstation Sparc 10 3 Stück 200.000 600.00098754390211 Compaq Pentium 10 Stück 40.000 400.000

1.000.000

200.000

1.200.000

ORDERS – full example according to directory D93A

43

UNH

+ME0000001+ORDERS:D:93A:UN’

BGM

+220+123321’

DTM

+137:990312:101’

DTM

+2:990503:101’

NAD

+BY+++Institute of Software

Technology:and

Interactive

Systems:Vienna

University of

Technology+Favoritenstraße

9-11/188-3+ Vienna++1010+AT’

CTA

+PE:HH:Hugo

Heuschreck

’

NAD

+SE+++Hard & Software

GmbH+Wiedner

Hauptstrasse

12/8+Vienna++

1040+AT’

TAX

+7+VAT+++20

CUX

+2:ATS:9’

LIN

+1++34567892189:EN::9’

QTY

+21:3:EA’

PRI

+AAA:200000:PE’

LIN

+2++98754390211:EN::9’

QTY

+21:10:EA’

PRI

+AAA:40000:PE’

UNS

+S’

MOA

+86:1200000’

UNT

+18+ME0000001’

Every EDIFACT message type is defined in a unique manner:

44

CONTENTS

Purchase order message

0. INTRODUCTION

1.SCOPE

1

.1 Functional definition

1.2 Field of application

1.3 Principles

2. REFERENCES

3. TERMS AND DEFINITIONS

3.1 Standard terms and definitions

4. MESSAGE DEFINITION

4.1 Segment clarification

4.1.1 Header section

4.1.2 Detail section

4.1.3 Summary section

4.2 Segment index (alphabetical sequence by tag)

4.3 Message structure

4.3.1 Segment table

UN/EDIFACT Directories

45

90.190.291.191.292.1

93.293.S93.WS.93A

D.93AD.94AD.94BD.95AD.95B…D.07A

See also:

http://www.unece.org/trade/untdid/directories.htm

Sequences – right or wrong?

46

(1)

DOC+...’NAD+...’RFF+...’AJT+...’DOC+...’NAD+...’MOA+...’TAX+...’DTM+...’AJT+...’RFF+...’DOC+...’

(2)DOC+...’MOA+...’PAI+...’STS+...’AJT+...’RFF+...’FTX+...’DOC+...’RFF+...’MOA+...’TAX+...’DTM+...’

(3)DOC+...’DOC+...’NAD+...’RFF+...’MOA+...’DTM+...’STS+...’DOC+...’MOA+...’AJT+...’RFF+...’RFF+...’

(4)DOC+...’DTM+...’DOC+...’NAD+...’MOA+...’DOC+...’MOA+...’DTM+...’AJT+...’RFF+...’FTX+...’FTX+...’

(5)

DOC+...’

MOA+...’

DOC+...’

NAD+...’

RFF+...’

DOC+...’

MOA+...’

AJT+...’

AJT+...’

DTM+...’

AJT+...’

RFF+...’

Collisions

47

UNH Message Header M 1... ----- Segment group 2 ------------------ C 20 --------+NAD Name and Address M 1 |LOC Place/Location identification C 9 |FII Financial institution information C 5 | | ----- Segment group 3 ------------------ C 9----------+ |RFF Reference M 1 | |DTM Date/time/period C 5 ---------+ | | ----- Segment group 4 ------------------ C 9----------+ |FII Financial institution information M 1 | |PAI Payment Instructions C 5 ---------+ |

Agenda

48

EDI motivation and definition

EDI standards

UN/EDIFACT: syntax and directories

EDI: chances and pitfalls

MIG: message implementation guide

Outlook

PRO EDIFACT

49

Shorter transaction times

Lower transaction costs

Reduction of recurring data collection – fault reduction

Lower staff costs

Better planning

Optimization potential through innovative processes

Just-in-Time (JIT) Production

Lower stocks

Reduction of paper based document transfer

Cost reduction in terms of document handling

CONTRA EDIFACT

50

Rather old-fashioned standard

Verbose

Inflexible

Change requests last rather long

Newer solutions (XML-based) provide greater flexibility

Tool vendor support for COTS (Commercial of the shelf) software rather low

EDIFACT interfaces are expensive

"BIG players only please"

Was EDI successful overall?

51

The rest of all business that should be

exchanging information electronically

FORTUNE 10000

(1000 in the top 10 Economics)

95%

5%

Using EDI

EDI Capable

2%

98%

Klaus-Dieter Naujok, 1999

Agenda

52

EDI motivation and definition

EDI standards

UN/EDIFACT: syntax and directories

EDI: chances and pitfalls

MIG: message implementation guide

Outlook

Business Document Standards

A

B

C

D

E

A

B

C

D

E

Standard

Format

Standard:

Standard

Message

Implementation

Guide

(MIG):

MIG

User Group

MIG

Company

MIG

Partner-specific

Syntax

Building Blocks

Content

Message Implementation Guide

54

Subset of an EDIFACT message for a certain domain/industry/application scenario

Example: MBS-PAYMUL message

Defined Subset of PAYMUL message

Entire EDIFACT rules are reflected in the standard

Only segments and segment groups are marked as

not used

which are conditional in the PAYMUL message

More information:

http://www.stuzza.at/1577_DE.pdf

Agenda

55

EDI motivation and definition

EDI standards

UN/EDIFACT: syntax and directories

EDI: chances and pitfalls

MIG: message implementation guide

Outlook

The UNeDOCs Project

56

"A generic methodology to link the paper based business world with the electronic business world"

Provide a smooth migration towards Digital Paper

Electronic successor of the paper based UN Layout Key

Combine a set of existing standards

Core Components

EDI

XML

Document presentation guidelines

The UNeDOCs initiative

57

Paper Document

aligned to UN Layout Key

XML or UN/EDIFACT

Electronic Edit Form

Business documents in a service oriented world

58

How serious is the problem?

59

Problems of current approaches

60

Multiple efforts for document standardization exist – most of them are incompatible to each other

Inclusion of every possible element leads to a strong overhead

Transfer syntax specific standards may require difficult reengineering

Logical level business document definitions are difficult to communicate between developers and stakeholders

Cross-industry and cross-domain integration is mostly not reflected

A promising global standard for business document definition exists: UN/CEFACT‘s Core Components Technical Specification

UN/EDIFACT

Web ServicesWindows Workflow…

UN/CEFACT's ModelingMethodology (UMM)Core Components Technical Specification (CCTS)

Functional Service View related standards

Business Operational View related standards

The Open-edi Reference Model – ISO 14662

Business Transactions

Business aspects

of business transactions

Information technology

aspects of businesstransactions

viewed

as

comply

with

covered

by

covered

by

comply

with

transformed

to

Business Operational View

Functional Service View

Core Components at a glance

63

Reusable building blocks for building business documentsBased on a common semantic basisContext mechanism for industry/domain specific documentsFlaw:Core components are a theoretical concept

Core Components cont'd

64

Are the

central building blocks

of the Core Component Technical Specification (CCTS)

Platform independent

Used

to create shared libraries

of interoperable business documents

The

ontological base

of the CCTS is the United Nations Trade Data Element Dictionary (UN/TDED)

Initially started as part of ebXML standards suite

Now a dedicated project independent of ebXML

Core Component (CC) example

65

No business contextIndependent of industry or domain

ACC

Aggregate Core Component

BCC

Basic Core Component

ASCC

Association Core Component

Business Information Entity (BIE) example

66

Core Components in a specific business context (e.g. travel industry)BIEs have a specific business semanticQualifiers (US_) help to define and differentiate a BIE from its associated CC and other BIEs

ABIE

Aggregate Business Information Entity

BBIE

Basic Business Information Entity

ASBIE

Association Business Information Entity

By introducing the business context, core components become business information entities

67

Core Components (CC)

Business Information

Entities (BIE)

BIEs are derived from CCs by restriction

Dependency between Core Components and Business Information Entities

68

Business Data Types (BDT) and Core Data Types (CDT)

69

Business Data Types (BDT) are derived from Core Data Types (CDT) by restrictionBusiness Information Entities use Business Data TypesCore Components use Core Data Types

Data Types cont'd

70

A data type consists of exactly one content component (CON)and multiple supplementary components (SUP)Content components contain information e.g. 15Supplementary components contain meta information e.g. temperature, Fahrenheit

Primitive Types (PRIM)

71

Primitive Types (PRIM) are used to set the value type of supplementary components (SUP) and content components (CON)

Enumeration types (ENUM)

72

Enumeration types (ENUM) are used to restrict the value range of supplementary components (SUP) and content components (CON)

The UML Profile for Core Components (UPCC)

73

Flaws of the Core Component Technical Specification

Standardization process of Core Components is based on spread sheets

No direct integration into modeling tools possible

UML Profile for Core Components

Independent project based on the CCTS

Set of

stereotypes

,

tagged values

and

OCL constraints

Can be

integrated into a modeling tool

of choice

Proof of concept based on UML modeling tool Enterprise Architect

UML class diagrams are used for the modeling of Core Components

Current version 1.0 (CCTS 2.01 compliant)

Version 3.0 is about to be released soon (CCTS 3.0 compliant)

Library concept used to aggregate artifacts of the same type

74

UPCC - example

75

holds the actual business

document but can also definenew ABIEs

aggregates ABIEs

aggregates BDTs

aggregates CCs

aggregates ENUM

aggregates PRIMs

76

UPCC

meta

model (

conceptual

)

Core Components – the (rough) big picture

77

UPCC 3.0

CCTS 3.0

UML 2.1

…

…

<xs:element name="…"

…

</xs:element>

complies with

store/

retrieve

retrieve

maintain

submit core component definitions

evalute

definitions/

standardize

definitions

use

model

generate

Core Component model

UN/CEFACT Core Components

Library

User Library

TBG 17

User

Questions?

78

<Lecturer>

<Name>

Philipp Liegl

</Name>

<Company>

Vienna University of Technology

</Company>

<Department>

Business Informatics Group

</Department>

<Address>

<Street>

Favoritenstraße 9-11/188

</Street>

<ZIP>

1040

</ZIP><City>

Vienna

</City>

<Country>

Austria

</Country>

</Address>

<Contact>

<Email>

liegl@big.tuwien.ac.at

</Email>

<Http>

http://www.big.tuwien.ac.at

</Http>

</Contact>

<? Presentation status=“

questions

” ?>

</Lecturer>