Electronic Data Interchange

1
Electronic Data Interchange

• 188.422 E-Commerce Technologien

• Philipp Liegl

2
Agenda

• EDI motivation and definition
• EDI standards
• UN/EDIFACT syntax and directories
• EDI chances and pitfalls
• MIG message implementation guide
• Outlook

3
EDI for everyone?
A2A
Administration
A2C
B2A
C2C
B2B
Business
Consumer
B2C
4
Different forms of data exchange

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

5
The goal of Electronic Data Interchange
Exchange of business related data independent of
software, hardware and communication protocols.
6
B2C vs. B2B

• B2C
• Server dominates the business process
• Consumer reacts on the fly
• B2B
• Applications must interact with each other
• Applications must follow an agreed
• business process (UMM)
• business document structure (CCTS)

6
7
B2C Client-Server Computing
HTTP request
Messaging Layer
HTTP response
Presentation Layer
Client
Web Application Server
Business Layer
Databases
ERP Systems
Legacy Applications
Persistence Layer
8
B2B Application Computing
B2B Application Server
B2B Application Server
SOAP request over HTTP, SMTP, ...
Messaging Layer
Messaging Layer
Document Layer
Document Layer
Common Document Logic
Business Layer
Business Layer


Databases
ERP Systems
Databases
ERP Systems
Persistence Layer
Persistence Layer
9
Agenda

• EDI motivation and definition
• EDI standards
• UN/EDIFACT syntax and directories
• EDI chances and pitfalls
• MIG message implementation guide
• Outlook

10
EDI define a format for the exchange of
information between applications
11
EDI standards
12
EDI standards
13
EDI standards

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

14
EDI standards cont'd
ODETTE
SWIFT
industry specific
ANSI X.12
UN/EDIFACT
industry independent
regional
international
15
Is every standard an EDI standard?
base-16

• 6d803ef64568e0191a85500f103ec39
• ltitemsgtltitemgtBooklt/itemgtlt/itemsgt
• 1010111101011000010100111110011101010
• \BPRC77.77CACHCTX01234056789DA0099109999
  
• MSH\GA0000VAERS PROCESSOR20010331605ORU
  RO120010422GA03T2.3.1AL

XML
binary
ANSI X.12
EAN
HL7
Standards are defined on many different levels
and in many different domains, however not every
standard is an EDI standard.
16
EDI and OSI
http//www.telecommunications-tutorials.com
17
United Nations Electronic Data Interchange for
Administration, Commerce, and Transport
UN/EDIFACT

• UN/CEFACT
• United Nations Center for Trade Facilitation and
  Electronic Business

18
The United Nations and e-Business?

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

19
The organization of UN/CEFACT
United Nations
International Court of Justice
Security Council
General Assembly
Economic And Social Council
Trusteeship Council
Secretariat
WTO (Trade)
WHO (Health)
WBG (Bank)
WCO (Customs)
UN/ECE

Committee for the Development of Trade, Industry
and Enterprise Development
UN/CEFACT Centre for the Facilitation of
Procedures and Practices in Administration,
Commerce and Transport
UN/CEFACT Forum
TMG Techniques and Methodologies Group
TBG International Trade Business Processes
Group
ICG Information ContentManagement Group
LG Legal Group
ATG Applied Technologies Group
20
The organization of UN/CEFACT cont'd
UN/CEFACT Plenary
Plenary Chair ___________________ Bureau
UNECESecretariat
FMG ForumManagement Group
UN/CEFACT Forum
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
1 February 2008
21
The International Trade Business Process Groups
(TBGs)
21
22
Known standards from UN/CEFACT
23
The UN Layout Key
24
Agenda

• EDI motivation and definition
• EDI standards
• UN/EDIFACT syntax and directories
• EDI chances and pitfalls
• MIG message implementation guide
• Outlook

25
The four pillars of EDIFACT
EDI
Data exchange
UN/EDIFACT
26
UN/EDIFACT

• 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

27
Common paper vs. EDIFACT standard

• Predefined form
• Fields of the form
• Choices/Enumerations
• Context specific groups of fields and
  compartments
• Logical grouping between the different groups
• Identification using a fixed form text

