Edi....Ecommerce
Download as PPT, PDFâĸ2 likesâĸ1,276 views
The document provides an overview of Electronic Data Interchange (EDI) and UN/EDIFACT standards. It describes how UN/CEFACT works to develop EDI standards under the United Nations, and how UN/EDIFACT is structured with data elements, segments, and messages. Examples of EDIFACT segments like NAD and DATE/TIME/PERIOD are also shown to illustrate the hierarchical structure and use of codes.
![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](https://image.slidesharecdn.com/edi-140409000726-phpapp02/85/Edi-Ecommerce-32-320.jpg)
![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](https://image.slidesharecdn.com/edi-140409000726-phpapp02/85/Edi-Ecommerce-33-320.jpg)
![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.
[âĻ]](https://image.slidesharecdn.com/edi-140409000726-phpapp02/85/Edi-Ecommerce-34-320.jpg)
![Business Data Types (BDT) and Core Data Types (CDT)
69
âĸ 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
ÂĢCDTÂģ
types:draft:coredatatypes:1.0::Code
ÂĢSUPÂģ
+ CodeListURI: String [0..1]
+ CodeListSchemeURI: String
+ LanguageIdentifier: String [0..1]
+ CodeListAgencyName: String
ÂĢCONÂģ
+ Content: String
ÂĢBDTÂģ
LandUsageType_Code
ÂĢSUPÂģ
+ CodeListAgencyName: String [0..1] = EasyBiz
+ CodeListSchemeURI: String [0..1] = urn:au:gov:vic:...
+ CodeListName: String [0..1] = LandUsageType
ÂĢCONÂģ
+ Content: LandUsageType [0..1]
ÂĢBasedOnÂģ](https://image.slidesharecdn.com/edi-140409000726-phpapp02/85/Edi-Ecommerce-69-320.jpg)
![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. 15
âĸ Supplementary components
contain meta information e.g.
temperature, Fahrenheit
ÂĢCDTÂģ
types:draft:coredatatypes:1.0::Code
ÂĢSUPÂģ
+ CodeListURI: String [0..1]
+ CodeListSchemeURI: String
+ LanguageIdentifier: String [0..1]
+ CodeListAgencyName: String
ÂĢCONÂģ
+ Content: String
ÂĢBDTÂģ
LandUsageType_Code
ÂĢSUPÂģ
+ CodeListAgencyName: String [0..1] = EasyBiz
+ CodeListSchemeURI: String [0..1] = urn:au:gov:vic:...
+ CodeListName: String [0..1] = LandUsageType
ÂĢCONÂģ
+ Content: LandUsageType [0..1]
ÂĢBasedOnÂģ](https://image.slidesharecdn.com/edi-140409000726-phpapp02/85/Edi-Ecommerce-70-320.jpg)
![Primitive Types (PRIM)
71
âĸ Primitive Types (PRIM) are used to
set the value type of
supplementary components (SUP)
and content components (CON)
ÂĢPRIMÂģ
Boolean
ÂĢPRIMÂģ
String
ÂĢPRIMÂģ
Decimal
ÂĢBDTÂģ
types:draft:coredatatypes:1.0::Code
ÂĢSUPÂģ
+ CodeListURI: String [0..1]
+ LanguageIdentifier: String [0..1]
ÂĢCONÂģ
+ Content: String](https://image.slidesharecdn.com/edi-140409000726-phpapp02/85/Edi-Ecommerce-71-320.jpg)
![Enumeration types (ENUM)
72
âĸ Enumeration types (ENUM) are
used to restrict the value range
of supplementary components
(SUP) and content components
(CON)
ÂĢENUMÂģ
FoodOperationType
+ MFV: string = Mobile Food Vehicle
+ MUT: string = Mobile Unit
+ OTH: string = Other
+ STD: string = Stand
+ TMQ: string = Tent/Marquee
ÂĢENUMÂģ
HealthPremisesType
+ HasGamblingLicense: string = HasGamblingLicense
+ IsBingoPlayed: string = IsBingoPlayed
+ ProvidesFoodForGuest: string = ProvidesFoodForGuest
+ ProvidesFoodForPublic: string = ProvidesFoodFor...
ÂĢBDTÂģ
HealthPremisesType_Code
ÂĢSUPÂģ
+ CodeListAgencyName: String [0..1] = EasyBiz
+ CodeListName: String [0..1] = HealthPremisesType
+ CodeListSchemeURI: String [0..1] = urn:au:gov:vic:...
ÂĢCONÂģ
+ Content: HealthPremisesType [0..1]](https://image.slidesharecdn.com/edi-140409000726-phpapp02/85/Edi-Ecommerce-72-320.jpg)
Edi....Ecommerce
- 1. Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology FavoritenstraÃe 9-11/188-3, 1040 Vienna, Austria phone: +43 (1) 58801-18804 (secretary), fax: +43 (1) 58801-18896 [email protected], www.big.tuwien.ac.at Electronic Data Interchange 188.422 E-Commerce Technologien Philipp Liegl
- 2. Agenda 2 âĸ EDI motivation and definition âĸ EDI standards âĸ UN/EDIFACT: syntax and directories âĸ EDI: chances and pitfalls âĸ MIG: message implementation guide âĸ Outlook
- 4. 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?
- 5. 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 âĻ
- 6. B2C vs. B2B 6 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 7 Messaging Layer Presentation Layer Web Application Server Databases ERP Systems Legacy Applications Persistence Layer Client HTTP request HTTP response Business Layer
- 8. 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
- 9. Agenda 9 âĸ 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 10 EDI
- 13. EDI standards 13 âĸ 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 14 industry specific industry independent regional international ANSI X.12 ODETTE SWIFT UN/EDIFACT
- 15. 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
- 17. United Nations Electronic Data Interchange for Administration, Commerce, and Transport â UN/EDIFACT 17 UN/CEFACT = United Nations Center for Trade Facilitation and Electronic Business
- 18. The United Nations and e-Business? 18 âĸ To maintain international peace and security âĸ To develop friendly relations among nations âĸ To achieve international co- operation
- 19. The organization of UN/CEFACT 19 United NationsUnited Nations International Court of Justice Security Council General Assembly Economic And Social Council Economic And Social Council Trusteeship Council Secretariat WTO (Trade) WHO (Health) WBG (Bank) WCO (Customs) UN/ECEUN/ECE âĻ UN/CEFACT Centre for the Facilitation of Procedures and Practices in Administration, Commerce and Transport UN/CEFACT Centre for the Facilitation of Procedures and Practices in Administration, Commerce and Transport TMG Techniques and Methodologies Group TMG Techniques and Methodologies Group TBG International Trade & Business Processes Group TBG International Trade & Business Processes Group ICG Information Content Management Group ICG Information Content Management Group LG Legal Group LG Legal Group ATG Applied Technologies Group ATG Applied Technologies Group UN/CEFACT Forum Committee for the Development of Trade, Industry and Enterprise Development Committee for the Development of Trade, Industry and Enterprise Development
- 20. The organization of UN/CEFACT cont'd 1 February 2008 International Trade and Business Processes Group International Trade and Business Processes Group Applied Technology Group Applied Technology Group Information Content Management Group Information Content Management Group Techniques and Methodologies Group Techniques and Methodologies Group Legal 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 ChairPlenary Chair ___________________ BureauBureau Plenary ChairPlenary Chair ___________________ BureauBureau FMGFMG ForumForum ManagementManagement GroupGroup FMGFMG ForumForum ManagementManagement GroupGroup UNECE Secretariat UNECE Secretariat UN/CEFACT Forum UN/CEFACT Plenary
- 21. The International Trade & Business Process Groups (TBGs) Ministry of International Commerce, Rome 21
- 22. Known standards from UN/CEFACT 22 UN/EDIFACT ebXML UMM & CC UN Layout Key
- 23. The UN Layout Key 23
- 24. Agenda 24 âĸ 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 25 EDI UN/EDIFACT Data exchange
- 26. 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
- 27. Common paper vs. EDIFACT standard 27 âĸ 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 28 âĸ Hierarchically structured âĸ Data element identification âĸ Delimiter based âĸ Data fields with fixed length âĸ Mandatory and conditional status of data elements and segments
- 29. EDIFACT subsets 29 EDIFICE EDITRANS ODETTE EDITEX EDITEC ETIS CEFIC EDIFURN EDIFOR EDIGAS EANCOM
- 31. 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 21st century" by A.P. Barrett for a deeper discussion (available in the IEEE library)
- 32. 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
- 33. 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
- 34. 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. [âĻ]
- 35. 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
- 36. 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. 37 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 Segment
- 38. Segment example 38 âĸ Buyer: 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: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.
- 39. 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. 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 type ORDERS Trigger Segments
- 42. Order 42 Institute of Software Technology and Interactive Systems Vienna University of Technology FavoritenstraÃe 9-11/188-3 A-1040 Wien Hardware & Software GmbH Wiedner HauptstraÃe 12/8 1040 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-Workstation 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 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â
- 44. 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
- 45. UN/EDIFACT Directories 45 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/directories.htm
- 46. 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+...â
- 47. 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 ---------+ |
- 48. Agenda 48 âĸ EDI motivation and definition âĸ EDI standards âĸ UN/EDIFACT: syntax and directories âĸ EDI: chances and pitfalls âĸ MIG: message implementation guide âĸ Outlook
- 49. 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
- 50. 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"
- 51. 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
- 52. Agenda 52 âĸ EDI motivation and definition âĸ EDI standards âĸ UN/EDIFACT: syntax and directories âĸ EDI: chances and pitfalls âĸ MIG: message implementation guide âĸ Outlook
- 53. Business Document Standards A B CD E A B CD E Standard Format Standard: Standard Message Implementation Guide (MIG): MIG User Group MIG Company MIG Partner-specific âĸ Syntax âĸ Building Blocks âĸ Content
- 54. 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
- 55. Agenda 55 âĸ EDI motivation and definition âĸ EDI standards âĸ UN/EDIFACT: syntax and directories âĸ EDI: chances and pitfalls âĸ MIG: message implementation guide âĸ Outlook
- 56. 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
- 57. The UNeDOCs initiative 57 Paper Document aligned to UN Layout Key XML or UN/EDIFACT Electronic Edit Form
- 58. Business documents in a service oriented world 58 <types/> <message/> <portType> <operation> <input/> <output/> <fault/> </operation> <operation> ... </operation> </portType> <types/> <message/> <portType> <operation> <input/> <output/> <fault/> </operation> <operation> ... </operation> </portType> QuoteRequest Quote PurchaseOrder Order Acceptance Order Rejection Buyer WSDL Seller WSDL XOR SOAP-Message Header Body <orderRejection> .... </orderRejection>
- 59. How serious is the problem? 59
- 60. 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
- 62. UN/EDIFACT Web Services Windows Workflow âĻ UN/CEFACT's Modeling Methodology (UMM) Core Components Technical Specification (CCTS) Functional Service View related standards Business Operational View related standards The Open-edi Reference Model â ISO 14662 BusinessTransactions Business aspects of business transactions Information technology aspects of business transactions viewed as comply with covered by covered by comply with transformed to Business Operational View Functional Service View
- 63. Core Components at a glance 63 âĸ 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 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
- 65. Core Component (CC) example 65 âĸ 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 66 âĸ 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 67 Core Components (CC) Business Information Entities (BIE) BIEs are derived from CCs by restriction
- 68. Dependency between Core Components and Business Information Entities 68
- 69. Business Data Types (BDT) and Core Data Types (CDT) 69 âĸ 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 ÂĢCDTÂģ types:draft:coredatatypes:1.0::Code ÂĢSUPÂģ + CodeListURI: String [0..1] + CodeListSchemeURI: String + LanguageIdentifier: String [0..1] + CodeListAgencyName: String ÂĢCONÂģ + Content: String ÂĢBDTÂģ LandUsageType_Code ÂĢSUPÂģ + CodeListAgencyName: String [0..1] = EasyBiz + CodeListSchemeURI: String [0..1] = urn:au:gov:vic:... + CodeListName: String [0..1] = LandUsageType ÂĢCONÂģ + Content: LandUsageType [0..1] ÂĢBasedOnÂģ
- 70. 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. 15 âĸ Supplementary components contain meta information e.g. temperature, Fahrenheit ÂĢCDTÂģ types:draft:coredatatypes:1.0::Code ÂĢSUPÂģ + CodeListURI: String [0..1] + CodeListSchemeURI: String + LanguageIdentifier: String [0..1] + CodeListAgencyName: String ÂĢCONÂģ + Content: String ÂĢBDTÂģ LandUsageType_Code ÂĢSUPÂģ + CodeListAgencyName: String [0..1] = EasyBiz + CodeListSchemeURI: String [0..1] = urn:au:gov:vic:... + CodeListName: String [0..1] = LandUsageType ÂĢCONÂģ + Content: LandUsageType [0..1] ÂĢBasedOnÂģ
- 71. Primitive Types (PRIM) 71 âĸ Primitive Types (PRIM) are used to set the value type of supplementary components (SUP) and content components (CON) ÂĢPRIMÂģ Boolean ÂĢPRIMÂģ String ÂĢPRIMÂģ Decimal ÂĢBDTÂģ types:draft:coredatatypes:1.0::Code ÂĢSUPÂģ + CodeListURI: String [0..1] + LanguageIdentifier: String [0..1] ÂĢCONÂģ + Content: String
- 72. Enumeration types (ENUM) 72 âĸ Enumeration types (ENUM) are used to restrict the value range of supplementary components (SUP) and content components (CON) ÂĢENUMÂģ FoodOperationType + MFV: string = Mobile Food Vehicle + MUT: string = Mobile Unit + OTH: string = Other + STD: string = Stand + TMQ: string = Tent/Marquee ÂĢENUMÂģ HealthPremisesType + HasGamblingLicense: string = HasGamblingLicense + IsBingoPlayed: string = IsBingoPlayed + ProvidesFoodForGuest: string = ProvidesFoodForGuest + ProvidesFoodForPublic: string = ProvidesFoodFor... ÂĢBDTÂģ HealthPremisesType_Code ÂĢSUPÂģ + CodeListAgencyName: String [0..1] = EasyBiz + CodeListName: String [0..1] = HealthPremisesType + CodeListSchemeURI: String [0..1] = urn:au:gov:vic:... ÂĢCONÂģ + Content: HealthPremisesType [0..1]
- 73. 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)
- 74. Library concept used to aggregate artifacts of the same type 74 BIELibrary CDTLibrary BDTLibrary PRIMLibrary ENUMLibraryDOCLibrary bLibrary from UMM 2.0 Base Module 0..* 0..*0..*0..*0..*0..*
- 75. UPCC - example 75 holds the actual business document but can also define new ABIEs aggregates ABIEs aggregates BDTs aggregates CCs aggregates ENUM aggregates PRIMs
- 77. 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
- 78. 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>[email protected]</Email> <Http>http://www.big.tuwien.ac.at</Http> </Contact> <? Presentation status=âquestionsâ ?> </Lecturer>