AFACT Handbook

Asia-Pacific Council for Trade Facilitation and e-Business
AFACT HANDBOOK for Trade Facilitation & e-Business
Part I Aout UN/EDIFACT
August 2007
(Revised at the 25th AFACT Meeting in Bangkok, Thailand)
i EDI & EDIFACT - Creating an Awareness in Asia-Pacific Revised at the 25th AFACT Meeting on August 6-9, 2007
i EDI & EDIFACT - Creating an Awareness in Asia-Pacific Revised at the 25th AFACT Meeting on August 6-9, 2007
CONTENTS
PREFACE ....................................................................................................................................................... v AFACT Awareness & Education Working Group .....................................................................................vi SECTION 1 INTRODUCTION TO EDI AND EDIFACT ........................................................................ 1 1 Introduction to EDI ............................................................................................................................. 1 2 The Necessity of Standards.............................................................................................................. 2 3. About UN/CEFACT and Forum........................................................................................................ 3 3.1. UN/CEFACT ................................................................................................................................ 3 3.2. UN/CEFACT Forum.................................................................................................................... 6 (a) ATG (Applied Technology Group)........................................................................................ 8 (b) ICGInformation Contents Management Group .......................................................... 8 (c) LGLegal Group ............................................................................................................. 11 (d) TBGInternational Trade & Business process Group ............................................... 11 (e) TMGTechniques and Methodologies Group ............................................................ 12 4. UN/EDIFACT Standards ................................................................................................................. 12 4.1. Basic concepts .......................................................................................................................... 14 4.2. Objectives:.................................................................................................................................. 19 5. UN/EDIFACT STANDARDS: HISTORY ...................................................................................... 21 5.1. Before EDIFACT ....................................................................................................................... 21 5.2. Introduction to UN/EDIFACT ................................................................................................... 22 5.3. Benefits of UN/EDIFACT ......................................................................................................... 22 5.4. Migration towards UN/EDIFACT............................................................................................. 23 5.5. Benefits of EDI........................................................................................................................... 23 6. EDI Implementation Planning......................................................................................................... 24 SECTION 2 New Technologies.................................................................................................................. 25 1. XML/EDI, OO-edi... ................................................................................................................... 25 1.1 XML a promising way for the development of EDI ............................................................... 25 1.2 Object Oriented-edi................................................................................................................... 26 2. Simpl-eBusiness........................................................................................................................... 27 2.1. Introduction ................................................................................................................................ 27 2.2. Simpl-EDI ................................................................................................................................... 27 2.3. Simpl-eBusiness.................................................................................................................... 28 2.4. Simpl-eBiz .............................................................................................................................. 29 2.5. Simpl-eMsg ............................................................................................................................ 29 3. Digital Paper UneDocs in International Trade .......................................................................... 31 3.1. Introduction ................................................................................................................................ 31 3.2. International Trade and Paper Work ...................................................................................... 31 3.6. About UNeDocs Workbase 2.0 ............................................................................................... 34 3.7. UNeDocs ToolKit....................................................................................................................... 38 3.8. Contact & Links ......................................................................................................................... 43 4. The Organisational Structure of UN/CEFACT ............................................................................. 43 4.1. Organisation UN/CEFACT....................................................................................................... 43 SECTION 3 - The Asia Pacific Council for Trade Facilitation and Electronic Business (AFACT) ... 49 1 The Mission ........................................................................................................................................ 49 2 Membership ........................................................................................................................................ 49 3 Office holders ..................................................................................................................................... 50 4 Organization structure......................................................................................................................... 52 5 Joint Working Groups......................................................................................................................... 52 6. Meeting schedule ................................................................................................................................ 53 7. Milestones........................................................................................................................................... 53 SECTION 4 - UN/EDIFACT Message and Code Handbook (MACH V2.4)............................................i PART I - GUIDELINES ON WHEN TO DESIGN A MESSAGE .......................................................... 1 1 Background .................................................................................................................................. 1 1.1 Requirements Analysis ............................................................................................................. 1 1.2 References .............................................................................................................................. 2 ii EDI & EDIFACT - Creating an Awareness in Asia-Pacific Revised at the 25th AFACT Meeting on August 6-9, 2007
Message Functionality................................................................................................................ 2 2.1 Terms and definitions ............................................................................................................ 2 2.2 Business and information modelling principles.................................................................. 3 2.3 UN/EDIFACT principles......................................................................................................... 4 2.4 Comparisons between BIM and UN/EDIFACT .................................................................. 5 2.5 Guidelines................................................................................................................................ 6 PART II - PREPARING MESSAGE BOILERPLATES.......................................................................... 8 1 Background .................................................................................................................................. 8 1.1 Assumptions............................................................................................................................ 8 1.2 Problem Analysis.................................................................................................................... 8 1.3 References .............................................................................................................................. 8 2 Overview....................................................................................................................................... 8 3 The Functional Definition Section............................................................................................. 9 3.1 A simple format for the Functional Definition section........................................................ 9 3.2 Extracts from a sample of Functional Definition sections............................................... 10 3.3 Summary ............................................................................................................................... 12 4 Field Of Application Section .................................................................................................... 12 4.1 Default text ............................................................................................................................ 12 4.2 Variations of the default....................................................................................................... 12 4.3 Deviation from the default ................................................................................................... 12 4.4 Summary ............................................................................................................................... 12 5 The Principles Section.............................................................................................................. 13 5.1 Guidelines for preparing the Principles section ............................................................... 13 5.2 Pitfalls in preparing the Principles section ........................................................................ 15 5.3 Summary ............................................................................................................................... 18 6 Message Terms and Definitions ............................................................................................. 18 7 The Data Segment Clarification Section................................................................................ 19 7.1 Introductory text .................................................................................................................... 19 7.2 Guidelines for describing Segment Groups...................................................................... 20 7.3 Guidelines for describing segments .................................................................................. 21 7.4 Combining the segment group and segment descriptions ............................................. 25 7.5 Dividing the message structure into sections................................................................... 26 7.6 A word of caution.................................................................................................................. 27 7.7 Summary ............................................................................................................................... 27 8 Conclusion.................................................................................................................................. 27 PART III - GUIDELINES FOR CODE NAMES & DEFINITIONS ...................................................... 29 1 Background ................................................................................................................................ 29 2 The Technical Assessment Checklist for Codes .................................................................. 30 3 Naming and Defining Codes.................................................................................................... 38 PART IV REDESIGNING SEGMENTS ............................................................................................. 47 4.1 Background ............................................................................................................................................ 47 4.2 Reason for Redesigning Segments .................................................................................................... 47 4.3 Methodology........................................................................................................................................... 47 4.4 Segment Redesign................................................................................................................................ 48 ANNEX A UN/EDIFACT Syntax Implementation Guidelines (1988)............................................. 49 1 INTRODUCTION .................................................................................................................................... 49 2 BASIC REQUIREMENTS FOR EDI APPLICATIONS....................................................................... 51 3 INTERCHANGE AGREEMENT............................................................................................................ 53 4 TERMINOLOGY ..................................................................................................................................... 57 5 CHARACTER SET FOR INTERCHANGE.......................................................................................... 57 6 TRANSMISSION COMPONENTS ....................................................................................................... 60 7 Identification & Control of UN/EDIFACT Messages .......................................................................... 62 8 Basic UN/EDIFACT Syntax Rules........................................................................................................ 64 9 SEGMENT CONSTRUCTION AND TRANSMISSION RULES....................................................... 76 10 EDIFACT SERVICE & CONTROL MESSAGES ............................................................................. 85 11 MIGRATION TO EDIFACT ................................................................................................................. 85 ANNEX B General Introduction to UNSM Descriptions (1988)...................................................... 87 iii EDI & EDIFACT - Creating an Awareness in Asia-Pacific Revised at the 25th AFACT Meeting on August 6-9, 2007
0 Foreword .................................................................................................................................................. 87 1 References .............................................................................................................................................. 87 2 Terms and Definitions ............................................................................................................................ 88 3 Message Structure ................................................................................................................................. 90 4 Interchange Structure............................................................................................................................. 91 Appendix I : Acronyms Commonly Found in AFACT Materials ........................................................... 95 APPENDIX II: BROCHURE ON UN/CEFACT ................................................................................................ 97 CEFACT Recommendations, Tools and Methodologies...................................................................... 101 APPENDIX III : GROSSARY/DEFINITION RELATING TO UN/EDIFACT.......................................................... 105 Appendix IV : UN/CEFACT Open Development Process ............................................................................... 1 Appendix V : UN/CEFACT Intellectural Property Rights Policy .............................................................. 1 Appendix VI : List of UN/CEFACT Recommendations ............................................................................. 1 Appendix VII : UNSMs Development History............................................................................................. 1 Appendix VIII : ebXML Sources ................................................................................................................... 1
iv EDI & EDIFACT - Creating an Awareness in Asia-Pacific Revised at the 25th AFACT Meeting on August 6-9, 2007
PREFACE The AFACT Handbook outlines the structure and mission of the Asia Pacific Council for Trade Facilitation and Electronic Business (AFACT). It also provides details on EDI (Electronic Data Interchange) implementation and EDI standards achievements of the various member countries/economies. This handbook aims to educate and create an awareness among the general public on EDI and UN/EDIFACT and its application in the Asia Pacific countries/economies. It is published by the AFACT Awareness & Education Group (AFACT-AEG). The list of members of this group, who are also the various countries' contact points for EDI/EDIFACT Awareness & Education, is shown in the succeeding pages. The handbook is revised every after the AFACT Plenary meeting if necessary. Copies can be obtained from the secretariats of EDI/EDIFACT Committees of the respective member countries/economies or can be downloaded from the AFACT homepage at http://www.afact.org. For more information on the AFACT Handbook, please contact either your respective member EDIFACT/EC Committees secretariat or the Chair of AFACT AEG: Mr. Kenji Itoh, Executive Director, JASTPRO Tel: +81-3-3555-6053 Fax: +81-3-3555-6032 Email: kenji.itoh@mac.com
Prepared by: Kenji Itoh, Chair AFACT Awareness & Education Working Group
v EDI & EDIFACT - Creating an Awareness in Asia-Pacific Revised at the 25th AFACT Meeting on August 6-9, 2007
AFACT Awareness & Education Working Group Distribution List (Country Contact List)
1 Australia Mr Ian Watt Tel : +61-3-59431002 E-mail: ian.watt@aecommerce.com.au Tel : +86-1-4225551 Fax : +86-1-4211497 E-mail:
2 China
Ms Tian Ying Deputy Division Chief, Engineer Computing Centre of MOFTEC 28 Dong Hou Xiang, An Ding Men Wai Beijing, 100011 Peoples Republic of China Ms Ariel Wang Innovative Digitech Enabled Applications & Services Institute, Institute for Information Industry 8th Fl. A., No.133, Mingshen E. Road., Sec.4 Taipei, 105 Taiwan Ms Anupam Srivastava DSA, NIC 246, Department of Commerce Odyog Bhavan, Rafi Marg, New Delhi -110001 India Mr David A. Lasse Marketing Director PT EDI Indonesia Wisma SMR, 3rd Floor, Suite 02 Jl. Yos Sudarso Kav. 89 Jakarta 14350, Indonesia Mr. Mahmood Zargar HoD of Iran Director General, Ministry of Commerce, eCommerce Planning & Development Office P.O. Box 14185-671 240 North Kargar St. Teheran 14178 Islamic Republic of Iran Mr Kenji Itoh Executive Director, JASTPRO Yaesu No.5 Nagaoka Bldg 2-29-11 Hatchobori Chuoku, Tokyo 104-0032
3 Chinese Taipei
Tel : +886-2-8732-6222 Fax : +886-2-8732-6271 E-mail: wjweng@iii.org.tw
4 India
Tel : +91-11-23063917 Fax : +91-11-24362535 E-mail:
5 Indonesia
Tel : (6221)6505829 Fax : (6221)6505987
6 Iran
Tel: +98-21-66924623 Fax: +98-21-66926326 Email: zargar@dpimail.net
Japan (Chair)
Tel : +81-3-3555-6053 Fax : +81-3-3555-6032 Email: kenji.itoh@mac.com
vi EDI & EDIFACT - Creating an Awareness in Asia-Pacific Revised at the 25th AFACT Meeting on August 6-9, 2007
8 Korea
Mr Sangwon Lim Secretariat of KIEC 6th Floor, Textile Center Bldg., 944-31, Daechi-dong, Kangnam-ku Seoul, 135-713, Korea Mr Zaid Ismail Senior Director National Chamber of Commerce & Industry of Malaysia 37 Jalan Kia Peng, 50450 Kuala Lumpur Malaysia Mr. Inayat Alli Ebrahim Chief Executive Alpha Systems 692/C, Allama Iqbal, PECHS, Karachi, Pakistan Mr. Michael Dodjie R. Fabian HoD Director III, Trade Information & Assistance Group DTI Bureau of Export Trade Promotion G/F DTI International Bldg., 375 Buendia Ave., Makati City, Philippines Mr Kamarudin Bin Tambi Singapore EDI Committee Secretariat CrimsonLogic, Pte. Ltd. 31 Science Pard Road Singapore 117611 Ms Ayoni Waniganayake Senior Deputy Secretary (General), Ceylon Chamber of Commerce 50, Nawam Mawatha, Colombo 2, Sri Lanka Mrs. Kultida Uamalachart National Electronics and Computer Technology Center (NECTEC) 6th Fl. NSTDA Bldg. Rama VI Road, Rajthevi Bangkok 10400, Thailand Mr. Ton Quoc Binh Technical Assistant High Performance Technology (VnPRO: Vietnam Trade Facilitation & EBusiness Promotion Association) 79, Ba Trieu St., Hanoi Vietnam
vii
Tel : +822-3-528-5020 Fax : +822-3-528-5715 E-mail: swlim@kiec.co.kr
9 Malaysia
Tel : +603-21419600 Fax : +603-21413775 E-mail: izaid@pd.jaring.my Tel: +92-21-4314328 Mobile: 0303-7278683 Fax: E-mail: iae@khi.wol.net.pk
10 Pakistan
11 Philippines
Tel: +632-890 4723 Fax: +632-896 4724 Email: betpdrf@dti.gov.ph
12 Singapore
Tel: +65-887-7516 Fax: +65-778-5277 Email: kama@crimsonlogic.com.sg
13 Sri Lanka
Tel: +94-11-2326096 Fax: +94-11-2449352 Email: ayoni@chamber.lk
14 Thailand
Tel: +66-2644-8150-9 Fax: +66-2644-6653 Email: kultida@notes.nectec.or.th
15 Vietnam
Tel: +84-4-9433-880 Fax: +84-4-9433-882 E-mail: binh_tq@hipt.com.vn http://www.hipt.com.vn
EDI & EDIFACT - Creating an Awareness in Asia-Pacific Revised at the 25th AFACT Meeting on August 6-9, 2007
16 Mongolia
S Oyunzul
17 Cambodia
Chan Sitthear
18 Afganistan 19 Hong Kong
Malyar Jabarkhel Ms. Emily Chung Deputy Chief Operations Officer Tradelink Suite 89, 5/F Hong Kong International Trade & Exhibition Center 1 Trademart Drive Kowloon Bay, Hong Kong
Tel: +976-1-323974 E-mail: info@mongolchamber.mn Tel: +855-23-216 331 E-mail: chansitthear@iic.edu.kh Tel: E-mail: malyar@hotmail.com Tel : 852-25991600 Fax : 852-25060188 e-mail: echung@tradelink.com.hk
viii EDI & EDIFACT - Creating an Awareness in Asia-Pacific Revised at the 25th AFACT Meeting on August 6-9, 2007
SECTION 1 INTRODUCTION TO EDI AND EDIFACT This section gives a short introduction of EDI and EDIFACT. 1 Introduction to EDI EDI (Electronic Data Interchange) is the direct transfer of business information between computer systems in different enterprise and/or organization (without human intervention or with minimal human intervention) using widely agreed standards to structure the transaction or message data. With a structured message, such as a purchase order, the data is formatted according to an agreed standard, thus facilitating the electronic transfer from one computer system to another. The present way of business communication:
Sender
Key in data
Print out Mail
Print out Receiver
The EDI way of business communication:
Sender
K e y in d a ta
EDI
P ro c e s s D a ta
AFACT EDI & EDIFACT Handbook (August 2007)
Page 1
The Necessity of Standards
A standard is, according to ISO's, "a technical specification or another document accessible to the public established with the co-operation and the consensus or the general approval from all the parts interested, based on the combined relations of science, technology and the experiment, aiming to the optimal advantage of the community as a whole, and approved by an organisation qualified on the national, regional or international level". The communications between computers, like the human communication, need a common language or a system of interpretation. The interpretation or the data conversion can function very well between two partners according to a mode of specific agreement of exchange or owner but with a higher number partners, the process of exchanges, in many specific formats associated to each partner, quickly becomes "hard to handle". A common language, using only one standard, facilitates the exchanges, allows the opening to other partners and the adaptability according to its own needs on the various levels international, European, national or sectorial.
EDI :
A q u e s tio n o f S ta n d a r d s
A p p lic a tio n to A p p lic a tio n e x c h a n g e S ta n d a rd is e d fo rm a ts o f e x c h a n g e U N /E D IF A C T , (E A N C O M , S M D G , W C O G7 ) C o m m u n ic a tio n p ro to c o ls X .4 0 0 , F T P , T C P /IP , H T T P , S M T P /M IM E ...
Standardisation in EDI thus concerns: the contents (standardisation of information to transmit, given codes, structures of messages); the container (protocols of telecommunication allowing to transmit the various types of EDI); and in a bound way, the organisation of the exchanges themselves, in a total context ("sequencing" of the messages, description of scenarios, concept of open "EDI "). For this last point, one can refer usefully to work of the international working group ISO/IEC/JTC1/SC30 on "Open EDI".
Page 2
In the field of telecommunications or safety for EDI, it goes without saying each time that is possible, the actors of EDI may find it beneficial to use the already existing standards in these fields. What follows only deals with language UN/EDIFACT.
E D I S ta n d a rd is a tio n F ie ld
L e v e ls In te rn a tio n a l E u ro p e a n N a tio n a l
F ie ld s o r D is c ip lin e s c o m p u tin g te le c o m m u n ic a tio n s
Types of docum ent re c o m m e n d a tio n s s ta n d a rd s p ro fils u s e rs g u id e
3. About UN/CEFACT and Forum 3.1. UN/CEFACT
UN/CEFACT, a United Nations body, has a global remit. It encourages close collaboration between governments and private business to secure the interoperability for the exchange of information between the public and private sector. It has developed: The UN Layout Key for Trade Documents, which is the foundation for the EU's Single Administrative Document (SAD) UN/EDIFACT, the international standard for electronic data interchange numerous trade facilitation recommendations
It is now drawing up the next generation of trade facilitation and e-business standards and tools. 3.1.1 INTRODUCTION The original text of TRADE/R.650 was approved by WP.4, the predecessor to the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), at its final meeting in September 1996 and was later approved by the Committee on the Development of Trade in December 1996. Subsequently, organizational changes, a change in organization name and experience gained from operating the Centre resulted in revisions
AFACT EDI & EDIFACT Handbook (August 2007) Page 3
to the original document, the last being Revision 3 which was approved by the UN/CEFACT Plenary in May 2004. During the intervening period, UN/CEFACT has experienced a significant process of transformation involving: Adoption of a vision and operating strategy Approval of the Open Development Process (ODP) as the means for progressing work An organizational restructuring of its Permanent Groups (PGs) to operate within the ODP Confirmation of a need to augment available support resources beyond those available from the UNECE Development of an intellectual property rights policy Approval of a united UN/CEFAT management structure and operating processes This document, Revision 4 of R.650, has been developed by the Bureau, after consultation with the United Nations Office of Legal Affairs (OLA), the United Nations Economic Commission for Europe (UNECE), Heads of Delegation (HODs), and it incorporates those changes arising out of the foregoing experience, consultation and implementation of the Tenth UN/CEFACT Plenary decisions
UN/CEFACT Plenary adopted at the Plenary

Bureau (*1) UNECE Secretariat
Forum Management Group (FMG) - Chair,
held in May 2004

*1) Bureau consists of Chair, 5 Vice Chairs, Forum Chair, Vice-Chair and Secretariat. Rapporteur, Forum Groups Chairs, and other experts are invited and can join discussions. *2) SSP Service Support Provider
SSP(*2)
Vice-Chair, Permanent Groups Chairs, UNECE secretariat (ex-officio), Plenary Chair & Vice-chairs ex-officio, depends on agenda item)
UN/CEFACT Forum Permanent Groups
TBG
International Trade & Business Process Group
ICG
Information Contents Management Group
ATG
Technology Applied Group
TMG
Techniques & Methodologies Group
LG
Legal Group
Page 4
The UN/CEFACT Structure consists of major three aspects of: Trade Facilitation Recommendations Electronic Business Standards Technical Specifications for the three pillars - processes, information and technology - that are vital in the development of world trade.
UN/CEFACT Plenary BUREAU
UN/CEFACT Forum
FCT
Forum Coordination Team
TBG
Projects
ICG
Information Content Management Group
ATG
Applied Technologies Group
Trade Facilitation e-Business
International Trade & Business Processes Group
TMG - Techniques & Methodologies Group LG - Legal Group
3.1.2
MISSION STATEMENT
The United Nations, through its Centre for Trade Facilitation and Electronic Business (UN/CEFACT), supports activities dedicated to improving the ability of business, trade and administrative organizations, from developed, developing and transitional economies, to exchange products and relevant services effectively. Its principal focus is on facilitating national and international transactions, through the simplification and harmonisation of processes, procedures and information flows, and so contribute to the growth of global commerce. This is achieved by: 1.1 Analysing and understanding the key elements of international processes, procedures and transactions and working for the elimination of constraints; 1.2 Developing methods to facilitate processes, procedures and transactions, including the relevant use of information technologies; 1.3 Promoting both the use of these methods, and associated best practices, through
channels such as government, industry and service associations; 1.4 Coordinating its work with other international organizations such as the World Trade Organization (WTO), the World Customs Organization (WCO), the Organization for Economic Co-operation and Development (OECD), the United Nations Commission on International Trade Law (UNCITRAL) and the United Nations Conference on Trade and Development (UNCTAD), notably in the context of a Memorandum of Understanding for a Global Facilitation Partnership for Transport and Trade; 1.5 Securing coherence in the development of Standards and Recommendations by cooperating with other interested parties, including international, intergovernmental and nongovernmental organizations. In particular, for UN/CEFACT Standards, this coherence is accomplished by cooperating with the International Organization for Standardization (ISO), the International Electrotechnical Commission (IEC), the International Telecommunication Union (ITU) and selected non-governmental organizations (NGOs) in the context of the ISO/IEC/ITU/UNECE Memorandum of Understanding (MoU). These relationships were established in recognition that UN/CEFACTs work has broad application in the areas beyond global commerce and that interoperability of applications and their ability to support multi-lingual environments, are key objectives.
3.2.
UN/CEFACT Forum
3.2.1 Forum Management Group (FMG) The Forum Management Group was established in September 2004 after a restructuring of the UN/CEFACT organization in May 2004. The FMG is directly responsible for the management of the Forum. Its responsibilities include: Executing the program of work of the Forum approved by the Plenary, ensuring coordination of related work among PGs, preventing any work duplication among PGs, reporting to the Bureau; Preparing the UN/CEFACT Forum meetings ; Developing and maintaining one set of general operational procedures for the Forum, including PG membership requirements, requirements for reporting and publishing, actions, voting results and other decisions and ensuring that these procedures are consistently followed by the PGs; Managing the overall implementation of the Open Development Process and making recommendations to the Bureau and the Plenary on any required modifications to those procedures; Coordinating the provision of resources to the PGs, working in conjunction with the UNECE secretariat. This includes external resources; Providing recommendations to the Bureau on the structure of the Forum;
Page 6
Resolve disputes which may arise within the Forum. Disputes which cannot be resolved by the FMG are referred to the Bureau.; Coordination of Forum promotion and communication activities in cooperation with the Bureau. UN/CEFACT is in the unique position to create Global eBusiness standards for the purpose of facilitating trade world wide. In cooperation with OASIS it has created the ebXML standard, which is leading the world into a new era, where business will be done over the Internet and businesses and governments will collaborate at a higher level to achieve the largest cost savings. The FMG is to provide the overall operational management of the UN/CEFACT Forum and is determined to accelerate delivery of standards the world is waiting for. The FMG will provide the Project Management to ensure that new project proposals are assigned to the appropriate permanent group to prevent duplication. The FMG will launch a Sponsorship programme to provide for the necessary funding of the work. The FMG membership is comprised of the chairs of the five permanent UN/CEFACT groups plus two additional members of TBG. The FMG Chair and Vice-Chair have been elected by the UN/CEFACT Forum. The semi-annual UN/CEFACT Forum is the concurrent meeting of all permanent UN/CEFACT Groups at one time in the same location to facilitate close liaison and full interaction as a single working body.
3.2.2 Permanent Groups
Organization UN/CEFACT Permanent Groups and their Working Groups
ATG
WG1 - EDIFACT WG2 - XML WG3 - Other Technologies
ICG
WG1 - Meta Data WG2 - Libraries
LG
WG1 - ODR WG2 - Cross Border Certification WG3 - RosettaNet
TBG
WG1 - Supply Chain WG2 Digital Paper WG3 - Transport WG4 - Customs WG5 - Finance WG6 - AE&C WG7 - Statistics WG8 - Insurance WG9 - TT&L WG10 - Healthcare WG11 - SS, E&S WG12 - Accounting & Auditing WG13 - Environment WG14 - BPA WG15 - ITP WG16 - Entry Points WG17 - Harmonization & Documentation WG1 8 Agriculture WG1 9 - eGovernment
TMG
WG1 - Business processes TG1 - BCF/UMM TG2 - BPSS TG3 - UBAC (Jointly with LG) WG2 - Core Components WG3 - e-Business Architecture
Page 7
(a)
ATG (Applied Technology Group)
The purpose of the Applied Technologies Group (ATG) is to be responsible for the creation and maintenance of the trade, business and administration document structures that are based on a specific technology or standard. The function of the ATG is the design, assembly and production of syntax specific solutions based on identified business and/or technical requirements from the empowered groups of UN/CEFACT. Membership is open to experts with broad knowledge in the area of various implementation syntaxes, protocols and mechanisms for the packaging of data for exchange, the functions of UN/CEFACT, and its groups. In addition Heads of Delegations may invite technical experts from their constituency to participate in the work. Experts are expected to contribute to the work based solely on their expertise and to comply with the UN/CEFACT Code of Ethics. [N.B. This text is subject to approval by the UN/CEFACT Plenary] Two working groups have been formed within the ATG, each with its own scope of work and responsibilities. ATG1 - EDIFACT Syntax Structures is the home for the work formerly done by the EDIFACT Working Group (EWG) T1 Technical Assessment body and will continue to focus on EDIFACT-related work to include development, maintenance and technical assessment responsibility for: UNSM Design Rules UNSM Design ISO/9735 ATG2 - XML Assembly Documents/Production Rules will focus on XML syntax-related work to include development, maintenance and technical assessment of: Schema Design Rules Schema Production XML expressions of ebXML Core Components XML expressions of ebXML Context Methodology UML to XML Methodologies
(b)
ICGInformation Contents Management Group
The Information Content Management Group (ICG) is a Permanent Working Group of UN/CEFACT (Centre for Trade Facilitation and Electronic Business) with the mandate to take all the steps necessary to ensure the release of quality technical specifications for ebusiness.
Page 8
The mandate identifies the overall objectives of the group, its key deliverables and any delegated responsibilities that it may have. The purpose of the ICG is to ensure that all technical specifications (UN/ECE recommendations, business requirements specifications, directories, libraries or repositories, core components, syntax specific implementations (such as UN/EDIFACT, XML, etc.) are released in accordance with the approved procedures and are to the highest quality level. Specific work items include: Business Requirements Specification (BRS) Requirements Specification Mapping (RSM) UN/CEFACT Registry UN/CEFACT Code Recommendations UN/CEFACT Audit
ICG Mandate 1. 1.1 Objectives Purpose
The purpose of the Information Content Management Group (ICG) is to ensure the release of quality technical specifications for e-business. To achieve this aim it will be responsible for the: Management of the UN/CEFACT information repositories and libraries for electronic business and Recommendations that fall within its scope as listed in section 2; Technical conformance and the registration of the UN/CEFACT business requirements Normalization and maintenance of the base syntax neutral information components that serve as the building blocks for the development of standards for implementation; and Technical conformance and registration of syntax specific information objects and components.
1.2 Scope
The activities related to the ICG are within the mission and objectives of UN/CEFACT and its empowered groups. The groups work to produce trade facilitation and electronic business recommendations and technical specifications to advance global commerce.
2. Key Deliverables
The key deliverables of the ICG are: A series of coherent, consistent and normalized reference libraries comprising the business requirements, information objects and code lists that are aligned with the domain reference models and serve as the building blocks for the development of standards for implementation; Validating the conformance of technical specifications with the corresponding publication guidelines and for the release of approved syntax specific information objects and components; Processes and procedures for the maintenance of the libraries;
Mechanisms for ensuring the quality of the library contents; Proposals, including draft Recommendations for review and approval by the UN/CEFACT Plenary and Maintenance of Recommendations : UNECE Recommendation No. 3 - ISO Country Code for Representation of Names of Countries; UNECE Recommendation No. 5 - Abbreviations of INCOTERMS; UNECE Recommendation No. 7 - Numerical Representation of Dates, Time, and Periods of Time; UNECE Recommendation No. 8 - Unique Identification Code Methodology UNIC; UNECE Recommendation No. 9 - Alphabetical Code for the Representation of Currencies; UNECE Recommendation No. 10 - Codes for Ship's Names; UNECE Recommendation No. 15 - Simpler Shipping Marks; UNECE Recommendation No. 16 - United Nations Code for Trade and Transport Locations (UN/LOCODE); UNECE Recommendation No. 17 - Payterms; UNECE Recommendation No. 19 - Codes for Modes of Transport; UNECE Recommendation No. 20 - Codes for units of measure used in international trade; UNECE Recommendation No. 21 - Codes for Types of Cargo, Packages and Packaging Materials; UNECE Recommendation No. 23 - Freight Cost Code; UNECE Recommendation No. 24 - Trade and Transport Status Codes; and UNECE Recommendation No. 28 - Codes for Types of Means of Transport.
3. Functional Expertise of Membership Membership is open to experts with broad knowledge in the area of the functions of UN/CEFACT, and its groups, as well as: Semantics of business practices and codification; Information modeling in the application of reusable design practices; and/or Syntax conversant with the rules defined for the syntax solutions supported by UN/CEFACT. In addition Heads of Delegations may invite technical experts from their constituency to participate in the work. Experts are expected to contribute to the work based solely on their expertise and to comply with the UN/CEFACT Code of Ethics. 4. Geographical Focus The focus is global. 5. Delegated Responsibilities The ICG is empowered in accordance with agreed procedures to: Establish working-groups and project teams as required; Approve project proposals via the Forum Coordination Team (FCT);
Page 10
Progress designated projects following UN/CEFACT's Open Development Process for Technical Specifications; Collaborate with other UN/CEFACT Groups and the UN/CEFACT Steering Group (CSG) on implementation of it's work plan; Present draft proposals and/or recommendations to the UN/CEFACT Plenary; Formal release of any ICG deliverables not requiring UN/CEFACT approval; and Cooperate and establish liaisons with other groups and organizations as required. LGLegal Group
(c)
The purpose of the Legal Group (LG) is to ensure that the legal aspects of electronic business and international trade facilitation are considered in the work of the UN/CEFACT. To this end the Legal Group analyses current legal processes and issues within the mission and objectives of UN/CEFACT, identifies legal constraints that adversely affect the mission and objectives of the Centre, and proposes practical improvements to these legal processes and issues. Deliverables of the Legal group include trade facilitation and electronic business recommendations and technical specifications to advance global commerce. Membership of the Legal Group is open to experts in the field of international trade law and IT law who have been mandated by their country's Head of Delegation. Experts are expected to contribute to the work based solely on their expertise and to comply with the UN/CEFACT Code of Ethics. Current projects: Unified Business Agreements and Contracts (UBAC) Project Recommendation on a legal framework for International Trade Single Window
(d)
TBGInternational Trade & Business process Group
The purpose of the International Trade and Business Processes Group (TBG) is to be responsible for business and governmental business requirements and content. This is achieved by initiating developments in the areas of process analysis, best practices, and international trade procedures. Where appropriate the UN/CEFACT Modelling Methodology is used to support the development of trade facilitation and electronic business solutions. This is achieved through: publication of recommendations and best practices related to international trade facilitation; specification of common business processes and reference models; harmonization of cross-industry business processes; and documentation of business requirements.
Page 11
Membership is open to experts with broad knowledge in the area of in the area of processes, procedures and modelling in the international trade and e-business arenas, the functions of UN/CEFACT, and its groups. In addition Heads of Delegations may invite technical experts from their constituency to participate in the work. Experts are expected to contribute to the work based solely on their expertise and to comply with the UN/CEFACT Code of Ethics. [N.B. This text is subject to approval by the UN/CEFACT Plenary] (e) TMGTechniques and Methodologies Group
The purpose of the TMG is to provide all UN/CEFACT Groups with Meta (base) Business Process, Information and Communications Technology specifications, recommendations and education. The TMG also functions as a research group evaluating new information and communication technologies (ICT), as well as techniques and methodologies that may assist UN/CEFACT and its groups to fulfil their mandate and vision in trade facilitation and e-business. The Group produces trade facilitation and electronic business recommendations and technical specifications to advance global commerce continuing the work of the former TMWG, such as the Core Component Technical Specification (CCTS) and the UN/CEFACT Modelling Methodology (UMM). Its membership is open to experts with broad knowledge in the area of business process, information and communications specifications, architecture, as well as current techniques and methodologies used within UN/CEFACT, technological developments, and the functions of UN/CEFACT and its groups. Three working groups have been formed within the TMG, each with its own scope of work and responsibilities. The Core Components Working Group (CCWG) provides techniques and methodologies for the development and reuse of business information. The Business Process Working Group (BPWG) provides techniques and methodologies for the description of inter-organizational business processes and the resulting information exchanges. The eBusiness Architecture Working Group (ebAWG) provides the framework for the different modeling and infrastructure concepts. 4. UN/EDIFACT Standards For the Electronic Data Interchange, the common language, called UN/EDIFACT and retained at the international level, rests on:1
1 UN/EDIFACT: defined as United Nations rules for Electronic Dated Interchange For Administration, Commerce and Transport. They comprise a set of internationally agreed standards, directories and guidelines for the electronic interchange of structured data, and in particular that related to trade in goods and services, between independent computerlized information systems. This chapter does not want to be an exhaustive course on the use of UN/EDIFACT.
Page 12
UN/EDIFACT Syntax, recommendation of the United Nations, taken again by the ISO, international organisation of standardisation, as a standard ISO 9735, it is the equivalent of a grammar; a vocabulary corresponding to the data items. The data are also standardised. There is the standard ISO 7372, dictionary of the data items of the International Trade. The steps of organisation or structuring of data to make exchanges are not new. Thus, in the past, of the sectorial agreements, national or international on the structuring of the data to be exchanged had allowed the "take-off" of EDI in particular in the sector commercial and transport. It is only in 1987 that the recommendation of UN/EDIFACT Syntax was adopted by the United Nations and taken up again as a standard by ISO 9735 (cf. will infra, left 3: History). Whole sectors now use this standard for the Electronic Data Interchange, while others still employ formats specific to their socio-professional sector while waiting for the migration towards international standard UNEDIFACT. Recommended within the framework of the United Nations, the rules are approved and published by the UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) in the United Nations Trade Data Interchange Directory (UNTDID) and are maintained under agreed procedures. What one commonly calls UN/EDIFACT is in fact a vast unit made up of the following elements: the UN/EDIFACT Syntax, taken again as a standard ISO 9735; Syntax Implementation Guidelines (Trade/WP.4/R.530 document); Message Design Rules (Trade/WP.4/R.840/Rev5 document); and United Nations Rules of Conduct for Electronic Data Interchange by Teletransmission (UNCID); and of the following directories which constitute the UNTDID, Trade Data Interchange Directory: UN/EDIFACT Data Element Directory EDED, a subset of ISO 7372; UN/EDIFACT Composite Data Element Directory - EDCD; UN/EDIFACT Segment Directory - EDSD; UN/EDIFACT Standard Message Directory - EDMD ; UN/EDIFACT Codes List - UNCL. Messages (EDMD) and their supporting directories (EDSD, EDCD, EDED and UNCL) are published twice a year in the form D.xxA and D.xxB, for instance, for the year 2002: D.02A and D.02B.
It gives only the basic elements. For more information to refer to the existing formations on this subject, please visit UN/CEFACT Website www.cefact.org. one often uses without distinction the term of repository or dictionary.
Page 13
The structuring of information to constitute an EDIFACT message is represented on the following diagram:
Structure of the Language INTERCHANGE
MESSAGE E D I F A C T Field Separators Syntax Rules (ISO 9735) Vocabrary (ISO 7372) Character Set (ISO 646, 10646) COMPOSITE DATA
SEGMENTS
S E M A N T I C
ELEMENTARY DATA
S Y N T A X
OSI
4.1.
Basic concepts
The elements of the language are composed of a syntactic part (taxis = order) and of a semantic part (= direction sowed). The semantic part corresponds to the use of the various components of the message which translate the function of this one and give a signification to EDIFACT message. The simple data identify elementary information like, for example, the produced code, the postal code, the unit price, the date of a document.
A data is represented by a code with 4 digits, the wording, a description and a format: example: 2380 DATE OR HOUR OR PERIOD an..35 Value of a date, of a date and hour, or one period in a specified format These simple data can be combined to form composite data and to translate logical information. For example, a date will be represented by the combination of three elements of simple data: qualifying date, to specify if it is about a date of order, of bill, ...; the date, i.e. the value itself; qualifying format of this date, to specify for example format YYMMDD.
example: the composite C507 (a letter C and 3 digits) made up like is indicated below: C507 DATE OR HOUR OR PERIOD Date and/or hour or period of a specified type. 2005 Qualify the date or hour or period 2380 Date or hour or period 2379 Qualify the format of the date or the hour or the period
an..3 an..35 an..3
the segment gathers simple data and/or composite data in logical entities translating a mini function, segment PRI " detailed information on prices for example detailed on the prices " for example.
PRI Desc: C509 5125 5118 5375 5387 5284 6411 5213
DETAILED INFORMATIONS ON PRICES Providing information on prices INFORMATIONS ON PRICES Price's qualifying Price Type of price encoded Type of price qualifying Unit price basis Unit of measure qualifying C an..3 an..15 an..3 C an..3 C an..9 Representation: a= alphabetic an..3 an= alphanumeric
n= numeric ..= variable length 3= number of character at a maximum
M C C
PRICE MODIFICATION C an..3 OF A PART OF THE ARTICLE ENCODED

Simple Data Element
Data Element Tag Cxxx= composite data element
Status: M= mandatory C= condition
Page 15
a message EDIFACT is composed of segments to translate a business function , for example an order, a payment order. the exchange (in English " interchanges ") constitutes the true communication and the dialogue between two partners. An exchange contains one or more messages (messages in the same way standard within functional groups). The exchange of a message made up of structured data and retraitables automatically in the dataprocessing applications of the partners constitutes an optimal communication EDI between partners of businesses. The Directives for the design of messages3 are intended to the originators of new messages with an aim of ensuring the coherence of use of the various elements. The syntactic part specifies the alphabet to be used to represent information and grammar EDIFACT. syntax rests on an alphabet (ASCII 7 bits, standardised ISO 646_83, with two UNOA, character sets and UNOB). A revision of syntax ISO 9735 (Amendment 1 to the standard ISO 9735 of 1992) made it possible to enrich the number of character sets usable in syntax EDIFACT. That gives the possibility of taking account of the accents, of the alphabets Greek and Cyrillic, that is to say: UNOC, ISO Standard 8859-1: Latin alphabet No.1; UNOD, ISO Standard 8859-2: Latin alphabet No.2; UNOE, ISO Standard 8859-5: alphabet Latin/Cyrillic; UNOF, ISO Standard 8859-7: alphabet Latin/Greek.
The use of other alphabets between partners is possible and must be specified by the partners of the exchange. The following diagram describes the use of the alphabet ISO 646-83 with two levels of possible character sets. In the character set of level A (Cf. diagram), the separators used are: Graphic Representation : + ? * '
Name Colon Plus sign Question Asterisk Apostrophe
Functionality component data element separator data element separator release character repetition separator segment terminator
Cf. Trade/WP.4/R.840/Rev4 document, Directives for the design of messages, at the end of this part. Page 16
The character set of level B includes the small letters and other separators are used which are IS4 for the end of segment, separating IS3 of heading of segment and elements of data and separating IS1 of constitutive elements of data. The rules of syntax4 specify grammar EDIFACT, i.e. the way in which the various elements are organised together: simple and composite data, segments and messages.
Cf. TRADE/WP.4/R.530/Rev.1 document, Directives for the use of syntax (cf 2.3 normative References) Page 17
Structure of an exchange (interchange)
Interchange Structure
Interchange
UNA
UNB
Functional Group
Or Message
UNZ
UNH Data Segment
Data Segment
Data Segment
UNT
TAG + Simple data element + Composite data element
Component data element Code : Data value Data value Data value
Component data element Data value
An interchange contains, if necessary, the segment of service UNA, character string of service, segment UNB, heading of interchange, of the functional groups, if used, or only of the messages, the segment: UNZ, end of interchange. A functional group contains the UNG, heading of the functional group, of the messages of same type, one, end of functional group. A message contains the UNH, heading of message, of the segments of data, the UNT, end of message. A segment contains a heading of segment, simple elements of data or composite elements of data or both according to cases'. A heading of segment contains a code of segment and if one uses the technique clarifies, the indication of repetition and overlap, an element of simple data contains only one value
Page 18
of elements of data, an element of composite data contains constitutive elements of data, a constitutive element of data contains only one value of element of data. Techniques of compression are described in syntax EDIFACT. Thus, for the elements of data for which the Repertory of the Elements of data indicates a variable value without other restrictions, the non-significant characters of the element of data can be omitted. The non-significant characters are not transmitted: for example zeros preceding a numerical value or white characters supplementing an alphanumeric value.The conditional segments not comprising an element of data developed must be omitted. In the same way elements of simple or constitutive data conditional can be omitted, according to certain rules of truncation. Fictitious example of a branching diagram
Message Structure
UN/EDIFACT Application Level Syntax Rule ISO 9735
Level 0
UNH M 1
AAA M 1
LLL C 1
UNT M 1
Gr.1 C 10
Gr.2 C 100 GGG C 5 HHH M 1 C KKK 50
Level 1
BBB 10
CCC M 1
Level 2
DDD C 10
EEE C 5
FFF C 5
Gr.3 10 III M 1 C
Level 3
JJJ 5
4.2.
Objectives:
Syntax EDIFACT is defined to be used as support with the design of messages EDIFACT. All the interest of a standard of syntax lies in the use of a common language single, internationally recognised and being able to be used independently of the branch of industry. The flexibility results of course from the neutrality of the language with respect to the data-processing equipment, of the telecommunications networks used and of the professional uses and "the evolutivity " of the repertories also an adaptation to the various needs of the users allows (addition, modification... of data, codes.). The repertories are thus updated twice per annum (repertories D.99A and D.99B, for example).
Page 19
This environment allows a design of general, intersectorial but also sectorial messages. EDIFACT thus grows rich by the constant development of new messages which follow the procedure to become standardised messages UNSM (United Nations Standard Message). The messages are classified in several categories: messages UNSM known as standard: they are recommendations of messages of the United Nations which appear in the repertories of the TDID / UNO; messages under development (MID): they are projects of messages under development. They cover the following fields: trade, customs, banks, insurances, transport, BTP, health, social, ... The use of a message UNSM, whatever the sector, can be done on a level national, sectorial, regional or international, for example, in the shape of subset (subsets), according to the professional need of the user. With term, it is reasonable to think that the various precursors having developed messages EDI in a specific language gradually will turn to UN/EDIFACT and thus that a migration will take place, the programmed migration following the example of messages ODETTE/GALIA, or the intention expressed by ANSI ASC X12. To obtain the last state of the list of the messages, consult your focal point. Standardised references concerning syntax EDIFACT Several successive versions of syntax were developed since 1988: Version 1: ISO 9735 of 1988; Version 2: Amended and reprinted in 1990; Version 3: Amendment 1 of 1992; Version 4: This new version of syntax includes/understands nine parts: Part 1: Syntax rules common to all parts, together with syntax service directories for each of the parts (published by the ISO on October 1, 1998); Part 2: Syntax rules specific to batch EDI (published by the ISO on October 1, 1998); Part 3: Syntax rules specific to interactive EDI (published by the ISO on October 1, 1998); Part 4: Syntax and service report message for batch EDI (message type CONTRL), (published by the ISO on December 15, 1998); Part 5: Security rules for batch EDI (authenticity, integrity and nonrepudiation of origin), (published by the ISO on April 1, 1999); Part 6: Secure authentication and acknowledgement message (message type - AUTACK), (published by the ISO on April 1, 1999);
Page 20
Part 7: Security rules for batch EDI (confidentiality), (Voting deadline was June 15, 1999); Part 8: Associated data in EDI, (published by the ISO on October 1, 1998); Part 9: Security key and certificate management message (message type KEYMAN), (published by the ISO on April 1, 1999).
5. UN/EDIFACT STANDARDS: HISTORY 5.1. Before EDIFACT
The first initiatives of data exchanges goes back to the years 1960 and were launched by the sectors of the automotive engineering and air transport which had important needs for exchanges. These sectorial initiatives corresponded to the use of formats and messages owners. In this type of step, the users ran up however very quickly against the difficulty in managing a multitude of syntaxes and formats different of messages. A common system thus proved necessary to obtain a single language allowing a possible opening to multiple partners, i.e. a "standard of data exchange ". Standards EDI were elaborated as well in the USA as in Europe. In North America, for the development of EDI, the American National Standardisation Institute, the Accredited Standard Committee X12 (ANSI ASC X12) was instituted in 1978. It carried out, in 1983, its first set of standards. Known under the name of ANSI X12, this standard was largely adopted in the USA. Another standard was elaborate under the aegis of the Co-ordinating committee of the data of transport (Transportation Data Coordinating Committee (TDCC/EDIA)). In September 1979, the first work relating to the some elements of data appearing in the commercial documents is undertaken by the working group on the facilitation of the procedures of trade (UN/ECE/TRADE/WP.4). This initiative made it possible to constitute the bases of the repertory of elements of data of the international trade. In 1980, the British experts with the working group of the United Nations for the facilitation of the procedures of the international trade deposit directives for the data exchange commercial (Guidelines for Trade Data Interchange, GTDI), adopted by the United Nations and published in 1981. In 1983, France works out an experimental standard entitled " Exchange of Commercial Files ", EFC. Work France-British is then undertaken to bring closer the GTDI and standard EFC.
Page 21
In 1985, the European and American experts also bring closer their work. A committee common UN/JEDI (Joint Electronic Data Interchange Group) is made up while the United Nations encourage this common work to develop a single standard for EDI.
5.2.
Introduction to UN/EDIFACT
Ever since the introduction of EDI, EDI users in Europe, USA and other countries have developed numerous industry based and national standards. As EDI gained more popularity, the need for a more generic globally acceptable EDI standard became more apparent. In 1985, the UN/EDIFACT ("United Nations/EDI for Administration, Commerce and Transport") was borne from a fusion of the European and the American national standards. UN/EDIFACT is fast gaining recognition and acceptance as the global EDI standard. In 1987, the acronym EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) is adopted, work are organised around three reporter in each area represented in Geneva (Western Europe, Eastern Europe and North America). The working group on the facilitation of the procedures of the international trade adopts the rules of syntax EDIFACT which the ISO will take again, international organisation of standardisation to make of it a standard (ISO 9735). It is then the flight of work UN/EDIFACT, since the deposit of the first message, that of the finalised "invoice" this same year until the hundred messages today while passing by the development of the directives for the design of message and of the procedures of maintenance UN/EDIFACT. At the end of 1987, in Western Europe, a program TEDIS (Trade Electronic Data Systems Interchange) is adopted by the Council of Ministers of the European Economic Community (Brussels). Its goal is to promote EDI and UN/EDIFACT and to co-ordinate the initiatives taken by the Member States and the groups of users. This program which started in 1988 is finished at the end of 1994. By the means of invitations to tender, it made it possible various companies to carry out studies and many work in the field of EDI. It is also necessary to announce during this launching period of EDI work of the GTF, groups French conveyors, having developed messages relating to forwarding and the delivery. 5.3. Benefits of UN/EDIFACT
EDIFACT is a fusion of European and the American national standards. Generally, EDIFACT retains the essence of the two national standards characterized by its flexibility and efficiency while not compromising its functionality. EDIFACT is flexible enough to be used across industries and across boundaries for both the government and private sector in a wide range of EDI applications.
Page 22
EDIFACT is also supported by a set of rigorous message design procedure, thus ensuring that EDIFACT messages which are endorsed by the UN conforms fully to the standard and hence are internationally functional. The essence of a good standard does not lie only in its flexibility, efficiency and functionality. Its acceptance is of paramount importance. EDIFACT is fast gaining popularity not only in the US and Europe, but also in Australia, New Zealand, Japan, Singapore, Korea, Malaysia, China, Chinese Taipei, India, Indonesia, Iran as well as in many developing countries in the Asia Pacific region. EDIFACT is the prevailing global EDI standards.
5.4.
Migration towards UN/EDIFACT
Progressively, between the years 1987 and 1994, process UN/EDIFACT could continue and show that it was able to take into account the needs for all the sectors, well beyond its field of origin, the facilitation of the international trade. A double movement of migration in its direction spread: - sectorial: all the European or world precursors, ODETTE, EAN... at least started or practically finished, for some, the translation of their messages in UN/EDIFACT; - national: after a historical vote, the ANSI X12 programmed stages for the migration towards UN/EDIFACT, it will remain to see how this intention will be concretised. (cf. memorandum of October 1993 of President Clinton in connection with Electronic Trades). To be also noted in Japan a progressive evolution towards standard UN/EDIFACT. The important one, in fact not being that everyone is aligned with the blow of gun but that the direction is posted by all without ambiguity; then, it is a question of cost and of calendar, being understood that if all is clearly affirmed, it is with an acceleration of the migration that one should assist, in the condition which process UN/EDIFACT is not choked by its own success and can simplify its consequently procedures.
5.5.
Benefits of EDI
Reduce costs With EDI, costs associated with paper handling, data entry, transcription, manual sorting, paper matching, filing, reconciling, mailing and lost mails are eliminated. Save time Information is delivered instantaneously enabling you to plan your production schedule promptly, thus saving more money. Improved customer service
With an improved environment and more streamlined communications, you are able to respond more rapidly to your customer's requirements and provide better customer service. The benefits of EDI are clear...either hook up or loose out. 6. EDI Implementation Planning Start planning for EDI now....... Determine your organisation's needs Study your company's existing procedures and how it can be improved using EDI. Identify the data to be communicated, often starting with the most common transactions. Identify business partners for EDI Decide on which partners should participate, usually starting with the larger ones. Discuss with them about how and when they plan to use EDI. Educate and train your staff Prepare your people for the changes that are coming. Train your staff in EDI awareness as well as the technical aspects of EDI. Integrate EDI into existing systems Consider the possibility of EDI as an integral part of a complete system rather than just a communication peripheral. Review and redesign existing systems, streamline existing procedures and change the paradigms. Decide on the network service Decide whether you want to build your own proprietary network or select a third party Value Added Network (VAN) service. Consider the benefits of a VAN as a clearing house for your EDI system. Consider the hosts of support facilities provided by VANs, including EDI implementation support, data communication protocols, technical help desk support and EDI consultancy - not forgetting that VANs have wide network coverage with big user base. Decide on the EDI standards
Page 24
Just as voice communication requires a common set of rules which everyone understands and uses to communicate with each other, the use of EDI requires a common set standards to be accepted for communication. Decide on how data is to be presented for transmission. Do not reinvent the wheel, explore the use of existing standards such as UN/EDIFACT.
SECTION 2 New Technologies 1. XML/EDI, OO-edi...
In the context of the Electronic Trade, the generalisation of the applications of Electronic data interchange from now on is regarded as a success. Thus for example, the totality of the French supermarkets and hypermarkets daily practise EDI with their suppliers, 90% of the provisioning of the assembly lines of the car is managed in EDI. Important sectors of the distribution specialised like do-it-yourself, the book and the disc, the pharmaceutical products, but also the trade, the tools or the electric components control their flows of goods by using messages EDI. The total turnover treated in EDI is thus evaluated to 800 billion francs in 1998 what represents a third of the value of the annual production of finished products (2500 billion francs). At the end of 1997, the study "Observatory Commercial and Electronic Exchanges" published by EDIFRANCE and the AFCEE estimated at 60.000 the number of companies implied in EDI. The evaluations at the end of 1998 show a doubling of this figure with 110.000 companies users of the Electronic commercial tool, no matter if they belong to the Internet family, EDI or a combination of both. For Internet showed that it could facilitate the access of the smallest companies to the tools of productivity reserved hitherto to the large accounts. From this point of view, the complementary between Internet and EDI appeared like an obviousness. 1.1 XML a promising way for the development of EDI
The advent of standard XML55 developed within the W3C is highly likely to constitute an additional lever to make progress exchanges EDI of the Electronic Trade. Its fast development and its success require however a clarification of the respective roles of syntax and contents of information conveyed in the professional data exchanges of the Electronic Trade " B to B " or with the administrations.
5 XML: eXtensed Markup Language is developed within the W3C (World Wide Web Consortium), the authority which gathers the representatives of the users and industrialists of data processing around the standardisation and the promotion of the Internet services. For more information to refer to the existing formations on this subject, in particular seminars of EDIFRANCE entitled " XML EDI and Electronic Trade " and " future of the exchanges: appraise standards and techniques " during which XML is studied in detail.
Page 25
To carry out automated transactions between the information systems, it is indeed necessary to have a common language and recognised by all the partners. This language must be independent of the systems, of the physical and linguistic borders. The dictionary of reference used by the many communities implied at the world level in the Electronic Trade between firms is the repertory of elements of commercial data of the United Nations (UN/TDED). This basic element, which is the subject of the standard ISO 7372, is supplemented by other dictionaries which define the components of the language (messages, segments, data and codes). This " alive " unit constitutes the repertory of data exchange commercial of the United Nations (UN/TDID), dated in a bi-annual way within the Centre for the Facilitation of the Procedures and of the Practices in the administration, the Trade and Transport / Edifact Working Group (see point 5). Independent of any syntax, the various elements of this corpus, already massively used in traditional messages EDI, can easily be re-used for the development of DTD 6 XML. This possibility has many advantages. The first of them is to avoid with the developers and the users of DTD XML to have to reinvent the vocabulary of the Electronic Trade. The risk, indeed, would be great to create a news " Tower of Babel " in which the developments owners would come to imprison the users in logic closed and incompatible with the requirements of the markets which claim information systems interconnection. Thus avoiding the duplication of a considerable energy, the developers would make the saving in already authorised efforts. Another of the advantages - and not of least - would come to the profit from the users. The many companies already committed in the professional data exchanges could indeed develop, to even improve their preceding investments, while profiting from a perfect compatibility between the messages EDI which they use already and new DTD developed on the basis of work of the United Nations. 1.2 Object Oriented-edi
Oriented modelling "object" constitutes a true revolution in the development of the complex information systems. Many directed methods object saw the day these last years. All these methods allowed the emergence of the language unified UML.7 For EDI, UML should be used to model the contents of the messages EDIFACT and the commercial or administrative activities which are the framework of the exchange considered. UML opens new prospects to theEDIFACT/ONU which will be able to thus evolve to true EDI Oriented Object.
DTD: Standard Document Definition For more information to refer to the formation than EDIFRANCE organizes on this subject, entitled " UML (Unfied Modelling Language)" AFACT EDI & EDIFACT Handbook (August 2007) Page 26
6 7
2.
Simpl-eBusiness
2.1. Introduction Lately more and more eBusiness standards/specifications being release with the promise that the new solution can be easily implemented by Small and Medium-sized Enterprises (SMEs). Sadly this is a clear indication that those responsible for the new specification are clueless about what the SMEs needs really are. Lets face it no small or medium-sized business company/business will be implement directly any eBusiness solution by applying the underlying standards/specifications themselves. They dont care what makes the solution tick. SMEs want to take a commercial-of-the-shelf (COTS) application that installs easily and interfaces with their COTS accounting application automatically. At most they are willing to do, is enter some setup information about their business partners they want to exchange invoices and purchase orders (and over time other electronic documents) with. Most of them are currently using a FAX to send and receive those invoices and purchase orders. Unless the eBusiness solution is as simple as the FAX that will be replaced, the chances of adopting anything more complex is not an option to them. The real requirement for those new eBusiness standards/specifications is to meet the application developers needs to provide to the SMEs a COTS solution that replaces their current FAX to seamlessly and effortless interfaces with their existing accounting system. Currently there are no such standards/specifications. That is not to say there have not been any efforts to develop such. During the late 1990th there were a few standards projects that tried to address the need for applications providers to create simple eBusiness applications. The end result was that either the projects were abandon because of its complexity or the lack of support of the user community. The latter because of being unable to convince the user community that change is required to simply eBusiness. It is time that eBusiness standards/specification developers recognize that fact. Users dont care about the latest technologies, the fact that the new solution is state-of-the art or uses XML instead EDI. Users want a solution that is keep simple, standard and speedy (K.I.S.S). The good news is that there are some providers, such as Illumonus <www.illumonus.com>, that are addressing that problem by apply the best of breed approach to provide a Simpl-eBusiness solution. 2.2. Simpl-EDI In the late 1990th Tom McGuffog, Director of Planning & Logistics for Nestl UK, published a paper titled K.I.S.S. Keep It Simple, Standard, Speedy and Certain. The document introduced the concept of Simpl-EDI which deals with the transfer of data in a fully automated environment, where supporting master data is available in a database and where the only data exchanged is simple transaction data. Tom presented his idea to UN/CEFCAT who in turn created the Simpl-EDI Ad-hoc group (SIMAC). The scope of the work was for the group to consider and recommend how Simpl-EDI and its related work items could be efficiently and effectively developed within UN/CEFACTs structure. The groups initial findings were that Simpl-EDI was not intended for all businesses, but applying the 80/20 rule, companies willing to review and simplify their processes will be able to use Simpl-EDI for 80% of their transactions automatically. One of the fundamental obstacles identified was successful data alignment and establishment of master databases
such as electronic catalogues. The concept of master data and a logistical approach was seen as being key to the success. As to Simpl-EDI itself, the group stated that this concept is not going to replace UN/EDIFACT as it will be based on core subsets for parties with simplified clear processes. A few years earlier SITPRO created a series of EDI messages to enable international trade documents to be exchanged electronically. The set of messages was called ElecTra (Electronic Trade). This work was based on UN recommendations and standards (UN/EDIFACT). SIMACs final recommendation was the creation of a single, unique global Electronic Commerce repository. The core of this repository should contain UN/EDIFACT data elements and codes resulting from the work of the Simpl-EDI messages taking into account other simplified message implementations such as the SITPRO ElecTra project. On the surface the recommendation seems to point in the right direction, suggesting the creation of simplified UN/EDIFACT messages using the 80/20 rule i.e. 20% of the data from the existing UNSMs to enable 80% of the business relationships simply and automatically, with exceptions requiring more sophisticated use of the UNSM. However, because of the pressure to join the XML development world, UN/CEFACT got sidetracked. Instead the creation of Simpl-EDI work was done by e-centre (UK) who much later handed the work over to UN/CEFACT in order for it to become a global standard for electronic business. This, becoming an international standard, has not happened so far. Instead the Simpl-EDI messages have become input to a new project called UNeDocs. UNeDocs is a project of the United Nations Economic Commission of Europe (UNECE) to develop and implement a set of aligned documents in paper and electronic format. For each document the project will develop a class diagram, the layout of the document based on the UN Layout Key, Web Form Box Completion Guidelines, XML specifications (i.e. schema, stylesheet), and a UN/EDIFACT message implementation guide. Sadly most of the current work is directed to the XML implementations and use of UN/CEFACTs Core Component work. Early drafts have revealed that a aligned document requires between 15 to 30 associated XML schemas for implementation. Surely not what one would call Simplification. 2.3. Simpl-eBusiness There is however good news, Illumonus <www.illumonus.com> has pickup the SimplEDI work from SIMAC and developed its Simpl-eBusiness that provides the simplification Tom McGuffog envision is a essential pre-requisites to the cost effective application of eBusiness. Illumonus agrees with Tom that good business practices, driven by business process analysis, will allow users of traditional eBusiness to better understand the business case for migration to Simpl-eBusiness, and for new eBusiness users to better understand the relations and eBusiness messages within their trading communities. This is why Illumonus has developed Simpl-eBusiness. Simpl-eBusiness applies the best of breed approach to provide a solution that is based on the concepts of Simpl-EDI (SimpleBiz) and ebXMLs Secure and Reliable Messaging (Simpl-eMsg).
Page 28
2.4. Simpl-eBiz Simpl-eBiz is a set of standard data definitions for all the data elements most commonly used in electronic commerce based on the UNTDED (ISO 7372). It uses the same definitions for such data elements as dates, quantities, buyers, sellers, products, services etc whether used on web screens, electronic forms, EDI messages, XML documents, or for business-to-business (B2B) communications, and for all industries, institutions and economies. Simpl-eBiz keeps all orders, invoices and other key transactions very simple by putting all the related data into master files and cross referring to these via standard numbers and codes. For example, there would be an EAN number for a buyer or customer on an order, but if you wanted to know about the buyers name and address, etc you would use this number to cross refer to the buyer master file to access all relevant data about him or her. Master files would be synchronized between companies in advance of trading to ensure that all data is aligned between value chain partners e.g. product prices. This can be done by EDI/XML or via a shared electronic catalogue on the Internet using Illumonus SimpleMsg gateway. Master data relates to value chain participants (buyers, sellers, banks, insurance companies, transporters, Customs, inspection bodies, consumers, citizens, patients and employees. Simpl-eBiz also defines standard messages across all value chains. For example, an order to deliver is the same as on order to move a product and almost the same as an order to process a piece of steel, treat a patient or pay a bill. Plans are simply future orders and reports or performance data represent actual achievement against past orders. Hence the maximum use is made of the same data elements and the same shared master data. Master data files are kept up-to-date and synchronized among organizations to ensure that transactions can be both error free and very simple and standard. The Simpl-eBiz messages are significantly simpler in content and structure than any previously published International UN/EDIFACT subset, by a factor of about ten to one. This simplification has been achieved by adherence to the fundamental principles outlined above; principles to which prospective users will need to subscribe if they are to take advantage of this approach. Simpl-eBiz provides small businesses with an EDI and/or ebXML solution to exchange documents with it large corporate customers without having to map between their "Commercial-of the shelf" (COTS) application and its associated database formats and the formats specified by the eBusiness Standards (as defined by their trading partners). SimpleBiz also provides support for the management of EDI and/or XML messages and files. Simpl-eBiz offers the solution to the complexity problem in that it addresses the overabundance of information contained in the full EDIFACT messages. Simpl-eBiz fully subscribes to the concepts behind Simpl-EDI as identified by Tom McGuffog. Simpl-eBiz is not another technology or syntax solution that address the structuring of the data but do not address the real problem behind the unjustified excess of information that is not related to the business process the message is being used in. 2.5. Simpl-eMsg Simpl-eMsg (Simpl-eMessaging) supports secure and reliable e-Business messaging which is as simple as operating email or sending a fax. Its modular approach is designed to
be accessible to ordinary business people who are comfortable using a computer. It provides robust communications support so users can easily track and manage their business transactions using the menus and screens provided. It uses familiar email style message exchanges to provide a minimum learning curve. Using an email approach also plugs into the messaging infrastructure at the heart of the Internet that sends billions of messages every day. Simpl-eMsg provides a mailbox capability. The mailbox can facilitate modern XML messages, older EDI messaging, or any other business documents (Word, Excel, PDF, etc.) depending on the needs of the customers. Mailboxes can be unique to a trading partner as needed. Simpl-eMsg supports secure and reliable standard Internet email protocol (SMTP) communications. This utilizes the stable standards of Internet communication protocols and the international UN/CEFACT and ISO approved ebXML Messaging (ebMS) standards to support trading partner to trading partner communication. Its modular approach provides facilities that contain secure and reliable data communication, mailbox management, trading partner administration, logging, archiving, data communications and error reporting. Trading Partner Management is simplified by utilizing an automatic setup exchange with the trading partners system to self configure the required initial partners information. Apart from administrating the commercial aspects of the trading partner relationship the only management actions the user should have to perform will be in the event of the need to add a new partner or changes to an existing trading partner. Again this is made easy as all that is needed is to provide the trading partners email address and execute the function that will permit communication with the trading partners system. The Log, Archive and Restore capabilities support the auditing and archiving of important business transactions and information. The log allows users to access information about their document exchange operations. Information posted to the log allows for system activity reporting and error tracking. Archive allows users to save any exchange at any time into a user-specified location. Restore allows archived data to be restored to its original state for reprocessing, retransmission, or analysis. All such systems comply with Sarbanes Oxley (SOX 404) requirements regarding the preservation of electronic data as apart of a comprehensive document retention policy, and in particular email. Simpl-eMsg can utilize Amazons Simple Storage Service (S3) and Flexible Payments Service (FPS). S3 can be used to store and retrieve any amount of data, at any time, from anywhere on the web. It gives any user access to the same highly scalable, reliable, fast, inexpensive data storage infrastructure that Amazon uses to run its own global network of web sites. The service aims to maximize benefits of scale and to pass those benefits on to users. FPS enables tens of millions of existing Amazon customers to transact with other Simpl-eBusiness users paying their invoices with no friction, simply using the same accounts and payment instruments that they use for purchases on Amazon.com - without having to re-enter information. Simpl-eMsg provides an error reporting capability that utilizes an optional second email or instant message address to notify a human operator immediately of any error condition, such as a non-delivery notification, or rejection notice. This is an essential element of audit trail mechanics.
3.
Digital Paper UneDocs in International Trade
UNeDocs documents can: be generated in paper, XML, PDF and EDI format; be visualized using a standard Internet browser or can be implemented in standard office software and support electronic signatures. It is a powerful migration tool from paper to paper-less environment. UNeDocs has been developed by UNCEFACT (under UNECE) and it provides interoperability for the exchange of document-based information between the public and private sector. 3.1. Introduction
In the early 1970s it was widely predicted that, by the year 1990, the World would be a Paperless Society in the fields of international trade and transport. By the mid 1980s the affluent world was advocating the use of Electronic Data Interchange (EDI) in this sphere. Nevertheless, despite the phenomenal expansion in the use of Information and Communication technology (ICT) in many fields such as banking, air-travel and education, since 1990s, its penetration to these fields has been somewhat modest. For instance, it has been estimated that 70 percent of trade and goods transport documents are still exchanged by paper or fax and often these are still manually signed. In addition the deployment of EDI was largely limited to the Developed World. What then are the reasons for this? Is it due to the digital divide between the rich and the poor or is it due to resistance to change or both or for completely different reasons? This chapter attempts to address the above issues and describe briefly the UNeDocs (digital paper) project which may be a solution to the present problem and a migration path for future progress. Until the late 1990s the technology of choice that was available for the transmission and processing of data automatically and securely was EDI. Countrywide deployment of EDI was however limited to smaller IT aware countries such as Singapore and Hong Kong plus communities such as maritime and air cargo ports and large companies such as Sears Roebuck, JC Penny and Wallmart. This was mainly due to the extremely high costs involved in setting up of a Value Added Network Service (VAN) and its operations. In addition, the EDI message structures were complex and were very different from paper documents and they proved very difficult to interface with software applications. This meant that integration was often prohibitively exensive. The latest generation technology that has become popular in international trade and transport is the eXtensible Markup Language (XML) which is easier and cheaper to implement and is perfectly attuned to the internet environment. Also, XML messages are machine readable as well as human readable. Any one, anywhere in the world could use XML if they posses a PC, as XML messages can be transmitted securely on the Web or using the Internet, and such messages can be made interoperable even with EDI-EDIFACT messages by the adoption of specific standards such as ebXML and UNeDocs (United Nations Electronic Documents) . If so why is that majority of the trading community the world over has not absorbed or integrated these technologies ?
3.2.
International Trade and Paper Work
International trade and sea transport are two areas that have deep rooted customs related to paperwork and procedures and those are difficult to change mainly due to the mindset of
parties requiring those. In addition new demands are being added instead of eliminating unnecessary practices. For instance a recent article on Certificates of Origin published by the International Chamber of Commerce (ICC Publication 670, ISBN-10: 92-842-00032, ISBN-13: 978-92-842-0003-0) recommends that the Commercial Invoices should be signed by the seller whereas UNCEFACT had recommended to the contrary several years ago. From such indications the prediction of the date on which the world will become a Paperless Society in international trade may have to be pushed forward at least by another 20 years. Then how could we move forward at least towards a Less Paper Society leave a side a Paper Less Society? Will UNeDocs provide an answer to this? UNeDocs is a new global standard for digital trade documents that has helped to bridge the gap between paper documents and ICT applications. UNeDocs is a project of UNCEFACT (United Nations Centre for Trade Facilitation and Electronic Business) www.uncefact.org, developed together with Adobe Acrobat, combined with XML Technologies. UNeDocs adapts paper based document standard for trade and transport i.e. the United Nations Layout Key (UNLK), ebXML data structures and PDF technology. It applies UN-Trade Data Elements Directory and its tags to define metadata and uses international codes, CEFACT / ISO /WCO core-components in data structures that has made UNeDocs interoperable across borders even with legacy EDI systems. Data received through any of these systems are reusable too. Ref. www.unedocs.org for details. The above characteristics of UN-eDocs described above demand standardisation and rationalization of procedures & documents and specific methodologies in processing data involved in international trade. UNeDocs is based on the concept of a data model from which any document used within the international purchase-and-supply chain can be derived. It therefore provides an opportunity to all parties concerned to re-engineer the processes (ERP) applying out-of-the-box solutions and also to create Single Electronic Windows (SEW) to conduct International Trade. Since UNeDocs data model is a superset of data elements used within the international purchase and supply chain, it can be easily tailored to meet virtually all user requirements and yet remain globally aligned. Hence UNeDocs can easily be adapted by virtually all parties involved in international trade; traders, banks, insurers, port authorities, Customs and transport & logistics service providers.
3.3.
Application of Digital Paper UNeDocs
Persons or institutions who wish to use eDocs for limited applications such as sending and receiving documents electronically can create the required documents easily by using a software application such as AdobeLiveCycle. It could be done by a person acquainted with UNLK design guidelines / CEFACT / WCO Standard Data Models and Codes etc.. The only cost involved in doing so is the price of the software which is in the region of USD 500. Once the documents have been created the uses need only Adobe Reader Software (Ver. 7 or above), installed in your PC which is downloadable free of charge. To prove your identity in most business transactions however, you may need a digital ID from a trusted third-party provider, - a certificate authority. Because the certificate authority is responsible for verifying your identity to others, choose one that is trusted by major companies doing business on the Internet. See the Adobe website for information about
Adobe security partners that offer digital IDs and other security solutions. The cost to the users would be the price of obtaining a Digital Signature from a Certifying Authority such as Verysign that would provide data security on transmission by encrypting the message and verifying the authenticity of the sender to the intended recipient of the document. The cost of obtaining such a digital signature (Private Key) would be USD 20 (approx) per annum. To apply security features to PDFs, you need Acrobat 8.0 Professional, Acrobat 8.0 Standard, or Acrobat 3D. [Note: For the latest information about digital signatures, choose Help > Online Support > Knowledge Base to open the Adobe Acrobat support page on the Adobe website, and then search for digital signatures.] eDocs could be read and processed as an XML or a PDF document or printed as a hard copy. The documents can be scrutinized and transmitted to the relevant parties with necessary certifications using a Public Key or after adding manual signature. However authorities granting permission or adding its certification to a document e.g. Certificate of Origin, the certification granted by that authenticity should be verifiable by multiple interested parties; hence the need for a Public Key that costs approximately USD 500 per annum to such institutions. PDF / XML Documents transmitted electronically could be made interoperable provided that such documents have been designed according to agreed Standards. Therefore when designing eDocs or ebXML messages it is imperative that UNeDocs co-components / ebXML / Standards are followed. If this is done correctly eDocs can be made interoperable even in an EDI system that follows UN-EDIFACT Standards. 3.4.
UNeDocs Standards
(The following have been re-produced from International Trade Single Window and Potential, Benefits to UK Business by Gordon Linington February 2005 - SITPRO Website. http://www.sitpro.org.uk UNeDocs brings together the best of all the UN/CEFACT standards with two other very important international standards: The United Nations Trade Data Element Directory (UNTDED) - maintained by the International Organization for Standardization as ISO 7372. The WCO Data Model - maintained by the World Customs Organization (WCO). Furthermore, the business information from across a number of documents has been merged together into one common source, known as the UNeDocs Data Model. Almost any document used in the international purchase and supply chain can be derived from the Model's data definitions. The UNeDocs Data Model represents the structure and relationships of business and regulatory information used within the international purchase and supply chain. This enables any trade, transport or Customs document/s to be derived from the same data model and, perhaps more importantly, they can then be generated into a language that computer systems will understand (e.g. EDI or XML).
3.5.
UN/CEFACT Core Component Library
The UNeDocs Data Model has been built up using core component building blocks from the UN/CEFACT Core Component Library. This means that it includes trade, transport and Customs related information such as the names and addresses of the seller, the buyer, the consignor, the consignee etc. It also includes total and item level weights, as well as commodity and product information, such as price, quantity and cost. The UN/CEFACT Core Component Library is published every 6 months and is given a unique version number. These library versions can be used by anyone who wants to build a data model based on international standards. And, by becoming involved in UN/CEFACT, any organisation is able to request that their business information is included in the library.
UNeDocs Code Lists XML New: UNeDocs WebServices trial version available! Code Lists to facilitate international Trade. The use of encoded trade data based on recognized international code sets simplifies trade procedures and reduces the risks associated with international trade. Coded data entries are well defined, reflect common and efficient business practice, avoid ambiguities and misunderstandings and are language independent. Codes are also a precondition to analyse the data in trade documents in an automated manner. Thus the use of codes enables selective risk assessment based on data analysis.
3.6. (i)
About UNeDocs Workbase 2.0 Who is this document aimed at?
This document has been put together by TBG2 to give an overview of the UNeDocs Project for new members joining or anyone who wishes to know more about the project. This project is very detailed and can get quite complex and for this reason information has to be defined to a very low level. A basic understanding of data modelling and UN/CEFACT CCTS v2.01 (Core Component Technical Specification) data modelling in particular would be useful for the details of this publication. (ii) What are the aims of UNeDocs?
UNeDocs brings together the standards of UN/CEFACT to facilitate international trade. Specifically UNeDocs brings together these standards for specifying, defining and structuring business and official information before applying standards for a particular format or layout, be it paper or electronic. This enables the information to be easily understood by all and to be converted backwards and forwards between formats with minimum loss, misunderstanding or degradation of the information. (iii) What is this and what is this for?
Page 34
This UNeDocs Workbase v2.02 (Stockholm Version) is a Core Component Technical Specification (CCTS) compliant data model covering the data requirements of a number of the trade, transport and Customs processes of the international supply chain. It is based on the UN/CEFACT Core Component Library version 06A (CCL06A). In addition to this we also use the following additional data structures that have been submitted to TBG17 (the group that harmonises and publishes the CCL) requesting their harmonisation and inclusion in the next version of the CCL and these are referred to in this documentation as candidates:

candidate Aggregate Core Components (ACCs), modifications to the ACCs in the existing CCL06A which are mostly requests to add further properties such as UNTDED cross-references, candidate Qualified Data Types (QDTs) and associated code lists, candidate Aggregate Business Information Entities (ABIEs).
Caveat: This data model draft version is a step forward in the UN/CEFACT drive to achieve facilitation of international trade through a new holistic approach to define aligned paper and electronic document flows via its UNeDocs Business Standards project. This publication is the first major step to meet the UNeDocs stated objectives and this is intended as the basis for implementation verification pilot projects in countries or sectors. It is in the process of being published and maintained as a UN/CEFACT Business Standard and therefore this version 2.02 cannot be considered as a final complete data model for production purposes. This data model also includes master document structures (Business Information Masters or BIMs) for defining subset business documents which follow the principles and guidelines for document families that are described in the UNECE Rec. No. 1. These BIMs reuse the highest-level UNeDocs Aggregated Business Information Entities (ABIEs) which are transport, packaging and trade aggregations. In all cases, the BIMs also include the more generic document identification aggregations (ABIEs) of document context and document header. The BIMs can thus be used to define contextualised document subset structures to build families of related cross border documents sharing common generic document header information, document 'family' specific information and including document specific usage information as required. The contents of this data model have been based on the work of the relevant TBG Working Groups and also on existing practices. The UNeDocs team would like to thank all of the groups who have contributed to this work and in particular the Transport Working Group (TBG3) and the Customs Working Group (TBG4 through WCO). Furthermore this data model includes cross-references to the UNTDED which is the most important data dictionary for cross border trade as it is used as the basis for defining the UN Layout document data requirements of many of the legally binding cross-border trade Conventions including the revised Kyoto Convention. These UNTDED references provide mappings to several key conventions such as the Single Administrative Document (SAD) and the IATA Airway Bill as well as to the UN Layout Keys wherever identified.
Page 35
Help in contributing to the future development of this UNeDocs Workbase is now required from experts within and external to UN/CEFACT in the form of the submission of the results of implementation verification projects which will be able to ensure that the final deliverable is fit for purpose. (iv) What requirements does this holistic data model for cross border trade cater for?
Semantic interoperability cannot be achieved by technical solutions alone, independent of whether they are EDI or XML based. The present situation is that >70% of cross border data is still exchanged via paper documents and that the use of UN/EDIFACT is still increasing by 20% each year and we believe that there can be no future solutions without considering the past and protecting present needs and current investments. Consequently this UNeDocs data model must first reflect, or serve as a basis to reflect, the well proven and globally implemented data structures of UN/EDIFACT as well as the data requirements of classic everyday paper documents. Today the use of eBusiness is often a document centric one which is certainly influenced and even mandated by established traditions, current legal jurisdictions, conventions and legacy, often batch oriented, applications. The move to adopt process oriented eBusiness started a long time ago and this approach will be a key factor for the success of Single Windows. Both approaches will continue to exist in parallel for the foreseeable future and the success of process orientated eBusiness methods will, to a large extent, depend on the migration of legal frameworks from paper-based requirements. Thus it is critical that the UNeDocs data model delivers data and document structures which cover both document centric and process driven data requirements. This data model is a way to support the re-engineering and re-design of business and administrative processes. It is important to note that this reengineering is not only beneficial for data exchange but also for the rationalisation of the business processes and their administration. Future process driven data exchange structures will be developed which will avoid the data redundancy inherent in the present document centric approach and which can be implemented by any appropriate syntactical solution like EDIFACT or XML. This can only be achieved by the reusability of well-named and well-defined data structures across industry and administrative domains, countries, documents and payload grammars. It is also important that the data model provides reusable and document structures aligned to document 'family' patterns. The benefits of achieving this maximised reusability is that the UNeDocs data model is the perfect partner for the Cross Border Data Reference Model (CBDRM) as identified at the UN Single Windows Symposium in May 2006. This also provides the ideal platform for the Single Windows Stakeholder Group to harmonise and modernise the data requirements of their conventions and regulations. Thus this data model will significantly help all parties involved in international supply chains to move forward by supporting both present and future requirements and by offering a smooth and strategic migration path.
(v)
How can this help you?
This data model assists you with the analysis of your business processes and business and administration data by providing globally approved:

cross-domain aligned data names and definitions, UNTDED cross-references plus reusable document frameworks and data structures
All of these are based on the relevant UN/CEFACT and ISO international standards. The use of the UNeDocs data model as the basis for your work offers the benefit of speeding up the development of cross-border trade related business requirement specifications by ensuring the maximum pre-harmonisation of identified data with the UN/CEFACT CCL and other aligned business requirement specifications. As a result this will also provide the opportunity for increased interoperability across all these crossborder processes. (vi) What you can do with this data model?
You can use this data model as a basis to identify the data which you need for your business and administrative processes and you can use the UNeDocs standard CCTS compliant names and definitions as well as the more established legal definitions from the UNTDED to describe your processes and documents. Then you can identify the gaps where information seems to be missing in the data model and you are invited to report this back to the appropriate TBG domain Working Group via the UNeDocs project team as change requests. The key domain Working Groups in question are Supply Chain (TBG1), Transport (TBG3), Customs (TBG4), Finance (TBG5), Insurance (TBG8), Environment (TBG13), Agriculture (TBG18) and eGovernment (TBG19). In order to help you in this work the data model provides wherever appropriate the UNTDED cross-reference. In addition the unique identifiers (UIDs) of the Core Components of the CCL06A are given as well as the TBG17 CCL Change Request identifiers. These references will enable you to more easily identify any data which you do not understand or which you require to use in your specific environment. We would urge you to join any appropriate UN/CEFACT domain Working Groups and the UNeDocs project in order to develop these standards further and to submit the Business Requirement Specifications for your governmental and trade processes as a UN/CEFACT Standard. It is of particular importance to receive from you the legal and traditional definitions and the name of the international convention where your data requirements are defined, e.g. the ASEAN CEPT form D. The UNeDocs project team will then be able to consider the inclusion of this contributed information in future versions of the data model for reuse by others which will promote global adoption by maximising harmonisation and interoperability of defined data exchanges. By basing your cross-border documentary requirements on the UNeDocs Workbase data model, not only does this offer benefits as described above but also it offers to reduce
significantly the effort in time and money required by traders and other parties to send and receive data and documents as of your requirements. The richer the data model becomes with respect to convention and regulatory names, definitions and their respective data structures the easier and faster it is to identify and to describe the data requirements of future legislative versions and for regional, national or industry specific variations. (vii)
What will the UNeDocs project team do with this data model?
We have submitted the new or modified ACCs and ABIEs in the data model to UN/CEFACT for harmonization and for future inclusion in the UN/CEFACT Core Component Library. Our parent TBG Workinh Group, TBG2, is in the process of having the project endorsed and released. We will use this Stockholm Workbase version 2.02 to serve as the basis for mapping the included document structures to the UN Layout Key, to UN/EDIFACT, to existing XML and for the generation of UN/CEFACT XML schemas. In the future, as the new eUNLK international standard evolves, this data model will be used as the foundation for mapping to eUNLK documents. (viii) What are the next steps?
To develop as a top priority core document structures which include only the minimum data exchange requirements for key document types. This will result in smaller document structures which are more readable and understandable and in turn this will encourage minimised data requirements. To continue to improve the data model contents by implementing change requests resulting from implementation verification projects and from other contributions. To broaden the scope of the data model by the inclusion of finance related data, by extending the trade contract related data, by aligning closer with the WCO data model (working towards the joint CBDRM) and by covering cross-border related OGA requirements.
To add family document structures covering additional document types. 3.7.

(i)
UNeDocs ToolKit
The Role of Trade Documents in International Trade
Trade Documents play a crucial role in international trade, as any efficient supply chain operation is based on the information provided in the trade documents. Documentary errors or the non-availability of trade documents usually leads to serious complications and sometimes even to a breakdown of the supply chain operation. The cost of maintaining trade documentation is a significant component of the final market price of the goods. It is estimated that direct and indirect costs of trade documentation accumulate to 5% to 10% of the value of the goods, depending on the nature of the goods and the specific supply chain scenario. In the presence of documentary errors this
percentage will significantly increase. With an international trade volume in goods of 5,500 billion US $ annually, documentation is a significant cost component of international trade. In order to reduce these costs and to permit efficient international trade a set of standards for efficient trade procedures and documentation has been developed. (ii) Importance of aligned Trade Documents
Trade Documents that adhere to international documentary requirements and best business practice are generally referred to as aligned documents. Important standards and best practice for aligned trade documentation have been developed in the United Nations Economic Commission for Europe (UNECE). Owing to the importance of this subject, the United Nations has set up a Centre for Trade Facilitation and Electronic Business (UN/CEFACT) within the UNECE to further develop and maintain these standards. Today most documents used by advanced trading nations and logistics operators are based on these standards for instance: The EU Single Administrative Document (SAD), the TIR carnet, the IATA Air Waybill or the IMO Bill of Lading. While the use of aligned trade documents has become a standard in advanced trading nations, the UNECE recognizes that specifically with regard to transition economies and developing countries non-aligned trade document systems are still being used. The use of these documents complicates procedures, unnecessarily increases the costs of the goods to be exported and is a considerable impediment for exporters to compete successfully on the international markets. (iii) UNeDocs aligned paper Documents
The UNECE has therefore set up the United Nations electronic Trade Documents (UNeDocs) project to develop guidelines and tools for implementing aligned trade documentation. UNeDocs provides a conceptional framework for developing aligned paper trade documents based on international trade standards and the subsequent development of the electronic equivalents of the paper document. UNeDocs designs documents on the basis of international trade procedures, the United Nations Layout Key (UNLK) and the United Nations Trade Data Elements Directory (UNTDED), ISO standard 7372. These two definitions, the document layout based on the UNLK and the semantic content of the document based on the UNTDED provide the basis for a later definition of the electronic equivalent of the trade document in UN/EDIFACT or XML format. UN/EDIFACT and XML are today's most widely used electronic business protocols and provide access and connectivity to e-business systems and electronic supply chain management. (iv) UNeDocs Toolkit for Trade Facilitators
As the alignment of paper documents is crucial for the development of electronic documents, the UNECE has now developed the first release of a set of tools for the design of aligned paper trade documents. The Toolkit consists of recommendations and guidelines. It has been developed for trade facilitators, logistic managers, government officials, software designers and other professionals who design or implement trade documents. It provides the United Nations Recommendations on the design of trade documents (UN Recommendation No. 1), the guidelines for implementation, the databases for the definition of the semantic basic data definitions (TDED) and the latest
UN/EDIFACT release. It also provides electronic templates of forms , both in MS-Word and in PageMaker 6.5 format. Trade facilitators can use this templates to translate forms into languages other than English and to adopt the forms to the specific national or sectoral requirements. (v) Copyright
All documents are copyright of the UNECE and subject to the standard United Nations copyright note. The UNECE points out that the sole authorized text leading to the UNLK are the published UN Recommendations and standards, especially the UN Recommendation No. 1 and the ISO 3535 standard. The electronic templates were designed to support the development process and also to deliver templates for the print of document forms. The rendering of the actual electronic form on a sheet of paper sometimes varies, owing to specific configurations of standard software or characteristics of certain printers. MS-Word forms are generally not suitable to produce camera-ready images. The UNECE strongly recommends to verify the final form layout against the measurements and standards of the UNLK before authorizing the trade document form. Acknowledgements This toolkit integrates documents and standards developed in the UNECE by the International Trade Procedures Working Group (ITPWG) and the Edifact Working Group (EWG) of UN/CEFACT and the TC 154 of the International Standards Organization . Download A compressed version of the Toolkit can be downloaded from the UNeDocs Download page. (http://www.uncefactforum.org/TBG/TBG2/tbg2.htm)
Contact information Markus Pikart Program Manager UNeDocs United Nations Economic Commission for Europe 8, Avenue de la Paix CH - 1211 Geneva Switzerland e-mail: mailto:markus.pikartr@unece.org Fax: :(+41 22) 917 0037 Version UNeDocs p-LK Toolkit for Trade Facilitators Version V0.2 Date 07.05.2002 Recommendations and Guidelines for aligned Trade Documents Forms UN Layout Key (UN Recommendation 1) UN Layout Key: Guidelines for Application Location of Codes in Trade Documents (UN
PDF
Database
HTML
Page 40
Recommendation 2) Aligned Invoice Layout Key (UN Recommendation 6) Numerical Representation of Dates, Times and Periods of Time (UN Recommendation 7) Layout Key for Standard Consignment Instructions (UN Recommendation 22) Handbook for the Design of UNeDocs Paper Forms UN Trade Data Element Directory 1993 (ISO 7372) UN Directories for electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) * authorized version by TC154
A - Templates for documents used in the commercial transaction sector Forms Layout Key for commercial invoices (UNECE) Enquiry/Request for quote/Offer invitation Offer/Quotation Order Acknowledgement of order Dispatch Advice ** Size NOT corresponding to UNLK PageMaker PDF TIF Word **
B - Templates for documents used in the payment sector Forms Documentary credit application (ICC) Documentary credit (ICC) PageMaker PDF TIF
C -Templates for documents used in transport related services sector C. 1 Forwarding and cargo-handling ("Intermediary services") Forms PageMaker PDF Layout Key for Standard Consignment Instructions (UN/ECE/FAL Rec 22) FIATA Forwarding instructions - FFI (FIATA)
TIF
Page 41
FIATA Forwarding instructions - FFI (FIATA) April 2002 Forwarders Certificate of Receipt FCR (FIATA) FIATA Warehouse Receipt FWR (FIATA) & second page C. 2 Transport Forms Standard Bill of Lading (International Chamber of Shipping) International Rail Consignment Note (CIM Convention) & second page International Road Consignment Note (CMR Convention) Universal Air Waybill (IATA) & second page Negotiable FIATA Multimodal Transport Bill of Lading (FIATA-FBL) Non-negotiable FIATA Multimodal Transport Way Bill (FIATA-FWB) & second page Forwarders Certificate of Transport (FIATA FCT) Shippers Intermodal Weight Certificate (FIATA - SIC) C. 3 Insurance Forms Insurance Policy Form PageMaker PDF TIF PageMaker PDF TIF
D - Templates for documents used in the Official Controls sector Forms PageMaker PDF TIF Dangerous goods declaration (UN/ECE/FAL Rec.11) Goods declaration for home use (Kyoto Convention) Goods declaration for export (Kyoto Convention) Goods declaration for transit (Kyoto Convention) & second page Certificate of origin (Kyoto Convention) GSP Certificate (UNCTAD) & second page Single Administrative Document (SAD)
E - Templates for the design of forms
Page 42
Forms UNECE Blue Forms Design Sheet United Nations Layout Keys (UNLK)
PageMaker PDF
TIF
Word**
3.8. (i)
Contact & Links Contact Information Michael Dill, Co-Leader [dill@gefeg.com] Sue Probert, Co-Leader [sue.probert@sepiaeb.com] Contact Information Chair Michael Dill (DE) GEFEG Dill@gefeg.com Vice-Chairs Eva Chan (MY) Dagang Net Technologies Sdn Bhd eva@dagangnet.com Idrahima Diague (SN) Gainde2000 idiagne@gainde2000.sn
(ii)
(iii)
TBG2 Links SITPRO's UNeDocsUK home page: www.unedocsuk.co.uk UNeDocs at the UN Economic Commission for Europe: www.unedocs.org ITAIDE Project: Customisation of UNeDocs for EU Customs and Taxation Purposes [pdf] [doc] Information on UNeDocs by Novannet: http://www.novannet.com/TBG2 Become involved in the working group responsible for UNeDocs. (http://www.unece.org/cefact/forum_grps/tbg/tbg2_edocs/tbg2_edocs.htm) The Organisational Structure of UN/CEFACT Organisation UN/CEFACT
4. 4.1.
Work relating to UN/EDIFACT is within the framework of the Economic Commission on Europe of the United Nations. They are carried out there by the UN/CEFACT (United Nations Centre for the Facilitation of Procedures and Practices for Administration, Commerce and Transport), which is an international centre in which all the countries are allowed to take part, which corresponds to the world character of UN/EDIFACT.
Page 43
Five UN/CEFACT Groups were established to form the UN/CEFACT development structure. The TBG (International Trade & Business Processes Group), ICG (Information Content Management Group) and ATG (Applied Technologies Group) are new operational Groups, with the TMG (Techniques and Methodologies Group) and LG (Legal Group) serving essentially as Support Groups. The basis for the work performed by all Groups will be in accordance with the Open Development Process for Technical Specifications as approved by the UN/CEFACT Plenary. UN/CEFACT Forum 1. The semi-annual UN/CEFACT Forum will allow the concurrent meeting in the same location of all the Groups at one time in order to facilitate closer liaison and full interaction as a single working body, with each individual Group having the option to convene further specific Group meetings at their discretion. All UN/CEFACT Group Chairs and Vice-chairs will serve as members of the Forum Management Team. 2. The groups will structure themselves internally as they deem necessary to undertake their work, e.g. into Working Groups with Project Teams with physical and/or virtual membership. Designated experts work will work in these Project Teams and be tasked with completing an approved project within a predetermined timeframe. In addition, standing project teams may be established for ongoing or recurring functions. 3. The TBG will be responsible for business and governmental process analysis, best practices, and international trade procedures using the UN/CEFACT Modelling Methodology to support the development of appropriate trade facilitation and electronic business solutions, including the development and maintenance of UN and UN/ECE Recommendations. 4. The ICG will be responsible for the management and definition of reusable information blocks retained in a series of libraries. 5. The ATG will be responsible for the creation of the trade, business and administration document structures that would be deployed by a specific technology or standard such as UN/EDIFACT or XML. 6. The TMG will be responsible for providing all UN/CEFACT Groups with base (meta) ICT specifications, recommendations and education. It will also function as an ICT research group. 7. The Legal Group (LG) will continue to be responsible for issuing, publishing and presenting analysis and recommendations regarding legal matters related to UN/CEFACT. It will support all UN/CEFACT Groups as well as its own projects as defined by the Plenary.
Page 44
UN/CEFACT New Organization Structure (approved by the Plenary in May 2004)
UN/CEFACT Plenary Bureau

(Bureau consists of Chair, 5 Vice-chairs, Forum Chair, Vice-chair & Secretariat. Rapporteur, Permanent Groups Chairs and other experts are invited members and can join freely the discussion.)
UN/CEFACT Forum
FMG
Forum Management Group
(Chair, Vice-chair, Permanent Groups Chairs and UNECE Secretariat ex-officioPlenary 5 Vice-chairs (ex-officio, depends on the agenda items)
TBG
ICG
ATG
TMG
Techniques & Methodologies Group
LG
Legal Group
Organization UN/CEFACT Permanent Groups and their Working Groups
ATG
WG1 - EDIFACT WG2 - XML WG3 - Other Technologies
ICG
WG1 - Meta Data WG2 - Libraries
LG
WG1 - ODR WG2 - Cross Border Certification WG3 - RosettaNet
TBG
WG1 - Supply Chain WG2 Digital Paper WG3 - Transport WG4 - Customs WG5 - Finance WG6 - AE&C WG7 - Statistics WG8 - Insurance WG9 - TT&L WG10 - Healthcare WG11 - SS, E&S WG12 - Accounting & Auditing WG13 - Environment WG14 - BPA WG15 - ITP WG16 - Entry Points WG17 - Harmonization & Documentation WG1 8 Agriculture WG1 9 - eGovernment
TMG
WG1 - Business processes TG1 - BCF/UMM TG2 - BPSS TG3 - UBAC (Jointly with LG) WG2 - Core Components WG3 - e-Business Architecture
Among the various groups from the CEFACT, the Forum is the technical authority of management of EDIFACT and ebXML. It meets twice per annum and acquired a great autonomy with regard to this technical management, the adoption and the publication of the repertories.
Page 45
The Bureau which is the management committee of the CEFACT, consisted of Chair, 5 Vice-chairs, Forum Chair, Vice-chair & Secretariat is chaired by Stuart Feder (Bank of International Settlement). In addition to that Rapporteur, Permanent Groups Chairs and other experts are invited members and can join freely the discussion.
UN/CEFACT Plenary Bureau
UN/CEFACT Forum
FMG
Forum Management Group
TBG
Projects
ICG
ATG
Trade Facilitation e-Business
TMG - Techniques & Methodologies Group LG - Legal Group
The above schematic (figure xx) depicts the proposed overall structure. It encompasses five UN/CEFACT Groups and a management group that will collectively be known as the UN/CEFACT Forum. The TBG, ICG and ATG are new operational Groups with the TMG and LG serving essentially as support Groups. The interactions between the groups are shown in the work flow in figure xx (below), with the understanding that a diagram can never properly represent the entirety of interactions that will occur between the groups as they progress both trade facilitation and e-Business activities. Therefore, the boxes depicted in figure 1 should not be viewed as silos, but rather as a series of interdependent management units that individually have the responsibility for progressing specific activities. The ATG supports work relating to the maintenance of the rules of syntax EDIFACT, with the proposals of new UNSMs or a modification of the existing UNSM. Work of revision of the rules of syntax EDIFACT defined in the standard ISO 9735, as well as the maintenance of the repertory of elements of data of the international trade based on the standard ISO 7372 are carried out by groups of the work of the ISO in close connection with the experts of the CEFACT. Within the framework of the CEFACT, procedures exist for the design and the modifications of documentation EDIFACT, in particular with regard to the messages, segments, data items and composite and lists of codes.
Twice a year, the EWG gathers more than 250 experts of all the sectors from all around the world. These meetings constitute the true authority of technical dialogue of the world EDIFACT.
Functional Relationship among TBG, ICG and ATG in UN/CEFACT Forum
UN/CEFACT Forum TBG ICG

Business Operational View BOV
ATG
Domain Definitions Domain Definitions Requirements Requirements
Analysis Analysis Design Design
Functional Service View FSV

Implementation Implementation
1. Key industry thinking has been encapsulated in the restructuring process. In particular, work on establishing business requirements, normalizing and simplifying business processes is separated from the work of producing syntax specific solutions using XML, EDI or other transfer protocol. 2. In technical terms, this separation of the Business Operational View (BOV) from the Functional Service View (FSV) follows the Open-edi Reference Model framework (ISO/IEC 14662). ISO/IEC 14662 defines the BOV as a perspective of business transactions limited to those aspects regarding the making of business decisions and commitments among organizations, which are needed for the description of a business transaction. The FSV is a perspective of business transactions limited to those information technology interoperability aspects of IT systems needed to support the execution of Open-edi transactions. 3. Furthermore, the UN/CEFACT Modelling Methodology provides an industry recognized methodology and UML profile for specifying an incremental construction of business processes and information models. It has the capability to provide various levels of specification detail (known as granularity) that are suitable for communicating the models variously, and at the correct level of granularity, to business domain experts, business application integrators and network application solution providers. These levels are realized through workflow stages domain definitions, requirements, analysis, design and implementation workflows-- each of which produce deliverables that are used as input
to subsequent processes. The specific workflows are outlined in Section VI, Workflow Approach.
Page 48
SECTION 3 - The Asia Pacific Council for Trade Facilitation and Electronic Business (AFACT) (reformed from Asia EDIFACT Board: ASEB in 1999) This section gives an introduction to the AFACT, including the mission, membership, office holders, organization structure, major milestones as well as meeting schedules. 1 The Mission AFACT aims to support in the Asia Pacific region policies and activities, especially those promoted by UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business), dedicates to stimulate, improve and promote the ability of business, trade and administrative organisations, to exchange products and relevant services effectively in a non-political environment. Its principals focus is to facilitate international transactions, through the simplification and harmonisation of procedures and information flows, and so contriubute to the growth of global commerce.
2 Membership The AFACT has, to date eighteen members. They are: COUNTRY 1 2 3 4 5 6 7 8 9 Japan Singapore Korea China Chinese Taipei Malaysia India Thailand Philippines MEMBER
SINCE
REPRESENTED BY Japan EDIFACT Committee Singapore EDI Committee Korea EDIFACT Committee China EDIFACT Committee Taipei EDIFACT Committee Malaysia EDIFACT Committee India Ministry of Commerce Thailand EDI Council Philippine EDI Committee
August 1990 August 1990 April 1991 September 1991 September 1991 May 1992 August 1992 February 1994 November 1994
Page 49
10 11 12 13 14 15 16 17 18
Sri Lanka Iran Indonesia Pakistan Australia Vietnam Mongolia Cambodia Afganistan
November 1994 June 1996 November 1996 September 1998 September 1999 October 2001 October 2002 October 2005 August 2006
Sri Lanka Committee
National
EDI
Iran EDIFACT Committee Indonesia EDI Council Pakistan EDI Committee TradeGate Australia VnPRO MonPRO
Office holders The office holders of the ASEB since Nov 1990 when the Board was set up are as follows: TITLE Chairman TERM Aug 2006 - Aug 2007 Oct 2005 - Aug 2006 Sep 2004 - Oct 2005 Oct 2003 - Oct 2004 Oct 2002 Oct 2003 Oct 2001 Oct 2002 Sep 2000 Oct 2001 Sep 1999 Sep 2000 Oct 1999 Nov 1996 - Oct 1998 Nov 1994 - Oct 1996 Nov 1992 - Oct 1994 Mr. Wan-Soo Sohn Mr. Wan-Soo Sohn Mrs Pearleen Chan Korea Korea Singapore
Page 50
NAME Dr. Jirachiefpattana Ajin
COUNTRY Thailand Pakistan Viet Nam Singapore Pakistan Malaysia Indonesia Chinese Taipei
Mr. Javed Naushahi Mr. Tran Thanh Hai Mr. Kenneth Lim Mr. Javed Naushahi Mr. Richard Mengko Mr. Ferng-Ching Lin
Nov 1990 - Oct 1992 Vice Chairman Nov 1996 - Oct 1998 Dec 1994 - Oct 1996 Nov 1992 - Dec 1994 Nov 1990 - Oct 1992 UN/CEFACT Rapporteur Mar 2001 Mar 2003 Oct 1998 Mar 2001 UN/EDIFACT Rapporteur Vice Rapporteur Sept 1990- Oct 1998 Nov 1996 - Oct 1998 Dec 1994 Oct 1996 May 1992 - Dec 1994 Nov 1990 - May 1992
Mr Edi Ohkubo Mr. Anuar Maarof Mr. Anuar Maarof MrYasuyuki Sakakubara Mr Martin Tsang Mr T. A. Khan Mr Kenji Itoh Mr Kenji Itoh Mr. T.A. Khan Mr. C. J. Cherng Mr Wan-Soo Sohn Ms Jocelyn Ang
Japan Malaysia Malaysia Japan Singapore India Japan Japan India Chinese Taipei Korea Singapore
Page 51
Organization structure AFACT STRUCTURE

AFACT Chairman AFACT Secretariat + Hosting Secretariat
Steering Committee
Awareness & Education Group (AF-AEG)
Kenji Itoh (Mr) Japan
Siti Aminah Abdullah (Ms) Malaysia

Purchasing Group (AF-PWG)
Customs Group (AF-CWG)
Technical Assessment & Harmonization Group (AF-TAG)
Frank Lin (Mr), Chinese Taipei
Ramin Salehkhou (Mr) Iran
Legal Working Group (AF-LWG)
Security Group (AF-SWG)
Jose A. Albert (Mr) P;hilippines

Finance Group (AF-FWG)
Greg Wu (Mr) Chinese Taipei
Business Process Analysis Group (AF-BPAWG)
Chair - vacant
Chau-hsiung Chou (Mr) Chinese Taipei

Transport Group (AF-TWG)
Chung Ping Liang (Mr) Chinese Taipei
XML Working Group (AF-XMLWG)
Internetworking Implementation Committee (IIC)
David Lasse (Mr), Indonesia

Air Transport Group (AF-ATG)
E-Commerce Working Group (AF-ECWG)
Yong Jae Kim (Mr) Korea
IIC Technical Group (IIC-TWG)
Dinesh Kumar (Mr) India
Environment Protection Group (AF-EPG)
Chair - vacant
Joint Working Groups

Page 52
A total of fourteen Joint Working Groups were established under the AFACT to promote sharing of information and expertise among members and to represent joint interests of the Asia Pacific region in the UN meetings. The activities of the groups are elaborated in Section 3.
6.
Meeting schedule MEETING 16th ASEB Meeting EDICOM 98 17th AFACT Meeting 18th AFACT Meeting AFACT Steering Committee 19 AFACT Meeting AFACT Steering Committee 20th AFACT Meeting 21st AFACT Meeting
th
DATE Jun 29 to Jul 3, 1998 Sept Sept Apr 19-20, 01 Oct 1 - 5 Apr 18-19, 02 Oct 28 Nov 1 02 Jan 2004
VENUE Tehran, Iran (confirmed) Seoul, Korea Taipei, Chinese Taipei Bali, Indonesia Jakarta, Indonesia Lankawi, Malaysia Kuala Malaysia Lumpur,
Karachi, Pakistan
7.
Milestones SEPT 1990 AUG 1990 NOV 1990 JAN 1991 APR 1991 SEPT 1991 SEPT 1991 OCT 1991 Appointment of the first term Rapporteur, Mr Kenji Itoh and Vice Rapporteur, Ms Jocelyn Ang of Japan and Singapore respectively Inaugural meeting of JSEB The formation of Japan-Singapore EDIFACT Board (JSEB) Korea became a member of the JSEB JSEB renamed Japan-Korea-Singapore EDIFACT Board (JKSEB) China became a member of the JKSEB Chinese Taipei became an associate member of the JKSEB Japan-Korea-Singapore EDIFACT Board (JKSEB) renamed Asia EDIFACT Board (ASEB) Rapporteur/Vice Rapporteur of JKSEB changed title to Rapporteur/Vice
Page 53
MAR 1992 MAY 1992 JUN 1992
AUG 1992 OCT 1992
Rapporteur for Asia Inaugural meeting of the ASEB Finance Joint Working Group (FJWG) Malaysia became a member of the ASEB Mr Kenji Itoh of Japan was nominated as the Rapporteur for the 2nd term and Mr Sohn Wan Soo of Korea was nominated as the Vice Rapporteur India became a member of the ASEB Mrs Pearleen Chan of Singapore was appointed as the new Chairman of ASEB and Mr Yasuyuki Sakakibara was appointed as the new Vice Chairman Inaugural meeting of the ASEB Awareness & Education Working Group (AS AEG) Inaugural meeting of the ASEB Technical Assessment Working Group (AS TAG) Inaugural meeting of the ASEB Transport Joint Working Group (AS TWG) Inaugural meeting of the ASEB Customs Joint Working Group (AS CWG) Thailand became a member of the ASEB Inaugural meeting of the ASEB Purchasing Joint Working Group (AS PWG) Inaugural meeting of the ASEB Security Working Group (ASSWG) Inaugural meeting of the ASEB Electronics & Computing Working Group (AS-ECG) Inaugural meeting of the ASEB Air Transport Working Group (AS-ATG) Philippines and Sri Lanka became members of the ASEB Inaugural meeting of the ASEB Internetworking Implementation Committee (AS-IIC) Iran became a member of the ASEB Indonesia became a member of the ASEB MOUs for Inter-VAN connectivity during the pilot stage had been signed during the 13th ASEB in New Delhi between: Dagang*Net and KTNET Dagang*Net and NICNET
Page 54
MAY 1993 OCT 1993 FEB 1994 JUN 1994 Nov 1994 Nov 1994 Jun 1995 JUN 1995 JUN 1995 JUN 1996 NOV 1996 NOV 1996
FEB 1997 APR 1997 APR 1997
Dagang*Net and EDINET Signing of MOU for Inter-VAN connectivity in Kuala Lumpur between Dagang*Net and TRADE-VAN Inaugural meeting of the ASEB Environment Protection Working Group (AS-EPG) Inaugural meeting of the ASEB Healthcare Working Group (ASHWG)
Page 55
EDI and EDIFACT - Creating An Awareness in Asia
SECTION 4 - UN/EDIFACT Message and Code Handbook (MACH V2.4) Best Practices for Designers Source: T1-Bernd Boesler Status: Revised for approval Date: March 2002
Acknowledgements Part I of this handbook was written by Marcel Deturche, of EDIFRANCE, who is the past Chairman of the Technical Assessment Group (TAG) in the European Board of EDI Standards. Parts II and III of the Handbook were written by Peter Wilson, the Principal Advisor to UKPEB (the UK Partnership for Electronic Business). Part III.3 was written by Jonathan Allen. Part IV was written by Jim Meunz, Senior Director of the Uniform Code Council. Annexes A and B were written by Don Trafford, who was the first Chairman of TAG. The handbook was reviewed and approved by the UN/CEFACT/EWG T1 Technical Assessment Group (T1). Comments Comments on the UN/EDIFACT Message and Code Handbook: Best Practices for Designers should be sent electronically to either of the editors: Paul Hague Email: paul.hague@e-centre.org.uk Margaret Pemberton Email: diskray@w150.aone.net.au Bernd Boesler Email: bernd.boesler@din.de
Contents of Section 4 MACH V2.4
SECTION 4 - UN/EDIFACT Message and Code Handbook (MACH V2.4)! PART I - GUIDELINES ON WHEN TO DESIGN A MESSAGE! 1 Background .................................................. ! 1.1 Requirements Analysis.............................. ! 1.2 References .............................................. ! 2 Message Functionality................................ ! 2.1 Terms and definitions............................. ! 2.2 Business and information modelling principles! 2.3 UN/EDIFACT principles......................... ! 2.4 Comparisons between BIM and UN/EDIFACT! 2.5 Guidelines................................................ ! PART II - PREPARING MESSAGE BOILERPLATES! 1 Background .................................................. ! 1.1 Assumptions............................................ ! 1.2 Problem Analysis .................................... ! 1.3 References .............................................. ! 2 Overview....................................................... ! 3 The Functional Definition Section ............. ! 3.1 A simple format for the Functional Definition section! 3.2 Extracts from a sample of Functional Definition sections! 3.3 Summary.................................................. ! 4 Field Of Application Section....................... ! 4.1 Default text .............................................. ! 4.2 Variations of the default......................... ! 4.3 Deviation from the default ..................... ! 4.4 Summary.................................................. ! 5 The Principles Section................................ ! 5.1 Guidelines for preparing the Principles section! 5.2 Pitfalls in preparing the Principles section! 5.3 Summary.................................................. ! 6 Message Terms and Definitions................ ! 7 The Data Segment Clarification Section.. ! 7.1 Introductory text ...................................... ! 7.2 Guidelines for describing Segment Groups! 7.3 Guidelines for describing segments..... ! 7.4 Combining the segment group and segment descriptions! 7.5 Dividing the message structure into sections! 7.6 A word of caution .................................... ! 7.7 Summary.................................................. !
ii
Conclusion.................................................... ! PART III - GUIDELINES FOR CODE NAMES & DEFINITIONS! 1 Background .................................................. ! 2 The Technical Assessment Checklist for Codes! 3 Naming and Defining Codes...................... ! PART IV REDESIGNING SEGMENTS ............... ! 4.1 Background............................................................... ! 4.2 Reason for Redesigning Segments ...................... ! 4.3 Methodology ............................................................. ! 4.4 Segment Redesign .................................................. ! ANNEX A UN/EDIFACT Syntax Implementation Guidelines (1988)! 1 INTRODUCTION ...................................................... ! 2 BASIC REQUIREMENTS FOR EDI APPLICATIONS! 3 INTERCHANGE AGREEMENT.............................. ! 4 TERMINOLOGY........................................................ ! 5 CHARACTER SET FOR INTERCHANGE............ ! 6 TRANSMISSION COMPONENTS ......................... ! 7 Identification & Control of UN/EDIFACT Messages! 8 Basic UN/EDIFACT Syntax Rules.......................... ! 9 SEGMENT CONSTRUCTION AND TRANSMISSION RULES! 10 EDIFACT SERVICE & CONTROL MESSAGES ! 11 MIGRATION TO EDIFACT ................................... ! ANNEX B General Introduction to UNSM Descriptions (1988)! 0 Foreword .................................................................... ! 1 References................................................................. ! 2 Terms and Definitions .............................................. ! 3 Message Structure.................................................... ! 4 Interchange Structure............................................... ! 8 Appendix I : Acronyms Commonly Found in AFACT Materials! APPENDIX II: BROCHURE ON UN/CEFACT .................. ! CEFACT Recommendations, Tools and Methodologies! APPENDIX III : GROSSARY/DEFINITION RELATING TO UN/EDIFACT! Appendix IV : UN/CEFACT Open Development Process! Appendix V : UN/CEFACT Intellectural Property Rights Policy! Appendix VI : List of UN/CEFACT Recommendations! Appendix VII : UNSMs Development History ............. ! Appendix VIII : ebXML Sources ................................... !
iii
General Introduction
The Message and Code Handbook (MACH) is a set of guidelines and best practices for Message Designers and Technical Assessment Groups. The MACH aims to bridge the gap between the Message Design Rules (MDRs) and the production of a message according to the Rules for Presentation of Standardised Message and Directories Documentation (TRADE/WP.4/R.1023 and its subsequent revisions). The guidance contained within the MACH is based upon several years experience of UN/EDIFACT message design and assessment. By documenting advice which was previously only provided verbally, it is hoped that the MACH will raise the level of quality and understanding of the UN/EDIFACT standard. Improving the quality of the source language will also make it easier for external parties to translate the directories into other languages; an important consideration for a global standard. One of the main objectives of the MACH is to transfer a larger degree of responsibility for message quality to the message submittor. This cannot be accomplished without detailed guidance. The UN/EDIFACT process has done much to ensure quality assurance at the end of the message development cycle, but this has occasionally resulted in a procedural bottleneck in the latter stages. By transferring knowledge (and with it more responsibility) to the message developer, it is hoped that there will be a lower Data Maintenance Request rejection rate in the future. The local Technical Assessment Group (TAG) and the T1 Technical Assessment Group (T1) will still be available to provide hands-on advice but there should be fewer DMRs requiring resolution, leading potentially to faster production of directories. In the context of empowerment, the UN/EDIFACT Working Group (EWG) will assume the task of producing UN/EDIFACT directories, so this step of re-addressing the balance of quality is seen as an important one. The MACH is divided into four parts, each dealing with a significant area of message design: Part 1 - Guidelines on when to design a message - provides a better understanding for the context in which a new batch EDI message should be designed. It also explains the common usage of batch EDI message features such as message type, document/message name, message function, etc. Part II - Preparing Message Boilerplates - aims to establish consistent criteria for deciding what information to state in each of the sections of the message boilerplate. Through the use of examples to illustrate good practice it has been possible to answer the six classic analytical questions with respect to boilerplates: the who, when, why, where, what and how. Part III - Guidelines for Code Names and Definitions - is a comprehensive set of guidelines for developing names and definitions for UN/EDIFACT Code Values. Traditionally, the development of codes has been the Achilles heel of the UN/EDIFACT process since there has been very little guidance in this area. Each year a high percentage of code requests is referred to T1 for resolution based upon the fact that the name of the code does not match the description. The aim of the set of guidelines in part III is to reduce significantly the percentage rate of code rejection. Part IV Redesigning Segments is a brief guide to redesigning existing segments with multifunctionality to comply with the Message Design Rules (MDRs). The section outlines a methodology and examples for use by users and answers the questions of why and when to redesign a segment. Required Reading Each part of the Message and Code Handbook makes reference to specific documents which will aid the understanding of those individual parts. However, on a general basis, knowledge of the following UN/EDIFACT documents is assumed as a prerequisite to the whole handbook:
iv
I. The EDIFACT Syntax (ISO 9735) II. The Batch EDI Message Design Rules (TRADE/WP.4/R.840/Rev.4) III. The Interactive EDI Message Design Rules (TRADE/WP.4/GE.1/R.1237) IV.Rules for Presentation of Standardised Message and Directories (TRADE/WP.4/R.1023/Rev.3) V. Technical Assessment Checklist (Batch and Interactive) VI.The UN/EDIFACT Directory
Documentation
PART I - GUIDELINES ON WHEN TO DESIGN A MESSAGE 1 Background
Part I of the Message and Code Handbook - Guidelines on when to design a message - provides a better understanding for the context in which a new batch EDI message should be designed. It also provides guidance on the common usage of batch EDI message features such as message type, document/message name, message function, etc.
1.1
Requirements Analysis
The primary purpose of the UN/EDIFACT process is to provide standard messages to users to cover their information exchange needs. In theory, taking into account the diversity of information exchange supporting all kinds of business, the number of messages that may be standardised, if not infinite, is great. However, the design approach adopted by UN/EDIFACT of using generic rather than specific data structures promotes reusability and hence helps to limit the number of potential messages. This decision was taken in order to ensure that the UN/EDIFACT standard is not merely a collection of disparate structures corresponding to specific requirements. Rather, the generic approach is based upon shared common exchange structures and allows for the design of fewer structures to support a wide range of requirements thus reducing the maintenance work load The generic approach does not only apply to the structural components of the message (segments, composite data elements and simple data elements) but also to the messages themselves. These generic principles, which are in place to provide universal and multi-sectoral use, include, but are not limited to, prohibiting the duplication (or overlap) of function and prohibiting the duplication of data structure names. As part of the generic approach, message design should follow some basic consistency principles: reusability of UN/EDIFACT data structures in a message; reusability of UN/EDIFACT data structures across message versions; a consistent relationship between user data and the corresponding UN/EDIFACT data structures; a consistent way of handling and processing the messages.
The reusability of UN/EDIFACT data structures, except for messages, is already largely covered through common use of supporting directories. The reusability of UN/EDIFACT data structures across message versions is largely achieved via the version/release procedures and the maintenance rules which relate to upwards compatibility. Consistency in the relationship between user data and UN/EDIFACT data structures is addressed by the Message Design Rules and initiatives like the harmonisation of Message Implementation Guides (MIGs). Nevertheless, it will take time to be fully achieved and a degree of care is required to avoid disturbing the installed user base. Consistency in the way that messages are designed is an issue that has been partially addressed by the Message Design Rules. More guidance is required in order to achieve the ultimate goal that, as far as possible, one piece of user data can be captured by one and only one UN/EDIFACT data structure (segment, composite or data element). Similarly, a set of user data (for example, person identification details, allowance or charge description, contact and communication information) should always be handled using the same segment or segment group.
A set of recommended best design practices in the Technical Assessment Checklist may considerably improve data consistency, ease the technical assessment phase and ease the message design phase by solving some basic issues. For example, there is no clear guidance on when to design a new message instead of reusing an existing one. Also, there is a lack of consistency in the way that messages are changed, deleted and acknowledged. Additionally, there is no common guidance on the way in which key processing attributes (business function, business activity, data processing activity, usage case, occurrence of usage case) are provided. On this latter point, the UN/EDIFACT directory set illustrates that a full range of solutions exists: messages which are limited to a sub-sector (e.g. container handing within the transport sector); messages with a limited functional scope (e.g. the container messages); messages with a very wide scope (e.g. GESMES, APERAK); messages which are bi-directional; messages which are uni-directional (e.g. all request and all response messages); messages which cover several processing activities (e.g. original, change, deletion, response, acknowledgement); messages which are limited to one processing activity (e.g. ORDERS, ORDCHG, ORDRSP). In some cases, this diversity in message design may be based on well defined business requirements but, unfortunately, it is often the result of inconsistent design practices, inconsistent usage of existing structures and variable interpretations of the rules and guidelines. The fact that the rules have been open to interpretation and that there are significant gaps in the provision of guidance are issues that contribute most to the extent of the diversity.
1.2
References
Business and Information Modelling Framework (Trade/WP.4/1995/CRP.21)
Message Functionality
Consistent guidelines for the design of batch UN/EDIFACT messages can be provided by drawing comparisons between the design philosophies of UN/EDIFACT and Business and Information Modelling (BIM). In order to make the comparison, though, it is necessary first of all to provide terms and definitions to explain the terminology being used, and then to describe BIM and UN/EDIFACT independently. (Note that for readers who are familiar with UN/EDIFACT and BIM design philosophies and terminology, it is possible to move directly to the guidelines in section 2.5.) 2.1 Terms and definitions
The following terms and definitions are applicable to section two: TERM Function DEFINITION The function of an object is its main goal. The function can be viewed as an attribute either of an object, or of an entity (e.g. function of a message).When identified by its business function (e.g. ordering function), however, the function can be seen as an entity.
TERM Message function
Business function
Activity Data processing function
Message type Message
Message profile
DEFINITION Description of the intended use of a message. It is generally equivalent to the business function which makes use of it or which generates it (such as ordering, order; invoicing, invoice; etc.). The information content of the message (insurance claim notification, directory definition, etc.) may also add clarification to the description of the message function. A business function is a set of activities performed in order to achieve a goal in a business environment. The name of the business function is generally a verb which corresponds to an action (e.g. ordering, invoicing, paying, etc.). An activity is an elementary action which has a limited goal from a business or data processing view point. A data processing function is a set of activities performed in order to achieve a goal in a data processing environment, e.g. receiving data, storing data, retrieving data, checking data. A data processing function is independent of the type of business which is performed. A message type identifies an EDI message specification in a given standard. A message is a set of data which is formatted according to a message type. It often has a document equivalent. It may correspond to either a class of documents (e.g. orders) or a subclass (e.g. blanket order). A message profile is the way in which a message type is used in a given business or data processing context.
2.2
Business and information modelling principles
A business or data process can be represented by a series of decomposition diagrams in a model. A decomposition diagram describes activities at a given level of abstraction. In IDEF0, the modelling methodology referred to by UN/EDIFACT, all sets of actions irrespective of the level of decomposition are considered as activities. In the context of the Message and Code Handbook (MACH), a distinction is made between activities at the lower level of decomposition and activities at higher levels of decomposition. Only those at the lower level of decomposition will be designated as activities; those at the higher level will be designated either as sub-functions or functions. An activity, then, should be considered as the lower level decomposition of a process. The basic criteria for an activity is that it should: occur over a period of time, have an identified purpose, create some kind of output. A sub-function is a set of activities which is not considered as a stand alone set of information with significance from a business or data processing perspective. The basic criteria for a sub-function is that it should:
occur over a period of time, have an identified purpose, not create by itself any kind of output (only the component activities do), be an intermediate level of decomposition which, as such, has no particular business relevance.
A function is a set of activities or sub-functions which is considered as a stand alone set of information with significance from a business perspective. Therefore, in a given business, a function is generally considered as one of the main parts of the business process and it is usually referred to by most of the parties involved in the business. The basic criteria for a named process is that it should: occur over a period of time, have an identified purpose, not create by itself any kind of output (only the component activities do), be at a level of decomposition which has a business relevance.
In most cases, especially in an EDI context, a decomposition diagram combines business activities and data processing activities. The diagrams main goal is to describe the information flows and activities needed to support business. 2.3 UN/EDIFACT principles
The UN/EDIFACT standard includes the following concepts for batch EDI messages: Concept Description Segment/ Data Element UNB-UNZ UNB/0026
Interchange Application reference
A sequence of messages. Identification of the application area. (The reference is usually assigned the same code as the message type if all messages of the interchange are of the same type.) Acknowledgement Code specified by the sender requesting request an acknowledgement of the interchange (by the use of a CONTRL message). Message The message is the basic EDI unit. In most cases, it is considered as equivalent to an electronic document. Message type The message type is the standard specification of the format (content and structure) of the message Document/message name A message or document name is used to and number specify the business usage of the message type (e.g. hire invoice as opposed to a sales invoice). The message or document can also be identified by a number. Message function Code indicating the data processing operation on the message (such as cancellation, deletion, original, request, response, etc.).
UNB/0031
UNH-UNT
UNH/S009
BGM
BGM/1225
Response type
Code specifying the type of acknowledgement required or transmitted.
BGM/4343
The interchange is the communication between partners in the form of a structured set of messages and service segments starting with an interchange control header (UNB) and ending with an interchange control trailer (UNZ). The application reference is used to identify the application which will process the message. It is not the identification of a software or implementation component (hardware or software) but rather the application domain to which the message processing belongs (invoicing, ordering). The acknowledgement request is used to identify whether the interchange is to be syntactically acknowledged. If requested, a CONTRL message will be returned indicating the receipt of the interchange and the correctness (from a syntax point of view) of the contained messages and/or groups. The message is the data set which is interchanged at a given time for a specific purpose. It is formatted in accordance with the message type to which it corresponds. In the same way as a paper document, it can be transmitted in several steps. As it is a processing unit, it can support several data processing operations (cancellation, change, re-transmission, etc.). Notably, these operations, except for the transmission sequence, cannot be specified using the UNH segment only. A full identification and specification of these operations requires the use of the BGM segment. As a consequence, the use of the UNH segment without the BGM segment in a message type is normally not sufficient to support all data processing operations in the message and may result in a misuse of the concepts and data of the UNH segment. The Document/message name (BGM) is a further specification of the usage of the message type. As the BGM segment has its own identification number which is different from the message number, it enables the distinction between the message, which is transmission oriented, and the document, which is business and application oriented. It also enables the distinction and identification of the different operations on a document. The message number can change for each operation while the document number often remains the same. The message function is used to specify the data processing operations on the message (e.g. original, cancellation, deletion, re-transmission, etc.). The basic idea is that the message or document remains as a stand alone business entity but may evolve during the process depending on the data processing operations made on it. A version-release mechanism should be used in order to trace the message life cycle in a logical manner. The current definition of the response type in the BGM segment is ambiguous. It combines two concepts: the type of document which is expected in response to the message; and the type of response the current transmission of the message relates to in the message life cycle. The response type data element should be limited to the first case. The second case should be covered by data element 1001/1000 in BGM as it is indicates potential usage profiles (response or acknowledgement) of the message type. It is linked to the original message but this can be achieved using specific reference mechanisms such as the Common access reference (data element 0068) which was defined for this purpose. 2.4 Comparisons between BIM and UN/EDIFACT
Through the comparison of the concepts from Business and Information Modelling with those in UN/EDIFACT a set of equivalencies and best practices can be identified.
1.
The concept of application and message type in UN/EDIFACT is very close to the concept of function. In most cases, a function has a single basic data model which is common to all flows between the activities of the function. This means that all the flows of the function have more or less the same structure and sometimes a degree of similarity in content. As a consequence, a function should, in most cases, require only one message type. Depending on the level of genericity of the message type and the level of specificity of the function, several functions may use the same message type. The concept of message function in UN/EDIFACT is very close to the concept of activity and flow. Therefore, all the attributes of the message/document (especially in BGM) should be used to identify the different flows between the activities of the function and the data processing operations which are performed on them.
2.
In summary, a standard message should correspond to a business function. The message function should be equivalent to the purpose or goal of the business function. Furthermore, a flow between two activities should be identified as a document (data elements 1001/1000 in the BGM segment) and a data processing operation on the document should be identified using data element 1225 in the BGM segment.
2.5
Guidelines
The following set of guidelines assists in the determination of when to design a new batch EDI message. 1. A message type should correspond to a business function; in principle, there should be only one message type per business function. The identification of a business function is subjective and is finally to be agreed upon by the users and those involved in the business. Note however, that a business function is not an activity, but it can be decomposed into activities. Two message types may have the same or a similar structure. The basic criteria in the design of a message type is not its structure but rather the function to which it corresponds. Message types with similar structures may be an indication of similarities at business function level. Similar message types may be combined in a more generic message type supporting several business functions if it is agreeable to parties involved in the business domains. Merging of message types should not result in business ambiguities (business organisation or processing difficulties). The BGM segment should be used to enable the identification of the different message profiles and the different operations on the message. The new version of the message design rules stipulates that a message must be specified with a BGM segment. The function of the message type should be the same as the description of the business function(s). The functional (or business) profiles of use of the message type corresponding to documents or business flows should be identified using data elements 1001/1000 in the BGM segment. The various data processing operations for the message should be identified using data element 1225 in BGM.
2.
3.
4. 5. 6.
7.
Data elements 1225/4343 should not be used to specify whether or not the message is a response, nor what type of response it is. The response is a business usage case of the message type and should be identified by using data elements 1001/1000. The response type data element (BGM/4343) should be limited to the identification of the type of document which is expected in response to the message
8.
PART II - PREPARING MESSAGE BOILERPLATES 1

1.1
Background
Assumptions
Part II of the Message and Code Handbook - Preparing Message Boilerplates - has been written according to the following assumptions: There is currently very little guidance about how to prepare the content of the message boilerplate. The absence of written guidance means that it is more difficult to manage a high level of consistency in the boilerplates. Message Design (MD) Groups invest a lot of time and effort in the development of boilerplates the provision of guidance will help to reduce this development time and establish the quality level. Groups which prepare Message Implementation Guidelines (MIGs) will benefit from boilerplates which are well written and precise. Boilerplates which are written precisely in the English language will be easier to translate into other languages. Parties who were not involved in the initial message design will have a greater understanding of how the message (including all components) was intended to be used.
1.2
Problem Analysis
The number of messages being added to the UN/EDIFACT directory is steadily increasing and so too is the number of new message design groups. With these increases, it is very important to document the practices used to prepare boilerplates and also to highlight some of the common mistakes that are made. By preparing a set of guidelines a level of quality is established. Conversely, the absence of guidelines places the emphasis on groups remembering what has been done before and thus makes it more difficult to maintain a high quality level. One of the main areas of confusion in preparing message boilerplates is deciding what text to put into each of the sections, since some of the sections are very closely related. This has led to the problem where, for example, vital information is difficult to find or not available in some messages. 1.3 References
The only reference relating to boilerplate documentation is in regard to the layout of each of the sections: Rules for Presentation of Standardised Message and Directories Documentation (TRADE/WP.4/R.1023/Rev.3).
Overview
UN/EDIFACT Message Boilerplates are divided into sections in accordance with the criteria specified in the Rules for Presentation of Standardised Message and Directories Documentation. However, rather than describe the content of each section (some of which simply contain standard text), only those sections which cause most difficulty for the message design groups and technical assessment groups have been covered within this report. These are the: Functional Definition section Field of Application section
Message Terms and Definitions section Principles section Data Segment Clarification section Examples have been provided to describe how to prepare the content for each section. In some cases imperfect examples have been selected from the message boilerplates, as well as model examples, in order to illustrate a point. It should be noted that the imperfect examples are a reflection of the lack of guidance provided so far rather than any other factor.
The Functional Definition Section
This section relates to section 1.1 of the standard message boilerplate layout as shown in the Rules for Presentation of Standardised Message and Directories Documentation. There are two main conclusions from an analysis of the Functional Definition sections of all of the messages in the directory. Firstly, the large majority of the Functional Definitions are of a good standard since they are concise and leave no room for misinterpretation. Secondly, it is possible to identify three problems from the analysis of the imperfect Functional Definition sections. The three problems are: failing to state the parties responsible for sending or receiving the message (or stating the information in a different section). placing text in the Functional Definition which would be better placed in the Principles section (such as the relationship to other messages). stating terms and definitions in the Functional Definition which would be better placed in the section dedicated to terms and definitions. These three problems are part of the wider issue of not knowing where in the boilerplate to state information about different aspects of a message. The best way of solving these problems (and the overall issue) is to provide more guidance about what should be stated in each particular section in the message. This part of the report is focused on improving the Functional Definition section. 3.1 A simple format for the Functional Definition section
A corollary of the conclusions from the analysis is that it is possible to offer guidance about what constitutes a good functional definition. At its most basic, the functional definition should state the party which sends the message, the party which receives the message and the purpose of the message (i.e. what it is for). This leads to a simple default formula: The [state full Message name] message is sent between the [state sender(s)] and the [state receiver(s)] for the purpose of [state function(s)]. Obviously, there are many variations of the same formula which can be used and the order of the information is unimportant. However, the maxim remains the same: state the sender(s), the receiver(s) and the function(s) of the message. For example, if there are multiple senders, receivers and subfunctions, then three simple statements will suffice: The [state full Message name] message can be sent by the [state senders]. It can be received by [state receivers]. It is used for the purpose of [list functions].
3.2
Extracts from a sample of Functional Definition sections
The following tables show a sample of Functional Definition sections extracted from EDIFACT messages. The first table provides a set of model Functional Definitions which obey the formula given above. By contrast, the second table provides a set of imperfect Functional Definitions along with suggestions for improvement. Message CUSDEC Model extract from Functional Definition section This Customs Declaration Message (CUSDEC) permits the transfer of data from a declarant to a customs administration for the purpose of meeting legislative and/or operational requirements in respect of the declaration of goods for import, export or transit. The message may also be used, for example: - to transmit data from an exporter in one country to an importer in another country; - to transmit consignment data from one customs authority administration to another; - to transmit data from a customs authority to other government agencies and/or interested administrations; - to transmit data from a declarant to the appropriate data collection agency on the movement of goods between statistical territories. A Credit Advice is sent by the Account Servicing Financial Institution to the Account Owner to inform the Account Owner that its account has been or will be credited for a specified amount on the date indicated, in settlement of the referenced business transaction(s). The International Forwarding and Transport Dangerous Cargo List Message is a message: - from the party acting on behalf of the carrier for the gathering of the dangerous goods information of the cargo in a certain port or place of call or loading, - to the party acting on behalf of the carrier in the next port or place of call or discharge, conveying the information relating to one conveyance or voyage of a means of transport such as a vessel, train, truck or barge, on the dangerous goods being carried on board -irrespective of the operations that will take place in the next port of call. The Payroll Deductions Advice is sent by a party (usually an employer or its representative) to a service providing organisation, to detail payments by payroll deductions, on behalf of employees, made to the service providing organisation. Comments Good example of a functional definition for a message with multiple related functions.
CREADV
A good text book example.
IFTIAG
A good functional definition since it follows the formula: state sender, state receiver, state function.
PAYDUC
A good functional definition. The text in parentheses helps the reader to understand, through the use of examples, which type of party can act as the sender.
10
In order to understand better how to prepare good Functional Descriptions it is necessary also to analyse the imperfect examples. Where appropriate, guidance is given regarding how to improve the imperfections, though there is no intention to apply the guidelines retroactively. Message INSPRE Imperfect example of Functional Description section The Insurance Premium message is used by communicating parties to notify the recipient about premiums due from a client. All information needed to produce a detailed request for payment can be sent. Comments This functional description would benefit greatly from examples of the communicating parties. (See PAYDUC above.) In addition, several uses of the message are given in the Principles section these would be better placed in the Functional Definition section. The first two paragraphs are, without a doubt, well placed within the functional description. However, the latter three paragraphs would be better placed within the Principles section of the message boilerplate.
PAXLST
This Passenger List Message (PAXLST) permits the transfer of passenger/crew data from a Customs, Immigration or other designated authority in the country of departure to the appropriate authorities in the country of arrival of the means of transport. Where national privacy legislation permits, and with the agreement of all parties involved, this message may also be exchanged between carriers and Customs, Immigration, Police or any designated authorities. This transfer of data may occur upon departure from the sending agency and prior to arrival of the vessel/ flight at the receiving agency. This is to permit the designated authority at the place of destination to screen this data and take timely decisions related to the clearance of passengers and crew. The transfer of data may also occur prior to departure, carriers may transmit passenger listings to customs and immigration for pre-arrival clearance. Endorsement of this message by the Customs Cooperation Council does not necessarily mean endorsement by national Immigration or Police authorities, nor does it place any obligations on parties to apply the message. A message to enable the transmission of the results of tests performed to satisfy a specified product or process requirement. The content includes, but is not limited to, test data and measurements, statistical information, and the testing methods employed.
QALITY
There is no mention of the sender or recipient.
11
3.3
Summary
To summarise thus far: The Functional Definition states who the message is for and why it was designed (the purpose).
Field Of Application Section
This section relates to section 1.2 of the standard message boilerplate layout as shown in the Rules for Presentation of Standardised Message and Directories Documentation. The Field of Application section is used to indicate where a message can be used. Since UN/EDIFACT has an international focus, messages are designed to cover international requirements. The majority of messages are also defined to be independent of business or industries, with the intention being to cover as wide a range of requirements as possible. Therefore a default text can be stated in the Field of Application section of the boilerplate. From an analysis of the D.95A Message Directory, 81 messages out of the 101 messages listed contain the default text only. The remaining 20 messages contain different wording either in addition to the default, or instead of the default text. 4.1 Default text
The default text is: The [state message name] may be applied for both national and international trade2. It is based on universal practice and is not dependent on the type of business or industry. 4.2 Variations of the default
From the analysis of the 20 messages that do not conform to this simple default, all but one can be considered to be valid variations on a theme. The variations come in several guises: Several messages (e.g. CONDRO, CONDRA) may be applicable to many sectors but have been designed by one particular industry sector (e.g. the Construction sector) with examples from that industry. This clarification is stated for the benefit of the user. Several messages (e.g. INSPRE, PRPAID) have also indicated the name of the sector for which the message was designed (e.g. insurance). 4.3 Deviation from the default
The one message with a Field of Application section that has information in addition to the default or variations thereof, is CONAPW. It could be argued that much of the information (all but the final paragraph) is about who can use the message which is more pertinent to the Functional Definition section. 4.4 Summary
To summarise thus far: The Functional Definition section states who the message is for and why it was designed (the purpose). The Field of Application section states where the message is applicable for use.
2
Note: In some messages, the word transactions or applications is used instead of the word trade.
12
The Principles Section
This section relates to section 1.3 of the standard message boilerplate layout as shown in the Rules for Presentation of Standardised Message and Directories Documentation. The Principles section is closely related to the Functional Definition section. In fact, the distinction between the sections has become blurred over the years, so much so that some messages contain text in the Principles section that should be in the Functional Definition and vice versa. The problem is mainly due to the fact that there has been no guidance on how to make the distinction. The first step to making the distinction between the sections clearer has already been covered in this paper through defining the contents of the Functional Definition. The contents of the Principles section is more difficult to define clearly, as there are more variables involved. However, from an analysis of the directories, there is a common set of guidelines that can be determined. This common set of guidelines (shown below) leads to the conclusion that the Principles section should be used to provide information about what considerations dictated the message design, and when the message should be sent, not in terms of time but in terms of the pre-conditions that must be satisfied prior to message transmission. The relationship with other messages may also be stated often it is one of the conditions that one message must be sent in response to another. 5.1 1. Guidelines for preparing the Principles section If the message is related to, or sent as a response to, another message or transaction, then the relationship should be stated. Note that in the vast majority of cases, the relationship between messages stated in the Principles section is described textually. However, the relationship between messages is sometimes, though infrequently, shown as a simple illustration of message flows. If this latter technique is used then the diagram should be high-level rather than a complex scenario model, since it is much more difficult to reach international agreement on complex scenario information. From a practical presentation point of view, the message flow diagram shall be limited to the use of ASCII characters. (For an example of a high-level message flow diagram, refer to the BAPLIE message or the ITRGRP message.) Message CONDRA BANSTA Model extract from the Principles section CONDRA will refer to the message CONDRO, previously received by the business parties. A BANSTA message may cover the response given to any previously sent message, such as a commercial or payment instruction, a request for information etc. This message provides a means to report on errors and inconsistencies found in the original message at application level. The party providing the transport services will send an instruction contract status message, usually after receipt of the instruction message.
IFTMCS
2.
State the relationship (e.g. one-to-one, one-to-many) between the main entities in the message. Also, identify whether one or more business transactions can be sent per message. Model extract from the Principles section The design principles adopted allow for referencing one or more commercial documents pertaining to the same declaration and for the
Message CUSDEC
13
DEBADV
IFTDGN
INSPRE RECECO
SANCRT
grouping of document lines into a single customs item. A Debit Advice may cover the financial settlement of one or more commercial trade transactions, such as invoices, credit notes, debit notes, etc. A Dangerous goods message may contain several consignments. A consignment may contain several goods items/ dangerous goods classes. Each goods item can only contain one dangerous goods class. The Insurance Premium Message refers to one single insurance contract. One credit cover may relate to one or more line covers. One credit cover may relate to one or more order covers. For each distinct period there is only one line cover. One credit cover must relate to only one buyer. One credit cover must relate to one seller. A certificate may cover several product items. A certificate should however be limited to product items of the same type or category.
3.
State any design considerations of a related nature that have been specifically excluded. (Note that this technique is often employed when distinguishing between messages used in different domains or messages that are of a similar, though distinct, nature.) Model extract from the Principles section It [BANSTA] is not intended to report on syntactical errors or to provide a non-repudiation response. CONDRA is the EDIFACT message to administer the exchange of engineering/ CAD files. The message itself does not consist of any engineering or graphical information. This information will be transferred within files written. It [CREADV] is not intended for use in securities trading. Data requirements for tracking equipment where equipment is not associated with a consignment (such as repair container) are NOT addressed in this message. Its [REQDOC] use should be limited to requesting documents for which there is no other more specific message already provided (e.g. Request for Quotation).
Message BANSTA CONDRA
CREADV IFTSTA
REQDOC
4.
State any business or legal principles that need to be explicitly obeyed. (Note: it is often more appropriate to state legal and business information in an Interchange Agreement.) Model extract from the Principles section If part of the invoice is disputed, then as a consequence the whole invoice is disputed. The message can replace the actual contractual document such as for instance a Waybill, under those circumstances where there are no legal or other restrictions. The only way to modify a Multiple Payment Order message is to cancel the whole message or part thereof (e.g. by the use of the FINCAN message). Where remittance advice relates to a dispute, the message: - does not necessarily relate to one settlement date - is not necessarily a notice for a payment to be made
Message COMDIS IFTMCS
PAYMUL REMADV
14
Message SANCRT
Model extract from the Principles section Inclusion of standard endorsements or generic textual declarations in the certificate is discouraged. It is recommended that these and other certification protocol requirements be accounted for outside the certificate in individual trading partner agreements.
5.
State conformance requirements to officially recognised codes of practice. Model extract from the Principles section Unless otherwise specified, the documentary credit amendment is subject to the Uniform Customs and Practices for Documentary Credits, International Chamber of Commerce, Paris, France, which are in effect on the date of origination.
Message DOCAMA
6.
If the message is intended to work in conjunction with the exchange of associated data (e.g. external objects) then this should be stated, along with an indication of the cross-referencing techniques used. Model extract from the Principles section CONDRA is the EDIFACT message to administer the exchange of engineering/ CAD files. The message itself does not consist of any engineering or graphical information. This information will be transferred within files written in existing standard graphical exchange formats or native formats, referred to within the message as external file reference to identify each of these files. The nature of the engineering files and its content is not relevant for the syntax of the EDIFACT message.
Message CONDRA
5.2
Pitfalls in preparing the Principles section
There are a number of potential pitfalls that should be avoided when stating the Principles section in message documentation. By avoiding the pitfalls, Message Designers and TAGs lower the level of maintenance that may be required, lower the level of duplication and raise the level of understanding. The pitfalls are shown below along with some examples which illustrate the point. 1. Do not specify how often (i.e. in terms of time) the message should be sent. Instead specify when the message should be sent in terms of the pre-conditions that must be satisfied prior to message transmission. Rationale By relating the message to the conditions of arrival of goods or, where national legislation permits, prior to the arrival of the conveyance the circumstances which lead to the transmission of the message are clear. Rationale The circumstances for sending the message are not provided. It is better to relate the message to business flows or actions.
Good Example The message is transmitted upon arrival of the goods, or where national legislation permits, prior to the arrival of the conveyance.
Imperfect Example The message can be sent once or twice per day depending upon the circumstances.
15
2.
Do not include the tags or names of directory items (segments, data elements, code values) in the Principles section. Rationale Duplication of information in data segment clarification section. From a maintenance perspective, it is easy to overlook the Principles section if the message structure is changed, thus leading to conflicting information.
Imperfect Example Goods item information can be related to the corresponding containers by linking the goods item group (GID) to the container details group(s) (EQD) by means of the SGP segment.
3.
Do not include segment group numbers in the Principles section. This also applies to the Data Segment Clarification section. Rationale If it is important to give a high-level overview of the message design principles then, for maintenance reasons, it is better not to refer to segment group numbers.
Good Example The Insurance Premium Payment message structure is as follows: a. general information valid for the whole message b. information about the involved parties c. information about paid, partly paid or not paid insurance premiums d. total amounts valid for the whole message. Imperfect Example Identification of administrative information concerning the interchange partners (Gr. 2)
Rationale Segment group numbers should only be stated in the data segment clarification section and the segment table. If the message structure is modified then the message designer would have to make major changes in the boilerplate if the segment group numbers are stated in multiple places.
4.
Do not list Terms and Definitions in the Principles section. (Note: Until recently there has not been a section within the boilerplate dedicated to the purpose of stating terms and definitions specific to the clarification of the message text. However, this facility will be available in section 3.2 - Message Terms and Definitions- of the next revision of the Rules for Presentation of Standardised Message and Directories Documentation.)
Imperfect Example
Rationale
16
A number of generic transport terms are used in this specification, to be described as: * MODE OF TRANSPORT: The method of transport used for the conveyance of goods or persons, e.g. by rail, by road, by sea. * MEANS OF TRANSPORT: The vehicle used for the transport of goods or persons, e.g. aircraft, truck, vessel. 5.
In order to make the distinction clear about what should and what should not go into the Principles section, all Terms and Definitions should be placed in the relevant section in the Boilerplate (i.e. section 3.2 - Message Terms and Definitions).
Only state the function(s) of the message in the Principles section when both of the following conditions apply: the function(s) have already been stated in the Functional Definition(s) section, and the function(s) are stated only in order to understand what considerations dictated the message design, when the message is to be transmitted or, if appropriate, the relationship with other messages.
(Note that this leads to the tenet that the prime section for stating function(s) is in the Functional Definition and that the function(s) may only be repeated to aid textual understanding.) Good example When using the message for requesting catalogue data only one catalogue may be referenced. Rationale The function of the message is stated in order to explain a design principle. (Note: This example assumes that the function of requesting catalogue data has been stated already in the Functional Definition.) Rationale As the text is only stating the uses of the message (and not the design considerations), it is information that would be better placed in the Functional Definition section.
Imperfect example Typical uses of the Request for Document Message are to request information from a data base (e.g. requesting a copy of a test certificate), requesting catalogue data, and requesting statements of account. 6.
Only state the sending and receiving parties of the message in the Principles section when both of the following conditions apply: the parties have already been stated in the Functional Definition(s) section, and the parties are stated only in order to understand what considerations dictated the message design, when the message is to be transmitted or, if appropriate, the relationship with other messages.
(Note that this leads to the tenet that the prime section for stating parties is in the Functional Definition and that they may only be repeated to aid textual understanding.) Good example A buyer may order one or more goods items or services. Rationale One of the principles of design is that one or more goods items or services may be ordered.
17
The party (buyer) is being stated only as a means to aid the understanding of the design principles. (Note: The example assumes that the party buyer - has been stated in the Functional Definition section.) Imperfect example Receiving parties are: Solicitor Sending parties are: Magistrates courts, Courts of Appeal. Rationale The Functional Description should be used to indicate who the message users are. The Principles section should indicate when the message is to be used and the design considerations involved.
5.3
Summary
To summarise thus far: The Functional Definition section states who the message is for and why it was designed (the purpose). The Field of Application section states where the message is applicable for use. The Principles section states what design constraints were applied in the design of the message and when it should be sent (in terms of the pre-conditions that must be completed prior to message transmission).
Message Terms and Definitions
This section relates to section 3.2 of the standard message boilerplate layout as shown in the Rules for Presentation of Standardised Message and Directories Documentation. The Message Terms and Definitions section is a new section that has been added to the message boilerplate. The section was designed as a result of the fact that several message boilerplates contain a set of terms and definitions in the Principles section as there was no other alternative. The new section is dedicated specifically for the definition of specialist terms which are used within the other sections of the boilerplate. The suggested format for Message Terms and Definitions is as follows: State the terms in alphabetical order, On the first line, state the name of the term in uppercase characters followed by the colon character, On the next line state the definition of the term. This results in the layout:
NAME OF TERM: Definition of term used within the message boilerplate.
For example: MEANS OF TRANSPORT: The vehicle used for the transport of goods or persons, e.g. aircraft, truck, vessel.
18
The Data Segment Clarification Section
This section relates to section 4.1 of the standard message boilerplate layout as shown in the Rules for Presentation of Standardised Message and Directories Documentation. The Data Segment Clarification section of the boilerplate is the key to understanding how segments extracted from the UN/EDIFACT segment directory can fulfil the Functional Definition of the message in accordance with the criteria stipulated in the Principles section. The most frequent problem in the Data Segment Clarification section stems from the fact that the segment function as stated in the segment directory is extracted for use in a particular message along with the segment tag and name. The first step towards improving the quality of message documentation is to prohibit the practice of extracting the segment function verbatim (or a slight variation of it) from the directory without adding anything to it. Segments necessarily have a generic description in the segment directory, but when they are chosen for use in a particular message it follows that they are chosen for a reason. If this reason is not indicated in the message boilerplate (in the Data Segment Clarification section) then vital contextual information is lost. In the case where the segments are non-repeating, the exact use of the segment should be indicated. In the case of repeating segments, examples of use should be provided. Note that the segment function may be extracted from the segment directory for use in the Data Segment Clarification section, but only when additional contextual information (such as an example) is added. 7.1 Introductory text
The first paragraph for the Data Segment Clarification section is standard text which appears in every UN/EDIFACT message: Standard first paragraph in Data Segment Clarification section: This section should be read in conjunction with the Branching Diagram and the Segment Table which indicate mandatory, conditional and repeating requirements. In the vast majority of cases the standard first paragraph is followed by the description of each segment and segment group stated in the order in which they are specified in the segment table. However, in several messages - such as AUTHOR, BANSTA and CREMUL - the introductory first paragraph is followed by an overview of how the message is structured. This is a useful technique if the message has several definable sections or parts to it. However, if this technique is employed there should be no reference to segment group numbers for maintenance reasons (i.e. if a new segment group is added to the message, then the textual references to the groups may be overlooked, thereby leading to inaccuracy). Instead, segment groups should be referenced by stating the intent of the segment group. For example, a segment group in the header section, whose prime intent is to provide names and addresses, should be referred to as The Name and Address segment group in the header section. A segment group in the detail section of a message whose primary intent is to give line item information should be referred to as The Line Item details segment group in the detail section. Often, it is the trigger segment that provides the information about the general intent of the segment group. The example shown below is an extract from the Data Segment Clarification Section of the AUTHOR message. If a new segment group was added between group 1 and 2, much of the text below would have to be altered because segment group numbers are quoted. It would therefore be better to refer to the intent of the segment group rather than to the segment group numbers.
19
Extract from the Data Segment Clarification section of the AUTHOR message: This section should be read in conjunction with the Branching Diagram and the Segment Table which indicate mandatory, conditional and repeating requirements. The following semantic principles applying to the message are intended to facilitate the understanding of the message. The Authorization message is structured in three levels: A, B, and C. Level A Segment Groups 1, 2, 3 and 9 contains general data related to the whole message. Level B Segment Groups 4 and 5 contains data identifying the message or transaction to be authorized. Level C Segment Groups 6 to 8 contains the authorization. The structure of the message is designed to allow several B levels, each B level being followed by its related C levels. Where a choice of code or text is given only the code element should be used wherever possible. 7.2 Guidelines for describing Segment Groups
An analysis of the UN/EDIFACT message directory indicates that segment groups are generally well described. The following points are evident from the analysis: The key is to keep the description simple and to provide a high level summary of how the segments in the group may be used. The description should not be so general that it is without value and should not be at the level of specificity normally found in Message Implementation Guidelines. The description should be a balance between these two extremes. Introduce the statement of the segment group description with: A group of segments to specify or A group of segments to indicate or a similar variation. For maintenance reasons, do not refer to other segment groups by quoting the segment group number. Instead, refer to another segment group by stating the general intent (or purpose) of the group. For example, a segment group in the header section, whose prime intent is to provide names and addresses, should be referred to as The Name and Address segment group in the header section. It is not always necessary to give an indication of the use of each segment in the segment group since many groups are quite large and the individual descriptions of the segments, immediately following the segment group description, will provide more detail. However an overview of the main segments is useful. If an overview of the segments is required within the segment group description, it is recommended the segments are described in the order in which they are specified in the segment group as shown in the segment table. If a segment group is only used under certain conditions, then these conditions should be made known. Segment Group Message Model description of segment group in Data Segment Clarification section Analysis
20
Segment Group Segment group 1: NAD-CTACOM
Message
COMDIS
Model description of segment group in Data Segment Clarification section A group of segments identifying the name and address of the parties involved in the transaction and their contacts.
Analysis
Segment group 7: DGS-FTXMEA-SG8
COSTCO
Segment group 8: QTY-GINDTM
INVRPT
A simple example of how to describe perhaps the most common grouping of segments in UN/EDIFACT messages. The description of each of the individual segments following the segment group description will provide examples of use. Note that the second sentence A group of segments to specify dangerous goods details provides a useful reminder of a design principle which related to the goods item. One goods item may be in different relates directly to the segment group being dangerous goods classes. described. A group of segments providing Simple high level description of a segment group. package quantities with package identification and relevant date/time information.
7.3 1.
Guidelines for describing segments The description of a segment should not be so general that it is without value and should not be at the level of specificity normally found in Message Implementation Guidelines. The description should be a balance between these two extremes. Message Model description of a segment in Data Segment Clarification section A segment to identify the transport details of the departing vessel. Analysis
Segment
TDT, Details of transport
VESDEP
ATT, Attribute
SUPMAN
A segment providing the member's sex or marital status details.
The description is at the correct information level. If the description had omitted of the departing vessel, vital information would have been lost, thus rendering it meaningless. Written at the correct level of specificity. There would have been no clarity if the description had instead stated: A segment specifying members attributes.
2.
If a segment is specified as non-repeating (i.e. with a maximum number of occurrences of one) the description in the Data Segment Clarification section should state exactly the intended purpose of the segment. All of the following examples are of non-repeating segments.
21
Segment
Message
DTM, Date/ time/ period DTM, Date/ time/ period
BANSTA (position 0030) BANSTA (position 0410)
Model description of a nonrepeating segment in Data Segment Clarification section A segment specifying the date and, if required, the time the message is created. A segment identifying the validation date/ time.
Analysis
IMD, Item description
SAFHAZ
A segment identifying a hazardous component of a substance.
RFF, Reference PAI, Payment Instructions
DOCADV REMADV
A segment identifying the documentary credit number. A segment specifying the conditions, guarantee, method and channel of payment for the Remittance Advice.
There is no ambiguity about how this segment is to be used. This example and the previous example illustrate another reason for giving examples. Segments can be specified in more than one place in a message. The description of IMD in the segment directory is: To describe an item in either an industry or free format. If this was simply copied into the SAFHAZ message, the user would have no idea how to use the segment. Good description - exact. The function of PAI as stated in the segment directory is: To specify the instructions for payment. Its use in REMADV is made very clear by the additional context information in the Data Segment Clarification section.
3.
If a segment is specified as repeating (i.e. with a maximum number of occurrences of more than one) the description in the Data Segment Clarification section should provide examples of the intended usage of the segment. (Note: Do not state actual code values, code names or definitions verbatim as these may change - rather give the intent of the code.) All of the following examples are of repeating segments
Segment
Message
Model description of a repeating segment in Data Segment Clarification section
Analysis
22
Segment
Message
NAD, Name and address
CALINF
Model description of a repeating segment in Data Segment Clarification section A segment to identify a name and address of a party, such as: - message sender - message recipient - ordering customer/principal - ordering customer agent
Analysis
PAI, Payment instructions
ORDERS
RFF, Reference
CODECO (Position 0040)
A segment requesting or confirming conditions of payment, guarantee and method of payment for the whole order. An example of the use of this segment is to specify that a documentary credit will be used. A segment to express a reference which applies to the entire message, such as: - reference to previous message - container announcement reference number A segment to provide a reference for the liner service, such as: - conference - marketing organization - syndicate - vessel sharing agreement A segment to identify a communication number of a person or department to whom communication should be directed, e.g. e-mail number, telefax number, telephone number.
The message design group has provided clear examples which will assist whichever group implements the message. Note that the examples do not list code value names but they are given in such a way that makes it easy for the implementor to reconcile with the code list. Good description.
Good description - exact.
RFF, Reference
CODECO (Position 0070)
CTA, Communicat -ion contact
IFTDGN
Examples provide good context information. The user can distinguish between how to use this repeating segment from how to use the same segment type in position 0040 (see above) which also repeats. Even though the main text is the same as the segment directory, the examples provide added value.
The imperfect examples provided in the next table are shown in order substantiate the fact that examples of segment usage greatly improve the description of segments in the data segment clarification section. Segment Message Imperfect description of a repeating segment in the Data Segment Clarification section Analysis
23
Segment
Message
DTM, Date/ time/ period CTA, Contact information NAD, Name and address MOA, Monetary amount 4
WKGRD C IFTCCA
RDRMES
Imperfect description of a repeating segment in the Data Segment Clarification section A segment specifying the relevant date or time. A segment to identify a person or department to whom communication should be directed. A segment to identify the relevant parties. The monetary amount component is recorded in this segment.
Analysis
Statement of the obvious. This description is identical to the directory description - it therefore adds nothing. No added value. Examples would provide more indication of context. No added value.
CONEST
When describing segments, other than the trigger segment, within a segment group, an explicit reference to the trigger segment is not enough on its own to provide contextual information for the segment in question. Examples should also be provided in accordance with the guidelines above. Rationale: The message design rules and syntax stipulate that the trigger segment is mandatory and starts a segment group. Therefore, by definition, all segments within a group must relate to the trigger segment. Merely referring to the trigger segment does not describe how the nontrigger segment may be used.
All of the following examples are extracted from descriptions of non-trigger segments (in the Data Segment Clarification section) which are specified in segment groups: Segment Message Model description of a non-trigger segment in a segment group (extracted from the Data Segment Clarification section) A segment to specify the date and time of the referenced document/message. Analysis
DTM, Date/ time/ period
APERAK
CONDPV LOC, Place/locatio n identification
A segment giving more specific location information of the party specified in the NAD segment e.g. internal site/building number.
This segment comes after the trigger segment RFF which is used to provide the document reference number. The purpose of the segment is clear without making an explicit reference to RFF. This is a valid reference to the trigger segment as it is supplemented by an example of how the LOC segment itself is used.
24
Segment
Message
DTM Date/ time/ period
CONDRO
Model description of a non-trigger segment in a segment group (extracted from the Data Segment Clarification section) Date of a reference quoted in the previous RFF segment, e.g. project date or message/document date.
Analysis
CUSEXP LOC, Place/locatio n identification
A segment identifying place/location relevant to the express consignment, e.g. country of consignment, place of loading/unloading.
This is a valid reference to the trigger segment as it is supplemented by an example of how the DTM segment itself is used. The express consignment details are specified in the trigger segment CNI. The description of LOC refers to the consignment information (without mentioning CNI) and gives an example of usage.
The imperfect examples provided in the next table are shown in order to substantiate the fact that if the description of a non-trigger segment does not provide examples of how it is to be used but merely includes a reference to the trigger segment of the group then the result is less than satisfactory. Segment Message Imperfect description of a non trigger segment in a segment group (extracted from the Data Segment Clarification section). A segment to identify a communications type and number for the contact specified in the CTA segment. A segment providing free text instruction relating to the associated INP segment. Analysis
COM, Communicat -ion contact FTX, Free text
ORDERS
CREEXT
The description of COM does not give an indication of how it is used. No information is provided other than what can be deduced. Examples would help.
7.4
Combining the segment group and segment descriptions
The following text is extracted from the Data Segment Clarification section of the COARRI message. It shows how the segment group description, combined with the descriptions of each segment contained within the group, gives an overall picture of the use of the segment group. Extract from the COARRI message Segment group 1: TDT-RFF-LOC-DTM A group of segments to indicate the main carriage means of transport.
25
TDT, Details of transport A segment identifying the voyage of the vessel relevant to the message (main transport). RFF, Reference A segment identifying a relevant reference number, such as: - shipping - syndicate - marketing organization - conference code LOC, Place/location identification A segment to identify a location related to the means of transport, such as: - place of departure/arrival (terminal within the port) DTM, Date/time/period A segment identifying a date/time related to the arrival or departure of the vessel, such as: - estimated date/time of arrival/departure
7.5
Dividing the message structure into sections
A message may be divided into sections. Normally, if a message is sectionalised it is divided into the Header, Detail and Summary sections. However, several messages (such as CUSDEC) contain more than three sections. Irrespective of the number of message sections used, each must be introduced. This is accomplished by a mandatory section heading and a mandatory statement preceding the first segment of each section. This is stated in the format:
[Section name] section Information to be provided in the [section name] section.
An example is shown below. Extract from Orders message 4.1.1 Header section Information to be provided in the Header section: 0010 | UNH, Message header A service segment starting and uniquely identifying a message. The message type code for the Purchase order message is ORDERS. Note: Purchase order messages conforming to this document must contain the following data in segment UNH, composite S009: Data element 0065 ORDERS
26
0052 D 0054 95A 0051 UN 0020 BGM, Beginning of message Refer to the Rules for Presentation of Standardised Message and Directories Documentation for precise information about the layout.
7.6
A word of caution
It is a good general indicator that if the description of a segment is merely copied from the segment directory to the boilerplate, then it will provide no added meaning about its context or usage within a particular message. However, it is very difficult (and almost definitely a waste of message design resources) to try to write a unique description for each segment type that is specified in every message. If this approach was adopted then it would lead to the opposite extreme where message designers and technical assessment groups are required to make up a description just for the sake of it, leading to a work of fiction rather than fact. It is necessary to reach a balanced approach to improve the documentation. This is largely provided by the proposal that mandates the provision of examples to show how a segment is to be used.
7.7
Summary
To summarise thus far: The Functional Definition section states who the message is for and why it was designed (the purpose). The Field of Application section states where the message is applicable for use. The Principles section states what design constraints were applied in the design of the message and when it should be sent (in terms of the pre-conditions that must be completed prior to message transmission). The Data Segment Clarification section states how the segments extracted from the segment directory can fulfil the Functional Definition in accordance with the criteria stipulated in the Principles section. 8 Conclusion
The main objective of Part II is to establish consistent criteria for deciding what information to state in the sections of the message boilerplate. From the study of message directories it has been possible to identify a set of guidelines for the preparation of each of the main sections and, through the use of examples, to illustrate good practice. It has also been possible to answer the six classic analytical questions with respect to boilerplates: the who, when, why, where, what and how. The answers to these questions have been determined from what is evident in messages already published in the UN/EDIFACT directories. The adoption of guidelines for preparing the contents of message boilerplates will have the following advantages: A reduction in message development time. An increase in the level of quality and consistency for message documentation. Better judgement criteria for Technical Assessment Groups. Improved source material for translation to other languages. Improved source material for the preparation of Message Implementation Guidelines.
27
It is hoped that these advantages will also lead to a reduction in the time it takes to approve messages for publication in UN/EDIFACT directories.
28
PART III - GUIDELINES FOR CODE NAMES & DEFINITIONS 1

1.1
Background
Assumptions
Part III of the Message and Code Handbook - Guidelines for Code Name and Definitions - has been developed according to the following assumptions: There are more codes submitted to the UN/EDIFACT process than any other type of Data Maintenance Request (DMR). The Joint Technical Assessment Group (JTAG) reviews more unresolved code values than any other type of unresolved DMR. There is less guidance regarding code allocation (naming and defining) than any other item that is submitted to the UN/EDIFACT directory set. The most quoted item from the Technical Assessment Checklist (TAC) by Regional TAGs is The code name does not match the code description. Increasingly, industry sectors are beginning to circumvent the UN/EDIFACT process and allocate codes locally, within Message Implementation Guidelines (MIGs), rather than undergo a 12 - 18 month approval cycle. 1.2 Problem Analysis
Without doubt the naming and defining of code values is an art, not a science. Therefore, there is a degree of subjectivity involved. This is acceptable, but only if there is a high level of consistency in the decision making. At a recent JTAG meeting 539 regionally unresolved Data Maintenance Requests (DMRs) were discussed, of which 78% were code values. So, clearly, there is a problem. Until recently, there has been almost a total lack of guidance on providing names and definitions for code values which inevitably means that the Regional TAGs are assuming most of the responsibility for codes rather than sharing the responsibility more equally with the code submittor. The lack of guidance also means that the quality of code names and definitions is not fully considered at the beginning of the process, but rather at the end. The objective of this part of the Message and Code Handbook is to address the reasons why there is such a high rejection rate, then to offer guidelines, based on existing international standards, that should reduce this figure significantly. 1.3 (i) (ii) (iii) (iv) (vi) References Code Data Maintenance Requests for D.96.A, D.96B and D.97A The D.96B UN/EDIFACT Directory Set ISO 11179-4, Rules and guidelines for the formulation of data definitions Conventions for data elements and codes (Trade/WP.4/R.765/Add.1) ISO 704 - Principles and methods of terminology
29
The Technical Assessment Checklist for Codes
For ease of reference the Technical Assessment Checklist (TAC) table that is used by Regional TAGs to assess a New Code or Code Change Request (table III.H) is shown below together with the General Check List (table I) that is applicable to all types of DMR. Both tables have been extracted from version 5.4 of the TAC and together they form the majority of guidance provided thus far to message designers on code allocation. Each of the check list items is explained below. The level of detail provided per check list item is roughly in proportion to the percentage of DMRs rejected for failing it. More attention has been given to check list items that frequently result in DMRs being repaired at JTAG.
30
Technical Assessment Checklist Table 6.9 - New Code or Code Change Request Ref. Check List Item Explanation
6.9 N1
Is the code value and the code value definition within the scope of the simple data element name and simple data element definition to which it belongs?
The name and description of a data element provides a degree of context, or domain information, for the code list that is associated with that data element. The name and description of the code value can also provide contextual information. All code values for a data element must therefore be in the same domain.
6.9 N2
6.9 N3
Is the code value definition unique within the code list for the simple data element to which it belongs? Is the code value definition stated in the singular?
This check list item is to ensure that the data element for which the code DMR has been submitted does not have other code values that can be used to perform the same function as the submitted DMR. This item aims to avoid inconsistency where the code value name is stated in the singular, with the code value definition in the plural, and vice-versa.
Percentage of code DMRs sent to T1 for noncompliance Medium - many DMRs that fall into this category are solved by the submitting entry points review. However it is the second highest reason for a code DMR being rejected. Very low emphasis of review is on submitting entry point. Low the submitting entry point solves DMRs that fall into this category.
Comments
The TAG of the submitting entry point reviews a code DMR, discusses different data elements for which the code may be suitable and decides upon a data element (either the original requested data element or a different one). The essence of the discussion (and any alternatives considered) is conveyed to T1 to assist them in their analysis. It is important that better descriptions and names are provided for data elements. The new Message Design Rules should assist in this area. The addition of synonyms to the description of a code value will assist in reducing this error. Often different regions, and industry sectors, have different names for the same entity. Therefore, if the code is identified with a synonym, the possibility of duplication is reduced.
31
6.9 N4
Is it true that the code value definition does not contain abbreviations?
This check list item is used to remove ambiguity in names and definitions. Even if an abbreviation is widely known within a particular sector, the code list will often be used by a wide range of sectors so it is important to be precise.
Percentage of code DMRs sent to T1 for noncompliance Low - emphasis of review is on submitting entry point.
Comments
The guiding principle is to expand the abbreviation or acronym on the first occurrence by providing the full text in parentheses after the acronym. If the acronym first occurs in the code value name, then occasionally this may mean that the name will be very long (i.e., over 70 characters). In this case the acronym or abbreviation should be expanded in the definition. If a code name or description contains several acronyms, it may be confusing to the reader to expand all of the acronyms on first occurrence. In this case all of the acronyms or abbreviations should be explained in a note to the code value which is published alongside the description.
6.9 N5
Is it true that the code value definition does not contain the phrase self explanatory, to be defined, to be provided, or synonyms thereof, unless the phrase is an intrinsic part of the code value definition?
Many terms, when used widely within an industry sector, are so ubiquitous that they require little or no explanation. When placed in code lists that are referred to by many user sectors, the terms are not as obvious, so definitions are the only way of understanding them.
Low - emphasis of review is on submitting entry point.
32
6.9 N6
Is the code value name consistent with the code value definition?
It the submitted code value has a name that is inconsistent with its definition then it is open to misinterpretation because of ambiguity. The code value will therefore not be used correctly which will inevitably lead to another DMR being submitted at a later stage. Poorly defined codes are likely to lead to a problem of duplication or overlapping of functionality with other codes.
6.9 N7
6.9 N8
Is it true that the value for a qualifier data element is only specified in the UN/EDIFACT code list directory? Is it indicated which message, segment, and data element the code is intended for?
If the value for a qualifier data element is not specified in the UN/EDIFACT code list the user is not able to give specific meaning to a composite data element or segment. Common understanding of meaning is ensured by the values inclusion in the UN/EDIFACT code list directory. Without this information it is difficult to assess the requirement for, or the suitability, of the code.
Percentage of code DMRs sent to T1 for noncompliance High This is the most quoted reason for objection to code DMRs. The TAG of the submitting entry point repairs many names and definitions, but inconsistency is not always noticed, so T1 rejects many DMRs on this basis. Low - emphasis of review is on submitting entry point.
Comments
More guidelines are required for message designers so that: Higher quality codes are submitted, and TAGs have better judgement criteria. More information about the changes made by the submitting entry point when a DMR is repaired would assist T1.
Very low emphasis of review is on submitting entry point.
33
6.9 N9
Is the requested code for inclusion in the UN/EDIFACT Directory or for one of the UN/ECE code recommendations referenced in the UN/EDIFACT Code directory
For maintenance reasons, only Class 1 and 2 codes are eligible for inclusion in the UN/EDIFACT Code List Directory. Class 1: Service data element code lists (0001/ 0999) Class 2: User data element code lists, maintained by EDIFACT There are two other classes of codes recognised, but not maintained, by EDIFACT: Class 3: User data element code lists included in international code lists, issued as ISO international standards & UNECE Recommendations, endorsed by WP.4; Class 4: Proprietary code lists (industry or sector code sets) maintained by parties other than EDIFACT, ISO or UN/ECE.
Low emphasis of review is on submitting entry point.
All qualifier data elements have Class 2 code lists. The majority of coded data elements NOT followed by 1131 and 3055 have Class 2 code lists. The majority of coded data elements followed by 1131 and 3055 have Class 4 code lists.
6.9 N10
6.9 N11
Is the 2 character alphabetic country code added to the front of the code value name for a national agency code entry in DE 3055 (Code list responsible agency)? Does the code entry have only one function?
The code values for data element 3055 provide the names of agencies, often in abbreviated form, and probably contain more acronyms than any other code list. Although all acronyms are expanded, the country in which the agency is based is not immediately obvious. In order to avoid confusion, therefore, the country code is stated alongside the agency name.
Very low emphasis of review is on submitting entry point.
There is a degree of subjectivity associated with this check list item, but it is a very useful check for avoiding ambiguity. In general, if TAGs notice the word and between two terms in a code name or definition that is not part of a proper name (or noun), then it is often an indication that the code is representing two functions rather than one. If this is proven to be the case, then TAGs recommend the creation of two code values, one for each function.
The guidelines for writing definitions and names should indicate when the use of and is likely to indicate multiple functionality. See section 3.1
34
6.9 N12
Does the code value definition state what the code value represents? Does the code value expand on acronyms in the first occurrence?
This is a check to ensure that the code name and definition are consistent in meaning and therefore avoids ambiguity.
6.9 N13
This check list item is used to remove ambiguity in names and definitions. Even if an abbreviation is widely known within a particular sector, the code list will often be used by a wide range of sectors so it is important to be precise.
Medium most DMRs in this category solved by submitting entry point. Low - emphasis of review is on submitting entry point.
6.9 N14
Is it true that if a new code is added to an existing data element, the data element name and definition complies with the rules stated in section 6.8 of the Technical Assessment Checklist? If not, has a DMR been raised to correct the data element?
The message design rules contain rules regarding the structured naming and defining of data elements for ensuring consistency of understanding. The Implementation Timetable & Strategy states that data element name and definition must comply with the new rules. If not, a DMR must be raised to correct the data element.
Zero see comments.
The guiding principle is to expand the abbreviation or acronym on the first occurrence by providing the full text in parentheses after the acronym. If the acronym first occurs in the code value name, then occasionally this may mean that the name will be very long (i.e., over 70 characters). In this case the acronym or abbreviation should be expanded in the definition. If a code name or description contains several acronyms, it may be confusing to the reader to expand all of the acronyms on first occurrence. In this case all of the acronyms or abbreviations should be explained in a note to the code value which is published alongside the description. At the Canberra EWG meeting in September 1999 a series of DMRs were raised to re-align the names and definitions according to the new rules.
35
6.9 N15
Is it true that if a change is made to an exiting code, the data element name and definition complies with the rules stated in section 6.8 of the Technical Assessment Checklist? If not, has a DMR been raised to correct the data element?
The message design rules contain rules regarding the structured naming and defining of data elements for ensuring consistency of understanding. The Implementation Timetable & Strategy states that data element name and definition must comply with the new rules. If not, a DMR must be raised to correct the data element.
Zero see comments.
At the Canberra EWG meeting in September 1999 a series of DMRs were raised to re-align the names and definitions according to the new rules.
36
Technical Assessment Checklist Table 6.1 - General Ref Check List Item Explanation
6.1 N1
Is the DMR form submitted in English?
English is the working language for UN/EDIFACT documentation.
6.1 N2
6.1 N3
6.1 N4
6.1 N5
Have all mandatory elements been provided in the request If additional documents are indicated as being provided, are they attached? Has the DMR received a log number assigned by the submitting entry point secretariat? Are all related DMRs submitted?
This is a consistency check to ensure that the submission of all DMRs includes the mandatory fields as specified in Annex A of the DMR processing procedures. Does not often apply to code submissions.
Percentage of code DMRs sent to JTAG for noncompliance Very low - Occasionally a well-known term within a particular industry is accepted by the submitting entry point, but is not known in other regions. Very Low
Comments
It is hoped that, by providing better guidelines for code value names and definitions, it is possible to improve the quality of the documentation. This will in turn assist in the translation of the directories to other languages.
Zero
This is a procedural check to ensure that all DMRs are registered with the secretariat.
Zero emphasis of review is on submitting entry point.
6.1 N6
Is TAG satisfied that the DMR meets the stated business requirements?
When TAG assesses a DMR for a new coded data element it is necessary to assess the code values that are submitted for the data element in order to understand how the data element is to be used. This is a matter of judgement but if the business need conflicts with the code request then the code value may not perform the function for which it is intended.
Low - emphasis of review is on submitting entry point.
37
Naming and Defining Codes
One of the major problems found in code value assessment is that the name contains conceptual information which is not evident from the definition, or vice versa. By following the guidelines within this section for formulating the code value definitions and then applying the same guidelines for the code value name, it is possible to eliminate many inconsistencies. In order to assist with the consistency check between code value names and definitions, a table of checklist questions is also provided. It is understood that there are code value names and definitions which come from industry sectors that cannot subject to alteration for legal reasons, such as a selection of Customs codes. From a pragmatic viewpoint, this is an exception that the UN/EDIFACT process has to live with if it is to reflect user community requirements. However, in the vast majority of code value submissions this is not the case. 3.1 Code value definitions
Code value definitions should: state the essential meaning of the concept; be unique within the code list in which it appears; be concise; be stated in the singular; state what the concept is, not only what it is not; be stated as a descriptive phrase or sentence(s); use internationally agreed terms and definitions where possible; not simply restate the code value name in a different word order, nor state only a synonym of the code value name; not include examples; only provide context limitations, or restrictions of use, when absolutely necessary; only refer to a party when absolutely necessary; only refer to an industry sector, administrative sector or business function when absolutely necessary; limit the use of and to a restricted set of conditions (described below), otherwise it may be an indication of multiple functionality; use / in a proper term only; limit the use of or to a restricted set of conditions (described below), otherwise it may be an indication of multiple functionality; where possible, expand acronyms on first occurrence.
Each of these principles for code value definitions is described in more detail below through the use of examples. I. State the essential meaning of the concept All primary characteristics of the concept represented should appear in the definition at the relevant levels of specificity for the context. The inclusion of non-essential characteristics should be avoided. The level of detail necessary is dependent upon the needs of the system user and environment. (ISO 11179-4) If a multiple-word term is being defined it is not necessary to define every word contained in the term. Instead, the multiple-word term should be treated as a single piece of information and it should be defined as such.
38
Example: Good definition: Poor definition:
Reason:
Recommended maintenance quantity Recommended quantity of an article which is required to meet an agreed level of maintenance. To indicate the recommended quantity of an article which is required to support an agreed level of organisational and intermediate maintenance to a usage pattern and period. Definition contains information that is more specific than the name implies. The reference in the definition to organisational and intermediate maintenance leads to the questions: what is organisational and intermediate maintenance and can the code value be used for any other type of maintenance? The definition also includes mention of a usage pattern or period which also potentially limits the use of the code value.
II. be unique within the code list in which it appears Two code values with the same name or with the same definition will lead to confusion upon implementation. III. be concise The definition should be brief and comprehensive. Extraneous qualifying phrases such as for the purposes of this data dictionary, shall be avoided. (ISO 11179-4). Example: Good definition: Poor definition: Drum deposit Deposit paid on a returnable drum The charge relating to the packaging of a product in a container drum when the drum is expected to be returned and has value when empty.
IV.be stated in the singular (An exception to this guideline is made if the concept itself is plural.) Example: Good definition: Poor definition: Agency approved price Provides an indication to the receiving party that the price has been approved by an agreed agency. Provides an indication to the receiving party that the prices have been approved by an agreed agency.
V. state what the concept is, not only what it is not (An exception to this guideline is made if the concept itself is negative.) Example: Good definition: Poor definition: Example: Good definition: Reason: Tooling charge Item or service relates to a tooling charge, not to the direct provision of goods. Charge does not relate to the direct provision of goods. Not found The goods notified to be missing have not been found. The concept of not found is itself negative.
39
VI. be stated as a descriptive phrase or sentence(s) A phrase is necessary to form a precise definition that can be readily understood. Example Good definition: Poor definition: Reason: Agent name Name of party authorised to act on behalf of another party. Representative name. The good definition provides clear understanding which will aid implementation.
(The above example has been extracted from ISO 11179-4.) VII. use internationally agreed terms and definitions where possible. Some code value definitions and names contain terms that have been extracted from internationally agreed code lists or may have some legally binding significance. If this is the case then these terms should always be used in preference to redefining the term in question. However, since UN/EDIFACT is a multi-sectoral standard some terms, if removed from their original context and placed in the wider UN/EDIFACT context, may be confused with other terms in the same code list. In this latter case it may be necessary to modify the original definition accordingly. VIII. not simply restate the code value name in a different word order, nor state only a synonym of the code value name. Simply restating the words of the name in a different order or stating only a synonym of a code value name as the definition is not acceptable. As stated above, the definition should be stated as a descriptive phrase or sentence. Note that if synonyms of the code name are required then they may be added after the full definition in the format: Synonym: alternative code value name. Example: Cargo operating temperature Good definition: The temperature at which the cargo is to be kept while it is under transport. Poor definition: Operating temperature of cargo. Example: Good definition: Export licence Permit issued by a government authority permitting exportation of a specified commodity subject to specified conditions as quantity, country of destination, etc. Synonym: Embargo permit. A full definition provides meaning to the code name. If the definition for the code value name Export licence had been only Embargo permit without the supporting text then confusion would arise.
Reason:
IX. not include examples Examples within code value definitions often limit the scope of how a code value can be used and may lead to misunderstanding. X. only provide context limitations, or restrictions of use, when absolutely necessary
40
(Context is defined in the Oxford English Dictionary as: parts that precede or follow a passage or word and fix its meaning. If context information is very detailed it can impose unnecessary limitations.) It is often possible to increase the potential usage of a code by removing inessential or extrinsic characteristics from the code value definition, yet still retain the original business requirement. It is perfectly valid to refer to a context if it is necessary for the understanding of the definition (i.e. it is an essential part of the definition), or if it is necessary to distinguish from another code value. In the latter case it is necessary to state the context in both the code value name and definition. Example: Good definition: Poor definition: Reason: Requested cancellation date, latest The latest date on which cancellation may be requested by a party. The latest date on which cancellation of a payment order may be requested by a party. The poor definition suggests a limitation of context to cancellation of a payment order which is not implied in the code value name. By removing the reference to the payment order the definition better reflects the name. Note that if, in the unlikely circumstances, it was necessary to differentiate between the cancellation of a payment order and the cancellation of other types of document, then the code value name should be amended to include reference to the payment order and the poor definition would be acceptable.
XI. only refer to a party when absolutely necessary One of the checks performed by TAG is to ensure that when a party is referred to within a code value, it is truly limited in scope to that party. If it is possible for the code value to be used by many parties, then reference to one particular party is an unnecessary limitation. It is perfectly valid to refer to a party if it is necessary for the understanding of the definition (i.e. it is an essential part of the definition), or if it is necessary to distinguish from another code value. For example, a data element called Reference type, coded may contain a code value for a reference generated by a seller and a code value for a reference generated by a buyer. In this example, the party type should be stated in the code value names and definitions. Example: Good definition: Poor definition: Reason: Inventory status advice Advice of stock on hand Advice of stock on hand provided by warehouse. Parties other than the warehouse may provide the inventory status advice. If the code value name was Inventory status advice from warehouse, and this was a concept that had to be distinguished from a more general concept then the latter definition would be correct.
XII. only refer to an industry sector, administrative sector or business function when absolutely necessary If it is possible for the code value to be used within many sectors, then reference to one particular sector would be an unnecessary limitation. It is perfectly valid to refer to a sector if it is necessary for the understanding of the definition, or if it is necessary to distinguish from another code value. For example, in a data element called Tax type, coded it may be necessary to have a code for taxes applicable in the Customs sector and another code to indicate taxes applicable in the Transportation sector. In this example, the sector should be stated in the code value names and in the definitions.
41
XIII. limit the use of and to the following conditions otherwise it may be an indication of multiple functionality: a) in a proper term (name or noun). b) between words or terms that are to be taken jointly (i.e. as a conjunction) when the terms are not synonyms of each other, each term relates directly to the other, and no obvious generic noun can be substituted in place of the terms. A good test if two terms are stated in a definition is to try to remove one of the terms. If the remaining term completely satisfies the requirements, then one of the terms is not required. If, on the other hand, the remaining term is rendered incomplete, ineffective or meaningless then it is necessary to have each. For example, many instructions are comprised of two parts and the removal of one part will not allow the instruction to be completed. Acceptable example: Reason: Combined certificate of value and origin The combined certificate of value and origin is one concept; it is indivisible. Purchase order and invoice reference The purchase order reference is conceptually different to the invoice reference; two code values should be defined rather than one. Replace item detail and summary only There is no generic term that can be used in place of detail and summary. If one of the terms is removed the remaining term does not satisfy the requirements. Call-off delivery Document or message to provide split quantities and delivery dates referring to a previous delivery instruction. Both split quantities and delivery dates must be present in order to satisfy the requirements.
Unacceptable example: Reason:
Acceptable example: Reason:
Acceptable example: Good definition: Reason:
XIV. use / in a proper term only The use of / in anything other than a proper term (name or noun) is often an indication that the code value is multi-functional, hence two code values should be submitted rather than one. XV. limit the use of or to the following conditions, otherwise it may be an indication of multiple functionality: a) in a proper term (name or noun) b) between alternatives, where each alternative relates directly to the other, the alternatives form a complete set of available options, and there is no obvious generic noun that can be substituted in their place. (Note replacing specific terms with the very generically bland term details is not recommended as a good practice.) It is not acceptable to use or between synonyms since if each term means the same thing then one is redundant - if each term is slightly different, then two codes are preferred to one.
42
Example 1: Acceptable definition:
Reason:
Documentary credit notification Document or message issued by an advising bank in order to transmit a documentary credit to a beneficiary, or to another advising bank. The phrase Document or message indicates two equally valid alternatives which are conceptually alike, not synonymous, and there is no obvious generic noun that can be used in their place. Likewise, the phrase to a beneficiary, or to another advising bank is acceptable for the same reasons. Purchase amount The cost of buying goods or services There is no obvious generic noun that can be used in place of goods or services. Payment plan reference A number which uniquely identifies a progress payment or a payment plan such as a milestone payment plan or any other plan related payment. A number which uniquely identifies a payment plan. Payment plan and progress payment are synonyms (if not then two codes should be created).
Example 2: Acceptable definition: Reason:
Example 3: Poor definition:
Good definition: Reason:
XVI. where possible, expand acronyms on first occurrence. The preferred method is to expand the acronym on first occurrence. Therefore, if the acronym first appears within the code value name, then it should be expanded immediately after the acronym, in parentheses. However, if this leads to the code value name being greater than 70 characters, then the acronym should be expanded in the definition. If a code value name or definition contains several acronyms then it is considered to be better practice to add a note to the code value so that each acronym can be expanded therein. 3.2 Code value names
In checking that the code value name is consistent with the definition, use the following guidelines: (a) If the definition must refer to a given party (e.g. buyer identification number) in order to distinguish between a similar type of code value for a different party (e.g. seller identification number), then it is also necessary to mention the party in the code value name. If the definition limits usage of a code to a given user sector (e.g. customs fee) in order to distinguish between a similar type of code value for a different sector (e.g. transportation fee), then it is also necessary to mention the sector in the code value name. If the code value definition is stated in the singular, then the code value name should be in the singular.
(b)
(c)
43
(d)
(e)
If the code value definition is stated with a limitation in context that acts as a means to differentiate from another code value (for example, within a container, on a piece of equipment) then it is necessary to repeat the context in the code value name. Code value names should, where possible, contain the most significant words first. Good example: Order quantity. Bad example: Date of estimate.
3.3 3.3.1
Recommendations for Code Naming Conventions Background
The UN/EDIFACT Working Groups T1 Technical Assessment Sub Working Group (T1) has observed that, during its efforts to process Data Maintenance Requests (DMRs) that create new code values, and when utilising the current directory to check for similar or existing codes, there tend to be blocks of codes concerned with the same subject which share common sets of words. These codes are often spread throughout the code list for a given element because the non-common words appear at the beginning of the code name. This means that an alphabetic sort fails to group the codes together, thus making a search for a particular name more difficult and more susceptible to error. See table 1 for examples. Table 1. Current Naming Practice Examples
Data Element Code Value Code Name
3035 3035 3035 2005 2005 2005
FT OC VW 356 382 686
Party responsible for financial settlement Party data responsible party Responsible party Sales date, and or time, and or period Earliest sale date Last sale date and/or time and/or period
T1 have also noted that a small number of select action or suffix words seem to be much more common than other words. These words fall into natural pairs or triples representing either complementary or opposite meanings. The work done by the MADRAS project to bring the data element names in the directories into conformance with the latest version of the Message Design Rules has demonstrated the benefits of a consistent naming strategy. 3.3.2 Proposal
T1 proposes the following steps to take advantage of the word distribution patterns in code names: 1. Common keywords should be grouped at the beginning of the code name in order of decreasing significance. 2. Where common phrases exist between a group of code names, these should be placed at the beginning of the code name.
44
3. Where one of the items contained in table 23 forms a part of the code name, it should be placed at the end of the name, separated by a comma. This would make a code name look like: <common_description>, <suffix_word> 4. Unless a good business case exists (such as special terms in use in a particular sector), T1 will normally expect code names including the words in table 2 to be formed in this way and will adjust those that are not in compliance with these recommendations. 5. Where a set of code names are clearly grouped in this way, but the action or suffix words are not in the table 2 list, developers are encouraged to take the initiative where appropriate (T1 recognises that not all such instances may be appropriate) and adopt the naming convention described above. 6. T1 does not propose any retroactive measures to bring all existing code names into line with these recommendations, but developers are encouraged to make conformance an issue when touching a code in any way, or adding related codes to an existing set. 7. These rules are not strictly enforceable, but are put forward as best practice recommendations. Table 2. Common Code Suffix Words estimated stop end maximum planned latest revised final
Actual Start Begin Minimum Scheduled Earliest Original Preliminary
estimated
3.3.3
Reasons for Change
T1 offers the following as supporting rationale for these recommendations: 1. It will be easier for users and message developers to locate connected codes in the directory by searching for a common phrase or text beginning the name when they are located together and sorted alphabetically. 2. It will be easier for T1 to check for existing codes and make recommendations to developers concerning new code names for both related and non-related codes. 3. It will be easier for developers and T1 to detect duplicate codes. 4. An increase in uniformity in code names will help to reduce ambiguity and duplication, and increase the usefulness and accuracy of the directories. 3.3.4 Examples
A set of examples relating how the proposed naming convention would be applied is provided in table 3:
3 This list is not considered to be closed, and T1 may add words or word pairs to the list, as they become obvious. There is no intention to include all such types of words in the list.
45
Table 3. Proposed Naming Convention Examples Project cost, actual Arrival time, earliest Building occupancy period, revised Shipping priority, requested Gantry height, maximum Project cost, estimated Arrival time, latest Building occupancy period, original Shipping priority, planned Gantry height, minimum
Shipping priority, actual
46
PART IV REDESIGNING SEGMENTS 4.1 Background

The purpose of this section is to alert and inform the user community and the Development Groups on how existing multi-functionality segments may be redesigned to comply with Message Design Rules. Such redesign will be required when the structure of a segment is amended by a Data Maintenance Request (DMR).
4.2 Reason for Redesigning Segments

The UN/EDIFACT Message Design Rules for EDI (Release 2.2, 1998-09-08) indicate that segments should have single functionality. Paragraph 4.5.1, Rule 39 states: The data element(s) within a segment shall relate directly to the purpose of the segment. Further, the New Message Design Rules Implementation Timetable and Strategy (Version 1.0, December, 1997) in paragraph 2.2 states in part: A DMR requesting an addition of an existing or new data element (stand-alone or composite) to an existing segment shall be subject to the new rules. If it is not compliant with the new rules then it shall be rejected. Where the target segment is not compliant with the new rules, it is strongly recommended that consideration be given to aligning it to the new rules. This may also mean that the existing segment is marked for deletion and one or more new segments are designed in accordance with the new rules to replace the existing segment. Since there are segments within the UN/EDIFACT Directory which do not comply with the single functionality rule, and structure changes to these segments are anticipated, there needs to be a methodology for redesign when this occurs.
4.3 Methodology
Segments that currently have multiple functionality and are the target of a proposed structure change will have their contents mapped into new or existing segments. The resulting segments will be placed in the same Segment group. If the multi-functional segment were a stand-alone segment in a message, then a new segment group would be created to replace the multi-functional segment. If the multifunctional segment were a trigger segment, then it would be replaced with the new segments. Since Version 4 of the syntax allows empty segments, the order in which the new segments occur should not be a concern. The following example is offered to illustrate the methodology. The TDT Segment may not comply with the new design rules in that it has multiple functionality. The functionality has been mapped into three new segments (TD1, TD2 and TD3) and one existing segment (PNA). (It should be noted that this example is for illustration purposes only, and does not intend to provide a correct and final solution for the TDT segment, nor its application in any one message.)
47
4.4 Segment Redesign

ORIGINAL SEGMENT TDT SEGMENT 8051 Transport stage code qualifier 8028 Conveyance reference number C220 Mode of transport C228 Transport means C040 Carrier 8101 Transit direction indicator code C401 Excess transportation information C222 Transport identification 8281 Transport ownership, coded Redesigned Segment Contents TD1 SEGMENT 8051 8028 C220 C228 8101 TD2 SEGMENT NEW1 Segment qualifier 1 C401 TD3 SEGMENT NEW2 Segment qualifier 2 C222 8281 NEW SEGMENT REDESIGN TD1 PNA TD2 TD3 X X X X X X X X X
Application to a Message ORDERS Message Before

SG 10 ---------------TDT SG 11 ---------------LOC DTM C10 M1 C10 M1 C5 --------------------------
ORDERS Message After

SG 10 ------------------ C10 TD1 M1 PNA C1 TD2 C1 TD3 C1 SG 11 ------------------ C10 LOC M1 DTM C5 ------------
---------
The above methodology represents a mechanical approach. Each Development Group should take the opportunity to determine the best way to meet the business need when the new segments are applied to messages. T1 will be happy to provide further clarification if necessary.
48
ANNEX A UN/EDIFACT Syntax Implementation Guidelines (1988)

NOTE: This section of MACH was formerly section 4.2.3 of the UNTDID
1 INTRODUCTION
The purpose of these guidelines is to assist Electronic Data Interchange (EDI) users with their implementation of the ISO-UN/EDIFACT (EDI for Administration, Commerce and Transport) Syntax Rules, and to expand some of the rules contained in ISO 9735, supported by examples. The guidelines are a part of a set of complementary documents available to users. documents in the series which users should be aware of are: The other
UNTDED: The United Nations Trade Data Elements Directory (also published as the International Standard ISO 7372) and associated code sets ISO 9735: The EDIFACT Syntax Rules standard The UN/EDIFACT Message Design Guidelines The UN/EDIFACT Directory Set, containing directories for: UNEDMD - Internationally agreed UN/EDIFACT Standard Messages (UNSMs); UNEDSD - UN/EDIFACT Standard Segments for UNSMs; UNEDCD - UN/EDIFACT Composite data elements for UNSMs; UNEDED - UN/EDIFACT Data Elements for UNSMs; UNEDCL - UN/EDIFACT Code List for UNSMs.
UNTDED is published separately by the UN, and maintained jointly with ISO. The remaining documents are compiled in the UN Trade Data Interchange Directory. In 1987, following the convergence of the UN and US/ANSI syntax proposals, the UN/EDIFACT Syntax Rules were approved as an ISO standard, having been developed within and submitted for approval by the United Nations Economic Commission for Europe's Working Party on the Facilitation of International Trade Procedures (UN/ECE WP.4). At the same time, WP.4 appointed three Rapporteurs to co-ordinate the continuing work in conjunction with the UN/ECE Secretariat. The Rapporteurs appointed were from Poland (coordinating the views and input from CMEA countries), from the United Kingdom (co-ordinating on behalf of the EEC and EFTA countries), and the United States (on behalf of the US and Canada). Additional Rapporteurs may be appointed in the future. In particular, the UNECE Secretariat and the Rapporteurs, supported by Advisory and Support Teams, will be the focal point for maintenance of the UN/EDIFACT Syntax Rules and for proposals for new UNSMs (or for amendments to existing UNSMs). The agreed maintenance procedures can be found in the Message Design Guidelines document, as can the contact points for the Rapporteurs.
49
Under NO circumstances should users, software providers, or network providers make any changes to the UN/EDIFACT Syntax Rules as defined in ISO 9735. Change requests should be registered either direct to the UN/ECE Secretariat, or via one of the Rapporteurs, (or by use of ISO procedures) for international discussion and approval, both at the UN and in the ISO. From the outset of the development of the UN/EDIFACT techniques, certain important design criteria were adhered to. These were that the techniques should be independent of the computers to be used, the systems using them, the applications using them, the communications methods to be used, and the data to be interchanged. The fact that there are a range of live and pilot applications, using a broad spectrum of mainframe, mini and micro computers, utilising a range of different computer communications protocols, (such as 2780, 3780, SNA/DNA, packet switching etc.), different systems solutions (including one-to-one direct interchange and mailbox switching), demonstrates that the criteria have been met. In addition to the above, UN/EDIFACT is designed to have the minimum impact upon the in-house systems using the technique. Many live applications constructing data for transmission of UN/EDIFACT messages, use a technique of creating a simple serial file - often structured to hold records containing data equivalent to that required for segments of data in the messages. This file is then submitted to a formatting routine, which constructs the data according to the UN/EDIFACT syntax. Experience has shown that for both converting from the in-house file layout into UN/EDIFACT Syntax for transmission, and for converting back into the required in-house layout on receipt of an EDIFACT structured transmission, parameter (or table) driven routines have proven to be very effective. When receiving a transmission for translation, by using such routines, it is possible for the recipient to ignore any data which is of no interest to him for his own in-house needs. It is stressed that UN/EDIFACT is a user application protocol for use within user systems, which is compatible with the OSI model, in that it presents user data for transmission via the services described by the model. A common technique is for users to have their own in-house written routines (or a software package), for formatting and de-formatting UN/EDIFACT structured transmission files. All of this is user data, which is then submitted to a proprietary communications protocol (such as 2780, 3780, X25 etc) as defined in the User Interchange Agreement.
50
Interchange +--------------------------------------+ | Agreement | | | | | +-----------------------+ +-----------------------+ | USER 'A' SYSTEM | | USER 'B' SYSTEM | |.......................| |.......................| | EDIFACT formatting and| | EDIFACT formatting and| | de-formatting routine | | de-formatting routine | |.......................| |.......................| +|-----------------------|+ +|-----------------------|+ || Communications || || Communications || || protocol || || protocol || |+-----------------------+| |+-----------------------+| | APPLICATION LAYER | | APPLICATION LAYER | +-------------------------+ +-------------------------+ | PRESENTATION LAYER | | PRESENTATION LAYER | +-------------------------+ +-------------------------+ | SESSION LAYER | | SESSION LAYER | +-------------------------+ +-------------------------+ | TRANSPORT LAYER | | TRANSPORT LAYER | +-------------------------+ +-------------------------+ | NETWORK LAYER | | NETWORK LAYER | +-------------------------+ +-------------------------+ | DATA LINK LAYER | | DATA LINK LAYER | +-------------------------+ +-------------------------+ | PHYSICAL LAYER | | PHYSICAL LAYER | | | | | +-------------------------+ +-------------------------+ | | | | +--------------------------------------+
2 BASIC REQUIREMENTS FOR EDI APPLICATIONS 2.1 Standards

Without strict adherence to the published UN/EDIFACT standards, many of the achievable benefits will be lost. The UN/EDIFACT Syntax Rules (ISO 9735), set the standards for structuring data into segments, segments into messages, and messages into an interchange. Data, segment and message standards are equally essential requirements. The United Nations Trade Data Elements Directory (UNTDED) sets out the standards for administration, commerce and transport data. Where appropriate it also commends codes for coded representation of data (often internationally maintained codes), and for qualifiers. Since UNTDED is also an ISO standard (ISO 7372), they are maintained jointly by the UN and ISO. Because of the repetitive nature of information required in each of the sectors for which UN/EDIFACT has been designed, it is possible to assemble logically related data elements into standard segments, which can then be used in several different messages meeting the requirements of related business functions. An example of this can be found by examining United Nations Standard Messages (UNSMs), such as the Commercial Invoice, the Purchase Order and the Despatch Advice. Such standard segments are published in the UNSM Standard Segments Directory, with other segments specific to certain messages.
51
Finally, UNSMs are published in the UN/EDIFACT Message Directory. The procedures for the maintenance of the UN/EDIFACT Syntax and the directories (including how users can propose changes/additions to existing segments/messages, and proposals for new UNSMs) are contained in the Message Design Guidelines. As far as possible, (providing the required function has been covered) users should try to use existing UNSMs. At first sight, users may find that some UNSMs appear unnecessarily complex. Upon closer examination however, it will be found that many (and in some cases, most) of the segments and groups of segments are defined as being "Conditional". This is because the messages have been designed for International and National use, by multi-industry sectors. Since conditional segments may be completely omitted from a message, a user's requirements can often be met by use of a relatively smaller percentage of the segments specified in a UNSM. Should this prove not to be the case, then the Message Design Guidelines must be studied.
2.2 Interface with the In-house System

Once having settled on the message standard to be used, users must then carry out a careful analysis of their in-house system with respect to the data requirements for the message in question. This will entail ensuring that all of the data which must be provided for the application in which the message is being used, (which could include data defined as conditional, as well as mandatory data), can be supplied from the in-house system. If not, some way must be found for doing so. (In some cases, certain elements of data can be held on a "parameter" file see Section 2.3). For receipt of EDI messages, clearly users must decide how the data is to be processed. (For example, can a Purchase Order message be taken directly into an existing in-house order processing system, or should some intermediate processing and perhaps re-ordering of data be carried out first?). For both transmission and receipt of EDI messages, attention should also be paid to any codes specified for use in the messages. These may not equate exactly with those used in the in-house systems, and some form of code conversion may be required. This can be particularly important if data not previously integrated between in-house applications are to be linked.
2.3 Software
Software of one kind or another is needed to format data from in-house systems into the message and syntax structure, and to reverse the process into a form required by in-house systems. This can either be developed in-house, or proprietary software packages can be obtained. In-house development can be a quick way of getting an application off the ground for one or two messages, but generally will not be cost effective as more EDI message are introduced into the application - mainly because the coutines are usually coded to be message dependent. This can cause maintenance difficulties as messages are amended and enhanced over a period of time. Software packages are available from a variety of sources, ranging from data capture systems to interface translators. Most are message independent, generally by use of table-driven techniques. If message content changes, this means that only the tables have to be amended, not the main modules of the package.
52
As previously identified, on some occasions users may find that the required data are not always available from the in-house system. For formatting of data for transmission, this can be true, particularly for some of data required for certain of the syntax service segments (e.g. the Interchange Header - UNB; and the Functional Group Header - UNG). It could also be true if for example, the full name and address of the organisation originating the data is required in the interchange in order to meet some form of legal requirement. A useful technique for solving these problems is to hold such constant data on a small parameter file, which can be accessed when required during the message formatting process.
2.4 Communications
Some form of communications carrier is the last essential basic element for implementation of EDI applications. Some applications still exchange magnetic tapes, but increasingly, telecommunications techniques are being used. Two options are available either direct communications, or via a third party service. Direct point-to-point or dial-up techniques may suffice if interchange partners are few in number, and their telecommunications protocols are identical. However, as the number of interchange partners increases, as the number of different telecommunications protocols have to be catered for, and as scheduling problems become more acute, it may well be found that the services offered by a range of network providers become a possible alternative. Although the services offered may vary in detail, most offer network communication, the interface to the network, protocol conversion services (i.e. data is provided using a preferred telecommunications protocol and it is a function of the network provider's service to convert to the protocols to those of the interchange partners), and mailbox/clearing-house services. Users of mailbox/clearing-house services send data to the network provider, who interrogates the header segment of each interchange in order to deposit the data in the mailbox of the appropriate addressee specified in the interchange header segment. Each recipient can then access his own mailbox to retrieve data. This can be a particularly useful facility if scheduling problems are acute, or if data is being exchanged across time zones. When joining an existing user group, it may be found that the choice of communications techniques has already been made by the group as a whole.
3 INTERCHANGE AGREEMENT 3.1 Introduction

Virtually every live data interchange application operates under an interchange agreement, which normally takes the form of a user manual. Once created, this has to be maintained in the same way that any computer system user manual has to be.
53
The type of controlling agency authority created varies from application to application. For example, in Customs interchange applications, it is the Customs authority itself which normally controls and maintains the necessary user documentation. Other examples include trade associations, trade facilitation organisations, and a secretariat created and funded by the trade itself.
3.2 Initial Development and Design

While it is impossible to specify precisely the technique which should be used for the initial development and design of interchange systems, some guidelines can be given, based upon an analysis of the techniques used for existing systems. A typical technique used is to create a steering committee chosen from a selection of users from the application area. A series of working sub-groups, each charged with a specific task, report to the steering committee as they progress their work. In turn, these sub-groups are formed from users, having the necessary expertise for the task in hand. The following list of tasks are typical of those which have been carried out by existing user groups. More detailed subjects might need to be included, depending upon the application area, and two or more of the tasks might be undertaken by one sub-group. A typical list of tasks for a specific application could be: to identify the functions - and therefore the types of messages (or transactions) to be interchanged, with reference to the agreed application data element directory and with particular emphasis on the mandatory or conditional status of each data element within each transaction. Since users in different application areas may wish, in the future, to interchange data, wherever possible standardisation of message types and structure within each application area will be to everyone's advantage. to identify the data elements required, element sizes and formats, element terminology, and to compile a user data element directory. (This would normally be done with reference to the UN Trade Data Element Directory insofar as international data elements are concerned). For national, or industry specific data elements, local agreement would be necessary. to identify the functions of user data segments required, making full use of the UNSM Standard Segments Directory, particularly with respect to standard user data segments designed for multi-industry/multi-application use. Should new user data segments need to be designed, the recommendations contained in the UN EDIFACT Message Design Guidelines should be followed, with "Change Requests" being submitted to the local Rapporteur's Advisory & Support Team as necessary. to specify the level of syntax rules to be used by the application, (i.e. Level A or B - see ISO 9735). to specify the method(s) to be used for the physical transmission of data within the application, including where relevant, the specification of requirements for magnetic tape transfer, for floppy disks transfer, and for telecommunications protocols. to identify any legal and security problems related to the transfer of information, which might require resolution. (It should be noted that the UN/ICC UNCID recommendations - "Uniform
54
Rules of Conduct for the Interchange of Trade Data" - address all legal questions which need to be considered. UNCID is included in the UN Trade Data Interchange Directory). to identify and recommend common coding techniques to be implemented by all participants in the user group. to identify and recommend encryption techniques (if required). to recommend the form and period of a trial phase of testing, prior to full implementation.
3.3 User Manual

Taking account of the above subjects, it is recommended that the user manual should at least include: a description of the level of EDIFACT syntax to be used; a description of the agreed character set to be used; a full and detailed description of the structure of message types to be used. (As far as possible, it is stressed that UNSMs should be used - or if not exactly suitable that the procedures for amendment set out in the Message Design Guidelines should be followed); the user data element directory (utilising UNTDED as far as possible); the user segment directory (utilising the standard segments defined in EDSD as far as possible); the user message directory; a specification of legal/security requirements to be observed; a description of the communications service(s) to be utilised; a specification of the transmission record length to be used (which must be standard within the application area); a indication of the techniques to be used for error correction, acknowledgements, etc.; an indication whether or not Functional Grouping is to be used; an indication of the type of encryption to be used (if any); an indication of the type of password facility to be used (if any).
3.4 Check List for the Interchange Agreement

An Interchange Agreement (normally in the form of a User Manual) governs all of the participants subscribing to the application interchange which it describes.
55
Separate bi-lateral agreements between participants in such an interchange application are not recommended, since they only serve to defeat the purpose of the standards specified for all users in the Interchange Agreement. For certain data fields in the Service segments which form the syntax, the Interchange Agreement must specify the code sets, lists of qualifiers, etc to be used. The fields and the criteria to be addressed are listed below, with the service data element reference number and the segment in which it appears, in brackets after the field name. INTERCHANGE SENDER (S002 UNB) The Interchange Agreement (IA) must specify whether a name or code should be used to identify the organisations sending data. If a code, the various code sets must be identifiable by use of qualifiers, which must be specified. INTERCHANGE RECIPIENT (S003 UNB) The IA must specify whether a name or code should be used to identify recipients. If a code, the various code sets must be identifiable by use of qualifiers, which must be specified. RECIPIENT'S REFERENCE/PASSWORD (S005 UNB) The IA must state if the field is to be used. If so, either a list of passwords must be maintained, or (more likely), senders must ascertain from their various partners what reference or password is to be provided. APPLICATION REFERENCE (0026 UNB) The IA must state whether the field is to be used, if so, it must state what information should be carried in the field. PROCESSING PRIORITY CODE (0029 UNB) The IA must state whether the field is to be used, if so, a list of codes and meanings must be provided. COMMUNICATIONS AGREEMENT IDENTIFICATION (0032 UNB) The IA must state whether the field is to be used, if so, whether a name or code should appear. If a code, its value must be provided. APPLICATION SENDER'S IDENTIFICATION (S007 UNG) IDENTIFICATION (S006 UNG) & RECIPIENT'S
The IA must either inform users either that it is their own responsibility to maintain code lists (plus qualifiers if necessary) for their partners, or it should publish and maintain agreed lists for all participants. CONTROLLING AGENCY (0051 UNG) The IA must provide the list of codes which could be used (although within one interchange application, it is most likely that only one code would be used. For example, if UNSMs are being used, the code would have the value UN).
56
MESSAGE VERSION NUMBER (0008 UNG) If UNSMs are being used, the current version number (and if necessary, the release number) of the message in question should be specified. If the application is using other than UNSMs, then the IA must publish the version numbers (and release numbers if necessary) - see Section 7 Identification and Control of messages. MESSAGE IDENTIFIER (S009 UNH) The message identifier field has 5 component data elements. The value of each of these must be specified as necessary per message type in the IA, according to the procedures set out in Section 7, dealing with the identification and control of messages.
3.5 Interchange maintenance authority

It is strongly recommended that some form of interchange maintenance authority be created. Such an authority would be responsible for the control and maintenance of the interchange agreement, with particular responsibility for the production and circulation of amendments to the user manual, and for control of change-over to new versions of messages.
4 TERMINOLOGY
For the definitions of the terminology used in this document, please see Annex A of the ISO 9735 standard.
5 CHARACTER SET FOR INTERCHANGE

In order to cover the range of user preference, two levels of syntax are identified with respect to use of character sets. These levels are defined in the Interchange Header (UNB) segment (in the data element S001 Syntax Identifiers) as UNOA (for the basic level A), and UNOB for level B. The full character set for both levels is specified in ISO 9735 EDIFACT Syntax Rules. Level B only, may use a higher level character set taken from ISO 646 IRV, including the use of three of the IS 1-4 non-printable separator characters in place of the printable separator characters used in Level A, as defined in ISO 9735. However, it should be clearly understood that users of Level B must revert to Level A if this is necessary to meet the capability and wishes of the recipient. Care should also be taken regarding the use of the IS 1-4 separator characters with respect to certain communications protocols. (For example, if the 2780 protocol is used, certain of the IS characters are not passed through to the application level process. In this case, use of the Level A set will overcome the problem). If not otherwise agreed between interchange partners, the "bit" representation of the recommended character set for computer-to-computer interchange for both Level A and B is the seven-bit representation specified in the basic ISO 646 standard. Binary coded decimal or other forms of hardware/software dependent character representation (for examples EBCDIC) must not be used for interchange (other than by prior agreement between
57
interchange partners), as these features are not available, or are not dealt with in the same way, in all makes of computers.
58
International Reference Version (IRV) ISO 646-1983 (E)

+------------------------------------------------+ |b7 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | |------|----|----|----|----|-----|----|-----|----| |b6 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | |------|----|----|----|----|-----|----|-----|----| |b5 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | +------+----+----+----+----+-----+----+-----+----+ +--------------| | | | | | | | | | |b4| b3| b2| b1| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |--------------+---+----+----+----+----+-----+----+-----*---D* |0 | 0 | 0 | 0 | 0 | NUL| DLE| SP| O | @ | P | ` | p | |--------------+---+----|----|----|----|-----|----*-----*----* |0 | 0 | 0 | 1 | 1 | SOH| DC1| !| 1 | A | Q | a | q | |--------------+---.----.*---*--------------------*---------D* |0 | 0 | 1 | 0 | 2 | STX| DC2| "| 2 | B | R | b | r | |--------------+---.----.*---*--------------------*---------D* |0 | 0 | 1 | 1 | 3 | ETX| DC3| #| 3 | C | S | c | s | |--------------+---.----.*---*--------------------*----------* |0 | 1 | 0 | 0 | 4 | EOT| DC4| $ | 4 | D | T | d | t | |--------------+---.---------.--------------------*----------* |0 | 1 | 0 | 1 | 5 | ENQ| NAK| %| 5 | E | U | e | u | |--------------+---.---------.--------------------*----------* |0 | 1 | 1 | 0 | 6 | ACK| SYN| &| 6 | F | V | f | v | |--------------+---.---------.--------------------*----------* |0 | 1 | 1 | 1 | 7 | BEL| ETB| '| 7 | G | W | g | w 3 |--------------+---.---------.--------------------*----------* |1 | 0 | 0 | 0 | 8 | BS | CAN| (| 8 | H | X | h | x | |--------------+---.---------.--------------------*----------* |1 | 0 | 0 | 1 | 9 | HT | EM | )| 9 | I | Y | i | y | |--------------+---.---------.--------------------*----------* |1 | 0 | 1 | 0 | 10| LF | SUB| *| : | J | Z | j | z | |--------------+---.---------.--------------------*-----*---D* |1 | 0 | 1 | 1 | 11| VT | ESC| +| ; | K | [ | k | { | |--------------+---.---------.*---*---------------*-----*----| |1 | 1 | 0 | 0 | 12| FF | IS4| , | < | L | \ | l | | | |--------------+---.---------.*---*---------------*-----*----| |1 | 1 | 0 | 1 | 13| CR | IS3| -| = | M | ] | m | } | |--------------+---.---------.--------------------*-----*----| |1 | 1 | 1 | 0 | 14| SO | IS2| .| > | N | ^ | n | ~ | |--------------+---.---------.---------------*----*-----*----| |1 | 1 | 1 | 1 | 15| SI | IS1| /| ? | O | _ | o | DEL| +--------------+---.-D--.----.---------------*----*-----*---D+
Specified by the standard and widely implemented

-----------| 2 | B | -----------| 3 | C | ------------
Specified by the standard, but not implemented by all manufacturers

.----. | STX| .----.
59
| ETX| .----.---| EOT| DC4| .---------. | ENQ| NAK| .---------.
Specified by the standard, but implemented with varying bit patterns

*---D* | p | *-----*----* | a | q | *---------D* | b | r | *---------D*
6 TRANSMISSION COMPONENTS
An interchange of data in the context of EDIFACT, is composed of one or more messages containing segments which in turn are made up of data elements.
6.1 Data Elements

(NOTE: It is stressed that all the examples of data which follow in this paper are examples. UNTDED should be studied to obtain the current formats, code set and qualifier values, etc). A data element may consist of a single data item, e.g. "2310 Delivery month" in which case it is called a simple data element, or it may consist of several data items, e.g. the composite data element "C198 PRODUCT IDENTIFICATION" which consists of two data elements, 7020 Article Number and 7823 Article Number Qualifier. In this case it is called a composite data element; each data item within a composite data element is called a component data element. A component is identified by its position within a data element. For example, if a data element was required to express the cost of insurance, it would be defined as a composite data element with two component data elements. In the first position would be "5486 Insurance Cost", accompanied by "6345 Currency Code" as the second component. The data elements referred to in the EDIFACT standard are either user data elements or service data elements. User data elements contain the substantive data which are to be transmitted. They are outside the scope of the standard and should be defined and agreed (preferably based on the UN trade data element directory - TDED) between interchange partners, and specified in a user data element directory. Service data elements contain data required for structuring the transmission. A list of the service data elements provided in this standard and their detailed descriptions are given in the UN Trade Data Element Directory (TDED), in the 'S' and the '000' series. They will also be found in ISO 9735. Data elements can only be transmitted within a segment.
60
Each data element in TDED is allocated a unique 4-digit numeric tag. In addition, each data element is allocated a unique and mnemonic four-character data element identifier which must be alphabetic. These identifiers can be used in internal systems, e.g. for system and programming documentation.
6.2 Segments
There are two types of segments: User Data segments and Service segments. Conditional Segments containing no data must be omitted from the message in which they would normally appear. User data segments contain data elements such as amounts, values, names, places and other data to be transmitted. The contents of user data segments are outside the scope of the UN/EDIFACT Syntax standard. User data segments must not be created with the first two letters of the tag "UN", as these are reserved for use in service segments. Service segments contain service data elements such as sender of the transmission, syntax rules type and level, date of the preparation of the transmission, priority type, etc. and/or other specific data which are required for the transmission. All service segment tags start with the two letters "UN" which are reserved for this purpose. On no account should users change service segments. A "Change Request" procedure is described in the Message Design Guidelines for the purpose of proposing amendments. The following categories of service segments are provided in the UN/EDIFACT syntax standard: Transmission structuring syntax segments, which are used to assemble transmissions in a standard way, e.g. to start and end each transmission, to start and end each message within a transmission, and to start and end functional groups of messages within a transmission (if this facility is required). Segments used in the Service messages "CONTRL" & "APERAK", which respectively are used for acknowledgements requests, for correction of syntax errors and rejections, and for confirmation of receipt or requests for correction of application errors. (The latter - APPLIC - is under development). A segment used in the General Purpose Message "GENRAL", which is used to indicate the type, title and references for the message.
Segments are identified by a code which uniquely identifies each segment as specified in a segment directory. A list of the service segments provided in the EDIFACT syntax standard, with detailed descriptions, is given in Annex B of ISO 9735.
6.3 Messages
A Message consists of a number of segments structured in accordance with the syntax rules. It must begin with the service segment "UNH Message header" and end with the service segment "UNT Message trailer". It must contain at least one user data segment, containing at least one user data element. There are two classes of messages: User messages and EDIFACT Service messages.
61
User messages contain the user data segments required for the message in addition to the "Message header" and "Message trailer" segments. There is an option to transfer a message progressively. At the time of the first transmission, it generally would not contain all of the information as defined in the interchange application message specifications, other than the data defined as being mandatory within the message. In this case, the originator may transmit a selection of the data elements at first, followed by a second (or successive) transmission(s), adding to or updating the data previously transmitted, the data being related by means of a structured, unique key. (An example might be a Booking message, where the transport operator needs a rough estimate of the space required for the shipment as early as possible to facilitate his planning. The precise details may be supplied by the originator later as they become available, until finally the transport operator has sufficient data to create a bill of lading). The use of the progressive message transfer technique is explained in more detail in Section 8.3.9 of this guide. UN/EDIFACT Service messages contain service segments for error correction, either at the syntax protocol level, or at the application level, and service segments for general free text. Their use is explained in Section 10 of this guide. Messages are uniquely identified by a message identifier field consisting of five component data elements, used to effect identification and control of messages, as explained in the next Section.
7 Identification & Control of UN/EDIFACT Messages

Note: The information in this section and, in particular that on version/release, no longer conforms to the existing Syntax implementation guidelines which need revision in light of the decision at the March 1994 session of WP.4 to implement Standard and Draft directories. Paragraphs where changes have been made are marked at the beginning with an *
7.1 Definition of a UNSM

A United Nations Standard Message (UNSM) is one which: i) has been registered, published, and which is maintained by the United Nations Economic Commission for Europe; ii) has the values contained in the Controlling Agency, Message Type, Message Version Number and Message Release Number fields (the requirements for the use of which are specified in ISO 9735), allocated and controlled by the UN/ECE; iii) always has the code value "UN" in the Controlling Agency field.
7.2 Definition of a Sub-set of a UNSM
62
A Sub-set of a UNSM is a message which is directly derived from an approved UNSM, has the same function as the UNSM from which it is derived, and which: i) contains all of the groups and segments defined as having a mandatory status within the message, and the mandatory data elements within them. There shall be no change to the status, order or content of the groups, segments, and composite data elements and data elements contained within the segments. (It should be noted, however, that although many UNSMs contain Conditional Groups of segments which may contain one or more mandatory segments, providing the complete conditional group is omitted from the sub-set, this does not break the rule regarding the inclusion of mandatory segments); ii) does not change the status, order or content of the segments, composite data elements and data elements in the conditional segments chosen for use from the UNSM; iii) does not add any segments, composite data elements or data elements to the message; iv) contains the identical values specified for use in the Message Type, Controlling Agency, Message Version Number and Message Release Number fields, as are specified for the UNSM from which the sub-set is derived.
7.3 UN/EDIFACT Directory Set Issue Numbers

It is essential that messages should be capable of being identified in relation to the current version of the directory from which they are derived, (i.e. the code lists, data elements, composite data elements and segments). * Whenever a new Standard directory set is published it contains the message specifications for all registered UNSMs and their supporting segments, composites, data elements and codes. * A directory will be identified by an issue number, allocated and controlled under UN/EDIFACT procedures. The issue number will be a single Character indicating if the directory contains Draft or Standard material (S or D) followed by a period separator, followed by the last two digits of the year in which the directory is agreed, followed by a sequential alpha character assigned by the UN/ECE. This sequential alpha character begins with A at the start of each year and is incremented if more than one directory of the same type (S or D) is published during the same year.
7.4 Message Version & Release Numbers for UNSMs and for Subsets of UNSMs
Refer to section 4.2.5 of UNTDID.
7.5 User Conventions for the Implementation of Sub-sets of UNSMs

United Nations Standard Messages are structured in such a way that they can be used by companies and organisations in many different industries. For example, the invoice UNSM contains data elements and segments which are in common use in the majority of invoicing applications. Other data elements and segments specified for use in the message have a more restricted application, and will probably be required by only a few industry applications. Thus, in the vast majority of cases, industries will choose and become responsible for specific industry related sub-sets from the total message structure. (The definition of a true sub-set defined above).
63
However, still abiding by this principle, users may wish to go beyond the standard sub-set definition, and for reasons of integrity, agree between a group of participants that certain data elements and/or segments which are conditional in a UNSM should always be required in their application. In choosing to go beyond the true sub-set definition set out in paragraph 2 above, users must bear in mind that to comply with the spirit of sub-sets, any sub-set must always be more restrictive than its parent UNSM. To provide a unique identification for any particular sub-set of a UNSM, users may wish to assign a code for use in the "Association assigned code" field of the UNH and/or UNG segments. Further, if it is considered that there may be a problem in assigning a code which may be duplicated by another group of users, it is suggested that the local Rapporteur's Team be consulted regarding the allocation of a code value.
7.6 User Conventions for the Implementation of UNSMs under Amendment

As UNSMs are used by more industries, it is quite likely that some messages will be found not to cover some of the specific requirements of those industries. To provide these requirements so that the messages can be used, immediate changes to (or additions of) segments and elements may be necessary by use of the official UN/EDIFACT "Change Request" procedures. Since the standards maintenance time-scales may delay the implementation of the required modifications to the UNSM for some time, users may wish to implement the changes immediately so that the message can be used in their application. In order to identify the amended message (which then is NOT a UNSM) during the interim period, the user group concerned should consider including an appropriate code in the "Association assigned code" field of the UNH and/or UNG segments. Where it is thought that there may be problems of duplicated Association assigned code values, the local Rapporteur's Team should be consulted regarding the allocation of a code value. As an alternative, in order to identify the group of users requesting the amendments to the UNSM, in the interim period of use of the message, the "Controlling Agency" data element should be used for this purpose.
8 Basic UN/EDIFACT Syntax Rules

The UN/EDIFACT syntax rules apply only to the data to be interchanged. They are independent of the type of computer to be used for the interchange application, whether mainframe, mini or micro. They are also independent of the data to be interchanged and the data standards in use; new data elements or data segments can be introduced and existing data elements and data segments changed (by use of the maintenance procedures) without affecting the rules. The syntax rules are independent of both the type of application (i.e. commercial, governmental, transport etc.), and of the telecommunications protocols or interchange media to be used. For example, a range of different applications are successfully using them on packet switched services, SNA, 2780,
64
3780, magnetic tape etc. Therefore it can be seen that the data to be interchanged sits inside the "envelope" provided by the data communication transport service.
8.1 Interchange Structure

As previously defined, in the syntax rules data elements are carried in user data segments, while service segments contain service data elements which form the structure of the syntax rules protocol. In OSI terms, a connection could include one or more EDIFACT interchanges, each separated from the other by control service segments which identify the start and end of each interchange. Within each interchange, there is then a hierarchical structure which allows for both control and identification of data for processing. This structure is shown in Section 6 of ISO 9735. The syntax deals with the representation of the syntax protocol and user data only, and not with the requirements of the technical transmission aspects of telecommunications protocols, media labels, etc. Further, it should be pointed out that UN/EDIFACT in no way encroaches upon the OSI concept. In an UN/EDIFACT interchange, everything from the first character of the Interchange Control Header segment to the last character of the Interchange Control Trailer segment, is user data, emanating from one computer system in a structure agreed by the users, for receipt into another computer system at the application level.
8.2 Use of the character set

In general, all of the characters specified in the User Interchange Agreement, (see section 3), can be used in data.
8.2.1 Relationship to syntax control characters

If Level A syntax is being used,, it is recommended that the following four characters of the recommended character set, namely: the plus sign ( + ) the colon ( : ) the apostrophe (') the question mark (?)
should not deliberately be chosen for use in data elements, as they are reserved for use within the EDIFACT syntax rules rules as syntax characters for Level A. However, it should be pointed out that in practice in live applications, this causes few problems, because they rarely appear in genuine data. If they do, it is a relatively trivial task for the program which formats the data into the syntax structure to insert a release character where appropriate, and for the program which de-formats the data to remove the release character - thus permitting that character to be passed on to the recipient's system as a character which is part of the user data.
8.2.2 Syntax separators, terminator and release character

Name & Function of Separator Segment terminator Separator in Level A ' Separator in Level B ISO646
65
(To terminate all segments. A data element separator must not be used after the last data element in a segment.) Segment tag and data element separator (To separate all segment tag service data elements from the first user data element in the segment, and to separate simple and/or composite data elements in a segment from each other.) Component data element separator (To separate all component elements in a composite data element from each other.) Release character (To release any of the characters + ; ' ? appearing in user data in Level A syntax. It MUST immediately precede the character in question and signifies that the NEXT single character is not to be interpreted as a syntax separator, terminator, or release character.) Examples Level A syntax separators
(apostrophe)
IS4
+ (plus sign)
ISO646 IS3
: (colon) ? (question mark)
ISO646 IS1 NOT USED
NAD+BY+ABC CO:26 MAIN STREET:LONDON:TW17 9NW' where: NAD is the unique segment code for a Name and Address segment BY is a qualifier meaning "Buyer", thus identifying the function of the NAD segment ABC to 9NW is a composite data element Level A release character SEG+75?+73?+ABC+HOW MANY PACKAGES??' where: In the users system, the first data element appears as 75+73+ABC and the second data element appears as HOW MANY PACKAGES? The release character is not counted as part of the length of any data element or component data within which it is transmitted. Release characters can be inserted by program so that data can be input and output without any special manual requirements. Level B syntax separators Note: The information separators IS1; IS3 and IS4 are described and their coded representation specified in clause 4 of ISO 646. They are control characters and thus non-printable. However, in the example below they are shown in brackets thus (IS1) to illustrate their use. NAD(IS3)BY(IS3)ABC CO(IS1)26 MAIN STREET(IS1)LONDON(IS1)TW17 9NW(IS4)
66
8.3 Interchange formatting rules 8.3.1 Interchange structure

As previously defined, service segments contain service data elements which are required at the application level for interchange or syntax control. A set of user interchange data must start with a "UNA Service String Advice" if for any reason neither the Level A or B the syntax separators, as defined in the standard, are used in the interchange which follows. If it is possible that the application may have to process interchanges preceded by the UNA string, you must ensure that your de-formatting software can process the data, which effectively is using "nonstandard" separator characters. One technique for achieving this is to have a routine which, when the UNA string is detected, dynamically updates the module which processes and checks the syntax separator characters. The set of user interchange data following the service string advice (if used) must start with the service syntax segment "Interchange Control Header" which has the segment code UNB. The set of user data must be terminated with the the "Interchange Control Trailer" which has the segment code UNZ. If several sets of user interchange data are included in one transmission, (i.e. there are several pairs of UNB and UNZ segments), each UNB segment must be preceded by a delimiter string advice if neither Level A or B separators are being used. With the exception of these service segments used to delimit a transmission (and two other service segments which are used to identify functional groups within a transmission), all data in a transmission must be interchanged within a message. A transmission may contain one message or any number of messages. A transmission in general form can therefore be depicted as: +--- UNB segment | | message(s) | +--- UNZ segment The syntax rules do not specify the order in which messages of different types should be transmitted within an interchange. The sender can forward messages in an order of his choosing, unless partners in an interchange application agree otherwise, or unless otherwise stated in the Interchange Agreement.
8.3.2 Service string advice - UNA

The string has a mandatory fixed length of 9 characters. The first three are UNA, immediately followed by the 6 characters as defined in ISO 9735. NOTE: ONLY in very special circumstance, (for example, at level A Syntax, if a user application group were interchanging only data related to mathematical equations, or, at level B syntax, if it were
67
found that any IS character from ISO 646 had been utilized for a specific function by a network or by a communications protocol), should any other delimiters than those detailed for Levels A and B be used.
8.3.3 Interchange control header segment - UNB (See ISO 9735 Annex B for detailed specification)
In addition to the segment code UNB, the following mandatory service data elements must be included in the following order: the syntax identifier and version number; the interchange sender; the interchange recipient, plus an optional (normally coded) sub-address for onward routing; the date and time of the transmission; and the interchange control reference. Some, or all of the following conditional service data elements can be included in the segment, if specified for use in the Interchange Agreement. If included, they must be in the following order: the recipient's transmission reference (or password to be provided by the sender); the application reference; the processing priority code; an acknowledgement request; the communications agreement identification; and a test indicator. (The recipient's transmission reference field may optionally be used to contain a password instead of a transmission reference). Clearly, such use must be specified in the Interchange Agreement. It may be required for example, where a group of users are interchanging their data via a bureau mailbox service, or where a password is needed to gain access to the recipient's system. If functional grouping is being used in the interchange, the facility exists to include a password in each group header. To gain access to the recipient's sub-systems, if required. As identified in Section 2, some of the above data may not be held in the in-house system. If not, it can be provided at run-time via a parameter file. The last field in the segment, the "Test Indicator", is used during the run-up phase to live working, since its use enables the recipient to identify all the data contained in the interchange as for trial use only. Clearly, care must be taken to set the field to zero as soon as live interchanges are started. An example UNB segment containing all of the conditional data elements and using level A syntax would be transmitted as: UNB+UNOA:1+123:AB:PO168+3572:DN:B1342+771206:121500+A143+B26AZ+DELINS+X+1+ CANDE+1' where: UNB UNOA:1 is the segment tag code. identifies version 1, level A of the syntax rules and Controlling Agency UNO. (For level B, the field would contain UNOB:1). The purpose of the version number is to allow for maintenance of the standard. Each future amendment, or groups of amendments to the syntax, will cause the version number to be incremented by 1.
68
123:AB:PO168
identifies the sender of the transmission in code with a qualifier of AB to identify the code set being used, followed by a code representing a reverse routing address to which the recipient should address any reply. identifies the recipient of the transmission in code (qualified by DN), plus a sub-address code. The sub-address code for onward routing may be used if the functional grouping facility, (which also provides for sub-addressing), is not used. 771206 is the date and 1215 is the time of the preparation of the transmission. This is the date/time that the interchange is assembled for transmission. is the unique interchange control reference for this transmission, allocated by the sender of the interchange. is recipient's reference, or a password. (This can be accompanied by a qualifier component element, if so specified in the Interchange Agreement) the field is left blank if not used. is an example of an application reference. A common usage of this field is to keep all messages of the same type within one unique transmission, and to carry the appropriate message identifier in this field. Such usage allows a transmission of a particular message type to be retrieved by the recipient from a mailbox service in advance of transmissions containing a different message type. The technique would not be used if either Functional Grouping or an interchange containing a mixture of different message types were being used, in which case it would be left blank. is a processing priority code, using a code defined in the Interchange Agreement (or left blank if not used). indicates that the sender is requesting an acknowledgement for the interchange, but only that the recipient has successfully received and identified the header and trailer segments (UNB & UNZ) for the interchange. The recipient would reply, using a "CONTRL" message (see Section 10). Such an acknowledgement does not mean that the contents of the interchange have been processed correctly and are acceptable to the recipient. The field is set to zero if an acknowledgement is not required. is an example of a code specified in the Interchange Agreement, which identifies the type of communications agreement under which the interchange is controlled, (or left blank if not used). indicates that this is a test transmission. The field is set to zero for transmission of live data.
3572:DN:B1342
771206:1215
A143
B26AZ
DELINS
CANDE
69
8.3.4 Interchange control trailer segment - UNZ (See ISO 9735 Annex B for detailed specification
In addition to the segment code UNZ, this control segment contains two mandatory service data elements. The first, the interchange control count, contains either a count of the number of messages in the interchange, or a count of the number of functional groups in the interchange if that facility has been used (see Section 8.3.5). The second data element, the interchange control reference, contains the identical reference to that carried in the same field of the UNB interchange header segment for the same interchange. Checking that the two fields are identical ensures that the set of interchange data has been successfully received. A UNZ segment which indicates a transmission with an interchange control reference of A143, containing 7 functional groups, would be transmitted as: UNZ+7+A143' For a transmission with the same reference where functional grouping has not been used, and which contains 2500 messages, the UNZ segment would be transmitted as: UNZ+2500+A143'
8.3.5 Functional group structure

Messages in a transmission can be assembled into one or more functional groups. For interchanges of data to/from North America, the use of functional grouping is mandatory. For other interchange applications, its use is optional, but should be specified in the interchange agreement. It is not permitted to mix the use of functional groups with messages not contained within functional groups in the same interchange. Each functional group must begin with the control service segment "Functional Group Header" which has the segment code UNG. Each functional group must end with the control service segment "Functional Group Trailer" which has the segment code UNE. An interchange consisting of a single functional group of "n" messages can therefore by depicted as:
+--| | | | | | | | | | +--UNB segment +| | | | | | +UNG segment
first message ....... "n-th" message UNE segment
UNZ segment
An interchange consisting of "n" functional groups, can be depicted as:

+--| | | | | | | UNB segment +--- UNG header of the 1st functional group | | messages | +--- UNE trailer of the 1st functional group
70
| | | | | | | | | | | | | | | +---
+--- UNG header of the 2nd functional group | | messages | +--- UNE trailer of the 2nd functional group ... +--- UNG header of the "n-th" functional group | | messages | +--- UNE trailer of the "n-th" functional group UNZ segment
8.3.6 Functional Group header - UNG (See ISO 9735 Annex B for detailed specification)
The main benefit of the use of functional grouping is that it permits large organisations which have several functional processes, (e.g. purchasing, invoicing etc) or data processing centres (for example at a divisional or departmental level), to create their own identifiable application level envelopes, which can also be addressed from the originating department to a department in the recipient's system. An example functional group, (which has the segment code UNG), could be transmitted as: UNG+INVOIC+15623+23457+860606:183500+CD1352+UN+89:1+A3P52' where: UNG INVOIC is the segment tag code. is the functional identification, used to identify the one message type contained within the functional group. is the Application Sender's Identification, which is a code identifying a specific division, department, section, etc., which has originated (or is responsible for) the messages contained in the functional group. If necessary, the data element can contain a second component of a qualifier, to identify the code set being used. is the Application Recipients Identification, a code identifying a specific division, department, section, etc., to which the messages in the functional group are finally destined. If necessary, it too can be qualified by a second component to identify the code set being used. is the date and time that the functional group of messages was assembled. (NOTE that the time, and perhaps the date, will often be earlier than the date and time carried in the UNB interchange header segment). is a unique reference number for the functional group, assigned by the division, etc., which originated the group of messages.
15623
23457
860606:1835
CD1352
71
UN
is the controlling agency code (see Section 7), which identifies the agency responsible for the production and maintenance of the message standards for the message type contained in the group. is the version and release number of all of the messages in the group, which must all be the same message type. This composite data element could contain one additional component data element for an association assigned code. It should be noted that if conditions also demand the presence of a number in the association assigned code field, the same data for the composite need not be repeated in the equivalent fields of the Message Header (UNH) service segment preceding each message in the Functional Group. Usage is fully explained in Section 7. is an application password, and is the only conditional data element in the segment, all the rest being mandatory. The password is only used if specified in the interchange agreement (or if agreed bi-laterally) and could, for example, be used to gain entry to the recipient's sub-system which will process the functional group
89:1
A3P52
The example above shows the typical use of the functional group facility, however, it should be noted that the facility for grouping messages of the same type together may still be used without using the internal system addressing capabilities from and/or to sub-systems in the sender and/or recipient organisations. In this case, the second, third, and fourth data elements in the group (Application Sender's Identification; Application Recipient's Identification and Date/Time of Transmission) could contain identical data to that contained in the comparable fields in the UNB interchange header segment (i.e. Transmission Sender; Transmission Recipient and Date/Time of preparation). For this type of usage the last data element in the functional group header (Application Password) would be omitted. Thus, the whole interchange and the functional groups contained within it, can be addressed point to point.
8.3.7 Functional Group trailer segment UNE (See ISO 9735 Annex B for detailed specification)
In addition to the segment code UNE, this service segment contains two mandatory service data elements. The first, "Number of messages" contains a count of the total number of messages in the functional group. The second, "Functional group reference" contains the identical reference to that carried in the same field of the UNG header segment for the functional group. Checking the two fields to be identical ensures that the functional group has been successfully received. A group trailer for a group of 72 messages with a group reference of CD1352, would be transmitted as: UNE+72+CD1352'
8.3.8 Message structure

A message must begin with the service segment "Message header" which has the segment code UNH. A message must end with the service segment "Message trailer" which has the segment code UNT. In
72
addition to these two delimiting segments, a message may contain one or more user data segments required for the message. A message containing one user data segment to be transmitted can therefore be depicted as: . UNH segment | | data segment | . UNT segment A message containing " n " segments to be transmitted can be depicted as: . UNH | | | | | . UNT segment first data segment ... n-th data segment segment
The syntax rules do not specify the order in which these user data segments should be transmitted within a message. This is a function of message design. The Interchange Agreement must contain specifications for all interchange messages and their segments as required by the user group.
8.3.9 Message header control segment - UNH (See ISO 9735 Annex B for detailed specification)
This segment, used for both data and service messages, has the segment code of UNH. It contains two mandatory service data elements: the message reference number; the message identifier;
and two conditional data elements for use with progressive message transfers only: the common access reference the status of the transfer
The message reference can be either: a program generated reference number starting at 1 for the first message in the interchange, and incremented by 1 for every successive message in the interchange; when the Functional Grouping technique is not being used; or when Functional Grouping is being used, a program generated number starting at 1 for the first message in each functional group, and incremented by 1 for every successive message in each functional group; or a meaningful reference number provided from the originator's in-house system.
73
The two techniques of program generated or meaningful reference numbers must not be mixed within an interchange. The preferred technique should be specified in the Interchange Agreement. Most live systems use the former techniques, with the numbers being program generated. The message identifier is a composite data element, having five component data elements: the type of message (mandatory) the version number of the message (mandatory) the message release number (conditional)* the controlling agency (conditional)* the association assigned code (conditional)*
* (NOTE: If Functional Grouping (See Section 8.3.6) is not being used, the controlling agency field becomes mandatory in the UNH. If conditions demand the presence of data in the release number, and/or association assigned code fields, (see Section 7) then these too must be provided in the UNH if Functional Grouping is not being used. The use of message release number, controlling agency and association assigned code has been fully explained in Section 7. The type of message identifier is of variable length 6 alphanumeric, e.g. INVOIC for invoice messages, or 850 for a purchase order transaction set (a non-UNSM message). The version and release numbers associated with the type of message are both variable length, 3 numeric. The rules for the control of version and release numbers are explained in Section 7. The common access reference (CAR) is a variable length alpha-numeric field, with a maximum of 35 characters. Within this maximum, any combination of sub-elements may also be specified according to user preference. Clearly however, all users in an interchange group must use the same format, which must be specified as part of the group's interchange agreement. The purpose of the reference is to serve as a key to which all subsequent transfers of data for the same business file, can be related. Therefore, the same reference must be included in the UNH of all related transfers. The status of the transfer has two component data element the first a variable length numeric field, with a maximum of 2 characters, which can have the values: 1 to 99 (indicating the sequence of transfers of data starting at 1 for the first transfer incremented by one for each additional transfer),
The second sub-element is a fixed length field of one alphabetic character, which can have the following values: C this must be present for the first transfer of data related to the common access reference if more than one transfer is foreseen, (i.e. indicating that a file is to be created, using the CAR as its key) F this must be present for the final transfer of data related to earlier transfers for the same CAR key.
74
The message reference, message identifier, common access reference, and the status of the transfer are all used for progressive transfer messages, related to a business file. The concept of progressive message transfer is that after the initial transmission of data related to a business file, successive transmissions can be used, either to upgrade or amend previously transmitted data related to the same business case, or to add new items of data. The decision as to what data is transmitted at any given time is under the control of the originator. Each transmission related to the same business file is linked by means of a unique common access reference (CAR), carried in the UNH segment. This reference is imposed by the originator of data, (in practice, the principal), and is held as a key by all other partners with whom the principal is in communication. The trade file thus created, covers the whole set of data necessary to carry out the task(s) proper to a specific party concerned with a trade transaction. This party receives into his own application the information made available by the sender, which may be data useful at a given time to allow initial processing to take place. An example could be an initial booking for transport, where the full detail of the goods to be carried is not yet available. The common access reference, unique to every business file, is the key by which the various transmissions of progressive transfer messages coming from or going to any specific trade operator are linked together. Within an exchange between partners, the CAR permits linkage of the different elements of required information to a series of operations connected with the same business file: Example Operation 1 - Order Operation 2 - Despatch advice Operation 3 - Delivery note Operation 4 - Insurance Certificate Operation 5 - Invoice From this, it can be seen that any data common to two or more of these operations between two parties, need only be transmitted once. The progressive message transfer technique permits the transmission of data which is available at a given time, sufficient to allow the recipient to act upon the information.
8.3.10 Message trailer control segment UNT (See ISO 9735 Annex B for detailed specification)
In addition to the segment code UNT, this segment contains two mandatory service data elements. The first, "Number of segments in a message" contains a count of the total number of segments in the message, including the UNH and UNT segments. The second, "Message Reference Number" contains the identical reference to that carried in the same field of the UNH message header segment for the same message.
75
8.3.11 Section control segment UNS (See ISO 9735 Annex B for detailed specification)
Some UN Standard Messages (UNSM's) have been designed having three distinct logical sections, the first containing what may be termed user header data for the message, the second containing detail information (which will often repeat within the message), and the third containing summary information related to the contents of the message. In this type of structure, the situation may arise where identical user data segment(s) may be required in more than one of the sections, but containing different values for their data elements, (or in some cases overriding the data carried in the identical segment in the header section). In order to permit the precise identification and control of this situation, a control segment is provided to delimit the three sections. An example of the function of overriding data carried in an earlier segment could be as follows. A purchase order message could specify in the header section a delivery address to which the (majority of) the order should be delivered. The same segment containing this information could be repeated in the detail section, related to a specific line item of the order. In this case, the delivery address related to the line item only, overrides the address given in the header section (which could well apply to all of the other line items in the detail section). The section control segment has a segment tag code of UNS and contains one data element. When used to delimit the header section from the detail section, it contains the value "D", and when used to delimit the detail section from the trailer section, it contains the value "S". When used, UNS segments must be specified in their correct positions within the relevant message(s) in the message directory. If messages are designed having a different structure - for example, where it is only necessary to separate a summary section from the rest of the message - then only the relevant UNS segment should be used. No more than two UNS segments should be used.
An example of the use of the UNS segment is shown below:
UNH+........data..........' ) Message Header AAA+..........data............' ] BBB+..........data............' ] User data segments forming CCC+..........data............' ] the header section. UNS+D' - Section control segment separating the header and detail sections BBB+..........data............' ] User data segments FFF+..........data............' ] (including an identically GGG+..........data............' ] described BBB segment) HHH+..........data............' ] forming the detail section. UNS+S' - Section control segment separating the detail and summary sections III+..........data............' ] user data segments forming JJJ+..........data............' ] the summary section. KKK+..........data............' ] UNT+.........data...........'
9 SEGMENT CONSTRUCTION AND TRANSMISSION RULES 9.1 Segment Composition

A segment must start with a tag, which is a mandatory composite service data element.
76
The first component data of the tag is mandatory, and contains a unique code to identify the segment. Service segment codes are defined in the EDIFACT standard and must not be changed. User data segment codes are allocated by the Controlling Agency responsible for the message and must be unique within the application(s) in which they are used. The remaining component data elements of the tag are conditional. They are only used if the segment can repeat within a message, and when it has been stated in the message specification that control numbers to indicate the level at which the segment in question is repeating within the message are to be transmitted, (explicit representation). Section 9.5.3 details the use of this technique. The structure of all segments therefore, is: SEG+........data elements.......' where: SEG is the code for the segment tag.
Segments may contain one, or several related user data elements, which may be either simple and/or composite, as previously defined. For a segment to be transmitted, it must contain data for at least one data element. The order of the data elements within the segment must be specified in a pre-defined sequence. For data segments, the order and content must be specified in the interchange application segment directory, along with the data segment code. At the segment level, every segment must be defined as being either mandatory or conditional within a message. Mandatory segments must be transmitted if the message is present, whereas conditional segments may be transmitted depending upon the pre-agreed conditions defined in the message specification. Data elements within segments, and component data elements within composite data elements, must also be defined as being either mandatory or conditional. If a data element or component data element is mandatory within a message, then the segment in which it appears must also be defined as being mandatory. Conditional data elements or component data elements within such a segment may be transmitted depending upon the pre-agreed and specified conditions. A conditional segment in a message may, however, contain one or more data elements or component data elements which are mandatory when the segment is used in the message. In this case, such data elements are mandatory at the segment level, rather than at the message level, and such component data elements are mandatory at the data element level. The syntax separators used will depend upon whether level A or level B syntax is being used.
9.2 Absence of Data 9.2.1 Absence of a segment

Where no data needs to be transmitted for a conditional segment, the complete segment (including the segment tag) must be omitted.
77
9.2.2 Absence of data within a segment

As described earlier, the order of data elements within a segment must be specified in a pre-defined sequence. This allows the receiving system to identify and process each individual data element. It follows therefore, that if data is omitted at the beginning, or the middle of a segment followed by data which is present, some means is necessary of recognizing the fact. In the examples which follow, the component data elements of the segment tag, (which can be used to indicated explicitly, the level at which the segment repeats), have been suppressed, and therefore do not appear. The absence of data for one or more conditional data elements preceding other data in the segment which is present, is indicated by the data element separator + for each missing data element: Example: SEG+DE1+DE2+DE3+DE4+DE5' A segment with all data elements present. A segment with DE1 omitted. A segment with DE3 and DE4 omitted.
SEG++DE2+DE3+DE4+DE5' SEG+DE1+DE2+++DE5'
Where no data is required for one or more conditional data elements at the end of a segment, the preferred technique is to use the segment terminator to truncate the segment following the last data element for which data is required: Example: SEG+DE1+DE2' A truncated segment with E3, DE4 and DE5 omitted.
Alternatively, data element separators can be used to indicate positively the absence of data for each, or some, of the data elements not required at the end of a segment. Example: SEG+DE1+DE2+++' A segment with DE3, DE4 and DE5 omitted (no + permitted after DE5, since it is the last element in the segment)
It should be appreciated however, that if unwanted data element separators at the end of segments are not truncated and there are a high percentage of such separators, an interchange of many thousands of characters could take appreciably longer to process. A further possible difficulty if there are certain types of telex links in the interchange chain, is that a string of 4 consecutive plus-signs can cause some automatic telex systems to abort the transmission. The absence of data for one or more conditional component data elements within a composite data element is indicated using similar principles to those described above. A data element separator must be inserted following the last component element for which data is required within a composite element. The absence of data for one or more component elements preceding another component element which is present, is indicated by the component element separator : for each missing component data element: Example: +CE1:CE2:CE3:CE4+ A composite data element with four component elements, all present.
78
+:CE2:CE3:CE4+
A composite data element with CE1 omitted. A composite data element with CE3 omitted. A truncated composite data element with CE3 and CE4 omitted. A truncated composite data element with CE1, CE2, CE3 and CE4 omitted.
+CE1:CE2::CE4+ +CE1:CE2+
++
SEG+:CE2:CE3:CE4+ A composite data element following a segment tag with CE1 omitted.
9.3 Suppression of Non-significant Characters

To increase efficiency of transmission and to limit processing overheads at reception, it is recommended that only the significant characters of data elements and component data elements defined as being variable length for the interchange application, should be transmitted. If in an in-house file, a fixed numeric field of 10 digits is defined as variable length for the interchange segment and has only two significant digits "12", the leading zeros can be suppressed: Example: the 0000000012 form in the in-house system becomes the +12+ form when suppressed. If in an in-house file, an alphanumeric/alphabetic field of 10 characters is defined as variable length for the interchange segment and has only two significant characters "AB", the trailing space characters can be suppressed, e.g. ........AB spaces........ +AB+ Leading spaces must not be suppressed. e.g. .....spaces AB spaces..... in the in-house system becomes +spaces AB+ when suppressed. becomes when suppressed.
This can be summarised as variable length numeric fields being right justified and variable length alphanumeric and alphabetic fields being left justified. It should be pointed out however, that recipients must have the capability of accepting either suppressed or non-suppressed variable length data, accepting however that processing overheads will be increased if suppression is not used. Any further types of compression, for example those offered by some proprietary telecommunications protocols, are outside the scope of EDIFACT.
79
9.4 Negative Values

Where negative values are required, a leading minus sign (a hyphen), should be transmitted before the numeric value. e.g. inhouse form becomes 1352|negative -1352 for transmission
Numeric fields transmitted without a sign are assumed to be positive, including where the data element description has an implied negative value (e.g. "Debit"). It is the function of the in-house process after receipt to take account of this type of data.
9.5 Repeated and nested segments

A common requirement for many types of message is the need to repeat segments. For example, an invoice could contain a number of items, each item containing a product code, quantity, price, etc. Sometimes several repeats of a segment can occur within an already repeating segment, for example, there could be several goods items in a container and several containers within a consignment. The data elements for a goods item are grouped together in one repeating data segment while the details for each container are grouped in another repeating segment, at a higher level. There are two types of structure which can occur in such repeating or repeating and nested segments. These can be defined as being vertical or horizontal. To meet some more complex requirements, the two structures can be combined within a specific message. For example, a message containing no repeating segments, only non-repeating data segments AAA, BBB and CCC, can be expressed diagrammatically as follows:
_____________________________ | | | | | UNH AAA BBB CCC UNT
Level 0
Each segment (including the service segments UNH and UNT) appear at a hierarchical level of zero, and in the transmission, each segment will appear only once in each message of the same type in character string form as:UNH+...data...'AAA+...data...'BBB+...data...'CCC+...data...'UNT+5' For easier legibility in examples, this can also be shown as: UNH+....data....' AAA+....data....' BBB+....data....' CCC+....data....' UNT+....data....'
9.5.1 Repeating segments

A message may also contain one (or more) segments which may repeat in the message.
80
e.g. Level 0 Level 1
___________________________ | | | | | | UNH AAA | BBB | UNT | | GDS FTX
where data segments AAA and BBB are non-repeating segments at level zero, whereas GDS and FTX are repeating segments at level 1. Segments at Level 0 are non-repeating segments having a status of either M 1 or C 1. Segments at Level 1 are either: i) a segment which can repeat 2 or more times and which does not start a group of segments, or ii) a segment shown as having one or more occurences, which starts a group. Segments at Levels 2 to "n" are those which appear consecutively below those at Levels 1 to n-1, having a hierarchical relationship to the segment(s) above. How many times they can repeat within the message is something which is dictated by the application for which they are specified, and which must be stated in the relevant message specification. A repeating segment can be defined as being "Conditional", repeating up to a maximum of 'n' times. If there is no data for such a segment, it would not appear at all in the message. Alternatively, a repeating segment can be defined as being "Mandatory" repeating up to a maximum of 'n' times. In this case there must be at least one occurrence of the segment in the message. Diagrams greatly assist users in understanding message structures. This is particularly true with regard to the level and status of each segment, and the number of times each segment can appear in the message. The conventions which should be followed are that each segment in the diagram, (or groups of segments as will be seen later), should be "boxed" with the status shown in the bottom left corner of the box, and the maximum number of occurrences shown in the bottom right corner of the box. Using this convention, the above diagram could become:
___________________________ | | | | | | +---+ +---+ | +---+ | +---+ |UNH| |AAA| | |BBB| | |UNT| |---| |---| | |---| | |---| |M|1| |M|1| | |C|1| | |M|1| +---+ +---+ | +---+ | +---+ | | | | +----+ +---+ |GDS | |FTX| |----| |---| |M|50| |C|5| +----+ +---+
Level 0
Level 1
81
This implies the following structure: All of the segments, if they appear, must appear in the order shown: UNH is mandatory and must appear once in the message. AAA is mandatory and must appear once in the message. GDS is a repeating segment at Level 1, it must appear at least once in the message, and can repeat consecutively up to a maximum of 50 times. BBB is a conditional segment which may be omitted if it contains no data, or may appear only once in the message. FTX is a repeating segment at Level 1, which may be omitted if there is no data for the segment, or can repeat concurrently up to a maximum of 5 times. UNT is mandatory and must appear once in the message. The standard specification for all segments is that the segment tag comprises 10 component data elements. The first is mandatory and contains the unique code to identify the segment. The remainder are conditional and are available to carry control numbers for use when required with repeating segments. When a segment appears at level zero in a message (i.e. it is a simple non-repeating segment), following the normal rules for truncation, all of the unused component separators following the segment codes are replaced by the segment tag separator. Any segment which can repeat within a message, can be constructed for output in one of two ways: without the use of control numbers associated with the segment code (subsequently referred to in this guide as implicit representation of repeating segments), in which case, as for nonrepeating segments, the unwanted component element separators are truncated and replaced by the segment tag separator, or with the use of control numbers associated with the segment code, to specify the level at which the segment repeats, (subsequently referred to in this guide as explicit representation of repeating segments). Use of control numbers is detailed in Section 9.5.3.
It is stressed that it is the responsibility of message designers to decide and to state in each message specification, what form of representation is to be used for segments in the message which can repeat. However, it is not permitted to mix the two techniques within a message. In current UNSM's implicit representation is specified, which is also the preferred technique for messages in use in and to North America. Some pre-EDIFACT applications in Europe still use explicit representation.
9.5.2 Comparison of implicit and explicit representation

Using a message with the following structure:
82
Level 0
Level 1
___________________________ | | | | | | +---+ +---+ | +---+ | +---+ |UNH| |AAA| | |BBB| | |UNT| |---| |---| | |---| | |---| |M|1| |M|1| | |M|1| | |M|1| +---+ +---+ | +---+ | +---+ | | | | +----+ +---+ |GDS | |FTX| |----| |---| |M|50| |C|5| +----+ +---+
Assuming that there are 3 occurences of the GDS segment and one occurrence of the FTX segment, the message would be transmitted as follows, (although in a character string, rather than the layout used for the example):
Implicit UNH+........data..........' AAA+........data..........' GDS+..........data..........' GDS:1+........data.......' GDS+..........data..........' GDS:2+........data.......' GDS+..........data..........' GDS:3+........data.......' BBB+........data...........' FTX+..........data..........' FTX:1+........data.......' UNT+........data...........'
Explicit UNH+........data..........' AAA+........data..........'
BBB+........data...........'
UNT+........data...........'
9.5.3 Repeating groups of segments

Within a message, two or more segments can be specified as a group of segments which can repeat as a group, with the group itself having either a Mandatory or Conditional status. There may be any number of groups within a message, with a group or groups also appearing within another group. As for conditional segments, a conditional group of segments may be completely omitted from the message if there is no data for the group, (even though the group may contain one or more segments within it which have a mandatory status). If a conditional group is transmitted, the group must contain the segment(s) within it having a mandatory status.
9.5.4 Message branching diagrams

Message specifications can include a branching diagram showing the structure of the message. The conventions used are shown in the following fictitious message.
83
Level
_______________________________________________.....___ | | | | | | | | __|__ __|__ | | | | | __|__ |UNH| |AAA| | | | | | |UNT| |---| |---| | | | | | |---| |M|1| |M|1| | | | | | |M|1| +---+ +---+ | | +---+ | +---+ +---+ | | |Gr1| | |Gr2| | | |---| | |---| | | |C|5| | |M|9| +----+ +----+ |---| +---+ |---| |RFF | |CTA | |NAD| |CUX| |TRD| |----| |----| |---| |---| |---| |C|10| |C|10| |M|1| |C|5| |M|1| +----+ +----+ +---+ +---+ +---+ | | | __|__ _______|_______ |Gr3| | | | |---| | | | |C|5| +---+ +---+ +---+ |---| |RFF| |CTA| |BNK| |NAD| |---| |---| |---| |---| |C|6| |C|5| |C|5| |M|1| +---+ +---+ +---+ +---+ | __|__ |DTM| |---| |C|1| +---+
In the above example, Group 1 is Conditional and the whole group (containing NAD, RFF, CTA and BNK) could either by omitted completely, or could repeat up to a maximum of 5 times. Each occurrence of the group must contain at least the NAD segment. Group 2 (containing TRD and the segments in Group 3) is Mandatory and must appear at least once. It could appear up to a maximum of 9 times. Within each occurrence of Group 2, Group 3 could be omitted completely if there were no data for the segments within the group, or alternatively could repeat up to a maximum of 5 times. For each occurrence of Group 3, the NAD segment must appear, while DTM may or may not appear, depending upon data being present for the segment. As can be seen, virtually any combination of horizontal and vertical structures for segments can be combined. The order in which segments must be processed is first from left to right, and then if necessary, from top to bottom when a vertical structure is encountered. Left to right processing is then followed again if horizontal and vertical structures are combined. Using Group 1 in the above diagram as an example, after having processed the segments to the left of the group in sequence, the first occurrence of the NAD segment (if present), would be followed by up
84
to 6 occurrences of RFF, followed by up to 5 CTAs and up to 5 BNKs, before returning to the top of the loop. Once all of the occurrences of NAD had been exhausted, processing would continue with the next segment to the right of the Group 1 on the diagram (CUX). It follows from this therefore, than when formatting a message, the user's in-house system must ensure that subordinate and repetitive records used to construct segments are sorted into the correct sequence for processing. It can also be seen from the diagram that a group must be entered via a single segment. In software terms, this segment is sometimes referred to as a "trigger" segment, i.e. the in-house record containing the data for the segment is used by the software as a "trigger" to start another occurrence of the group. It should be born in mind however that: i) two or more different loops cannot begin at the same segment, at the same position in a message; and ii) an inner loop must be completed before returning to a further occurrence of the outer loop within which it appears. The last point to be borne in mind, is that the levels at which segments appear must be shown on the left of the branching diagram, with the segments opposite the level number being kept in a horizontal line. This become particularly important for understanding and checking purposes, if the message is a complex one with parts of the diagram being "exploded" onto another page of the branching diagram.
10 EDIFACT SERVICE & CONTROL MESSAGES

[NOTE: This Section is being submitted initially as a separate paper, which after approval, will be inserted].
11 MIGRATION TO EDIFACT
Any user seeking advice on migration from any other interchange standard to EDIFACT, should contact their local EDIFACT Rapporteur's Advisory Team.
11.1 Rapporteur Advisory & Support Teams (RT's)

It is via the RT's that maintenance procedures for the EDIFACT Syntax Rules, Data Element Directory, Segment Directory, and Message Directory will be co-ordinated, in conjunction with the UN/ECE Secretariat. The contact points for the rapporteurs currently appointed are: European Board for EDI Standardization (EBES): Mr R POWER (Rapporteur) Tel: +353 1 808 2000 FORBAIRT Fax: +353 1 837 0172 Glasnevin DUBLIN 9 IRELAND
85
Internet: Powerr@forbairt.ie Pan American EDIFACT Board (PAEB): Mr T. WHEEL (Rapporteur) Tel: +1 703 767-6394 U.S. Department of Defense, Fax: +1 703 767-6378 DLA-AQAC-E, 8725 John J. Kingman Road, Suite 2533 Fort Belvoir, VA 22060-6221 United States Internet: thomas_wheel@hq.dla.mil Central and Eastern European EDIFACT Board: Mr B. GEORGIEV (Rapporteur) Tel: +359 2 876 142 Bulgarian Chamber of Commerce Fax: +359 2 873 209 & Industry 11-a Saborna Str. BG-1000 SOFIA BULGARIA Australia/New Zealand EDIFACT Board: Mr H. Bates (Rapporteur) Box 635 LAKES ENTRANCE Victoria 3909 Australia
Tel: +61 51 55 34 59 Fax: +61 51 55 34 58
Asian EDIFACT Board: Mr K Itoh (Rapporteur) Tel: +81 3 437 61 35 JASTPRO Fax: +81 3 437 61 36 Daiichi-Daimon Bldg. 2-10-1 Shibadaimon, Minato-ku Tokyo 105 Japan Internet: jastpro@po.iijnet.or.jp African EDIFACT Board: Mr. P. MOUBELET-BOUBEYA Tel: +241 77 47 70 Cabinet du Secretaire Generale Fax: +241 76 58 38 du Gouvernement B.P. 91 LIBREVILLE GABON
86
ANNEX B General Introduction to UNSM Descriptions (1988)

NOTE: This section of MACH was formerly section 4.2.5 or 4.2.6 of the UNTDID
0 Foreword
The United Nations Standard Message types, UNSMs, are intended for both national and international electronic data interchange applications. The development work is undertaken by the UN/EDIFACT Rapporteur teams with representation from interested UN/ECE Working Party No. 4 (WP.4) members. Known Electronic Data Interchange (EDI) messages that are in operation or in development are taken into consideration. The term Message is also known in other standards as a Transaction Set. The UN/ECE Working Party No. 4 on Facilitation of International Trade Procedures, UN/ECE/TRADE/WP.4 is responsible for the registration and maintenance of UNSMs and their supporting material. Rapporteurs are appointed by WP.4 and function under WP.4/GE.1 (Meeting of Experts on Data Elements and Automatic Data Interchange). They are responsible for the development and maintenance of UNSMs and the material submitted to GE.1 for approval. The basis for all messages is a set of interdependent documents which are required in order to interpret, understand and use UNSMs. These documents are listed and briefly defined in Section 1 - "References" of this chapter. More information about the UN/ECE/WP.4 and the development structure can be found in the "UN/EDIFACT How and Why Handbook" which is available from the UN/ECE Secretariat (Palais des Nations, CH-1211 Geneva 10, Switzerland) or from Regional UN/EDIFACT Board secretariats.
1 References
The following interdependent documents, which are included in the "United Nations Trade Data Interchange Directory (UNTDID) or STANDARD directories, as well as in the DRAFT directories are required in order to interpret, understand and use UN/EDIFACT messages. UN/EDIFACT Data Elements Directory (EDED), a subset of the United Nations Trade Data Elements Directory (UNTDED) (ISO 7372) (Part 5,chapter 5) UN/EDIFACT Consolidated Code List (UNCL), a list of all code sets associated with coded data elements (Part 5, chapter 6) UN/EDIFACT Composite Data Elements Directory (EDCD), with their component data elements (Part 5, chapter 4) UN/EDIFACT Standard Segments Directory (EDSD), which contains a full description of all standard segments used in UNSMs (Part 5, chapter 3) UN/EDIFACT Directory of UNSMs (EDMD), which contains a full description of all United Nations Standard Message Types (Part 5, chapter 2) UN/EDIFACT Syntax Rules (ISO 9735), which define in concise form the standard for formatting data elements and segments into messages (Part 4, chapter 2.2)
87
UN/EDIFACT Syntax Implementation Guidelines, which expand on some of the details of the syntax rules (Part 4, chapter 2.3) UN/EDIFACT Message Design Guidelines, intended for message designers (Part 4, chapter 2.4) The Internal Organization of the Work of the UN/EDIFACT Rapporteurs (TRADE/WP.4/R.785), which includes in Appendix 1 the procedures for modifying UNSMs
2 Terms and Definitions

The formal definitions relating to the syntax rules are found in the UN/EDIFACT Syntax Rules (ISO 9735). The following clarifications are consistent with the formal definitions, and are provided to aid in the understanding of the message.
2.1 Message
A UNSM is a collection of information, that is exchanged to convey information related to a specific transaction between the partners engaged in EDI. Messages are composed of logically grouped segments required for the type of message transaction covered.
2.2 Segment
A segment is the intermediate unit of information in a message. A segment consists of a predefined set of functionally related data elements which are identified by their sequential positions within the set. A segment begins with a segment identifier, a unique three alphabetic upper case code which uniquely identifies each segment, and ends with a segment terminator.
2.3 Segment Status (Requirement Designator)

The status of a segment in a specific message type may be: Mandatory (M) - This segment must be used in the message Conditional (C) - This segment will be used in the message dependent on certain conditions. The relevant conditions for required occurrence of the segment must be given as part of the message definition. If no conditions are specified then the segment may be used subject to agreement between trading partners, or at the option of the message originator.
2.4 Segment Sequence

Segments have specific places in a message and the same segment type may occur more than once in a message. Segments may occur in any of the following three sections of the message: Header Section - A segment occurring in this section relates to the entire message. Detail Section - A segment occurring in this section relates to the detail information only and will override any similar specification in the header section. Summary Section - Only segments containing totals or control information may occur in the summary section, e.g. invoice totals, overall discount, etc.
2.5 Maximum Use of Segments

88
Some segments may be repeated a number of times at their specific locations in the message structure. The status (requirement designator) and maximum number of repetitions of a type of segment are indicated in the Segment Table and in the Branching Diagram.
2.6 Group of Segments (Loops)

Within a message, specific groups of functionally related segments may be repeated; these segment groups are referred to as loops. The maximum number of repetitions of a particular loop at a specific location is indicated in the message Segment Table and in the Branching Diagram. A group of repeating segments (a loop) may be nested within other loops, provided that the inner loop terminates before any outer loop terminates.
2.7 Data Elements

A Data Element is the smallest unit of information in a segment. Their descriptions and usage are defined in the UN/EDIFACT Data Element Directory (EDED). Two or more data elements may be grouped together to form a composite data element. The data elements forming a composite data element are data elements in their own right and are included in UNTDED. They are referred to as components in the Composite Data Elements Directory (EDCD). The use of data elements in a segment is defined in the UN/EDIFACT Data Segment Directory (EDSD). The status of a data element in a segment may be: Mandatory - This data element must be used in the segment. Conditional - This data element will be used in the segment dependent on certain conditions. The relevant conditions for required occurrence of the data element may be given as part of the segment definition. If no conditions are specified then the data element may be used subject to agreement between trading partners, or at the option of the message originator.
The segments in the Segment Directory are designed for use in a wide range of message types. This means that in some message types one or more conditional data elements or composite data elements in a segment may not be used.
2.8 Qualifiers
A data element whose function is to give a more precise meaning to another data element is referred to as a qualifier. The data value of a qualifier is a code taken from it's associated code set. The code sets are part of the UN/EDIFACT Code Lists (EDCL).
2.9 Data Element Format Notation

The UNTDED notation is used to indicate the data type and length of each data element. a3 3 alphabetic characters, fixed length
89
n6 an5 a..6 an..35 n..9
numeric characters (numbers), fixed length 5 alphanumeric characters, fixed length up to 6 alphabetic characters up to 35 alphanumeric characters up to 9 numeric characters (number)
In addition, the following notation is used: Datatype: a n an id alphabetic numeric alphanumeric alphabetic, numeric or alphanumeric identifier
2.10 Numeric Data Elements

Data element values shall be regarded as positive. Although conceptually a deduction is negative, it shall be represented as a positive value and such cases shall be indicated in the data element directory. If a data element is to be indicated to be negative (in relation to it's concept), it shall in the message be preceded by a minus sign e.g. -112. The minus sign and the decimal mark (comma or point) are not counted in the number of characters of the data element format. The representation of numeric data elements specifies maximum lengths without specifying the position of any appropriate decimal mark. To assist in-house file designers and data interchange partners who prefer to specify a precise number of decimals, the following lengths may be used as a guideline. Numeric Class Weights Cubes Quantities Unit prices Amounts Currency rates Percentages Tax rates Repr: Digits n..15 n..9 n..15 n..15 n..18 n..12 n..7 n..7 Integer Digits 12 5 12 11 15 6 3 3 Decimals
3 4 3 4 3 6 4 4
3 Message Structure
The message structure section is provided for each UNSM to clarify and further explain the usage of the segments within the message structure. Segments are functionally defined to be applicable over a wide range of messages. However, restrictions may apply according to the function of the segment within the structure. A UNSM is designed to be used in and across different industries and applications for both national and international exchange. To meet these requirements several segments and segment groups are defined as conditional. It is important, therefore, that users intending to use the message first study each conditional segment and segment group to decide which are necessary for their particular application.
90
To illustrate message structure there will be both a branching diagram and a segment table, with loops showing the segments in the message type, their sequence, status, repetitions allowed, nestings and groupings. In the branching diagram, the sequence of the segments is top-to-bottom and left-to-right. A segment is indicated by ist three-letter tag and underneath its status, Mandatory (M) or Conditional (C), and allowed number of occurrences. Groups of segments are represented by boxes showing a unique group number, ist status and the maximum number of allowed occurrences of the group. All segments and groups within a group box, belong to that group. In the segment table, the segments are listed in the order of occurrence in the message . They are identified by their tags and names. In addition the status Mandatory (M) or Conditional (C) is stated together with the number of times each may be repeated at that occurrence. A mandatory segment must appear at least once. Each segment group has a number and an indication of M or C together with a number indicating the number of times the group may appear within the message or within another group. In the segment table loop lines indicate the segments within the group, its beginning and its end. A segment group must contain at least one mandatory segment which must be the first segment in the segment group. Segment Group Example: --Segment Group 1 ------- M 5 ---------! AAA Segment Name M 1 ! ! --Segment Group 2 ------- C 10 ----! ! CCC Segment Name M 1 ! ! DDD Segment Name C 5 -------------!---! Group 1 which must occur at least and may occur up to 5 times and contains: AAA which must occur at least once for each Group 1 occurrence, and BBB which may occur up to 5 times for each Group 1 occurrence, and Group 2 which is nested in Group 1 and which may occur up to 10 times for each Group 1 occurrence and contains CCC which must occur at least once for each Group 2 occurrence, and DDD which may occur up to 5 times for each Group 2 occurrence.
4 Interchange Structure
In an interchange the Service String Advice, UNA, and the service segments UNB to UNZ shall appear in the following order: Service String Advice Interchange Header Functional Group Header Message Header User Data Segments Message Trailer Functional Group Trailer Interchange Trailer UNA Conditional UNB Mandatory Conditional Mandatory As required Mandatory Conditional UNZ Mandatory
UNG UNH UNT UNE
91
In addition to the above service segments, the service segment UNS can, when required, be used to divide a message into sections. There may be several functional groups or messages within an interchange and several messages within a functional group.
92
----------------------------------------|Establishment |CONNECTION| Termination | A CONNECTION contains one --------------------|-------------------- or more interchanges. The | technical protocols for | for establishment | maintenance and | termination etc.are not +-------------------+-------------------+ part of this standard. | | ----------------------------------------|Interchange |INTERCHANGE |Interchange | An INTERCHANGE contains: -------------------|--------------------- - UNA, Service string | advice, if used | - UNB, Interchange header | - Either only Functional | groups, if used, or | only Messages | .....--------------+--------------------+ - UNZ, Interchange trailer . | | ----------------------------------------|UNA|UNB|'| Either |or only |UNZ|'| A FUNCTIONAL GROUP contains | | | |FUNCTION.GRPS|MESSAGES | | | - UNG, Functional group -----------------|----------.-----------header | . - Messages of the same | . type +----------------+----------.-----------+ - UNE, Functional group | +........+..+ | trailer | . . | ----------------------------------------|UNG |'|Message |MESSAGE |Message |UNE|'| A MESSAGE contains: --------------------|-------------------- - UNH, Message header | - Data segments +-------------------+-------------------+ - UNT, Message trailer | | ----------------------------------------|UNH |'|Data |DATA |Data |UNT|'| A SEGMENT contains: | | |segment |SEGMENT |segment | | | - A Segment TAG -------------------|--------------------- - Simple data elements or | - Composite data elements +------------------+-------------------+ or both as applicable | | ---------------------------------------|TAG |+|SIMPLE |+|COMPOSITE |'| A SEGMENT TAG contains: | | |DATA ELEMENT | |DATA ELEMENT | | - A segment code and, ---|--------------|----------|-----|---if explicit indication, | | | | repeating and nesting | | | | value(s). See 8.1 and 9. | | | | | | | | A SIMPLE DATA ELEMENT contains -------------------------------- A single data element |Code|:|Value| |Value| |COMP|:|COMP| value -------------------|D/E | |D/E | A COMPOSITE DATA ELEMENT | | | | contains: --|------|--- Component data elements | | ------- ------- A COMPONENT DATA ELEMENT | | | | contains: |Value| |Value| - A single data element ------- ------value --.---|-. means alternative to |
Figure 1 Hierarchical structure of an interchange
93
UNA, UNB, UNZ, UNG, UNE, UNH and UNT are Service segmnets, see 6.1 and Annex B. In the diagram, the level A separators/terminators have been used (see EDIFACT Syntax rules, ISO 9735 section 5.1).
94
Appendix I : Acronyms Commonly Found in AFACT Materials

ANSI AFACT ANZEB ASEB CALS CDT CEEB CEFACT CSG CTIED DAT DISA EBES EC ECE ECOSOC EDI EEMA EFTA E-mail ESCAP ESCWA Forum GE.1 GE.2 IAPH IATA IEC IFIA ISO ITT JWG MDRG NATPRO PAEB American National Standard Institute Asia Pacific Council for Trade Facilitation and Electronic Business Australia/New Zealand EDIFACT Board Asia EDIFACT Board Continuous Acquisition Life Cycle Support Committee on Development and Trade Central and Eastern European EDIFACT Board See UN/CEFACT CEFACT Steering Group Committee for Trade, Industry and Enterprise Development Directory Audit Team Data Interchange Standard Association (USA) European Board for EDI/EC Standardization Electronic Commerce Economic Commission for Europe UNs Economic and Social Commission Electronic Data Interchange European Electronic Messaging Association European Free Trade Association Electronic Mail Economic and Social Commission for Asia and the Pacific Economic and Social Commission for Western Asia See UN/CEFACT Forum Group of Experts on Data Elements and Automatic Data Interchange Group of Experts on Procedures and Documentation International Association of Ports and Harbours International Air Transport Association International Electrotechnical Commission International Federation of Inspection Agencies International Organization for Standardization International Trade Transactions Joint Working Group Message Design Rules Group North American Trade Procedures Organization Pan American EDIFACT Board
95
S.W.I.F.T. SDG UN/CEFACT UN/EDIFACT UN/LOCODE UNCITRAL UNCTAD UNLK WCO WEEB WP.4 WTO WWW
Society for Worldwide Interbank Financial Telecommunications Syntax Development Group United Nations Center for Trade Facilitation and Electronic Business UN Electronic Data Interchange for Administration, Commerce and Transport UN Location Code United Nations Commission on International Trade Law United Nations Conference on Trade and Development United Nations Layout Key World Customs Organization Western European EDIFACT Board Working Party on Facilitation of International Trade Procedures World Trade Organization World Wide Web
96
APPENDIX II: BROCHURE ON UN/CEFACT
UN/CEFACT
United Nations Centre for Trade Facilitation and e-Business
An International Private-Public Sector Partnership
97
Our Mission: To improve the ability of business, trade and administrative organizations, from developed, developing and transitional economies, to exchange products and relevant services effectively -- and so contribute to the growth of global commerce. Our Focus: The facilitation of international transactions, through the simplification and harmonisation of procedures and information flows.
Who Are We? UN/CEFACT is the UN's Centre for Trade Facilitation and e-Business (Its name was originally called as UNs Centre for Facilitation of Procedures and Practices for Administration, Commerce and Transport when it was re-organized from UNECE/WP.4 in March 1997, but its name was changed to the current one as its acronym is unchanged.) It is open to participation from UN member states, inter-governmental organizations, and sectoral and industry associations recognised by the UN's Economic and Social Commission (ECOSOC). The Centre's objective is to be "inclusive" and not "exclusive" so it actively encourages organizations who use its recommendations and standards to take part in their creation. The participation of many private sector associations in CEFACT's work at the policy level, and of hundreds of private sector technical experts in CEFACT working groups, is a unique feature of the Centre, forging new cooperative relationships between private business and intergovernmental organizations. Within the UN system, CEFACT is located in the Economic Commission for Europe (ECE) which is part of the UN's network of Regional Commissions. These Regional Commissions report to the highest UN body in the area of economics and development: ECOSOC. This is the ideal location for developing practical recommendations for action, because within the UN system and their work areas, the Regional Commissions have the closest links to national governments at the expert level. History Two-thirds of world trade originates from the UN Economic Commission for Europe's (ECE's) region, i.e. Europe and North America -- the region which also pioneered the reduction of tariff barriers to trade internationally. With reduced tariff barriers came a realization of the importance of procedural trade barriers, a great interest in seeing procedural barriers reduced or eliminated, and the beginning of significant work in this area by the ECE in the late 1960s. This work has resulted in trade facilitation techniques, recommendations and norms which have been implemented across the world. As a consequence, the ECE has developed a centre of excellence in trade facilitation within the UN system and, today, over 1500 private and public sector experts participate in the work. CEFACT was established by the ECE in early 1996 in response to new technological developments, a desire to officially recognise the contributions made by the above mentioned experts (many of whom come from outside the ECE region), and the need to make better use of available resources.
98
CEFACT - Expanding Global Commerce
Free trade agreements, while a necessary condition, are not sufficient to guarantee continued growth in world trade. Sustainable growth can only be accomplished by increasing the participation of small and medium sized enterprises in international trade. For this to happen, international trade must be easier and simpler, i.e. progress needs to be made in reducing and harmonizing the cumbersome and time-consuming paperwork, formalities and procedures often required for international trading. This is the facilitation of administration, commerce and transport -- and it is CEFACT's goal. Reducing Bureaucracy and Increasing Transparency While CEFACT does considerable work in the harmonization and simplification of documents and data formats, these are only the tip of an iceberg. The real problems are administrative and commercial procedures which are based upon the information requirements of each party and the way in which information is transferred between those parties. To attack the problem of cumbersome and difficult procedures, CEFACT: - analyzes the key elements in international transactions; - identifies the constraints that effect them; and - develops recommendations to eliminate identified constraints and harmonize remaining procedures;
Improving data flows via electronic commerce Facilitating business and administration requires more than just identifying the minimum data requirements, one must also examine the best methods for transmitting the data. In this area, CEFACT analyzes the use of information and electronic commerce technologies in order to develop recommendations and, where appropriate, methodologies and tools.
Lowering transaction costs To actually reduce transaction costs, it is not enough to understand the problem and present solutions -- those solutions must be implemented. Since procedures are frequently linked to administrative requirements, implementing often requires cooperation between governments and the private sector. CEFACT therefore works through government, industry and service association channels, as well as its delegations, to promote and implement facilitation recommendations, tools, and associated best practices.
Developing a network of supporting institutions To increase its effectiveness, CEFACT actively co-ordinates with other international organizations such as the World Trade Organization (WTO), the World Customs
99
Organization (WCO), the UN Conference on International Trade Law (UNCITRAL) and the UN Conference on Trade and Development (UNCTAD). Many of these organizations also participate directly in CEFACT's work. In addition, since it's work has broad applications beyond global trade, CEFACT recognizes the need to secure coherence, particularly in its electronic commerce methods. To do this, it meets regularly with other interested parties, such as the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). To enlarge its "local" impact, CEFACT actively supports the establishment of national trade facilitation organizations.
Improving Private and Public Sector Management In summary, CEFACT's overall goal is to improve the collection, management and exchange of trade and transaction data -- i.e. information that is essential to the management of national economies as well as individual companies and organizations.
100
CEFACT Recommendations, Tools and Methodologies
The UN Layout Key Improving Data Flows in Traditional Trade as well as on the Information Super Highway
Most of the international trade documents used throughout the world today are designed in conformity with what is called the "United Nations Layout Key" (UNLK), another CEFACT development. This standardization allows the use of rationalized methods for document preparation where information is typed only once for a full set of export documents. Today, as a reflection of the increasing automation of trade data flows, the UNLK is also used by information systems either for the conversion of data records to printed output or in the screen displays used for data entry. CEFACT has not forgotten that much of the world's trade and data exchange still takes place on paper (even if the data comes from or is eventually stored on a computer). Therefore, it continues to develop recommendations for the best use of the UN Layout Key in the design of specific documents such as invoices, purchase orders and the dangerous goods declarations used in international transport.
Trade Facilitation Recommendations Reducing Bureaucracy, Harmonizing Data and Improving Information Flows There are thirty-three CEFACT Trade Facilitation Recommendations. Five of these recommendations have become International Organization for Standardization (ISO) standards. All (except two, which are maintained by ISO) are reviewed and updated on an ongoing basis. Some of these recommendations have as their purpose reducing the complexity of existing procedures, while others strive to harmonize transaction data or the methods used for transmitting that data. (See Appendix VI List of UN/CEFACT Recommendations.) Among CEFACT's Trade Facilitation Recommendations are: - UN/LOCODE; a unique international code for locations in international trade which is widely used in the transport and tourism industries. - Facilitation Measures Related to International Trade Procedures; a series of measures which governments should consider implementing, each measure outlining the procedures and documents covered as well as the problems for which solutions are proposed. - PAYTERMS; abbreviations for terms of payment. - Transport Status Codes; codes to harmonize information exchanged on the statusof consignments, goods or means of transport at a certain time or place in the transport chain. - National Trade Facilitation Organizations; guidelines for establishing national organizations or committees to encourage the implementation of trade facilitation measures.
101
Because of their particular importance on a global level, Trade Facilitation Recommendation 1, on the UN Layout Key, and Recommendation 25, on the use of UN/EDIFACT, have been approved and endorsed by the UN Economic and Social Council as a global UN Recommendations.
UN/EDIFACT - Improving Data Flows On the Information Superhighway Today, exchanging information rapidly and accurately between companies, and even between countries, is indispensable if one is to be competitive. Developed and maintained by CEFACT, UN/EDIFACT (UN Electronic Data Interchange for Administration, Commerce and Transport) provides the essential rules for data exchange, particularly when data needs to be processed by more than one organization or exchanged at minimum cost. For the information superhighways of electronic commerce, UN/EDIFACT provides important "rules of the road" -- especially for the fast lane. Electronic Commerce (EC) combines existing and new technologies and this combination changes the way organizations do business. Electronic mail (e-mail), the World Wide Web (WWW) and Electronic Data Interchange (EDI) are the most important EC technologies. EDI is the exchange of structured data between computer applications, using agreed rules. It is indispensable to the automated exchange of large volumes of data and the implementation of modern management techniques such as just-in-time manufacturing or inventory management. UN/EDIFACT is the international standard for EDI. All of these EC technologies can be used over the Internet, as well as networks based on Internet technology such as internal Intranets and closed group Extranets. Additionally, email and EDI can be implemented among users of almost any private or public sector network. EDI is widely used by companies around the world, but is seldom mentioned in the popular press. This is because consumers do not "see" EDI or even know when they are using it. For example, someone who fills out a form displayed on the WWW only sees the WWW and the form -- not the software application behind the form. Whether that software uses the entered data directly, or creates and sends an EDI message, is not important to the consumer. But there are clear advantages to EDI for the organization receiving this data: increased security, the ability to combine the consumer's data with large data volumes coming in EDI formats from corporate accounts, and greater ease in exchanging data with third parties. UN/EDIFACT helps the organizations that use EDI to harmonize their data across national, sectoral and organizational frontiers -- independently of their hardware or software choices. As a common, internationally agreed standard, it is also politically neutral, which can be important when communicating data with a wide variety of partners.
CEFACT - A Centre of Competence The CEFACT secretariat as well as its delegates and participating technical experts
102
have developed an expertise in the area of trade facilitation unrivalled by any organization. A Trade Facilitation Information Hub Through its publications, annual CD-ROM and extensive Internet resource site, CEFACT offers a global hub for the collection and dissemination of trade facilitation information, advice, guidance and models. A Focal Point for Coordinating Technical Work One of the strongest points of CEFACT as an organization is its ability to coordinate the work of interested experts on a global level.
Who Uses CEFACT's Work? Many industrial sectors and associations including: the international electronics industry (including companies like IBM, Hewlett-Packard and Digital Equipment), the International Air Transport Association (IATA) and the International Article Numbering Association (EAN); the Society for Worldwide Interbank Financial Telecommunications (S.W.I.F.T.) for communications between banks and non-bank organizations; National statistical administrations and central banks throughout Europe, and the world, for the exchange of statistical data between themselves and with organizations like Eurostat, the International Monetary Fund and the Bank for International Settlements. Well over 50 national administrations in customs, transport, and a variety of other administrative areas such as healthcare, social security and Value-Added Tax declarations, examples being: Australia, Belgium, France, India, Korea, Malaysia, the Netherlands, Romania, Russia, Singapore, Sweden, the United Kingdom, the United States, and Zimbabwe;
To Obtain the Greatest Benefit from CEFACT's Work: Join Us While the results of CEFACT's work are publicly available to use and benefit all governments and organizations, full advantage can only be gained by taking part in the work. Some of the advantages to be gained by participating are: a thorough understanding of the reasoning behind recommendations, as well as variations on their implementation; assurance that your national situation and the needs of your organization have been taken into full consideration; advance information about what other countries and organizations are planning or implementing.
103
For More Information: For further information on CEFACT's ongoing work, refer to our Internet WWW address: http//www.unece.org/trafix/ For information on how you, or your organization, could participate in the work -- as well as any other questions -- please contact the secretariat at: CEFACT UN Economic Commission for Europe Palais des Nations, Rm. 442 1211 Geneva 10 Switzerland Telephone: 41 22 917 2773 Telefax: 41 22 917 0037 E-mail: CEFACT@unece.org
104
APPENDIX III : GROSSARY/DEFINITION RELATING TO UN/EDIFACT Grossary/Definition relating to UN/EDIFACT
(Source ISO 9735 V3.0)

NOTES: 1. When a word or phrase appears in italics within a definition, this means that a definition exists in this annex for this word or phrase. 2. The terms are classified alphabetically; an identifier is added at the end of each definition, in square brackets, to facilitate the comparison between different linguistic versions. For example the English term "Alphabetic character set" is called in French "Jeu de caracteres alphabetique", and will not appear at the same alphabetic place in the two versions of the syntax; the identifier in brackets shall nevertheless remain "[ 1 ]". 3. Where ISO standards are referenced, the definitions have been taken from the referenced standard.
A.1
alphabetic character set: A character set that contains letters and/or ideograms, and may contain other graphic characters except digits. [ 1 ] alphanumeric character set: A character set that contains letters, digits and/or ideograms, and may contain other graphic characters. [ 2 ] asymmetric algorithm: A cryptographic algorithm employing a public key and a private key. Together these form an asymmetric key set. [ 3 ] attribute: A characteristic of an entity. [ 4 ] authentication: See data origin authentication. [ 5 ] batch EDI: electronic data interchange in which no strong requirements exist for formalised data exchange using query and response between the parties. [ 6 ] business: A series of processes, each having a clearly understood purpose, involving more than one organisation, realised through the exchange of information and directed towards some mutually agreed upon goal, extending over a period of time. [ 7 ] certificate: The public key of a user, together with some other information, rendered unforgeable by a signature with the private key of the certification authority which issued it. (ISO/IEC 9594-8) [ 8 ] certification authority: An authority trusted by one or more users to create and assign certificates. (ISO/IEC 9594-8) [ 9 ] certification path: An ordered sequence of certificates of objects in the Directory Information Tree which, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path. (ISO/IEC 9594-8) [ 10 ]
A.2
A.3
A.4 A.5 A.6
A.7
A.8
A.9
A.10
105
A.11
character: A member of a set of elements used for the organisation, control, or representation of data. (ISO/IEC 10646-1) [ 11 ] character repertoire: The set of graphic characters of a coded character set, considered independently of its encoding. [ 12 ] code extension: The techniques for the encoding of characters that are not included in the character repertoire of a given coded character set. [ 13 ] code list: The complete set of data element values of a coded simple data element. [ 14 ] code list directory: A listing of identified and specified code lists. [ 15 ] coded character set: A set of unambiguous rules that establishes a character set and the one-to-one relationship between the characters of the set and their bit combinations. (ISO/IEC 6429) [ 16 ] component data element: A simple data element used within a composite data element. [ 17 ] component data element separator: A service character used to separate the component data elements within a composite data element. [ 18 ] composite data element: An identified, named and structured set of functionally related component data elements, as described in a composite data element specification. In transfer, a composite data element is a specific ordered set of one or more component data element(s) in conformance with a composite data element specification. [ 19 ] composite data element directory: A listing of identified and named composite data elements with their composite data element specification. [ 20 ] composite data element specification: The description of a composite data element in a composite data element directory, including the specification of the position and status of the component data elements constituting the composite data element. [ 21 ] conditional: A type of status, used in a message specification, segment specification, or composite data element specification, to specify that a segment group, segment, composite data element, stand-alone data element or component data element is used optionally or when the appropriate conditions occur. [ 22 ] confidentiality: The property that information is not made available or disclosed to unauthorized individuals, entities or processes. (ISO 7498-2) [ 23 ] control character: A character whose occurrence in a particular context specifies a control function. (ISO 2382-4) [ 24 ] credential: Data that serves to establish the claimed identity of an entity. (ISO 7498-2) [ 25 ] cryptography: The discipline which embodies principles, means, and methods for the transformation of data in order to hide its information content, prevent its undetected modification and/or prevent its unauthorized use. (ISO 7498-2) [ 26 ]
106
A.12
A.13
A.14
A.15 A.16
A.17
A.18
A.19
A.20
A.21
A.22
A.23
A.24
A.25
A.26
A.27
data: A reinterpretable representation of information in a formalised manner suitable for communication, interpretation or processing. (ISO/IEC 2382-1) [ 27 ] data element: A unit of data described in a data element specification. There are two classes of data element: simple data elements and composite data elements. [ 28 ] data element directory: A listing of identified, named and specified simple data elements (simple data element directory) or composite data elements (composite data element directory). [ 29 ] data element separator: A service character used to separate from each: - non repeating stand-alone data elements; or - composite data elements in a segment; or - a set of occurrences of a repeating data element; or - a null set of occurrences of a repeating data element, where a set of occurrences of a repeating data element is a repeating data element having one or more of its occurrences (up to a maximum specified number) present in a transfer; and where a null set of occurrences of a repeating data element is a repeating data element for which none of its specified occurrences are present in a transfer. [ 30 ] data element specification: The specification of a composite data element in a composite data element directory (composite data element specification), or of a simple data element in a simple data element directory (simple data element specification). [ 31 ] data element value: A specific instance of a simple data element, represented as specified in a simple data element specification and, if the simple data element is coded, in a code list. [ 32 ] data integrity: The property that data has not been altered or destroyed in an unauthorised manner. (ISO 7498-2) [ 33 ] data origin authentication: The corroboration that the source of data received is as claimed. (ISO 7498-2) [ 34 ] data value representation: The types of characters allowed (e.g. alphabetic, numeric) and conditions of length relating to the data element values of a simple data element. [ 35 ] decimal mark: The character that separates the digits forming the integral part of a number from those forming the fractional part. (ISO 6093) [ 36 ] decipherment: The reversal of a corresponding reversible encipherment. (ISO 7498-2) [ 37 ] decryption: See decipherment. (ISO 7498-2) [ 38 ] default service characters: The set of characters used as service characters in circumstances where a different set is not defined in the service string advice. [ 39 ]
107
A.28
A.29
A.30
A.31
A.32
A.33
A.34
A.35
A.36
A.37
A.38 A.39
A.40
dependency identifier: An identifier used in a dependency note to specify the type of dependency between the entities listed in the dependency note. [ 40 ] dependency note: A note used: i. in a message specification to express relationships between segment groups or between segments; ii. in a segment specification to express relationships between data elements; iii. in a composite data element specification to express relationships between component data elements. [ 41 ] dialogue: A two-way conversation between an initiator and responder within an IEDI transaction. It is formally composed of a pair of interchanges. [ 42 ] digital signature: Data appended to, or a cryptographic transformation (see cryptography) of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient. (ISO 7498-2) [ 43 ] EDI (Electronic Data Interchange): The electronic transfer from computer application to computer application of commercial or administrative transactions using an agreed standard to structure the transaction or message data. [ 44 ] encipherment: The cryptographic transformation of data (see cryptography) to produce ciphertext. (ISO 7498-2) [ 45 ] encoding: The representation of a character as a bit combination. [ 46 ] encryption: See encipherment. (ISO 7498-2) [ 47 ] exponent mark: A control character used to indicate that the character(s) that follow it are to be interpreted as an exponent. E or e is the exponent mark. [ 48 ] filtering: The process by which octets containing arbitrary bit patterns are converted to octets belonging to the character set which the underlying syntax is capable of supporting. [ 49 ] graphic character: A character, other than a control character, that has a visual representation and is normally produced by writing, printing or displaying. (ISO 2382-4) [ 50 ] group: A group of messages (of one or more message types) and/or packages (each containing an object), headed by a group header and ending with a group trailer. [ 51 ] group header: The service segment heading and identifying a group. [ 52 ] group trailer: The service segment ending a group. [ 53 ] hash function: A (mathematical) function which maps values from a large (possibly very large) domain into a smaller range. A 'good' hash function is such that the results of applying the function to a (large) set of values in the domain will
108
A.41
A.42
A.43
A.44
A.45
A.46 A.47 A.48
A.49
A.50
A.51
A.52 A.53 A.54
be evenly distributed (and apparently at random) over the range. (ISO/IEC 95948) [ 54 ] A.55 I-EDI (Interactive EDI): The exchange of pre-defined and structured data within a dialogue, which conforms to the syntax of Parts 1 and 3 of ISO 9735 for some business purpose, between a pair of co-operating processes, in a timely manner. [ 55 ]
A.56 I-EDI transaction: An instance of a scenario. It consists of one or more dialogues. [ 56 ] A.57 identifier: A character or group of characters used to identify or name an item of data and possibly to indicate certain properties of that data. [ 57 ] ideogram: In a natural language, a graphic character that represents a concept and associated sound elements. Example; A Chinese ideogram or a Japanese Kanji. [ 58 ] initiator: The application which starts the dialogue and/or I-EDI transaction. [ 59 ] integrity: See data integrity. [ 60 ] interchange: A sequence of messages and/or packages, of the same or of different types, starting with the interchange header (or with the service string advice if used), and ending with the interchange trailer. [ 61 ] interchange header: The service segment starting and uniquely identifying an interchange. [ 62 ] interchange trailer: The service segment ending an interchange. [ 63 ] key: A sequence of symbols that controls the operations of encipherment and decipherment. (ISO 7498-2) [ 64 ] mandatory: A type of status, used in a message specification, segment specification, or composite data element specification, to specify that a segment group, segment, composite data element, stand-alone data element or component data element shall be used at least one time. [ 65 ] message: An identified, named and structured set of functionally related segments, covering the requirements for a specific type of transaction (e.g. invoice), as described in a message specification; a message starts with a message header and ends with a message trailer. In transfer, a message is a specific ordered set of segments in conformance with a message specification. [ 66 ] message body: An identified, named and structured set of functionally related segments, covering the requirements for a specific type of transaction (e.g. invoice), as described in a message specification, excluding the message header and the message trailer. [ 67 ] message directory: A listing of identified and named messages each with its message specification. [ 68 ]
109
A.58
A.59 A.60 A.61
A.62
A.63 A.64
A.65
A.66
A.67
A.68
A.69
message header: The service segment starting and uniquely identifying a message. [ 69 ] message specification: The description of a message in a message directory, including the specification of the position, status and maximum number of occurrences of the segments and segment groups constituting the message. [ 70 ] message trailer: The service segment ending a message. [ 71 ] message type: Code identifying a type of message . [ 72 ] non-repudiation of origin: This element of service allows the originator of a message to provide the recipient(s) of the message irrevocable proof of origin of the message and the integrity of its content. This will protect against any attempt by the originator to subsequently revoke the message or its contents. Non-repudiation of origin is provided to the recipient(s) of a message on a per-message basis using asymmetric encryption techniques. (ITU-T F.400/X.400, Amendment 1) [ 73 ] numeric character set: A character set that contains digits and may contain control characters and special characters but not letters. (ISO 2382-4) [ 74 ] object: A stream of bits grouped in octets (which may be associated with an EDIFACT message). [ 75 ] object header: The service segment starting and uniquely identifying an object. [ 76 ] object trailer: The service segment ending an object. [ 77 ] organisation: A unique framework of authority within which a person or persons act, or are designated to act, towards some purpose. (ISO 6523) [ 78 ] package: An object plus its associated header and trailer segments. [ 79 ] parent-child relationship: A relationship between two entities, one ("child") being contained within and directly subordinated to the other ("parent"). [ 80 ] position identifier: An identifier used in a dependency note to identify an entity (segment group, segment, or data element) by its position in the parent entity. [ 81 ] private key: (In a public key cryptosystem) that key of a user's key pair which is known only by that user. (ISO/IEC 9594-8) [ 82 ] public key: (In a public key cryptosystem) that key of a user's key pair which is publicly known. (ISO/IEC 9594-8) [ 83 ] qualifier: A simple data element whose data element value, extracted from a code list, gives specific meaning to the function of another data element or a segment. [ 84 ]
110
A.70
A.71 A.72 A.73
A.74
A.75
A.76
A.77 A.78
A.79 A.80
A.81
A.82
A.83
A.84
A.85
release character: A character indicating that the character immediately following it shall be passed to the application as received. [ 85 ] repeating data element: A composite data element or stand-alone data element having a maximum occurrence of greater than one in the segment specification. [ 86 ] repetition separator: A service character used to separate adjacent occurrences of a repeating data element. [ 87 ] responder: An application replying to an initiator. [ 88 ] scenario: A formal specification of a class of business activities having the same business goal. [ 89 ] secret key: a key used with symmetric cryptographic techniques and usable only by a set of specified entities. (ISO/IEC 11770-1) [ 90 ] segment: An identified, named and structured set of functionally related composite data elements and/or stand-alone data elements, as described in a segment specification; a segment starts with the segment tag and ends with the segment terminator. In transfer, a segment is a specific ordered set of one or more composite data element(s) and/or stand-alone data element(s) in conformance with a segment specification and the syntax rules for transfer. [ 91 ] segment directory: A listing of identified and named segments with their segment specification. [ 92 ] segment group: An identified hierarchical set of segments and/or segment groups within a message. [ 93 ] segment specification: The description of a segment in a segment directory, including the specification of the position, status and maximum number of occurrences of the data elements constituting the segment. [ 94 ] segment tag: A simple data element uniquely identifying a segment, by reference to a segment directory. [ 95 ] segment terminator: A service character indicating the end of a segment. [ 96 ] service character: A character reserved for syntactical use; the service characters are the component data element separator, the data element separator, the release character, the repetition separator and the segment terminator. [ 97 ] service composite data element: A composite data element used in service segments. A service composite data element specification contains only service simple data elements. [ 98 ] service data element: A service simple data element or a service composite data element. [ 99 ]
A.86
A.87
A.88 A.89
A.90
A.91
A.92
A.93
A.94
A.95
A.96 A.97
A.98
A.99
111
A.100 service message: A message used to exchange service information relating to the use of EDIFACT syntax rules or security. A service message specification contains only service segments. [ 100 ] A.101 service segment: A segment used i. in service messages; ii. to control the transfer of data. A service segment specification contains only service composite data elements and/or service simple data elements. [ 101 ] A.102 service simple data element: A simple data element used only in service segments and/or service composite data elements. [ 102 ] A.103 service string advice: An optional string of characters used at the beginning of an interchange to specify the service characters used in the interchange. [ 103 ] A.104 simple data element: A data element containing a single data element value. There are two uses of a simple data element: within a composite data element (component data element); and within a segment outside a composite data element (stand-alone data element). [ 104 ] A.105 simple data element directory: A listing of identified and named simple data elements with their simple data element specification. [ 105 ] A.106 simple data element specification: The set of attributes characterising a simple data element in a simple data element directory. [ 106 ] A.107 special character: A graphic character that is not a letter, digit, or blank character, and usually not an ideogram. ( ISO 2382-4) [ 107 ] A.108 stand-alone data element: A simple data element used within a segment without being in a composite data element. [ 108 ] A.109 status: An attribute of a segment, a segment group, a composite data element or a simple data element identifying the rules for the presence or absence of the segment/data element in the usage of a message. The types of status are conditional and mandatory. [ 109 ] A.110 string: A sequence of elements of the same nature, such as characters, considered as a whole. (ISO 2382-4) [ 110 ] A.111 symmetric algorithm: A cryptographic algorithm employing the same value of key for both enciphering and deciphering or for both authentication and validation. [ 111 ] A.112 threat: A potential violation of security. (ISO 7498-2) [ 112 ] A.113 transfer: The communication of information from one partner to another. [ 113 ] A.114 trigger segment: The segment starting a segment group. [ 114 ]
112
Appendix IV : UN/CEFACT Open Development Process
UNITED NATIONS
E
Economic and Social Council
Distr. GENERAL TRADE/CEFACT/2005/5 29 April 2005 ENGLISH ONLY
ECONOMIC COMMISSION FOR EUROPE COMMITTEE FOR TRADE, INDUSTRY AND ENTERPRISE DEVELOPMENT Centre for Trade Facilitation and Electronic Business (UN/CEFACT)
Eleventh session, 20 23 June 2005 Item 3 of the provisional agenda
UN/CEFACT OPEN DEVELOPMENT PROCESS WORK ITEM
Submitted by the UN/CEFACT Forum Management Group
This document is for approval
GE.05-
Executive Summary
This document describes the Forum Management Group (FMG) proposal to enhance the Open Development Process (ODP), currently only covering the development of UN/CEFACT Technical Specifications, with additional procedures for developing other Standards, in order to ensure the openness, timeliness and applicability of all UN/CEFACT deliverables. The FMG will ensure that this enhanced version of the ODP covers approval, publication, implementation, user feedback, maintenance and procedures for both minor and major revisions. This document further updates the current Open Development Process for Technical Specifications in the light of the reorganization of the UN/CEFACT Forum following the tenth UN/CEFACT Plenary session in May 2004. The FMG believes that the Open Development Process is fundamental to UN/CEFACT's large and accelerating acceptance as a modern standardization organisation by the international community and by Electronic Business implementers (such as software developers) around the world. It is also considered vital for the maintenance of the technical quality and cross-industry compatibility that an Electronic Business platform requires.
UN/CEFACT Open Development Process

UN/CEFACT produces Standards and makes Recommendations for their usage. The Standards can be Business or Technical Specifications and can consist of a single part or multiple parts. They are intended for all implementers and end-users. They are unique in providing specifications for any business use or technical application independent of communication protocol, underlying operating systems and hardware platforms. In the past UN/CEFACT has defined an Open Development Process (ODP) for Technical Specifications only. Given the wide range of Standards UN/CEFACT is now producing, the FMG proposes to enhance the ODP to specify different procedures for each (part of a) UN/CEFACT Standard under the principles of the ODP. The Open Development Process is designed to involve all materially interested parties worldwide, in the creation and evolution of Standards in an open process. UN/CEFACTs goal is to produce Standards that are timely, technically excellent,
2
implementable on any platform, and relevant both to industry participants and to enduser communities. UN/CEFACTs Open Development Process is not revolutionary. It is evolutionary because it builds upon standards development processes already used by industry consortia and other standards developing organisations. Perhaps the most unique feature of this process is the use of iterative refinement and participation through the Internet, to build international consensus. The premise is that people are usually much better at reviewing and criticising a specification than they are at compiling a requirement list and writing a first working draft. UN/CEFACT's groups delegate that important task to small, dedicated editing groups that work with recognised experts.
Goals of the ODP

UN/CEFACT has five goals for developing Standards. They are: openness; worldwide participation; speed; compatibility; and technical excellence. Openness The Standard development process is open for anyone to provide comments at certain stages in the process. The resulting Standards must be open as well. That means: free of any constraints or restrictions associated with intellectual property rights (IPR). Anyone wishing to contribute to the Standard must be willing to do so without imposing IPR barriers. UN/CEFACT believes strongly in fostering competition across the technologies described by UN/CEFACT Standards. Anyone should be able to produce a complete implementation of the specifications described by the Standards without IPR-related cost or red tape. Worldwide Participation All interested parties should have the opportunity to review, comment on, and contribute to the Standards. In the age of the Internet, the best way to do this is to carry out a public review of working draft specifications, which UN/CEFACT will make freely available on their website: www.unece.org/cefact . This ensures that developers from Bangalore to Sao Paulo to Munich can help shape the Standards - without having to pay any fees and without incurring travel expenses to attend standards development meetings. The UN/CEFACT process builds consensus on a truly international scale at the cost of a simple Internet connection. Standards development projects shall maintain a log of : 1) contributing experts and their sponsoring organization(s), 2) actions taken to promote input and review by the potential stakeholder community for which the standard
3
is intended; and 3) the resolution of comments received. This log shall be included with each posting of a version of the draft specification on the UN/CEFACT website. Speed In todays fast-changing environment, it is vitally important that the process of developing UN/CEFACT Standards should be in line with the needs of the industry, developers, and users. This requires timely availability of these Standards and a speedy, but careful, development process. Compatibility UN/CEFACT Standards must not depend on features that can only be made available using a single application or industry specification. Software developers and end-users around the world must be able to depend on technical applications that can, for example, be implemented the same way, and give the same results, on all hardware platforms and operating systems. Technical Excellence UN/CEFACT groups will develop all of their Standards with the active participation of experts, and liaisons. In this way, each specification embodies a best of breed experience along with innovation that benefits every user of the Standards. This approach enables companies/industries to employ their expertise and existing technology, when implementing UN/CEFACT Standards, resulting in high quality, and mature implementations which will make it into the marketplace sooner.
The Open Development Process for Technical Specifications

UN/CEFACTs experience has proven that the best way to develop a specification that meets all its process goals is to start with a small editing group and have them write a first working draft in close consultation with industry experts who have a deep understanding of the business process in question. Consensus is then built using an iterative review process that allows an ever-widening audience to participate. This iterative improvement approach allows consensus to be achieved rapidly because reviewers are able to see their comments and suggestions incorporated into successive versions of the document.
ODP Steps
ODP 1
Project & Team Formation
ODP 2
Require ments
ODP 3
Internal Draft
ODP 4
Internal Review
ODP 5
Public Review
ODP 6
Impl.
Verification
ODP 7
Publication
ODP 8
Maintenance
Project Proposal
Requirements Document
Internal Draft
Public Draft
Impl. Draft
Final Draft
Publication
Initial Contributions
Comments Comments Comments Log Log Log
Step 1. Proposing a new specification A request for a new specification that extends or enhances UN/CEFACT Standards can either be filed directly with the appropriate UN/CEFACT Permanent Group or with the UN/CEFACT Forum Management Group, in which case it will be forwarded, after review, to the appropriate group. Sometimes end-users or industry groups request a new specification. Sometimes one or more industries or expert groups propose one. In any case, the allotted UN/CEFACT host Working Group's first step is to form an editing group and assign a project editor. UN/CEFACTs goal of speed demands that this group be kept as small as possible. Typically, the editing group will comprise a project editor and two or three associate editors selected from within the UN/CEFACT group's experts. Step 2. Compiling a requirements list The group begins its work by compiling a requirements list, holding discussions with the specification requesters, participating industry experts, software developers, end-users, and implementers. They gather as much information as possible from those with expertise and those with a material interest in the specification. UN/CEFACT's goal of technical excellence demands that contributors must be experts in the area that is being standardised. This allows diverse voices to comment on the details of the specification and ensures that no single organization can dominate the process. UN/CEFACTs other goals of maximum reusability and flexibility mean that
5
contributors must try to include features that are applicable to more than one business and/or industry area. Step 3. Writing the first working draft The editors write the first working draft. To satisfy UN/CEFACTs goal of openness, everyone that has made a contribution to this working draft, or a subsequent working draft, must agree to remove any IPR constraints or restrictions that might be associated with their contribution. Since most people are usually much better at reviewing and criticising a specification than they are at compiling a requirements list and writing a first working draft, the editors work to produce a document that is suitable for review and comment. It is not expected that they produce a nearly final, polished version at this early stage. Step 4. Refining the first working draft The iterative improvement process begins when the first working draft is distributed to members of the responsible UN/CEFACT Working Group, technical implementers and other interested industry experts for their review and comment. This initial review serves to identify potential problems, point out areas for improvement, and build consensus among the technical implementers (who are likely to be implementing the final specification). The editors collect the comments, revise the working draft, and recirculate it until the reviewers are satisfied with the content. Experience has shown that 2 or 3 revisions are usually enough to arrive at a stable second working draft. Speed dictates that the initial review period be limited to a month or two at the most. The goal is to get the first working draft into a form suitable for public review as quickly as possible. The technical implementers help UN/CEFACT to meet the goal of compatibility early in the development process. The implementers have a wealth of experience in implementing the specifications for different business areas and industries. They are invaluable for identifying potential problems. Step 5. Public review The UNECE secretariat publishes the second working draft on its website thereby allowing the public to review and comment on the specification. In keeping with the goal of worldwide participation, UN/CEFACT allows anyone with access to the Internet to comment on the proposed specification. The public review period lasts for at least a month (and can be extended if many comments are received).
This is a critical part of the development process. Comments from the public have frequently raised fundamental process and technical issues - missed by the expert reviewers - that have considerably improved the specifications. The editing group collects the comments, criticisms, and suggestions from the public and uses them to further refine and improve the specification. As changes are made, the updated document is republished on the website. In UN/CEFACTs open process, everyone can see the changes, and the broad participation helps to build international consensus. Again, experience has shown that 2 or 3 iterations over a month or two suffice to address the public comments and to build consensus for the final version of the specification. Step 6. Implementation verification After approval by the Group, the final specification and its disposition log will be posted on the UN/CEFACT website to allow verification through implementation. Implementers (especially those who contributed to the working draft) are encouraged to verify the validity of the technical specifications by implementing them. The verification period is the most critical part of the entire development process. Problems and issues identified will result in considerable improvement in order to move the working draft towards a UN/CEFACT Technical Specification Standard. The editing group collects the problems and issues identified from the implementers and uses them to further refine and improve the specification. As changes are made, the updated document is forwarded to the implementers, as well as re-published on the website. In UN/CEFACTs open process, everyone can see the changes, and the broad participation helps to build international consensus. Again, experience has shown that 2 or 3 iterations over a month or two are enough to address the public comments and to build consensus for the final version of the specification. Step 7. Final Technical Specification release After successful verification by at least two independent implementations, and confirmation from the editing group, the UN/CEFACT group releases the Technical Specification as a UN/CEFACT Standard available for download on UN/CEFACTs website. Given the diverse group from around the world that contributed to refining the working draft, it should receive broad industry endorsement upon final release and be quickly implemented. UN/CEFACTs goal of openness ensures that the final specification contains no barriers to implementation: anyone with Internet access can
freely download a copy of the specification and produce an implementation without paying any additional licensing fees or royalties. Following the release of the final specification, the editing group disbands. Steps 1-7 typically consume a total of 9 to15 months. Step 8. Maintenance As the specification is implemented in various industry and business sectors UN/CEFACT's groups begin to receive feedback pointing out problems or suggesting improvements. Maintenance of the specification is handled by forming an editing group (where deemed necessary by the Working Group) and restarting the process at step 2 with the errata and suggestions forming the core of the new requirements list. UN/CEFACT's groups will maintain a list of problems, errors and misprints on their website so that the public can access them easily.
Proposal
The ODP for Technical Specifications has already been in use for several years and is probably the most elaborate process required developing a UN/CEFACT Standard. Each type of UN/CEFACT Standard should have an independent set of procedures defined within the ODP to cover its development, approval, publication and maintenance. UN/CEFACT Standards can be Technical Specifications, Business Requirement Specifications, Architecture and Business Models, Methodologies, Core Components, Libraries, Code lists, Directories, XML Schemas, Requirements Specification Mappings, Syntax implementations, Electronic Documents, Standard Messages, Naming and Design Rules, Transformation Rules and other deliverables. These will all be covered by the ODP, working from the same template, adjusting it according to the requirements of the specific deliverable. This means that the existing ODP must be enhanced to cover the separate sections for the processes of different Standards. The new sections to cover a complete set of procedures for UN/CEFACT Standards and UN/CEFACT Recommendations need to be defined and added into the ODP and should include all steps from the beginning of development through to maintenance. The existing steps for the development of Technical Specifications should be the guideline for all Standards, but do not necessarily include all steps.
A publishable matrix of proposed and current projects will be maintained by the FMG and regularly updated to give the status of each Standard with regard to its stage in the Open Development Process and the schedule for ODP reviews measured with respect to its appropriate development procedure. In addition, the UN/CEFACT Forum proposes to develop a fast-track set of procedures for external deliverable submissions. _________________________
Appendix V : UN/CEFACT Intellectural Property Rights Policy
UNITED NATIONS
Economic and Social Council Distr. GENERAL ECE/TRADE/CEFACT/2006/11 17 May 2006 ENGLISH ONLY
ECONOMIC COMMISSION FOR EUROPE COMMITTEE ON TRADE Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Twelfth session Geneva, 22-24 May 2006 Item 12 of the provisional agenda
ORGANIZATIONAL MATTERS UN/CEFACT Intellectual Property Rights Policy Note by the UN/CEFACT Bureau
At its 2005 session, the UN/CEFACT Plenary approved the principles of its Intellectual Property Rights Policy (as found in document TRADE/CEFACT/2005/MISC.3). The Plenary also asked the Special Contact Group, in cooperation with the Bureau, to prepare a document for clearance with the UN Office of Legal Affairs (see Decision 05-12 in document TRADE/CEFACT/2005/37). The Bureau and the Special Contact Group, with the UNECE secretariat, have followed these instructions and clearance for the attached document was received from the UN Office of Legal Affairs (OLA) on 15 May 2006 after several exchanges of information on the wording. This document reflects and adheres to the principles approved at the 2005 Plenary. The OLA has also requested the inclusion of a disclaimer in the publication, on the website and in connection with any other presentation of UN/CEFACT outputs covered by the IPR policy. The text of this disclaimer can be found in annex to this document.
1.
Royalty-Free Goals for UN/CEFACT Specifications
1. In order to promote the widest adoption of Specifications, UN/CEFACT seeks to issue Specifications that can generally be implemented without fees or restrictions. Subject to the conditions of this IPR Policy (the Policy), UN/CEFACT will generally not approve a Specification if it is aware that Essential Intellectual Property Rights (IPR) exist that are not available without fees or restrictions.
2. Definitions
2. A Participant is an individual, association, organization, corporation, other entity or Affiliate of such an entity, or an agency of government, that has formally joined a UN/CEFACT Forum Group. Participant is the legal entity on whose behalf an Authorized Individual acts.
Affiliate is any entity other than a government, which directly or indirectly 3. controls, is controlled by, or is under common control with, another entity, so long as such control exists. In the event that such control ceases to exist, such Affiliate will be deemed to have withdrawn from UN/CEFACT, and the withdrawal implications set forth in Section 3(b)(ii) of this Policy will apply. For purposes of this definition, with respect to a business entity, control means direct or indirect beneficial ownership of or the right to exercise (i) greater than fifty percent (50%) of the voting stock or equity in an entity; or (ii) greater than fifty percent (50%) of the ownership interest representing the right to make the decisions for the subject entity in the event that there is no voting stock or equity
An Authorized Individual is an individual designated by a Participant to 4. represent and bind that Participant with respect to the obligations set forth by UN/CEFACT's policies, such as this Policy, the Open Development Process and TRADE/R.650/Rev.4. 5. Contributing Non-Participant is an invited expert to UN/CEFACT who might be called in for their particular expertise. These Contributing Non-Participants must agree to the terms of this Policy and the rules of UN/CEFACT in general. Specifically, the disclosure and waiver obligations set forth in this policy apply equally to Contributing Non-Participants as well as Participants. A government agency may only be bound by the terms of this Policy as a Participant through an Authorized Individual, designated in writing. A government agency or representative can never be deemed a Contributing Non-Participant under the terms of this Policy.
IPR or Intellectual Property Rights includes patents, copyrights, trademarks, 6. utility models, invention registrations, database rights, moral rights, and data rights.
7. "Essential IPR" means any and all IPR in any jurisdiction in the world that would necessarily be infringed by implementation of a Specification because there are no commercially acceptable, non-infringing alternatives for implementing the Specification. The availability of a commercially acceptable non-infringing alternative shall be judged according to the state of the art when a Development Milestone (set forth in Section 4(d))
2
relating to the IPR occurs. Essential IPR shall not include rights in any enabling technologies that may be necessary to implement or use a Specification, such as technology related to the underlying hardware, operating system, middleware, or business processes.
Specification as used in this Policy encompasses all Technical Specifications, 8. Working Draft Technical Specifications, Final Technical Specifications, Recommendations, final UN/CEFACT Recommendations, as those terms are used in R650 and the ODP (http://www.disa.org/cefact-groups/atg/docs/developmntprocess.cfm), and any other formal documents and drafts that are materially involved in the Specification development process. Open Development Process or ODP is the process by which UN/CEFACT 9. Technical Specifications and Recommendations are developed, approved, published and maintained.
10. Contribution is any material submitted to a UN/CEFACT Forum Group by a Participant or Authorized Individual. This material must be submitted in writing or by electronic means, whether through an in-person meeting or through any electronic conference or mailing list maintained by UN/CEFACT and which is or was proposed for inclusion in a UN/CEFACT Recommendation as defined in this Policy. This definition includes general feedback from Participants and Authorized Individuals.
Forum Group is the group of Participants that has been approved by the 11. UN/CEFACT Plenary to undertake a long-term work program.
12. Forum Management Group is the body responsible for management of the Forum Groups and harmonization of work programs, among other things (See TRADE/R.650/Rev.4 for a more complete description).
3. Participant Waiver Obligations
13. The following obligations apply to all Participants and Contributing NonParticipants.
a) Waiver Obligation
14. Subject to Section 3(b), as a condition of participating in UN/CEFACT, each Participant agrees to waive its rights to enforce its Essential IPR against any party implementing a Specification from any Forum Group of which Participant was a member or made a Contribution. The Participants waiver of its rights to enforce Essential IPR against any party implementing the Specification extends only to the actual implementation of the Specification; Participant does not waive its rights to enforce its
3
Essential IPR as to any applications or uses of its Essential IPR other than the actual implementation of a Specification. 15. If a Specification requires an implementation in its entirety, then the waiver extends only to such implementations, but if the Specification allows implementations in part, then the waiver extends to such portions.
b) Waiver Exception
16.
The Waiver Obligation of this Policy does not apply to either: i) Participants Essential IPR that is properly and timely disclosed in accordance with the requirements of this Policy and the Open Development Process, provided that the Participant disclosing such Essential IPR expressly and timely elects not to waive its rights, again in accordance with the requirements of this Policy and the Open Development Process; or any new material added to a Specification after a Participant formally withdraws from that Specifications Forum Group in a writing to the Chair. The Waiver Obligation will continue to apply to any Contributions made to the Specification by the Participant after withdrawal.
ii)
c)
Waiver Term
17. With respect to patents or any other IPR with a limited term, the term of such waiver shall be for the life of the patent or other IPR in question. With respect to any other IPR, the waiver shall be perpetual. Notwithstanding any other terms of this Policy, the waiver obligation applicable to a particular Specification does not apply to any Participant with respect to any party that is asserting a claim that an implementation of that Specification infringes that partys IPR.
4. Disclosure a) Disclosure Obligations
18. Disclosure is required only where the Participant elects not to waive its right to enforce its Essential IPR under the Waiver Obligations of this Policy and instead elects to follow the Exception Handling procedures of this Policy. In order not to waive the Participants rights to enforce its Essential IPR, the Authorized Individual must disclose the Essential IPR on or prior to the first Development Milestone that arises after the Authorized Individual first has actual knowledge of the Essential IPR. This disclosure
4
obligation applies to Participants only with respect to Forum Groups in which the Participant is a member or to which the Participant provides a Contribution. 19. An Authorized Individuals failure to disclose in accordance with Section 4 of this Policy automatically results in the Participants waiver of its right to enforce the applicable Essential IPR as set forth in Section 3. The waiver extends to the enforcement of all future Essential IPR that originates from its waived Essential IPR. For example, should an Authorized Individual fail to disclose a known Essential pending patent claim prior to a first Development Milestone, the Authorized Individual may not then disclose a patent claim that originated from the undisclosed pending claim prior to a future Development Milestone. There is no requirement that the Authorized Individual perform a patent search or 20. any analysis of the relationship between the patents that the Participant holds and the Specification in question. However, notwithstanding any other terms of this Policy, the right to enforce any Essential IPR that has not been disclosed prior to five days after the final technical specification release Development Milestone (Section 4(d)(vi)) will be waived by the Participant pursuant to Section 3 of this Policy, whether or not the Authorized Individual has actual knowledge of that Essential IPR. 21. Once the Authorized Individual discloses specific Essential IPR with respect to a Specification following the rules laid out in this Policy, the Participant is relieved from its obligation to continue to disclose that Essential IPR at additional Development Milestones unless the nature of the Essential IPR has changed (e.g., a claim is approved or a patent application has issued).
b) Disclosure Statement Contents
22.
Disclosure statements must be sent to the Chair of the Forum Group in question and the Forum Management Group and include in writing: i) an identification of the portion of the Specification that the Participant believes infringes the Participants Essential IPR; a specific identification of the Participants Essential IPR as specified in Section 4(c); a signed statement from the Authorized Individual, binding on the Participant, indicating that the Participant does not agree to waive its rights to enforce the disclosed Essential IPR, and elects to implicate the Exception Handling procedures of this Policy.
ii)
iii)
c)
Specific Identification of Essential IPR
i)
For copyrights, the specific identification includes a disclosure of any formal registration numbers or information; or in the case of an unregistered copyright, a copy of the copyrighted material and an explanation of Participants entitlement to legal rights in the material. For trademarks, such specific identification includes a disclosure of any formal registration numbers or information; or in the case of an unregistered trademark, a description of the mark and an explanation of Participants entitlement to legal rights in the mark. For issued patents, the specific identification includes the patent number and an identification of specific claims. Any patent claims not specifically identified, even if included in otherwise disclosed patents, are waived pursuant to the Waiver Obligations of this Policy. For laid-open or published patent applications, or for allowed claims in any patent application, the specific identification includes the disclosure and identification of specific claims. Any patent claims originating from published or allowed claims that are not specifically identified, even if included in otherwise disclosed patents, are waived pursuant to the Waiver Obligations of this Policy. For any pending claims in an unpublished patent application, the specific identification includes only the disclosure of the existence of such claims. Any patent claims originating from pending claims not specifically identified, even if included in otherwise disclosed patents, are waived pursuant to the Waiver Obligations of this Policy.
ii)
iii)
iv)
d)
Timing of Disclosure: Development Milestones
23. Authorized Individuals are obligated to disclose IPR in accordance with this Policy at the following times (Development Milestones): i) ii) iii) iv) v) vi)
e)
at the time of making a Contribution containing the Essential IPR; within 30 days after joining a newly established or operating working group; 30 days after the publication of the first working draft (step 3 of the ODP); 30 days after the publication of each subsequent working draft (steps 4, 5, and 6 of the ODP); 30 days after the end of the public review period (step 5 of the ODP); 5 days after final technical specification release (step 7 of the ODP).
Disclosures to Be Publicly Available
24. Essential IPR disclosure information for each Specification will be made public along with each public Working Draft issued by the Forum Group. No later than 10 days following each Development Milestone, the Working Draft will be updated to include a list of all specifically identified Essential IPR disclosed, and all Exception Handling procedures implicated, by any and all Participants pursuant to this Policy.
5. Intellectual Property Ownership
25. No right related to IPR of a Participant will be deemed waived except as expressly set forth in this Policy. Further, each Participant in each UN/CEFACT Group approved by
6
the UN/CEFACT Plenary will retain ownership of all rights in IPR that such entity owned prior to participation and that may vest in the course of participation. Except as specifically set forth in this Policy, Participants and Contributing Non-Participants do not grant any waivers, or otherwise limit their rights in or to, their Contributions, Essential IPR, or any other IPR.
6. a) Exception Handling IPAG Formation
In the event that an Authorized Individual or Participant, following the disclosure 26. and waiver exception procedures outlined in this Policy, informs UN/CEFACT that they will not waive their rights to enforce particular Essential IPR, an Intellectual Property Advisory Group (IPAG) will be launched by the Plenary Bureau, in coordination with the Forum Management Group, to resolve the conflict. The IPAG is an ad-hoc group constituted specifically in relation to the Forum Group with the IPR conflict. An IPAG may also be formed without such a disclosure if the Plenary Bureau and the Forum Management Group determine that an IPAG could help avoid anticipated IPR problems. During the time that the IPAG is operating, the Forum Group may continue its technical work within the bounds of its charter.
b) IPAG Composition
27.
The IPAG is composed of:

two Vice-chairs of the Plenary; Chair and Vice-chair of the Forum Management Group; relevant Forum Group Chair(s); and others suggested by the Forum Management Group or the Plenary Bureau.
Members of the IPAG should be authorized to represent their organization's views 28. on IPR licensing issues. Any member of the IPAG may also be represented by legal counsel, though this is not required.
c) i) IPAG Procedures IPAG Formation Timing
29. Within 30 days after being launched by the Plenary, an IPAG will be convened by the Forum Group Chair, in coordination with the Forum Management Group and the Plenary Bureau and based on a charter developed initially by this group and following the requirements listed in this Policy.
ii) IPAG Charter Requirements
30.
The charter should include:

clear goals for the IPAG, especially a statement of the question(s) the IPAG is to answer; duration; confidentiality obligations; and determination of the publication of the IPAG charter, IPAG deliberations, and IPAG conclusions.
31. The IPAG charter must specify deadlines for completion of individual work items it takes on. The IPAG, once convened, may propose changes to its charter as appropriate, to be accepted based on consensus of the IPAG participants. The Plenary Bureau will choose a member of the IPAG to serve as Chair.
c) IPAG Conclusion
i)
Possible IPAG Conclusions
32.
After appropriate consultation, the IPAG may conclude: b) c) d) e) f) g)

the initial concern has been resolved with no need to change the Specification; the Forum Group should be instructed to consider designing around the identified Essential IPR; the IPAG needs further information; the Forum Group should terminate its activity on this subject; the Specification, if issued, should be rescinded; or alternative solutions should be considered. In such a case, the IPAG shall consult with the UN in relation to such alternative solutions, concerning any relevant UN regulations, rules and policies.
7.
Warranties and Indemnities
a)
Every Participant warrants that to the best of its Authorized Individuals knowledge, and without investigation, no third party contends that the Participants Contributions infringe that third partys intellectual property. THERE ARE NO OTHER WARRANTIES OR INDEMNITIES MADE BY THE PARTICIPANTS OR UN/CEFACT, AND UN/CEFACT AND PARTICIPANTS HEREBY DISCLAIM ANY IMPLIED OR EXPRESS WARRANTIES. UN/CEFACT does not take a position as to the validity or scope of any Essential IPR or any other rights that might be claimed to relate to the implementation of a Specification. UN/CEFACT makes no representation that it has made any independent investigation or effort to identify or evaluate any such rights.
b)
c)
8.
Confidentiality
33. UN/CEFACT and the Participant have no duty of confidentiality with respect to any information transferred between them. No Contribution that is subject to any requirement of confidentiality or any restriction on its dissemination will be considered in any part of the UN/CEFACT Open Development Process, and there must be no assumption of any confidentiality obligation with respect to any such Contribution. No submission of any kind should be made on the basis of an assumed confidentiality obligation or restriction on dissolution.
Annex This following disclaimer shall be included in the publication, on the website and in any other form of presentation, of UN/CEFACT outputs covered by the IPR policy. DISCLAIMER "UN/CEFACT draws attention to the possibility that the practice or implementation of its outputs (which include but are not limited to Recommendations, norms, standards, guidelines and technical specifications) may involve the use of a claimed intellectual property right. "Each output is based on the contributions of participants in the UN/CEFACT process, who have agreed to waive enforcement of their intellectual property rights pursuant to the UN/CEFACT IPR Policy (document ECE/TRADE/CEFACT/2006/11 available at http://www.unece.org/cefact/ or from the UNECE secretariat). UN/CEFACT takes no position concerning the evidence, validity or applicability of any claimed intellectual property right or any other right that might be claimed by any third parties related to the implementation of its outputs. UN/CEFACT makes no representation that it has made any investigation or effort to evaluate any such rights. "Implementers of UN/CEFACT outputs are cautioned that any third party intellectual property rights claims related to their use of a UN/CEFACT output will be their responsibility and are urged to ensure that their use of UN/CEFACT outputs does not infringe on an intellectual property right of a third party." "UN/CEFACT does not accept any liability for any possible infringement of a claimed intellectual property right or any other right that might be claimed to relate to the implementation of any of its outputs."
10
Appendix VI : List of UN/CEFACT Recommendations UN/CEFACT Recommendations (as of 2006-08-08)

Rec. No. Revised Name United Nations Layout Key for Trade Documents ISO Country Code for Representation of Names of Countries (ISO 3166) National Trade Facilitation Organs; Arrangements at the national level to coordinate work on facilitation of trade procedures Abbreviations of INCOTERMS; Alphabetic code for INCOTERMS 1990 Aligned Invoice Layout Key for International Trade Numerical Representation of Dates, Time and Periods of Time (ISO 8601) Unique Identification Code Methodology (UNIC) Alphabetic Code for the Representation of Currencies (ISO 4217) Codes for Ships Names Documentary Aspects of the International Transport of Dangerous Goods Measures to Facilitate Maritime Transport Documents Procedures Facilitation of Identified Legal Problems in Import Clearance Procedures Authentication of Trade Documents by Means other than Signature Simpler Shipping Marks Code for Ports and Other Locations (UN/LOCODE) PAYTERMS : Abbreviations for Terms of Payment Facilitation Measures related to International Trade Procedures Code for Modes of Transport Codes for Units of Measurement used in International Trade (Rev.3) Codes for Types of Cargo, Packages and Packing Materials with Complementary Codes for Package Names Layout Key for Standard Consignment Instructions Freight Cost Code Harmonization of Transport Status Codes Use of the UN/EDIFACT The Commercial Use of Interchange Agreements for Electronic Data Interchange Pre-Shipment Inspection Codes for Types of Means of Transport Doc. No.Issue Date TRADE/WP.4/137 (March,1981) ECE/TRADE/201 (January, 1996) TRADE/WP.4/INF.33;TD/B/FAL/INF. 33 (September, 1974) ECE/TRADE/202 (January, 1996) ECE/TRADE/148 (September, 1983) TRADE/WP.4/INF.108;TD/B/FAL/IN F.108 (October, 1988) TRADE/WP.4/INF.119;TD/B/FAL/IN F.119 (January, 1992) ECE/TRADE/202 (January, 1996) TRADE/WP.4/INF.52;TD/B/FAL/INF. 52 (February, 1978) ECE/TRADE/204 (January, 1996) TRADE/WP.4/INF.123 (June, 1993) TRADE/WP.4/INF.62;TD/B/FAL/INF. 62 (March, 1979) TRADE/WP.4/INF.63;TD/B/FAL/INF. 63 (March, 1979) TRADE/WP.4/INF.119 (May, 1992) ECE/TRADE/205 (January, 1996) ECE/TRADE/142 (March, 1982) ECE/TRADE/141/Rev.1 (September, 1982) ECE/TRADE/138 (March, 1981) ECE/TRADE/WP.4/R.888/Rev.4 (September, 1995) ECE/TRADE/195 (August, 1994
ECE/TRADE/198 (March, 1989) ECE/TRADE/170 (March, 1990) TRADE/WP.4/R.1067/Rev.2 (September, 1995) TRADE/WP.4/R.1079/Rev.1 (September, 1995) TRADE/WP.4/R.1133/Rev.1 (March, 1995) ECE/TRADE/237 (June, 1999) Adopted in March, 1999 TRADE/CEFACT/2001/23 (15 January, 2001-A)
withdrawn
New UD UD UD UD
Harmonized Commodity Description and Coding System for the Coding of Goods and Commodities Electronic Commerce Agreement E-Commerce Self-Regulatory Instruments (Codes of Conduct) Compendium of Trade Facilitation Recommendations Recommendation and Guidelines for Establishing a Single Window Recommendation and Guidelines on Single Window Data Harmonization Legal Framework for International Trade Single Window Online (Alternative) Dispute Resolution Cross boarder recognition of Digital Signature
TRADE/CEFACT/2000/12 (March, 2000) ECE/TRADE/257 (May 2000) TRADE/CEFACT/2001/14 (March, 2001) ECE/TRADE/279(2002) ECE/TRADE/352 (October, 2004)
UD: Under development
Appendix VII : UNSMs Development History

Message Name Directory No. Status Issued Doc. No. Application error and acknowledgement Message Authorisation Message Availability request Interactive Availability response Interactive Balance Message Banking Status Message Bayplan/Stowage plan occupied and empty location Msg Bayplan/Stowage plan total numbers Message Berth management Message Bulk marine inspection summary report Message Bank transaction & portfolio transaction report Message Balance of payment customer transaction report Message Direct Balance of Payment Declaration Message Balance of Payment Information from Customer M. Business Credit Report Mess Vessel Call Information Mess Request for legal D.01A UNSM 01.03 D.01B UNSM 01.09 D.01C UNSM 01.11 D.02A UNSM 02.08 D.02B UNSM 03.02 D.03A UNSM 03.06 D.03B UNSM 04.01 D.04A UNSM 04.05.27 D.04B UNSM 04.11 D.05A UNSM 05.07.22 D.05B UNSM 06.01. D.06A UNSM 06.09.28 D.06B UNSM 06.12.12 D.07A UNSM 07.07.02
APERAK AUTHOR AVLREQ AVLRSP BALANC BANSTA * BAPLIE BAPLTE x BERMAN BMISRM BOPBNK BOPCUS BOPDIR BOPINF BUSCRD CALINF CASINT
UNSM UNSM iUNSM iUNSM UNSM UNSM UNSM UNSM x UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM
UNSM UNSM iUNSM iUNSM UNSM UNSM UNSM
UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM
CASRES CHACCO CHAMAP CLASET CNTCND COACSU COARRI CODECO CODENO COEDOR *| COHAOR COLADV COLREQ COMDIS CONAPW CONDPV CONDRA CONDRO CONEST CONITT
administration action in civil proceedings Message Legal administration response in civil proceedings Message Chart of Accounts Message Chart of Mapping Message Classification Information Set Message Contractual Conditions Message Commercial Account Summary Message Container discharge/loading report Message Container gate-in/gate-out report Message Permit expiration/clearance ready notice Message Transport equipment stock and profile report Message Container special handling order Message Advice of a Documentary Collection Message Request for a documentary collection Message Commercial Dispute Message Advice on Pending Works Message Direct Payment Valuation Message Drawing Administration Message Drawing Organization Message Establishment of Contract Message Invitation to Tender Message
UNSM UNSM R.1285 UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM
UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM
Message Name Directory No. Status Issued Doc. No. Payment Valuation Message Quantity Valuation Message Response on Pending Works Message Tender Message Work Item Quantity Determination Message Container Announcement Message Contributions for payment Message Container Pre-notification Message Container Discharge/Loading Order Message Container Release Order Message Container Stuffing/Stripping Confirmation Message Container Stuffing/Stripping Order Message Credit advice Message Extended credit advice Message Multiple Credit Advice Mess Current Account Message Customs cargo report Message Customs declaration Message Customs Express Consignment Declaration Message Periodic Customs Declaration Message
D.01A UNSM 01.03
D.01B UNSM 01.09
D.01C UNSM 01.11
D.02A UNSM 02.08
D.02B UNSM 03.02
D.03A UNSM 03.06
D.03B UNSM 04.01
D.04A UNSM 04.05.27
D.04B UNSM 04.11
D.05A UNSM 05.07.22
D.05B UNSM 06.01.
D.06A UNSM 06.09.28
D.06B UNSM 06.12.12
D.07A UNSM 07.07.02
CONPVA CONQVA CONRPW CONTEN CONWQD COPARN COPAYM COPINO COPRAR COREOR COSTCO COSTOR CREADV* CREEXT* CREMUL* CURRAC CUSCAR CUSDEC CUSEXP CUSPED
UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM
Message Name Directory No. Status Issued Doc. No. Customs conveyance report Message Customs response Message Data Plot Sheet Message Data tracking message Debit advice Message Multiple Debit Advice Message Debts Recovery Message Delivery Schedule Message Delivery Just-in-time Message Despatch advice Message Equipment Damage & Repair Estimate Message Dangerous goods recapitulation message Direct Debit Message Directory Definition Message Data Maintenance Request Definition Message Data Maintenance Status Report/Query Message Documentary Credit Advice Message Advice of an Amendment of a Documentary Credit Msg. Documentary Credit Amendment Information Message Request for an Amendment of a Documentary Credit Msg. Documentary Credit Application Message
D.01A UNSM 01.03
D.01B UNSM 01.09
D.01C UNSM 01.11
D.02A UNSM 02.08
D.02B UNSM 03.02
D.03A UNSM 03.06
D.03B UNSM 04.01
D.04A UNSM 04.05.27
D.04B UNSM 04.11
D.05A UNSM 05.07.22
D.05B UNSM 06.01.
D.06A UNSM 06.09.28
D.06B UNSM 06.12.12
D.07A UNSM 07.07.02
CUSREP CUSRES
DAPLOS
UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM
UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM
DATRAK DEBADV* DEBMUL* DEBREC DELFOR*| DELJIT*| DESADV * DESTIM * DGRECA DIRDEB * DIRDEF DMRDEF DMSTAT DOCADV DOCAMA DOCAMI DOCAMR DOCAPP
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
UNSM UNSM
Message Name Directory No. Status Issued Doc. No. Response to an Amendment of a Documentary Credit Msg Documentary Credit Issuance Information Message Accounting Entries Message Financial Cancellation Message Multiple interbank funds transfer message Financial Statement of an account message General purpose message Generic Statistical Message Cargo/Goods handling and movement Message Insurance Claim assessment and reporting message Loss Assessment Request Message Insurance claims notification message Insurance claim solicitor's instruction message Forwarding and Consolidation Summary Message Forwarding and transport shipment charge calculation Msg Dangerous Goods Notification Message International transport freight costs & other charges Msg.
D.01A UNSM 01.03
D.01B UNSM 01.09
D.01C UNSM 01.11
D.02A UNSM 02.08
D.02B UNSM 03.02
D.03A UNSM 03.06
D.03B UNSM 04.01
D.04A UNSM 04.05.27
D.04B UNSM 04.11
D.05A UNSM 05.07.22
D.05B UNSM 06.01.
D.06A UNSM 06.09.28
D.06B UNSM 06.12.12
D.07A UNSM 07.07.02
DOCARE DOCINF ENTREC FINCAN FINPAY * FINSTA GENRAL GESMES HANMOV ICASRP | ICASRQ ICNOMO ICSOLI *| IFCSUM IFTCCA IFTDGN IFTFCC
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM
UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM + MiD MiD UNSM UNSM
UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM MiD MiD UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
UNSM UNSM UNSM
Message Name Directory No. Status Issued Doc. No.
D.01A UNSM 01.03 UNSM x UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM MiD
D.01B UNSM 01.09 UNSM x UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM + iUNSM UNSM UNSM UNSM UNSM
D.01C UNSM 01.11 UNSM x UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM
D.02A UNSM 02.08 UNSM x UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM
D.02B UNSM 03.02 UNSM x UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM
D.03A UNSM 03.06 UNSM x UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM
D.03B UNSM 04.01 UNSM x UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM
D.04A UNSM 04.05.27
D.04B UNSM 04.11
D.05A UNSM 05.07.22
D.05B UNSM 06.01.
D.06A UNSM 06.09.28
D.06B UNSM 06.12.12
D.07A UNSM 07.07.02
IFTIAG x Dangerous Goods List IFTICL IFTMAN IFTMBC IFTMBF IFTMBP IFTMCA IFTMCS IFTMIN IFTRIN IFTSAI * IFTSTA IFTSTQ IHCEBI IHCLME IMPDEF INFCON INFENT INSDES
Message Cargo insurance claims message Arrival Notice Message Booking confirmation Message Firm booking Message Provisional booking Message Consignment Advice message Instruction contract status message Instructions Message Forwarding and transport rate information Message Forwarding and transport schedule & availability Info Msg International Multimodal Status Report Message International Multimodal Status Request Message Health insurance eligibility & benefits inquiry & response Interactive Healthcare claim or encounter request & response - Interactive EDI implementation guideline definition message Infrastructure condition mes Enterprise accounting information Message Instruction to despatch message
UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM
iUNSM UNSM UNSM UNSM UNSM
Message Name Directory No. Status Issued Doc. No. Insurance Premium Message Inspection Request message Inspection Report message Invoice Message Inventory Report Message Insurance policy administration message Motor Insurance Policy Message Intermediary system enablement or disablement message In-transit Groupage In-transit Report Detail Message Job Application Result Message Joint Interest Billing Report Job Information Demand Message Job Application Proposal Message Job Order Confirmation Message Job Order Modification Message Job Order Message Justified payment request message Ledger message Life reinsurance activity message Life reinsurance claims Message
D.01A UNSM 01.03
D.01B UNSM 01.09
D.01C UNSM 01.11
D.02A UNSM 02.08
D.02B UNSM 03.02
D.03A UNSM 03.06
D.03B UNSM 04.01
D.04A UNSM 04.05.27
D.04B UNSM 04.11
D.05A UNSM 05.07.22
D.05B UNSM 06.01.
D.06A UNSM 06.09.28
D.06B UNSM 06.12.12
D.07A UNSM 07.07.02
INSPRE INSREQ INSRPT | INVOIC INVRPT IPPOAD IPPOMO ISENDS*| ITRGRP ITRRPT*| JAPRES JIBILL JINFDE JOBAPP JOBCON JOBMOD JOBOFF JUPREQ*| LEDGER LREACT LRECLM
UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM MiD UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM
Message Name Directory No. Status Issued Doc. No. Medical adverse drug reaction message Medical pre-authorisation message Person identification Message Medical Prescription Message Medical Service Request Message Medical Service Report Message Medical Resource Usage & Cost Message Means of transport and equipment position message Message implementation guide (MIG) report Stowage Instruction Message Metered services consumption report Mess Purchase Order Change Request Message Purchase Order Message Purchase Order Response Message Order Status Enquiry Message Order status report Message Party Information message (Trading partner profile data) TT&L, Product Application Status Request - Interactive
D.01A UNSM 01.03
D.01B UNSM 01.09
D.01C UNSM 01.11
D.02A UNSM 02.08
D.02B UNSM 03.02
D.03A UNSM 03.06
D.03B UNSM 04.01
D.04A UNSM 04.05.27
D.04B UNSM 04.11
D.05A UNSM 05.07.22
D.05B UNSM 06.01.
D.06A UNSM 06.09.28
D.06B UNSM 06.12.12
D.07A UNSM 07.07.02
MEDADR MEDAUT MEDPID MEDPRE MEDREQ MEDRPT MEDRUC MEQPOS MIGRPT MOVINS MSCONS ORDCHG ORDERS*| ORDRSP*| OSTENQ OSTRPT PARTIN PASREQ
MiD MiD UNSM UNSM UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM
Message Name Directory No. Status Issued Doc. No. TT&L, Product Application Status Response Interactive Passenger List Message Payroll Deduction Advice Message Extended payment order Message Multiple payment order Message Payment order Message Property and Casualty Property Damage Report Price/sales catalogue Message Pricing history Message Project Cost Reporting Message Product data message Product Exchange Reconciliation Message Product Inquiry Message Product service message Project Tasks Planning Message Insurance Premium Payment Message Quality data Message Quote Message Raw Data Reporting Mes Reinsurance Bordereau message Receiving Advice Message Reinsurance Calculation message
D.01A UNSM 01.03
D.01B UNSM 01.09
D.01C UNSM 01.11
D.02A UNSM 02.08
D.02B UNSM 03.02
D.03A UNSM 03.06
D.03B UNSM 04.01
D.04A UNSM 04.05.27
D.04B UNSM 04.11
D.05A UNSM 05.07.22
D.05B UNSM 06.01.
D.06A UNSM 06.09.28
D.06B UNSM 06.12.12
D.07A UNSM 07.07.02
PASRSP PAXLST PAYDUC PAYEXT * PAYMUL * PAYORD * PCPRDR PRICAT PRIHIS PROCST PRODAT | PRODEX PROINQ PROSRV PROTAP PRPAID QALITY *| QUOTES RDRMES REBORD RECADV * RECALC
iUNSM UNSM UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM
D.01A UNSM 01.03 UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM iUNSM UNSM UNSM UNSM UNSM UNSM UNSM
D.01B UNSM 01.09 UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM iUNSM UNSM UNSM UNSM UNSM UNSM UNSM
D.01C UNSM 01.11 UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM iUNSM UNSM UNSM UNSM UNSM UNSM UNSM
D.04A UNSM 04.05.27 UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM iUNSM UNSM UNSM UNSM UNSM UNSM UNSM
D.05B UNSM 06.01. UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM iUNSM UNSM UNSM UNSM UNSM UNSM UNSM
D.06B UNSM 06.12.12 UNSM UNSM UNSM UNSM MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM iUNSM iUNSM UNSM UNSM UNSM UNSM UNSM UNSM
RECECO RECLAM RECORD REGENT REINAC RELIST REMADV REPREM REQDOC REQOTE RESETT RESMSG RESREQ RESRSP RETACC RETANN * RETINS RPCALL SAFHAZ SANCRT
Credit Risk Cover Message Reinsurance Claims Message Reinsurance core data message Registration of enterprise Message Reinsurance account Reinsured objects list message Remmitance advice message Reinsurance Premium message Request for Document Message Request for quote Message Reinsurance Settlement Message Reservation Message Reservation Request Interactive Reservation Response Interactive Reinsurance Technical Account Message Announcement for return message Instruction for returns message Repair call message Safety and Hazard Data Message Int'l movement of goods governmental regulatory Msg.
10
Message Name Directory No. Status Issued Doc. No. Schedule acknowledgement - interactive message Schedule request interactive message Schedule update interactive message Sales Forecast Message Sales Data Report Message Social Administration Message Social Security Claim Decision Social Security Data Request Modification of Identity Details Message Worker's Insurance History Message Notification of Registration of a Worker Message Statement of account Message Settlement transaction reporting message Superannuation Contributions Advice Message Superannuation Maintenance Message Supplier Response Message Tank Status Report Message Tax Control Message Test message explicit mode Test message implicit mode
D.01A UNSM 01.03
D.01B UNSM 01.09
D.01C UNSM 01.11
D.02A UNSM 02.08
D.02B UNSM 03.02
D.03A UNSM 03.06
D.03B UNSM 04.01
D.04A UNSM 04.05.27
D.04B UNSM 04.11
D.05A UNSM 05.07.22
D.05B UNSM 06.01.
D.06A UNSM 06.09.28
D.06B UNSM 06.12.12
D.07A UNSM 07.07.02
SKDACK SKDREQ SKDUPD SLSFCT SLSRPT SOCADE SSCLDE SSDREQ SSIMOD SSRECH SSREGW STATAC STLRPT SUPCOT SUPMAN SUPRES TANSTA TAXCON TESTEX TESTIM
MiD iUNSM iUNSM UNSM UNSM UNSM MiD MiD UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM UNSM MiD MiD
11
Message Name Directory No. Status Issued Doc. No. Tourism information request message Tourism information response message TT&L, Information Inquiry Request - Interactive TT&L, Information Inquiry Response - Interactive Terminal performance message Traffic or Travel Description Definition Traffic or Travel details of individual traveller Traffic or Travel Route Guideance & Planning message Traffic or Travel Location Definition Traffic or Travel Information Request Traffic or Travel information acknowledgment Traffic or Travel Situation Information Timetable static data update - Interactive TT&L, Data update request message Interactive TT&L, Data update response message Interactive Utilities master data message Utilities time series message Value Added Tax Message
D.01A UNSM 01.03
D.01B UNSM 01.09
D.01C UNSM 01.11
D.02A UNSM 02.08
D.02B UNSM 03.02
D.03A UNSM 03.06
D.03B UNSM 04.01
D.04A UNSM 04.05.27
D.04B UNSM 04.11
D.05A UNSM 05.07.22
D.05B UNSM 06.01.
D.06A UNSM 06.09.28
D.06B UNSM 06.12.12
D.07A UNSM 07.07.02
TINREQ TINRSP TIQREQ TIQRSP TPFREP TRADES TRADIN TRAILS TRALOC TRAREQ TRAVAK TRAVIN TSDUPD TUPREQ TUPRSP UTILMD UTILTS VATDEC
MiD MiD iUNSM iUNSM UNSM MiD MiD MiD MiD MiD MiD MiD iUNSM iUNSM iUNSM UNSM + UNSM + UNSM
MiD MiD iUNSM iUNSM UNSM MiD MiD MiD MiD MiD MiD MiD iUNSM iUNSM iUNSM UNSM UNSM UNSM
12
D.01A UNSM 01.03 UNSM UNSM UNSM UNSM 206 D.01A +3 28 2
D.01B UNSM 01.09 UNSM UNSM UNSM UNSM 207 D.01B +1 27 2
D.01C UNSM 01.11 UNSM UNSM UNSM UNSM 207 D.01C
D.02A UNSM 02.08 UNSM UNSM UNSM UNSM 207 D.02A
D.02B UNSM 03.02 UNSM UNSM UNSM UNSM 207 D.02B
D.03A UNSM 03.06 UNSM UNSM UNSM UNSM 207 D.03A
D.04A UNSM 04.05.27 UNSM UNSM UNSM UNSM 207 D.04A
D.05A UNSM 05.07.22 UNSM UNSM UNSM UNSM 208 D.05A +1
D.05B UNSM 06.01. UNSM UNSM UNSM UNSM 208 D.05B
D.06B UNSM 06.12.12 UNSM UNSM UNSM UNSM 208 D.06A
VESDEP WASDIS WKGRDC WKGRRE
Vessel Departure Message Waste Disposal Information message Work Grant Decision Message Work Grant Request Message Numbers of Messages in the Directory Directory Number/Version UNSM:United Nations Standard Message (newly added) MiD :Message in Development UNSN Messages marked for deletion Inter-active UNSM Change designator: Plus sign (+) Asterisk (*) Vertical Line (|) Character x (x) Character R iUNSMInter-active message
27 2
27 2
27 2
27 2
27 2
27
27
27
27
27
27
27
14
15
15
15
15
15
15
15
15
15
15
15
15
15
13
Appendix VIII : ebXML Sources
1. UMM Technical Specifications
http://www.unece.org/cefact/umm/umm_index.htm
Symbol Issued date Title Download
UN/CEFACT Modelling Methodology (UMM) UMM User Guide (UMM in a nutshell) UMM Foundation Module V1.0 (2006) Version Date: 2006-10-06 Status: Technical Specification UMM Base Module V1.0 (2006) Version Date: 2006-10-06 Status: Technical Specification
[pdf] (180 Kbytes) [pdf] (658 Kbytes) [pdf] (113. 49 Kbytes)
CEFACT/TMG/N093
UMM User Guide (User Guide for Revision 12) UMM Metamodel - Revision 12 (2003)
UMM Revision 10 (2001)
[pdf] (1.27 Mbytes) [pdf] (275.02 Kbytes) [zip] (771.95 Kbytes)
UMM Web page of the UN/CEFACT Business Process Working Group
2. ebXML ISO Technical Specifications
http://www.unece.org/cefact/tc154_h.htm http://isotc.iso.org/livelink/livelink/fetch/2000/2122/138351/138352/customview.html?func=ll& objId=138352&objAction=browse&sort=name ISO TS 15000 Part 1-4 http://isotc.iso.org/livelink/livelink?func=ll&objId=3233082&objAction=browse&sort=name ISO TS 15000-1; 2004 ebCPP ISO TS 15000-2; 2004 ebMS ISO TS 15000-3; 2004 ebRIM ISO TS 15000-4; 2004 ebRS http://isotc.iso.org/livelink/livelink?func=ll&objId=3233203&objAction=browse&sort=name ISO TS 15000-5; 2005 ebCCTS http://isotc.iso.org/livelink/livelink?func=ll&objId=3236411&objAction=browse&sort=name ISO TS 15000-6; 2006 ebBPSS
3. XML Naming and Design Rules

Title Download
XML Naming and Design Rules 2.0 XML Naming and Design Rules 2.0 ECE/TRADE/CEFACT/2006/13/Corr.1
[pdf] (1,978 KB) [pdf]
4. OASIS - ebXML Site: http://www.ebxml.org/

AFACT Handbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AFACT Handbook

Uploaded by

Copyright:

Available Formats

Asia-Pacific Council for Trade Facilitation and e-Business

AFACT HANDBOOK for Trade Facilitation & e-Business

Part I Aout UN/EDIFACT

(Revised at the 25th AFACT Meeting in Bangkok, Thailand)

Tel : +886-2-8732-6222 Fax : +886-2-8732-6271 E-mail: wjweng@iii.org.tw

Tel : +91-11-23063917 Fax : +91-11-24362535 E-mail:

Tel : (6221)6505829 Fax : (6221)6505987

Tel: +98-21-66924623 Fax: +98-21-66926326 Email: zargar@dpimail.net

Tel : +81-3-3555-6053 Fax : +81-3-3555-6032 Email: kenji.itoh@mac.com

Tel : +822-3-528-5020 Fax : +822-3-528-5715 E-mail: swlim@kiec.co.kr

Tel: +632-890 4723 Fax: +632-896 4724 Email: betpdrf@dti.gov.ph

Tel: +65-887-7516 Fax: +65-778-5277 Email: kama@crimsonlogic.com.sg

Tel: +94-11-2326096 Fax: +94-11-2449352 Email: ayoni@chamber.lk

Tel: +66-2644-8150-9 Fax: +66-2644-6653 Email: kultida@notes.nectec.or.th

Tel: +84-4-9433-880 Fax: +84-4-9433-882 E-mail: binh_tq@hipt.com.vn http://www.hipt.com.vn

18 Afganistan 19 Hong Kong

Print out Mail

Print out Receiver

The EDI way of business communication:

AFACT EDI & EDIFACT Handbook (August 2007)

The Necessity of Standards

A p p lic a tio n to A p p lic a tio n e x c h a n g e S ta n d a rd is e d fo rm a ts o f e x c h a n g e U N /E D IF A C T , (E A N C O M , S M D G , W C O G7 ) C o m m u n ic a tio n p ro to c o ls X .4 0 0 , F T P , T C P /IP , H T T P , S M T P /M IM E ...

AFACT EDI & EDIFACT Handbook (August 2007)

F ie ld s o r D is c ip lin e s c o m p u tin g te le c o m m u n ic a tio n s

Types of docum ent re c o m m e n d a tio n s s ta n d a rd s p ro fils u s e rs g u id e

3. About UN/CEFACT and Forum 3.1. UN/CEFACT

UN/CEFACT Plenary adopted at the Plenary

held in May 2004

UN/CEFACT Forum Permanent Groups

AFACT EDI & EDIFACT Handbook (August 2007)

UN/CEFACT Plenary BUREAU

Trade Facilitation e-Business

International Trade & Business Processes Group

TMG - Techniques & Methodologies Group LG - Legal Group

AFACT EDI & EDIFACT Handbook (August 2007)

3.2.2 Permanent Groups

Organization UN/CEFACT Permanent Groups and their Working Groups

AFACT EDI & EDIFACT Handbook (August 2007)

ATG (Applied Technology Group)

ICGInformation Contents Management Group

AFACT EDI & EDIFACT Handbook (August 2007)

AFACT EDI & EDIFACT Handbook (August 2007)

TBGInternational Trade & Business process Group

AFACT EDI & EDIFACT Handbook (August 2007)

AFACT EDI & EDIFACT Handbook (August 2007)

AFACT EDI & EDIFACT Handbook (August 2007)

Structure of the Language INTERCHANGE

an..3 an..35 an..3

PRICE MODIFICATION C an..3 OF A PART OF THE ARTICLE ENCODED

Data Element Tag Cxxx= composite data element

Status: M= mandatory C= condition

AFACT EDI & EDIFACT Handbook (August 2007)

Name Colon Plus sign Question Asterisk Apostrophe

AFACT EDI & EDIFACT Handbook (August 2007)

AFACT EDI & EDIFACT Handbook (August 2007)

Structure of an exchange (interchange)

UNH Data Segment

TAG + Simple data element + Composite data element

Component data element Data value

AFACT EDI & EDIFACT Handbook (August 2007)

Gr.2 C 100 GGG C 5 HHH M 1 C KKK 50

AFACT EDI & EDIFACT Handbook (August 2007)

AFACT EDI & EDIFACT Handbook (August 2007)

5. UN/EDIFACT STANDARDS: HISTORY 5.1. Before EDIFACT