• EDI message
• Data element
• Coded data elements
• Segments
• Segment groups
• EDI syntax

28
EDIFACT specifics

• Hierarchically structured
• Data element identification
• Delimiter based
• Data fields with fixed length
• Mandatory and conditional status of data elements
  and segments

29
EDIFACT subsets
30
BatchEDIFACT at a glance
31
Batch vs. interactive EDIFACT

• 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
  21st century" by A.P. Barrett for a deeper
  discussion (available in the IEEE library)

32
Simple Data Elements specified in EDED

• 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

33
Simple Data Elements

• 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

34
Simple Data Elements with Code Lists

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

35
Composite Data Element

• 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

36
C507 example

• 31204992
• 3 Invoice document issue date time
• 120499 12. April 1999
• 2 DDMMYY Calendar date D Day M Month Y
  Year
• 5990412101
• 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
Segment

• NAD NAME AND ADDRESS
• 010 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

38
Segment example

• Buyer
• Institute of Software Technology and Interactive
  Systems, Vienna University of TechnologyFavorite
  nstraße 9-11/188-31040 Vienna, Austria
• NADBYInstitute of Software Technologyand
  Interactive SystemsVienna University of
  TechnologyFavoritenstraße 9-11/188-31040
  Vienna, Austria
• NADBYInstitute of Software Technologyand
  Interactive SystemsVienna University of
  TechnologyFavoritenstraße 9-11/188-3
  Vienna1010AT

Segments are assembled to messages.
39
Segment Groups

• 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
Segment table message typeORDERS
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----------
Trigger Segments
41
Branching Diagram ORDERS
42
Order
Institute of Software Technology and Interactive
Systems Vienna University of Technology Favoritens
traße 9-11/188-3 A-1040 Wien
Hardware Software GmbH Wiedner Hauptstraße
12/81040 Wien
Bestellnr. 123321 Bestelldatum 12. März
1999 Lieferdatum 3. Mai 1999 Agent Hugo
Heuschreck
EAN-Nummer Artikel Menge Einh.
ÖS/Einh. ÖS Gesamt 34567892189 Sun-Workstatio
n Sparc 10 3 Stück 200.000
600.000 98754390211 Compaq Pentium 10 Stück
40.000 400.000
1.000.000
200.000
1.200.000
43
ORDERS full example according to directory D93A

• UNHME0000001ORDERSD93AUNBGM220123321D
  TM137990312101DTM2990503101NADBYInst
  itute of Software Technologyand Interactive
  SystemsVienna University of TechnologyFavoritens
  traße 9-11/188-3 Vienna1010ATCTAPEHHHugo
  HeuschreckNADSEHard Software GmbHWiedner
  Hauptstrasse 12/8Vienna1040ATTAX7VAT20
  CUX2ATS9LIN134567892189EN9QTY213E
  APRIAAA200000PELIN298754390211EN9QT
  Y2110EAPRIAAA40000PEUNSSMOA86120000
  0UNT18ME0000001

44
Every EDIFACT message type is defined in a unique
manner
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
45
UN/EDIFACT Directories
90.1 90.2 91.1 91.2 92.1
93.2 93.S 93.W S.93A
D.93A D.94A D.94B D.95A D.95B D.07A
See also http//www.unece.org/trade/untdid/direct
ories.htm
46
Sequences right or wrong?
(1) DOC... NAD... RFF... AJT... DOC... N
AD... MOA... TAX... DTM... AJT... RFF..
. DOC...
(2) DOC... MOA... PAI... STS... AJT... R
FF... FTX... DOC... RFF... MOA... TAX..
. DTM...
(3) DOC... DOC... NAD... RFF... MOA... D
TM... STS... DOC... MOA... AJT... RFF..
. RFF...
(4) DOC... DTM... DOC... NAD... MOA... D
OC... MOA... DTM... AJT... RFF... FTX..
. FTX...
(5) DOC... MOA... DOC... NAD... RFF... D
OC... MOA... AJT... AJT... DTM... AJT..
. RFF...
47
Collisions
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
---------
48
Agenda

• EDI motivation and definition
• EDI standards
• UN/EDIFACT syntax and directories
• EDI chances and pitfalls
• MIG message implementation guide
• Outlook

49
PRO EDIFACT

• 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

50
CONTRA EDIFACT

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

51
Was EDI successful overall?
Using EDI
EDI Capable
95
98
2
5
FORTUNE 10000
The rest of all business that should be
exchanging information electronically
(1000 in the top 10 Economics)
Klaus-Dieter Naujok, 1999
52
Agenda

• EDI motivation and definition
• EDI standards
• UN/EDIFACT syntax and directories
• EDI chances and pitfalls
• MIG message implementation guide
• Outlook

53
Business Document Standards
Standard

• Syntax
• Building Blocks
• Content

54
Message Implementation Guide

• 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

55
Agenda

• EDI motivation and definition
• EDI standards
• UN/EDIFACT syntax and directories
• EDI chances and pitfalls
• MIG message implementation guide
• Outlook

56
The UNeDOCs Project

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

57
The UNeDOCs initiative
XML or UN/EDIFACT
Paper Document aligned to UN Layout Key
Electronic Edit Form
58
Business documents in a service oriented world
59
How serious is the problem?
60
Problems of current approaches

• 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/CEFACTs Core Components
  Technical Specification

61
(No Transcript)
62
The Open-edi Reference Model ISO 14662
UN/CEFACT's ModelingMethodology (UMM) Core
Components Technical Specification (CCTS)
Business Operational View related standards
Business Operational View
comply with
Business aspects of business transactions
Business Transactions
coveredby
viewed as
transformed to
Functional Service View
comply with
Functional Service View related standards
Information technology aspects of
business transactions
UN/EDIFACT Web Services Windows Workflow
coveredby
63
Core Components at a glance

• Reusable building blocks for building business
  documents
• Based on a common semantic basis
• Context mechanism for industry/domain specific
  documents
• Flaw
• Core components are a theoretical concept

64
Core Components cont'd

• 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

65
Core Component (CC) example

• No business context
• Independent of industry or domain

ACC Aggregate Core Component BCC Basic Core
Component ASCC Association Core Component
66
Business Information Entity (BIE) example

• Core Components in a specific business context
  (e.g. travel industry)
• BIEs have a specific business semantic
• Qualifiers (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
67
By introducing the business context, core
components become business information entities
Core Components (CC)
Business Information Entities (BIE)
BIEs are derived from CCs by restriction
68
Dependency between Core Components and Business
Information Entities
69
Business Data Types (BDT) and Core Data Types
(CDT)

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

70
Data Types cont'd

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

71
Primitive Types (PRIM)

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

72
Enumeration types (ENUM)

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

73
The UML Profile for Core Components (UPCC)

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

74
Library concept used to aggregate artifacts of
the same type
75
UPCC - example
holds the actual business document but can also
define new ABIEs
aggregates ABIEs
aggregates BDTs
aggregates CCs
aggregates ENUM
aggregates PRIMs
76
UPCC meta model (conceptual)
77
Core Components the (rough) big picture
evalute definitions/ standardize definitions
maintain
UN/CEFACT Core Components Library
TBG 17
submit core component definitions
retrieve
CCTS 3.0
use
UPCC 3.0
complies with
store/retrieve
User
UML 2.1

model
generate
ltxselement name"" lt/xselementgt

User Library
Core Component model
78
Questions?

• ltLecturergt
• ltNamegtPhilipp Liegllt/Namegt
• ltCompanygtVienna University of Technologylt/Company
  gt
• ltDepartmentgtBusiness Informatics
  Grouplt/Departmentgt
• ltAddressgt
• ltStreetgtFavoritenstraße 9-11/188lt/Streetgt
• ltZIPgt1040lt/ZIPgtltCitygtViennalt/Citygt
• ltCountrygtAustrialt/Countrygt
• lt/Addressgt
• ltContactgt
• ltEmailgtliegl_at_big.tuwien.ac.atlt/Emailgt
• ltHttpgthttp//www.big.tuwien.ac.atlt/Httpgt
• lt/Contactgt
• lt? Presentation statusquestions ?gt
• lt/Lecturergt