Data Harmonization Guide FC-3 - unescap.org - Full Report_9.pdf · Data Harmonization and Modelling Guide for Single Window Environment ... PERT Project Evaluation and Review Technique

Data Harmonization and Modelling Guide

FOR SINGLE WINDOW ENVIRONMENT

The secretariat of the Economic and Social Commission for Asia and thePacific (ESCAP) is the regional development arm of the United Nations andserves as the main economic and social development centre for the UnitedNations in Asia and the Pacific. Its mandate is to foster cooperation betweenits 53 members and 9 associate members. It provides the strategic linkbetween global and country-level programmes and issues. It supportsGovernments of countries in the region in consolidating regional positions andadvocates regional approaches to meeting the region’s unique socio-eco-nomic challenges in a globalizing world. The ESCAP secretariat is locatedin Bangkok, Thailand. Please visit the ESCAP website at www.unescap.orgfor further information.

The shaded areas of the map indicate ESCAP members and associate members.

i

Data Harmonization and ModellingGuide for Single Window

Environment

UNITED NATIONS NETWORK OF EXPERTS FOR PAPERLESS TRADEIN ASIA AND THE PACIFIC

UNITED NATIONS ECONOMIC AND SOCIAL COMMISSION FOR ASIA AND THE PACIFIC

UNITED NATIONS ECONOMIC COMMISSION FOR EUROPE

In cooperation with

WORLD CUSTOMS ORGANIZATION

ii

Data Harmonization and Modelling Guidefor Single Window Environment

The designations employed and the presentation of the material in this publication do not imply theexpression of any opinion whatsoever on the part of the Secretariat of the United Nations concerning thelegal status of any country, territory, city or area, or of its authorities, or concerning the delimitation of itsfrontiers or boundaries. This document has not been formally edited.

United Nations publicationCopyright © United Nations 2012All rights reservedManufactured in ThailandST/ESCAP/2619

iii

FOREWORD

International supply chains demand traders to improve efficiency in their practices while dulycomplying with a myriad of procedural, regulatory and documentary requirements. In recent yearsthese requirements have multiplied and become more complicated as a result of increasingattention to safety measures, security concerns, border protection and control by governments.Traders and Government agencies have a new challenge. To remain competitive they have toconduct business faster, at lower costs and to higher security standards in a rapidly changing andincreasingly complex global trading environment.

Simplification and harmonization of trade data and documentary requirements can contributesignificantly to the reduction of the time and costs of international trade transactions. Harmonizingdata used in trade documents and aligning them with international standards also ensures datainteroperability among the various parties engaged in the international supply chain. In addition,data harmonization is a necessary step towards trade automation and the introduction of electronicSingle Window facilities for electronic data sharing and exchange.

Based on the experiences and practices of various countries and building on the previous work,such as the Single Window Data Harmonization Guidelines from the World Customs Organization(WCO) and the United Nations Economic Commission for Europe (UNECE) Recommendation No.34 on Data Simplification and Standardization for International Trade, this United Nations Networkof Experts for Paperless Trade in Asia and the Pacific (UNNExT) Data Harmonization andModelling Guide for Single Window Environment aims to assist governments and businesses inharmonizing and standardizing the international trade data required in fulfilling all import, export,and transit-related regulatory requirements.

This Guide is part of the UNNExT suite of capacity building tools designed to support theimplementation of paperless trade and Single Window facilities. It complements other UNNExTtools, such as the Business Process Analysis Guide To Simplify Trade Procedures and the LegalGuide for Single Window Implementation and Paperless Trade. It is recommended to be usedtogether with them for maximum benefits. It is our hope that the Data Harmonization andModelling Guide will help government officials as well as the trading community in their efforts toharmonize and streamline trade data for the implementation of paperless trade, especially in aSingle Window environment. We believe this will ultimately contribute to efficiency and competitive-ness in international supply chains.

Ravi RatnayakeDirectorTrade and Investment DivisionESCAP

Virginia Cram-MartosDirectorTrade and Sustainable Development DivisionUNECE

iv

ACKNOWLEDGEMENTS

This publication was prepared by a team led by Shamika Sirimanne, Chief, Trade FacilitationSection, United Nations Economic and Social Commission for Asia and the Pacific (ESCAP), andconsisting of Sangwon Lim of ESCAP, and Markus Pikart and Yan Zhang of UNECE. Significantcontributions were made by UNNExT experts Somnuk Keretho, Saisamorn Naklada and ThayananPhuaphanthong from the Institute for Information Technology Innovation, Kasetsart University.Substantive input was provided by SP Sahu from the World Customs Organization as well asMary Kay Blantz and Jina Choi (consultants).

The Guide was peer-reviewed by the UNNExT Advisory Group on Document Simplification andData Harmonization, consisting of Hisanao Sugamata, Thomas Lee and Kerri Ahn. The Guide waspiloted at the UNNExT Capacity Building Workshop on Data Harmonization for Single WindowEnvironment in Seoul, Republic of Korea, on 7 and 8 October 2011 to a group of 23 practitionersfrom 15 countries. Observations and comments from the participants have been incorporated. Theexternal editing was provided by Ellie Meleisea.

The Data Harmonization and Modelling Guide for Single Window Environment was developed aspart of a joint United Nations Development Account project by ESCAP and UNECE and under theauspices of the UNNExT. The project, Enhancing Trade Competitiveness of Least DevelopedCountries, Countries in Transition and Transit Countries through the Implementation of SingleWindow Facilities, aims to raise the technical capacity of trade facilitation practitioners and helpaccelerate the adoption of modern trade facilitation measures, especially in least developed,landlocked and transition countries of Asia and the Pacific.

v

CONTENTS

Page

FOREWORD ............................................................................................................................... iii

ACKNOWLEDGEMENTS ........................................................................................................... iv

ABBREVIATION .......................................................................................................................... x

1. INTRODUCTION ................................................................................................................. 1

1.1 Background .................................................................................................................... 11.2 Purpose of the Guide ................................................................................................... 21.3 Target Audience ............................................................................................................ 21.4 Outline of the Guide ..................................................................................................... 2

2. OVERVIEW OF DATA HARMONIZATION ........................................................................ 3

2.1 Trade Facilitation and Data Harmonization................................................................. 32.2 What Is Data Harmonization? ...................................................................................... 52.3 Objective and Goal of Data Harmonization ................................................................ 62.4 Benefits of Data Harmonization ................................................................................... 6

3. PLANNING A DATA HARMONIZATION PROJECT ........................................................ 9

3.1 Identifying Tasks in a Data Harmonization Project .................................................... 93.2 Preparing Management and Team for Data Harmonization Implementation ........... 93.3 Estimating Efforts for Each Task in a Data Harmonization Project .......................... 113.4 Developing a Project Schedule.................................................................................... 123.5 Designating Tasks ......................................................................................................... 123.6 Developing a Detailed Project Plan ............................................................................ 13

4. INTRODUCTION TO STANDARDS AND CONCEPTS FOR DATAHARMONIZATION AND DEVELOPMENT OF ELECTRONICTRADE DOCUMENTS ....................................................................................................... 15

4.1 The United Nations Layout Key (UNLK) ..................................................................... 154.2 The United Nations Trade Data Element Directory (UNTDED, ISO 7372) ............. 174.3 Data Models as a Tool to Design Electronic Trade Documents ............................... 174.4 The World Customs Organization (WCO) Data Model .............................................. 20

vi

CONTENTS (Continued)

Page

5. THE STEP-BY-STEP APPROACH FOR DATA HARMONIZATION ANDDEVELOPMENT OF ELECTRONIC TRADE DOCUMENTS .......................................... 25

5.1 Step 1: Capture Data Requirements of Business DocumentsIdentified through Business Processes Analysis ........................................................ 26

5.2 Step 2: Define Data in Each Document and Define the Semanticof the Data and the Data Formats .............................................................................. 32

5.3 Step 3: Analyse Data Elements across Various Documentsand Organize Them in a Comparable Manner .......................................................... 35

5.4 Step 4: Map Data Elements to Reference Data Model ............................................. 355.5 Step 5: Obtain the Structure of an Electronic Document .......................................... 42

6. PRACTICAL RECOMMENDATION FOR DATA HARMONIZATION ............................... 47

6.1 Gaining Support for Data Harmonization .................................................................... 476.2 Coordinating Requirements of National Data Harmonization

with Relevant Regional and International Partners .................................................... 476.3 Iterative and Incremental Approach to Data Harmonization ...................................... 486.4 Criteria for Standard Selection ..................................................................................... 496.5 Maintenance of Outputs from Data Harmonization Projects ..................................... 49

GLOSSARY ................................................................................................................................. 51

REFERENCES ............................................................................................................................ 53

ANNEX I: Compiled Data Dictionary of ASEAN ATIGA Form D ......................................... 55

ANNEX II: ASEAN ATIGA Form D Data Mapped to WCO DM 3.0 ..................................... 57

ANNEX III: ASEAN ATIGA Form D XML Schema from WCO DM 3.0................................. 59

ANNEX IV: Cases of Data Harmonization ............................................................................... 62

vii

BOXES

Page

Box 1 Project Evaluation and Review Technique (PERT) ................................................. 12

Box 2 XML and EDI .............................................................................................................. 42

viii

FIGURES

Page

Figure 1.1 Step-by-step approach to development of electronic Single Windowand paperless trading ........................................................................................... 1

Figure 2.1 Components of a form .......................................................................................... 5

Figure 2.2 Examples of core data elements ......................................................................... 7

Figure 4.1 Exporter data structure ......................................................................................... 18

Figure 4.2 Examples of Dictionary Entry Name ................................................................... 21

Figure 4.3 UML class diagram of the WCO Data Model 3.0 .............................................. 22

Figure 5.1 Stepwise approach to Business Process Analysis ............................................. 27

Figure 5.2 UML diagram used in Business Process Analysis ............................................. 28

Figure 5.3 Activity diagram for “Obtain Export Permit” use case ....................................... 28

Figure 5.4 Sample list of forms captured from Activity Diagrams ....................................... 29

Figure 5.5 Image of ASEAN ATIGA Form D ......................................................................... 30

Figure 5.6 Overleaf Notes of ASEAN ATIGA Form D .......................................................... 31

Figure 5.7 Mapping of data between paper form and compiled datadictionary with UNTDED ....................................................................................... 34

Figure 5.8 WCO DM 3.0 with link to Interactive Data Set .................................................. 39

Figure 5.9 Example of Schema trim-down for customization .............................................. 45

Figure 5.10 XML Schema for ASEAN ATIGA Form D ........................................................... 46

Figure 6.1 Scope of Single Window and International Supply Chain ................................. 48

ix

TABLES

Page

Table 2.1 Definition of trade facilitation ................................................................................ 4

Table 3.1 Tasks-outputs relationship in a data harmonization project ............................... 10

Table 3.2 Summary of project team roles and responsibilities .......................................... 11

Table 4.1 Relationship between data element, data model, electronicdocument specification and electronic message ................................................ 19

Table 4.2 Data elements of the class “Declaration” ........................................................... 23

Table 5.1 Steps for data harmonization and development of electronic documents ....... 25

Table 5.2 Example of document data dictionary (ASEAN ATIGA Form D) ...................... 33

Table 5.3 Example of document categorization .................................................................. 36

Table 5.4 Example of data dictionary compilation .............................................................. 37

Table 5.5 Data dictionary of Certificate of Origin (ASEAN ATIGA Form D)mapped to WCO Data Model 3.0 ....................................................................... 38

x

ABBREVIATIONS

ADB Asian Development Bank

APEC Asia Pacific Economic Cooperation

APEC ECSG Asia Pacific Economic Cooperation Electronic Commerce Steering Group

ASEAN Association of South East Asian Nations

ATIGA ASEAN Trade in Goods Agreement

B2B Business-to-Business

B2G Business-to-Government

DEN Dictionary Entry Name

DM Data Model

ESCAP United Nations Economic and Social Commission for Asia and the Pacific

G2B Government-to-Business

G2G Government-to-Government

ISO International Organization for Standardization

NSW National Single Window

OECD Organisation for Economic Co-operation and Development

PERT Project Evaluation and Review Technique

SWIF Single Window Implementation Framework

TDED Trade Data Elements Directory

TOGAF The Open Group Architecture Framework

UML Unified Modeling Language

UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business

UNECE United Nations Economic Commission for Europe

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

UNLK United Nations Layout Key

UNNExT United Nations Network of Experts for PaperlessTrade in Asia and the Pacific

UNTDED or TDED United Nations Trade Data Elements Directory orTrade Data Elements Directory

WCO World Customs Organization

1

1. INTRODUCTION

Figure 1.1. Step-by-step approach to the development of electronicSingle Window and paperless trading

1.1 BACKGROUND

Simplification and harmonization of trade dataand documentary requirements can contributesignificantly to the reduction of time and costsfor international trade transactions. Harmoniz-ing data used in trade documents and aligningthem with international standards ensure datainteroperability among the various parties en-

gaged in a trade transaction. In particular, har-monization is a necessary step toward tradeautomation and the introduction of electronicSingle Window facilities, where all trade-re-lated information and data should be submittedonly once so that repetitive keying of the samedata can be reduced. Data harmonization is aprerequisite in introducing a system for elec-tronic data sharing and exchange.

This UNNExT Data Harmonization and Model-ling Guide for Single Window Environment isdeveloped as a tool to assist governments andbusinesses in harmonizing and standardizingthe international trade data required in fulfillingall import, export, and transit-related regulatoryrequirements through the elimination of redun-dant data and duplication in exchanging and

recording information. The improvement in dataquality will lead to greater simplification of tradeprocesses and predictability in trade transac-tions. Less complexity and fewer delays willhelp to enhance trader compliance and securerevenues. It can also facilitate regional andinternational agreements on harmonization andautomation of cross border data exchange.

e-Single Window &paperless trading

Cross-border data harmonization& exchange

National data harmonization

Documents simplification and alignment

Process simplification and harmonization

Business Process Analysis

Data Harmonization and Modelling Guide for Single Window Environment

2

1 UNNExT. (2009). Business Process Analysis Guide toSimplify Trade Procedures. Thailand: United Nations

2 h t t p : / /www.unece .o rg / f i l eadm in /DAM/ce fac t /recommedations/rec34/ECE_TRADE_400_DataSimplificationand_Rec34E.pdf

3 Thailand’s Single Window e-Logistics is also calledNational Single Window to align with ASEAN SingleWindow Initiative.

1.2 PURPOSE OF THE GUIDE

This Guide provides a stepwise approach onhow to conduct a data harmonization exerciseand a basic concept for assembling electronicmessages. It complements the ESCAP andUNECE UNNExT Business Process AnalysisGuide to Simplify Trade Procedures1 and is anextension to the WCO Single Window DataHarmonization Guidelines and UNECE Recom-mendation No. 34.2 It is also intended to beused as an UNNExT instrument for building thetechnical capacity of stakeholders needed forconducting data harmonization in implementinga Single Window and paperless trade.

The Guide should help project managers, datamodellers, and data analysts to harmonizedata element names and the structure oftrade, transport, and administrative documentsexchanged across the international supplychain with reference data models. The step-by-step approach demonstrates how to createdata models to specify the structure andproperties of particular documents. These datamodels then can serve as a basis for deve-loping messages.

The steps described in the Guide are basedon the experience gained from nationalprojects, such as the data harmonizationexercises Thailand carried out in preparationfor the development of its Single Windowe-Logistics,3 which simplified and made tradedocuments ready for automation.

1.3 TARGET AUDIENCE

The Guide is intended to serve practitioners,project managers, data modellers, and dataanalysts from government agencies, the privatesector and the business community involved inharmonization and simplification of internationaltrade procedures through harmonization of

related data requirements with internationalstandards.

1.4 OUTLINE OF THE GUIDE

This Guide provides information about dataharmonization and details on the organizationaland procedural processes necessary toachieve data harmonization. It outlines the sys-tematic approach, standards and tools to facili-tate a data harmonization exercise, practicalrecommendations for data harmonization,cases and application of the results of dataharmonization exercises.

The sections of the Guide are as follows:

Chapter 1 briefly presents the importanceof data harmonization, the purpose of theUNNExT Data Harmonization and Model-ling Guide, and how it can be used for thebenefits of target audience;

Chapter 2 introduces the concept of dataharmonization, its scope and role for tradefacilitation and how it contributes to greaterefficiency in fulfilling documentary require-ments of the international trade transactions;

Chapter 3 suggests how to plan a dataharmonization project and how to structuremanagement and implementation teams;

Chapter 4 introduces standards, technology,and tools to be used in conducting dataharmonization and developing electronictrade documents;

Chapter 5 describes the processes and stepsto follow in conducting data harmonizationand developing an electronic message;

Chapter 6 provides practical recommenda-tions for data harmonization exercises,including the iterative and incremental ap-proach to data harmonization, criteria forstandard selection, and maintenance of out-puts from the data harmonization project;

The Glossary lists terms used in the Guide; The References provide sources for which

any reference is made in the Guide; and The Annexes contain some of sample data

harmonization deliverables as well as sepa-rate cases of data harmonization, whichdescribe relevant national experiences andillustrate how the Guide can be used inactual practice.

3

2. OVERVIEW OF DATA HARMONIZATION

2.1 TRADE FACILITATION ANDDATA HARMONIZATION

International trade procedures encompass allactivities ranging from the ordering of goods,physical transfer of goods, and payment forgoods along the supply chain (UNECE, 2001).They entail activities, practices and formalitiesinvolved in collecting, presenting, communicat-ing and processing data to fulfil business andregulatory requirements prior to and during themovement of goods across borders (OECD,2002).

Trade documents and data, whether in paperor electronic format, are important as theyprovide the means to exchange informationassociated with commercial, transport, regula-tory or financial procedures. Traders oftenface complex and myriad formalities and docu-mentary requirements. They have to deal withrepeated requests for the same information.Cumbersome, repetitive and non-standardizedtrade documents and data required for bordercrossings are identified by the business com-munity as a major deterrent to entering certainmarkets (UNESCAP, 2009).

According to the Asia Pacific Economic Coop-eration (APEC) Business Advisory Council(1996), each international trade transactionrequires an average of 40 documents to meetrules and regulations set for international tradeand transport. These documents are made upof approximately 200 data elements of which15 per cent are repeated at least 30 times and60 to 70 per cent are repeated more thanonce.

These documentary requirements are costlyand are a major cause of delay in cross-border operations. A study commissioned bythe European Commission states that the

costs of complying with these requirementsamount to accounting for 3.5 to 7 per centof the value of goods (OECD, 2002). It canbe as high as 10 to 15 per cent, if thereare typing and other errors (UNCTAD,1994).

Trade facilitation is recommended by manyinternational and intergovernmental organiza-tions as a strategy to remove the redundan-cies and bottlenecks in international trade.Although the scope of trade facilitation isdefined differently from one organization toanother, what is found in many is that theharmonization and standardization of informa-tion and information flows associated withinternational trade transaction are importantelements of trade facilitation. As illustrated inTable 2.1, most organizations regard theharmonization and standardization of informa-tion and information flows associated with theinternational trade transaction as one of thekey improvement measures for facilitatingtrade.

Harmonizing data used in trade documentsand aligning them with international standardswould help automate and streamline tradeprocedures. Reducing information requirementscan benefit the trading community throughimproved quality and timeliness of data sub-missions. Streamlined trade procedures anddocuments can also significantly help reducetransmission cost and improve trade competi-tiveness.

In the context of trade facilitation, the scopeof data harmonization covers the datarequirements of all stakeholders in the interna-tional supply chain. According to UNECE(2001), stakeholders of the international supplychain are categorized into four groups. Theyare:


4

A supplier (exporter/seller) who sells goodsor services as stipulated in a salescontract;

A customer (importer/buyer) to whomgoods and services are sold as stipulatedin a sales contract;

An intermediary who provides commercial,financial, and/or transport services withinan international supply chain, such asfreight forwarder, customs broker, thirdparty logistics service provider, expressintegrator, carrier of all modes, port andterminal operator, inland container depot,bank, insurance company, InformationTechnology (IT) value-added service pro-vider, bank and financial institutions; and

An authority (including an authorized pri-vate inspection agency) of the exportingcountry, the importing country, and thecountry in transit, who monitors cross-

border movement of goods in a way thatreflects national and international publicinterests.

The United Nations Layout Key for TradeDocuments (UNECE, 2002) provides a list ofkey documents prepared and used by stake-holders in different stages of the internationalsupply chain and categorizes those documentsinto four document families which are:

The Commercial transaction documentfamily, which includes documents appliedbetween commercial parties in the produc-tion, sale and purchase phases of a trans-action. The buyer and the seller are keyoriginators of documents in this sector.

The Payment document family, whichincludes documents that are exchangedbetween partners in international trade andtheir banks as well as between banks to

Table 2.1. Definition of trade facilitation

APEC OECD UNECE WCO WB WTO(Woo (OECD, (UNECE, (WCO, (World (WTO

Trade Facilitation and 2002) 2002; 1999) Bank, Website,Wilson, OECD, 2005) 2005; OECD2000) 2002) 2002)

The simplification and harmonization of tradeprocedures

The harmonization and standardization ofinformation andinformation flowsassociated with theinternational tradetransaction

The use, standardization, and improvement ofphysical infrastructureand facilities

The harmonization of applicable laws andregulations with theinternational standards

The automation of trade procedures

The removal of barriers to the mobility ofbusiness people

5

process payments for commercial transac-tions.

The Transport and related servicesdocument family, which includes docu-ments relevant to the physical internationalmovement of goods. It covers documentsused in 1) the forwarding and handling ofgoods activities in terminals, warehousesand ports, 2) payment for such intermedi-ary services, and 3) cargo insurance.

The Official controls document family,which includes documents that governmentauthorities in exporting country, importingcountry, and country where goods are intransit use as one of instruments tofacilitate the control of international goodsflow.

Given the complex scope of trade facilitationwith many stakeholders involved, the effortsrequired to complete a full scope of data har-monization can be extensive. Under resourceconstraints, a phased implementation of dataharmonization may be considered (see Section6.3 for further explanation).

2.2 WHAT IS DATAHARMONIZATION?

In our daily lives, we often encounter situationswhere we have to provide our personal orbusiness data in a certain form. As illustratedin Figure 2.1, a form mainly consists of 1) adata element name which is also known inUNECE Recommendation No. 1 as a fieldheading expressed in a plain language of textor code specifying the nature of the data in adata field and 2) a data field which is an areadesignated for a specified data entry.

There is always a possibility that each of usinterprets each data element differently. Forexample, a delivery date can mean differentthings to different parties.

For a buyer, a delivery date can be “dateand optionally time when goods are re-quested to be delivered.”

For a seller, a delivery date can be “dateand optionally time when goods are esti-mated to be delivered.”

2. Overview of Data Harmonization

Figure 2.1. Components of a form

Form: A data carrier designed to carry a visible record of data entries

Field headingor Data Element NameA field identifierexpressed in plainlanguage, in full or abbr.

1. Goods consigned from (Exporter’sbusiness name, address, country)

Reference No.

ASEAN TRADE IN GOODS AGREEMENT/ASEAN INDUSTRIAL COOPERATION SCHEME

CERTIFICATE OF ORIGIN(Combined Declaration and Certificate)

FORM D Issued in (Country) See Overleaf Notes

3. Means of transport and route(as far as known)

Departure date

Vessel’s name/ Aircraft etc.

Port of Discharge

Data FieldAn area designatedfor a specified dataentry

2. Goods consigned to (Consignee’sname, address, country)

4. For Official Use

Preferential Treatment Given UnderASEAN Trade in Goods Agreement

Preferential Treatment Given UnderASEAN Industrial Cooperation Scheme

Preferential Treatment Not Given (Pleasestate reason/s)

Signature of Authorised Signatory of theImporting Country

.......................................................................................................................


6

For a driver delivering packages, a deliverydate can be “date and period of time dur-ing which goods are scheduled to be deliv-ered.” It can also be “actual date and timewhen goods are delivered.”

Without clear instructions, we provide data foreach field heading in a format that we assumeappropriate. For example, the data regardinga delivery date of 20 August 2010 can beexpressed in various representation formats,i.e.

DD/MM/YY: 20/08/10 DD/MM/YY (Buddhist year): 20/08/53 DD-MM-YYYY: 20-08-2010 MM/DD/YY: 08/20/10 MM-DD-YYYY: 08-20-2010 YYMMDD: 100820 YYYYMMDD: 20100820 YYYY-MM-DD: 2010-08-20 DD MONTH YYYY: 20 August 2010 MONTH DD, YYYY: August 20, 2010

Party A may provide data for a delivery dateusing DD/MM/YY format while Party B mayuse MM/DD/YY format. The provision of dataunder the same category in different represen-tation formats makes electronic sharing andintegration of data within an organization andacross organizations incompatible.

In addition, the meaning of a data element canbe addressed using different vocabularies. “Ahereditary name common to all members of afamily,4” for example, can be referred to assurname, last name, and family name. Theidentical meaning of these three differentwords can be understood by human beingsbut not by different computer applications builton different platforms. Without reconcilingdifferent data elements of identical meaning,electronic sharing and integration of databecomes complex and costly.

Data harmonization is an act of reconciling thedefinition and representation formats of dataelements in a domain of interest. It entails a

set of activities that improves the consistencyin the use of data elements in terms of theirmeaning and representation format. Throughdata harmonization, a set of core data ele-ments (data elements expressed using differ-ent vocabularies but with identical meaning)can be extracted. Description of each coredata element inclusive of its definition andrepresentation format can then be formalized.Examples of core data elements are shown inFigure 2.2.

Sharing common data with business partnersis one way to improve the efficiency of datausage. By sharing common data with part-ners, those data can be reused in a way thatbenefits organizational objectives and goals.An electronic document can be a data carrierthat facilitates data sharing and reuse beyondwhat a paper document can offer.

2.3 OBJECTIVE AND GOAL OFDATA HARMONIZATION

The objective of data harmonization, in thecontext of trade facilitation, is to eliminateredundancies and duplication in internationaltrade data.

Data harmonization enables data intero-perability among individual information systemsin the international supply chain, includingSingle Windows5, by producing a set of har-monized core data elements with semanticstandard.

2.4 BENEFITS OF DATAHARMONIZATION

The standardization of data requirementsformalizes the definition and representationformat of data elements used by variousstakeholders. Clear definitions of data ele-ments enhance the way in which data ele-

4 The New Oxford American Dictionary, 2nd Edition.

5 A Single Window is “a facility that allows partiesinvolved in trade and transport to lodge standardizedinformation and documents with a single entry pointto fulfill all import, export, and transit-related regula-tory requirements. If information is electronic, thenindividual data should only be submitted once.”UNECE Recommendation No. 33.

7

ments are interpreted. A clear representationformat serves as a guideline for providingaccurate data. They contribute to use of betterquality data in the business process andreduce the risk of errors, costs and delays.

According to a case experience of the Euro-pean Commission Taxation and CustomsUnion,6 the process of standardizing datarequirements leads to the discovery of redun-dancy in data requirements and core dataelements. A set of these core data elementsthen serves as input for the development of aSingle Administrative Document (SAD). Giventhat a SAD contains a minimum list of dataelements that every authority responsible foradministering border control needs at differentpoints in the trading process and a maximumlist of data elements that some authoritiesmay require, it abolishes the use of differentadministrative forms, removes duplicate datarequirements, and simplifies data collection ina border control process.

The outputs of data harmonization provide abasis for coordinated development of variousinformation systems used in the differentstages of the international supply chaindomain. It sets the semantic standard for

different development teams within the tradecommunity to adopt as a basis in developingdifferent information systems.

The results of data harmonization also providea basis for automating a seamless Business-to-Business (B2B), Business-to-Government(B2G) and Government-to-Government (G2G)information exchange in a Single Window facil-ity; data harmonization provides semantic rulesthat can be used to govern domestic sharingand integration of electronic data at leastwithin the border. If all the information systemsin the supply chain use the same set of dataattributes and semantic rules, they can com-monly interpret the exchanged data and auto-matically process it to achieve their intendedbusiness objectives.

In summary, the benefits of data harmonizationare as follows:

It provides a common basis for standardiz-ing data for import, export and logisticsinformation.

It reduces data redundancy and costs ofdata exchange.

It ensures data compatibility and enablesdata interoperability among stakeholders,resulting in further facilitation of trade pro-cedures.

It facilitates the establishment of SingleWindow facilities and cross border dataexchange among Single Windows.

2. Overview of Data Harmonization

Figure 2.2. Examples of core data elements

6 European Commission Taxation and Customs Union,The Single Administrative Document (SAD) Character-istics, Available at: http://ec.europa.eu/taxation_cus-toms/resources/documents/sad-characteristics_en.pdf.

SourceDefinition

Certificate ofProduct Standards

PhytosanitaryCertificate

Certificate ofOrigin

The first point of arrival inthe country of finaldestination*

Place of destination Declared point ofentry

Destination (Place)

Free form description of themarks and numbers on atransport unit or package**

Shipping mark Distinguishingmark

Mark

Core DataElement 1

Core DataElement 2{

{

* International Standards for Phytosanitary Measures, Guidelines for Phytosanitary Certificates(Publication No. 12)

** UN/CEFACT Export Certification (eCert) RSM


8

9

After a data harmonization project is formallyauthorized and its high-level scope is identi-fied, a designated project manager develops adetailed work plan that helps guiding the har-monization of data requirements falling into thescope of interest.

A project manager of a data harmonizationproject, in cooperation with appropriate stake-holders, should:

Identify and list the required tasks in alogical sequence;

Form management and work teams;

Estimate the efforts required for carryingout each task;

Develop a project schedule;

Assign tasks to team members includingdata analysts; and

Develop a detailed project plan.

3.1 IDENTIFYING TASKS IN A DATAHARMONIZATION PROJECT

To identify project tasks, one can use a tech-nique normally used in developing a workbreakdown structure. A work breakdown struc-ture is basically an output-oriented descriptionof project tasks. It typically starts with outputs.The work components of the outputs are thenbroken down into the tasks necessary toachieve them.

In the context of data harmonization, it isnecessary to identify the tasks required toderive the following outputs:

A list of (paper/electronic) documents andmessages that fall within the scope of thedata harmonization project

A set of data dictionaries that include thedata that corresponds to the identified listof designated documents and electronicdocuments and messages

A National Data Model that 1) consolidatesdata requirements listed in each datadictionary and 2) contains the standardsemantic definition and representationformat for each data requirement mappedto a data model

A set of Message Implementation Guide-lines for key documents that supports bothUN/EDIFACT and XML message syntaxes

The steps listed in this Guide can be adoptedas project tasks. Table 3.1 provides a snap-shot of main tasks that data analysts need tocarry out to derive each project output.

3.2 PREPARING MANAGEMENTAND TEAM FOR DATAHARMONIZATIONIMPLEMENTATION

In implementing a data harmonization project,it is essential to establish project managementand to assign roles and responsibilities clearlyto team members, in order to ensure a high-quality successful implementation. This part ofthe Guide describes the roles of projectsponsors, project leader/manager, a changemanagement unit, and team members.

a. Identifying the right project sponsor

Project sponsors, committed senior executivesrepresenting the key stakeholders of a projectsuch as the Single Window implementation,who will oversee the data harmonizationproject, provide advice on the project’s direc-tions and make policy decisions, should be

3. PLANNING A DATA HARMONIZATIONPROJECT


10

identified. They will regularly review projectstatus, take note of emerging issues and risks,and provide direction on overcoming anyissues and risks and approve potentialsolutions. They will be also responsible forconvincing stakeholders and concerned partiesthat the results gained from the data harmoni-zation project will be implemented.

b. Assigning a competent project manager

The project manager is an individual withstrong management and communication skillswho understands the operation and objectivesof the project implementation. This individual isresponsible for planning, monitoring, control-ling, and adjusting the project plan, its execu-tion and the quality of the outputs. It mayhelp if a project manager has a good under-standing on electronic data interchange and/orexperience in implementation and operation oflarge-scale information systems.

c. Designating Change Management Unit

A Change Management Unit (CMU) is thegroup authorized to oversee a version controland manage any revision of the standard thatmay occur as a result of a project. The CMUwill assess the feasibility of any issue, analysethe impact of a change, decide on the neces-sity of the requested change, and determinethe need for formal verification of the change.

d. Comprising team members

Team members for data harmonization imple-mentation may include data analysts, data

modelers, and technical engineers who mayperform the following roles. It is also highlyrecommended to include business domainexperts to properly collect and integratebusiness requirements. Typical functions ofdata analysts, data modelers, and technicalengineers are listed below. Depending on theexpertise available, a team member may takeon multiple functions.

Data Analyst

Conduct data analysis

Organize data elements and their attributesin a comparable manner

Describe different attributes of data ele-ments including their definitions, theirrepresentation format, and the number oftimes (occurrence) that a particular type ofdata could appear in a document.

Work with domain experts or data ownersto prepare the required data.

Provide support by addressing data relatederrors, provide any potentially new datarequired as a result of changes and per-form data maintenance activities as projectmoves through the various levels of testing.

Data Modeler

Translate business requirements into con-ceptual, logical and physical data modelswith a focus on issues such as reducingredundancy of data within an existing com-puter system or improving the way in whichit moves from one system to another.

Table 3.1. Tasks-outputs relationship in a data harmonization project

Main Tasks Outputs

1. Capture the documentary requirements of the A list of collected documents, electronic documentsbusiness processes that are within the scope or messages falling under the scope of a dataof the data harmonization project harmonization project

2. Define captured data elements in a Data A set of data dictionaries that corresponds to theDictionary identified list of paper and electronic documents/

messages

3. Analyse data elements National Data Set

4. Map core data elements to a reference A set of Message Implementation Guidelines for keydata model documents

11

Design, build, and maintain the logicaland physical data models to support thebusiness requirements in a dynamic, clientoriented environment.

Develop data models for organizationaldata domains.

Work with resources resulting from devel-opment, data architecture, and businessunits to create an integrated model foroperational database and data warehouse.

Technical Engineer

Update and maintain all technical specifica-tions

Provide guidance on technical and archi-tectural issues related to internationalstandards and best practices

The tasks of the different participants in thedata Harmonization Project are outlined inTable 3.2:

3.3 ESTIMATING EFFORTS FOREACH TASK IN A DATAHARMONIZATION PROJECT

Based on the identified tasks, the project man-ager estimates the time required to completeeach task. In a data harmonization project,significant amounts of time and effort arespent on analyzing and defining data elements

and mapping the local definitions to a standarddefinition. This is particularly in the caseswhere:

Instructions or international conventionsthat define data requirements in the docu-ments are not available.

Forms with sample data are not available. Forms that carry data elements under the

scope of harmonization are not alignedwith the international standards.

In these circumstances, data analysts need toconsult the owner of the document from whichdata elements are extracted from in orderto gain a better understanding of the dataelements. With better understanding, data ana-lysts are able to provide a definition for eachdata element with greater accuracy.

There is no standard benchmark time to com-plete each step in a data harmonization project.Describing the data definition, representationformat, and the number of times (occurrence)that a particular type of data could appear in asimple document may take only one hour. Fora complicated document, the same task maytake more than one working day. Likewise,there is no one-size-fits-all solution to deter-mine the amount of required resources.However, the Project Evaluation and ReviewTechnique (PERT) may be helpful for time andresource estimation (Marchewka, 2006).

Table 3.2. Summary of project team roles and responsibilities

Project ChangeResponsibilities Project Leader/ Manage- Data Data Technical

Sponsor Manager ment Analysts Modelers EngineersUnit

Risk Management x x

Project Planning x x

Project Monitoring and Control x

People Management x

Development Processand Operation x x x x x

Quality Management x x x x x

Change Management x x

Communication x x x x x x

3. Planning a Data Harmonization Project


12

3.4 DEVELOPING A PROJECTSCHEDULE

Based on the set of tasks identified in alogical sequence, the project task estimates,and the duration of the project stated in thecontractual arrangement made with the projectsponsor, the project manager prepares theproject schedule. The schedule containingthe start date, the finish date, and durationof time to complete each output can bepresented in the form of a Gantt chart(Marchewka, 2006).

3.5 DESIGNATING TASKS

The number of data analysts/modellers re-quired on a project depends on the projectscope and duration specified by the projectsponsor. The shorter the project duration is orthe broader the project scope is, the larger thenumber of data analysts/modellers is required.In a data harmonization project, data analysts/modellers are responsible for:

Describing different attributes of dataelements including their definitions, theirrepresentation format, and the number oftimes (occurrence) that a particular type ofdata could appear in a document.

Organizing data elements and their at-tributes in a comparable manner.

Developing message implementation guide-lines.

Data analysts/modellers should be selectedbased on the following skills:

Technology skills: Although it is not neces-sary, basic knowledge of database man-agement and data modelling techniques isdesirable. Related work experience in infor-mation systems development is comple-mentary.

Business/organization skills: It is useful ifthey have a knowledge of a particular or-ganization or industry under the scope ofdata harmonization.

Interpersonal and communication skills: It isimportant that they are able to effectivelycommunicate and interact with the project’sstakeholders. They should have the abilityto create and sustain reasonably good rela-tionships with the people who represent theowner of documents under the scope ofthe data harmonization project.

Analytical skills: They should be able tothink critically. They should be mindful andcapable of spotting the commonalities inthe differences, i.e. 1) data elements withdifferent names but with an identical defini-tion and 2) data elements with identicalnames but different definitions. Finally, theyshould be able to organize captured dataelements in a comparable manner.

Box 1: Project Evaluation and Review Technique (PERT)

The PERT provides probabilistic treatment of activity duration in the estimation. The PERT estimate may beused to compute a weighted average for each individual task. A three-point estimate includes pessimistic, mostlikely, and optimistic times as described below.

The Optimistic Time is the minimum time in which a task can be completed. It is the best-case scenarioset with the assumption that all activities go as planned and no internal or external obstacles will occur.

The Most Likely Time is an estimate of the expected time that is required to complete the task. The Pessimistic Time is the maximum time of the worst-case scenario in which the task should be

completed.

To calculate the estimated time it takes to complete each step, the most likely time, and the pessimistic timehave to be identified and placed in a following equation.

Task Estimate = Optimistic Time + (4 * Most Likely Time) + Pessimistic Time 6

13

3.6 DEVELOPING A DETAILEDPROJECT PLAN

The project manager compiles the project taskestimates, project schedules and project staff

into the detailed plan. The detailed plan shouldbe circulated to all project stakeholders forcomments and resource reconciliation. It isimportant that the project manager takes intoaccount their feedback and ensure that theplan is realistic.

3. Planning a Data Harmonization Project


14

15

Modern global trade takes place in a multi-lingual environment, touches the legislation ofdifferent countries and economic regions andinvolves many different, independent parties.Trade documents, in both paper-based andelectronic format, are frequently used toexchange and record information in tradetransactions. Simplifying and standardizingthese documents is a key step for implement-ing a smooth exchange of information and forfacilitating a successful cross-border exchangeof goods.

This Chapter provides an overview of the keystandards for trade documents in paper andelectronic format. It introduces important stan-dards, such as the United Nations Layout Key(UNLK), which was introduced for the simplifi-cation of paper-based trade documents andthe WCO Data Model7 used for the design ofelectronic trade documents.

4.1 THE UNITED NATIONS LAYOUTKEY (UNLK)

The UNLK is a key instrument for the simplifi-cation of trade documents. In the early 1960s,the UNECE set up a Working Party on Facili-tation of International Trade Procedures to

develop a standard for simplified trade docu-ments. The Working Party was first chargedwith preparing an international Model Formbased on agreed paper size, form design prin-ciples and list of items to be included. TheModel Form was finalised based on contribu-tions of governments, interested internationalorganisations and the business community,and adopted as the United Nations Layout Keyfor Trade and Transport Documents (UNLK).

Due to the practical value of aligning interna-tional trade documents to the UNLK, and itsinternational acceptance, this standard formwas formally introduced as UNECE Recom-mendation No.1, in 1973.8 Today the UNLK isthe lead standard for the simplification of tradedocuments. Nearly all forms for internationaltrade documents are aligned to the UNLK. TheSingle Administrative Document (SAD) for EUCustoms declarations, IATA and FIATA trans-port documents, the Transports InternationauxRoutier (TIR) or the General System of Prefer-ences (GSP), to mention only some, are tradedocuments aligned to the UNLK.

To support trade facilitators in designingaligned trade documents, UNECE and ESCAPdeveloped a “Guide for the Design of AlignedTrade Forms for Paperless Trade”9 and a

4. INTRODUCTION TO STANDARDS ANDCONCEPTS FOR DATA HARMONIZATIONAND DEVELOPMENT OF ELECTRONICTRADE DOCUMENTS

7 The WCO Data Model is a set of carefully combineddata requirements that are mutually supportive; it willbe updated on a regular basis to meet the proceduraland legal needs of cross-border regulatory agenciessuch as Customs, controlling export, import and tran-sit transactions. © 2011, World Customs Organization(WCO), Brussels, Belgium, All rights reserved. WCOData Model is accessible at www.wcopublications.orgor please contact [email protected],

8 The full text of the recommendation, along withaddendum and guidelines for applications, is availableon: http://www.unece.org/cefact/recommendations/rec_index.htm.

9 The guide is available at http://www.unece.org/fileadmin/DAM/trade/Publications/ece_372_ManualForDesignAlignedTradeForms.pdf.


16

simple electronic tool to design aligned tradedocuments.

Although the UNLK is a standard initially de-signed for paper-based documents, it containsessential principles that provide the basis forthe development of an electronic documentspecification. Such principles include:

Reusability of data

In an aligned trade document, each piece ofinformation is placed on a specific, designatedlocation. This allows producing a Master Form,which contains information that is used inseveral trade documents. Master Forms werefirst used with typewriters for paper-basedtrade documents. A set of trade documentswith carbon sheeted back sides would be putinto a typewriter, with the Master Form on thetop. The information would be printed on theMaster Form and, through the carbon copyprocess, copied on the relevant fields of theunderlying set of trade documents. By fillingin the Master Form, one would establish a“one-run system” in which the whole set ofdocuments for the trade transaction would beproduced in a single instance.

The benefits of this one-run system are obvious:

Data are typed only once, Data are checked only once, Data are transferred error-free to the indi-

vidual documents, Form sizes could be standardized, etc.

An example of an aligned series of exportdocuments, based on a Master Form and in-tended to be completed by the “one-run”method, is explained in the “United NationsLayout Key for Trade Documents Guidelinesfor Application”. The Guidelines include theMaster Form and the forms for the Offer,Acknowledgment of Offer, Invoice, DispatchAdvice, Banking Instructions, and ForwardingInstructions.10

Even if paper is still the most commonly usedmedium for trade documents, electronic tradedocuments are now becoming more and morecommon. Electronic documents require stan-dards to describe their semantic and syntax11

for electronic data interchange. So, the con-cept of the Master Form for paper-baseddocuments has its equivalent in the concept ofa common data model for electronic tradedocuments, where the same data structuresare used in different documents. This will belater described in Section 4.3.

Box-design to group data

Traditionally, documents consisted of a continu-ous “running” text, leaving gaps for filling invariable data. As a means of rationalizing tradeforms, the UNLK groups data that belong to-gether into boxes. A particular box is identifiedby a box heading (or “guide words”) indicatingthe nature of the data to be entered. Thismethod is commonly referred to as “box design”.

For example, a form would contain a box witha heading “Consignor”. This box would containinformation such as the Consignor name andaddress, but also contact details such as tele-phone and fax numbers or the reference num-ber of the Consignor.

10 These are available at http://www.unece.org/cefact/rec-ommendations/rec01/ece_trade_270_E.pdf.

11 Semantic describes the meaning of information;syntax describes the way information is representedin a document. For example; the information that aConsignor is “The name of the party consigninggoods as stipulated in the contract by the partyordering the transport” provides semantic. The infor-mation that Consignor data is transmitted through acharacter string with a maximum length of 512 char-acters is information on syntax.

3336 Consignor

Example of Box design Principle fromFIATA Forwarding Instructions FFI

(Approved byFIATA)1492 ConsignorReference No.

Emblemof NationalAssociation

17

The “Box Design principle” of the UNLK issimilar to the concept of object classes whichis used for the development of electronic tradedocuments in chapter 5.

4.2 THE UNITED NATIONS TRADEDATA ELEMENT DIRECTORY(UNTDED, ISO 7372)

Each box in an aligned trade document has a“box heading”, such as Consignor, whichspecifies data that can be put into the box. Toprovide clear and unambiguous meaning ofthe information in the trade documents, theUNLK “headings” are recorded in a dictionarythat is published as the United Nations TradeData Elements Directory (UNTDED, ISO7372).12 UNTDED elements mainly consist ofa data element tag in the form of a four-digitnumber to identify the data element, a dataelement name and a description that providesa definition of the data element.

Over the years, the UNTDED has been continu-ously expanded. Today it provides an interna-tionally accepted standard repository for thesemantic of trade data elements used in inter-national trade. UNTDED definitions describeinformation from the point of view of a businessexpert, such as a trader or a Governmentofficial. The UNTDED has also been integratedinto the latest standards for electronic tradedocuments, such as the UN/CEFACT CoreComponent Library (CCL)13 and UN/EDIFACT14.The definition data in an aligned form usingthe UNTDED provides a very useful basis fordeveloping electronic specifications of this infor-mation in a later step.

The definition of data objects based on aninternationally accepted standard also simpli-fies the cross-border exchange of data andharmonizes procedures.

Examples of UNTDED data elements

3336: Consignor

Description: Name of the party consigninggoods as stipulated in the transport con-tract by the party ordering transport

4.3 DATA MODELS AS A TOOL TODESIGN ELECTRONIC TRADEDOCUMENTS

The rapid expansion of global trade in the1990s and the availability of modern infor-mation and communication infrastructure fortraders and government administration posedan increasing need for the automated proces-sing of documents and trade information.

Today there are a number of initiatives tomove from paper-based trade to the use ofelectronic trade documents. The main differ-ence in moving from paper to electronic docu-ment processing lies in the fact that paperdocuments are processed by humans, whocan contextualize the information they receive.For example, if the Consignor box in the For-warding Instructions contains the information“1200 Geneva” then the human reader wouldassociate this information with the informationon the location of the Consignor. If this infor-mation were to be processed electronically, thecomputer explicitly has to be told that “1200”is the postal code of the city and “Geneva” isthe name of the city. Thus information in elec-tronic documents needs to be defined andstructured much more precisely than in paperdocuments.

Many countries now implement Single Windowsystems15, which allow exchanging the com-plete set of information needed for exporting

4. Introduction to Standards and Concepts for Data Harmonization and Development of Electronic Trade Documents

12 For the UNTDED, ISO7372 Data Elements, see: http://www.unece.org/trade/untdid/UNTDED2005.pdf.

13 For the UN/CEFACT CCL, see: http://www.unece.org/cefact/codesfortrade/unccl/CCL_index.html.

14 UNECE developed UN/EDIFACT and ebXML (ISO15000) as international standards for electronic ex-change of trade information.

15 The Single Window is a facility that allows partiesinvolved in trade and transport to lodge standardizedinformation and documents with a single entry pointto fulfill all import, export, and transit-related regula-tory requirements. If information is electronic thenindividual data elements should only be submittedonce. See also UNECE Recommendation 33: http://www.unece.org/cefact/recommendations/rec33/rec33_trd 352e.pdf.


18

or importing goods. This means that the datasuch as the “Consignor” information in theForwarding Instructions can appear, for ex-ample, as the “Exporter” information in theCertificate of Origin. This requires that the ITsystems of both the freight forwarders andauthorities that issue the Certificate use thesame data definition and structure for dataelements such as the “Consignor”.

A Data Model (DM) is a description of all dataobjects that are needed to manage the inter-national supply chain process. A DM is a keytool in the development of modern Informationand Communication Technology (ICT) applica-tions that need to interchange data with otherapplications.

The data description in a Data Model includes:

A precise and commonly accepted defini-tion of the semantic of the information. For

example, a Data Model could define an“Exporter” as:

Exporter Person who makes or onwhose behalf an export dec-laration is made

A description of the structure of this infor-mation.

For example, a Data Model would describe thatinformation about an “Exporter” consists of theExporter’s name, address and contact information.

Data Models that are used in internationaltrade should be developed based on the UN/CEFACT Core Component Technical Specifica-tion (CCTS)16. The CCTS provides a method-ology to describe the semantic and the logicalstructure of trade information independently

Figure 4.1. Exporter data structure

Exporter

nameidentification

Address

city Namecountrycountry Sub Divisioncountry Sub Division Namelinepostcode

Contact

name

Communication

identificationtype

Communication

identificationtype

Source: WCO DM 3.0

0..*

0..*

0..*

0..*

16 For the UN/CEFACT CCTS see: http://www.unece.org/cefact/codesfortrade/CCTS_index.htm.

19

from the implementation of a specific syntax17

for data interchange. This means that the elec-tronic documents can be produced using manydifferent syntax implementation tools, such asUN/EDIFACT18, Extensible Markup Language

(XML)19 or other formats. This openness todifferent technical implementations is impor-tant, as Single Windows have to provideinterconnectivity to many proprietary systems ina country.


Table 4.1. Relationship between data element, data model, electronic documentspecification and electronic message

Purpose Builds on Standards Application

Data Element, in Describes a piece of UNTDED Define data fromUML20 called a information used in the perspective ofProperty Term international trade such a business expert

as “Exporter name” and“Exporter identification”in Figure 4-1

Data Object, in Describes a set of data Grouped data CCTS, CCL Define data fromUML called elements that belong elements the perspective ofObject Class together such as the a system analyst/

“Exporter” or the developer“Address” Data Class inFigure 4-1

Data Model Describes the structure Data Models WCO DM, CCL Define dataof data objects used in consist of data structures andinternational trade, objects and relations for laterincluding their relationship. other building processing of

blocks, such as information in ICTbusiness applicationsprocess modelsand informationmodels

Electronic Describes the technical It is a subset of XML Schemas and Define adocument standard on message the Data Model UN/EDIFACT framework fromspecification structure using specific Message which electronic

syntax. Implementation messages can beGuide provided by built.WCO Data Modelor other sources

Electronic Contains detailed Electronic XML and Instancesmessage information that is document UN/EDIFACT implemented based

structured according to a specification on electronicmessage specification message

specification

17 Syntax describes the way information is encoded in amessage. Depending on the standard chosen, thereare different ways that the same piece of informationcan be encoded.

18 UN/EDIFACT is the “United Nations Electronic DataInterchange for Administration, Commerce and Trans-port”. It comprises a set of internationally agreedstandards, directories and guidelines for the electronic

interchange of structured data, and in particularthat related to trade in goods and services betweenindependent, computerized information systems.”For more, see http://www.unece.org/cefact/edifact/welcome.html.

19 Extensible Markup Language (XML) is a set of rulesfor encoding documents in machine-readable form.

20 Please refer to 4.4.1.


20

When using a DM, each electronic documentuses only the data needed for that exchange;therefore, it becomes a subset of the usedDM. Only the structures of the DM that areactually used in the trade document will beincluded in the specification of the electronicdocument. For example, a Certificate of Originwill include the name and address structure ofthe DM for the “Exporter”, but not the one forthe “Importer”.

In the UN/EDIFACT, such an adaptation iscalled a Message Implementation Guideline(MIG). A MIG could, for example, prescribethat certain fields that are marked as optionalin a UN/EDIFACT message specificationpublished by UNECE are not used in messageexchanges in the specific country. Likewise,in XML the specification of the structuresincluded in a message is called an XMLSchema.

The relationship between Data Element, DataModel, Electronic Document specification andElectronic Message are summarised in Table4.1.

4.4 THE WORLD CUSTOMSORGANIZATION (WCO)DATA MODEL

The development of a standard Data Modelthat meets the information requirements ofthe large number of parties and businessprocesses that participate in international tradeis a complex task. To aid users, the WorldCustoms Organization (WCO) has developedthe WCO Data Model (DM). The WCO recom-mends the use of this DM for simplificationand automation of information in cross bordertrade. Governments are invited to use thisDM and to adapt it to their specific require-ments.

The WCO DM has been developed as a resultof a Group of Seven (G7) agreement tostandardize and simplify customs data require-ments of the G7 countries, in compliance withthe “Kyoto Customs Data Principles”. The WCOtook over the maintenance and managementof the output of the G7 initiative in January2002. The WCO published the data set and

the message implementation guidelines as“WCO Customs Data Model – version 1.0”.

As a consequence of the event of 11 Septem-ber 2001, the WCO established a Task Forceon Supply Chain Security. In order to meet therequirements defined by this Task Force, theWCO Customs Data Model was updated toversion 1.1. Version 2.0 of the WCO CustomsData Model covered conveyance reporting aswell as a data set for transit, as defined by theCommon Transit Convention21.

The increasing emphasis on Single Windowconcepts identified a need for further inclusionof Cross Border Regulatory Agency (CBRA)requirements. This work formed the basis ofVersion 3.0 of the renamed WCO Data Model,also referred to WCO DM in the later chap-ters.

The benefits of using the WCO DM for crossborder data exchange are as follows:

Data can be submitted once and reused inmany different business processes;

Data collection and validation processesare greatly simplified; and

Applications can be developed according toone single data interchange standard.

4.4.1 Unified Modelling Language(UML) and Object Classes

Information in a DM is described using theUnified Modelling Language (UML). In UML,trade information is structured according to theobject class, property term and representationterm:

The object class describes the domainto which object the information belongs.Typical objects in cross border trade areexporters, importers, goods item descrip-tions, locations, etc.

A property term (or attribute) represents adistinguishable piece of information of the

21 For the Common Transit Convention, see: http://eur-lex.europa.eu/Notice.do?mode=dbl&lang=en&ihmlang=en&lng1=en,de& lng2=cs,da,de,el,en,es,et,fi,fr,hu,it,lt,lv,nl,pl,pt,sk,sl,sv,&val=393167:cs&page=

21

object class. For example, for the object“Location” the name of the location wouldbe a property term/an attribute.

The representation term describes thedata format of the property term. Forexample, the name of the location wouldbe given in text format.

For example, in the WCO DM, the objectclass “Exporter” has the two property terms,the “Name” and the “Identification”. The prop-erty term “Name” is represented by a string ofcharacters (text), maximum 70 characters. The“Identification” is represented by a code (identi-fier), maximum 17 characters

WCO ID WCO DEN Definition Format

R031 Exporter. Name. Text Name [and address] of party who makes - or on whose an..70behalf - the export declaration - is made - and who is theowner of the goods or has similar right of disposal over themat the time when the declaration is accepted.

R032 Exporter. Identification. To identify the name and address of party who makes, or on an..17Identifier whose behalf the export declaration is made, and who is the

owner of the goods or has similar rights of disposal over themat the time when the declaration is accepted.

4.4.2 Dictionary Entry Namesand ISO 11179

The objects in a DM are identified througha Dictionary Entry Name (DEN). When deve-loping electronic documents, it is useful tounderstand the structure of the DEN as it

helps to understand the meaning of theinformation object.

The WCO DM uses the ISO 11179 standard todefine the DEN. A DEN consists of a tripartitename, with a format of “Object Class. PropertyTerm. Representation Term”, as shown inFigure 4.2.

R031: Exporter. Name. TextR053: Supplier. Identification. Identifier306: Commodity. Value. Amount

Figure 4.2. Examples of Dictionary Entry Name (DEN)

Tripartite Dictionary Entry Name

Object Class(OC)

Property Term(PT)

RepresentationTerm (RT)

Exporter Name Text

Supplier Identification Identifier

Commodity Value Amount

Dictionary Entry Names in WCO DM 3.0



22

Figu

re 4

.3.

UM

L cl

ass

diag

ram

of

WC

O D

ata

Mod

el 3

.0

So

urc

e:

WC

O

23

Table 4.2. Data elements of the class “Declaration”

WCO Name Definition WCO DENID

013 Number of loading lists The number of loading lists, manifests or similar Declaration. Loadingdocuments. List. Quantity

019 Document/message Code specifying the status of a document. Declaration. Status. Codestatus, coded

023 Goods declaration Date on which a Goods declaration has been Declaration. Acceptance.acceptance date or will be accepted by Customs in accordance Date Time(Customs), coded with Customs legislation.

065 Office of declaration, To identify a location at which a declaration is Declaration. Declarationcoded lodged. Office. Identifier

104 Authentication Proof that a document has been authenticated Declaration.indicating where appropriate the authentication Authentication. Textparty.

109 Total invoice amount Total of all invoice amounts declared in a single Declaration. Invoice.declaration. Amount

131 Total gross weight Weight (mass) of goods including packaging but Declaration. Total Grossexcluding the carrier’s equipment for a Mass. Measuredeclaration.

187 Customs office of To identify a location at which a subsequent Declaration. Subsequentduty/tax payment declaration is lodged. Declaration Office.declaration, coded. Identifier

227 Number of seals To specify the number of seals affixed. Declaration. SealsAffixed. Quantity

228 Total number of items Count of the total number of goods items within Declaration. Goods Item.a declaration Quantity

373 Document/message Date and time when the document/message was Declaration. Cancellation.cancellation date and cancelled. Date Timetime

374 Document/message Date and time when the document/message was Declaration. Rejection.rejection date and time rejected. Date Time

383 Version number The sequential number that determines the Declaration. Version.version of a specific document/message number. Identifier


For example, the Dictionary Entry Name of thedata element R031 “Exporter. Name. Text” ofthe WCO Data Model can be decomposed asObject Class=Exporter, Property Term =Nameand Representation Term = Text

To better understand the meaning of the dataelement, it is useful to read the DEN back-ward, replacing the “.” with the word “of the”:

The text of the name of the Exporter


24

4.4.3 UML Diagram of the WCO DataModel

The WCO Data Model describes the relation-ship between the object classes using theUML class diagram as shown in Figure 4.3.

Each blue box in Figure 4.3 represents oneobject class. For example, Declaration (Docu-ment) means a class derived from the superclass “document” as described below:

This class “Declaration” consists of the follow-ing data elements shown in Table 4.2:

WCO ID Class Name Definition

42A Declaration Any statement or action, in any form prescribed or accepted by theGovernmental Agency, giving information or particulars required by theGovernmental Agency

25

This chapter explains the practical steps fordata harmonization, for the mapping of dataelements to a data model and for developingspecifications for electronic messages and

documents. Such specifications provide thebasis for paperless trade and for the useof electronic messages in the Single Windowsystem.

5. THE STEP-BY-STEP APPROACH FOR DATAHARMONIZATION AND DEVELOPMENT OFELECTRONIC TRADE DOCUMENTS

Table 5.1. Steps for data harmonization and development of electronic documents

Step 1 Step 2 Step 3 Step 4 Step 5(5.1) (5.2) (5.3) (5.4) (5.5)

Purpose Capture data Provide a precise Analyse data Reconcile Obtain structurerequirements in definition for the elements across data elements of the electronicbusiness documents data elements various and obtain a documentidentified through documents data modelBusiness ProcessAnalysis

Activity Business Process Analyse each Organize data Map the data GenerateAnalysis (optional) document to elements in a elements to electronicCollect a list of define data comparable reference document(s)documents and definition, type, manner for data model (If using WCObasic data format and analysis (for example, DM, customizerequirements constraints WCO DM) XML schema

by referring toImplementationGuide providedby WCO DM

Input BPA results, target List of List of Document Messagebusiness documents Documents Document Data Implementation

Data Dictionary Guide (MIG)Dictionaries Compilation (If using WCO

DM,WCO DMXML schemas)

Output Collection of Document Document Data Electronicdocuments, forms Data Data Dictionary Document(s)and messages. Dictionary Dictionary with (If using theOptional Business for each compilation for mapping to WCO DM,Process description document each document reference Customized XML(UML Diagrams) family data model schemas and

XML messagesin compliancewith WCO DM)


26

When conducting data harmonization and de-signing electronic trade documents, it is helpfulto use an approach of breaking down the taskinto smaller steps. Each step has a specificobjective and a defined output, which becomean input into the next step.

This stepwise approach is considered bestpractice and is recommended in different dataharmonization guides such as the APEC DataHarmonization Guide (APEC ESCG 2009) andthe Single Window Implementation Framework(SWIF 2010) developed under European Union(EU) Information Technology for Adoption andIntelligent Design for EGovernment (ITAIDE)Project. The stepwise approach is also imple-

mented and described in the data harmoniza-tion concept of UNECE Recommendation 34.

The steps and activities are summarized inTable 5.1.

Steps 1, 2, and 3 develop a simplified, stan-dardized and harmonized data set for crossborder trade. The Steps 4 and 5 explain themapping of the data set to a reference datamodel. The WCO DM is selected as a refer-ence data model in this Guide for illustrationbecause it is expected that many countriessupport the WCO DM as international standardfor B2G and G2G data exchange in crossborder trade.

5.1 Step 1: Capture Data Requirements of Business Documents Identifiedthrough Business Processes Analysis

Capture Define Analyse Reconcile eDocument

In a Single Window environment, documentsand information are used to drive businessprocesses. To simplify, standardize and auto-mate data and documents, one has to under-stand the business processes that generate oruse both the data and the documents.

The first step in a data harmonization projectis to collect all the data requirements inrelevant business documents by analyzing thetarget trade processes. This step will deliverthe list of trade documents that are used in adata harmonization project and a descriptionof the business processes in which thesedocuments are used.

A Business Process Analysis (BPA), a struc-tured, formal approach for capturing, analysingand simplifying business processes, is recom-mended in this step. The UNNExT BusinessProcess Analysis Guide to Simplify TradeProcedures22 provides guidelines for conduct-ing a BPA.

A BPA provides an “as-is” picture of businessprocesses in the current trade environment.By analysing the “as-is” processes andidentifying bottlenecks, recommendations canbe developed and implemented to obtain a“to-be” picture. This procedure leads to asimplification of the processes prior to theirautomation.

A BPA is conducted in three major phases asshown in Figure 5.1:

Phase I: Scope setting

Phase II: Data collection and processdocumentation

Phase III: Process analysis and recommen-dations development

The outcome of the data collection andprocess documentation in Phase II helps tounderstand the data requirements of the stake-holders in the supply chain. If the capturedbusiness processes are further simplified inthe “to-be” picture, data requirements are likelyto be simplified as well (ADB and ESCAP,2009).

22 For more see: http://www.unescap.org/unnext/tools/business_process.asp

27

Figure 5.2 illustrates two types of Unified Mod-elling Language (UML) diagrams used in theUNNExT BPA Guide for visualization of busi-ness processes – Use Case diagram and Ac-tivity diagram.

The primary purpose of the Use Case diagramis to describe the main activities and actorsthat are included in a BPA (See Figure 5.1 asan example). The diagram provides the frame-work and the terms of reference for the de-tailed analysis of the processes in the activitydiagrams.

Each activity diagram is an elaboration of ause case or business process. It describeshow each business process, denoted by a usecase in a use case diagram, is carried outstep-by-step, who is responsible for carrying

which activity, what documentary requirementsare involved, and how the information flows.An example of UML activity diagram is shownin Figure 5.3, which is an elaboration of “Ob-tain Export Permit” use case. This activity dia-gram describes how an exporter or representa-tive obtains an export permit; documentary re-quirements, denoted by rectangles, can beeasily spotted.

From activity diagrams, one can generate a listof paper documents and electronic documentsor messages that fall into the scope of thedata harmonization project. The name of theparty responsible for issuing each paper docu-ment and electronic document or message canalso be located. Figure 5.4 shows a list offorms captured from activity diagrams in anactual BPA.

Figure 5.1. Stepwise approach to Business Process Analysis

Phase I

ProcessAnalysts

Process Participants/Business Domain Experts

Project Manager/Project Leader

ProjectSponsor

Phase II

Phase III

1) Define a projectscope

2) Develop a detailedplan and secure

resources

3) Acquirebackground information

4) Conductinterviews and document

captured data

5) Analyze the “as-is”process and identify

bottlenecks

6) Develop and proposerecommendations

Source: UNNExT, 2009.

5. The Step-By-Step Approach for Data Harmonization and Development of Electronic Trade Documents


28

Source: UNNExT, 2009

Figure 5.2. UML diagrams used in Business Process Analysis

Figure 5.3. Activity diagram for “Obtain Export Permit” use case

Obtain ExportPermit

Exporteror Representative

Departmentof Foreign

Trade

Exporter or Representative Department of ForeignTrade

Collect A, 4

Verify submittedinformation

Incorrect

Correct

Sign andauthenticate

A, 4

Permit for the Exportof Rice (A, 4)

Prepare documentsfor the application of

export permit

Draft Permit forthe Export of

Rice (A, 4)

Sales Report(KP 3)

Evidence ofSales (PurchaseOrder or Sales

Contract)

Application forPermission toExport Rice

(KP, 2)

Application forthe Collectionof the Permitfor the Exportof Rice (A, 3)

29

Often a BPA is carried out as an independentproject, before data harmonization. Not everydata harmonization project might be able tosecure resources and time for a formal Busi-ness Process Analysis project. If it is not pos-sible to conduct a formal BPA, then at leastthe most basic information on documents anddata included in the data harmonization projectshould be collected. The information thatneeds to be collected in this step includes:

List of forms Sample documents (forms with sample

data) Information on how the document is used

(who issues the document, who approves/certifies the document, who uses the infor-mation)

Box completion guidelines, rules andregulations on filling the data, relevantinternational conventions

Rules, regulations and laws that govern theuse of the document

Description on electronic documents (XMLSchemas, EDI Message ImplementationGuides, sample messages)

Code list used when filling in forms or byelectronic documents

Figure 5.5 shows an example of a documentthat can be collected in the process ofcapturing documentary requirements; it is theAssociation of South-East Asian Nations(ASEAN) Trade in Goods Agreement (ATIGA)Form D in the UNLK format. The form itselfsuggests data requirements that must befulfilled by the relevant party. Examples ofdata that are required for this documentinclude data about the exporter, an importer, aconveyance route, a product, a country thatissued the certificate and the purpose of theform.

Its Overleaf Notes shown in Figure 5.6 pro-vides valuable information that helps improveits users’ understanding about how to enter thedata and how to use the form.

1. Proforma Invoice2. Purchase Order3. Application for Permission to Export Rice4. Sales Report5. Application for the Collection of the Permit for the Export of Rice6. Permit for the Export of Rice7. Application for Certificate of Standards of Product8. Rice Quality Certificate9. Certificate of Standards of Products10. Application for Phytosanitary Certificate11. Booking Request Form – Border Crossing12. Booking Confirmation – Border Crossing13. Booking Request Form – Inland Transport14. Booking Confirmation – Inland Transport15. Cargo Insurance Application Form16. Commercial Invoice17. Letter of Credit18. Packing List

Figure 5.4 Sample list of forms captured from Activity Diagrams

19. Cover Note20. Bill of Lading21. Insurance Policy22. Export Declaration23. Good Transition Control List24. TKT 308.225. Equipment Interchange Report (EIR)26. Container Loading List27. Container List Message28. Outward Container List29. Manifest30. Phytosanitary Certificate31. Certificate Origin32. Application for Certificate of Origin33. Application for Letter of Credit34. Credit Advice35. Debit Advice36. Remittance Advice

Source: UNNExT, 2009



30

13. Third Country Invoicing

Accumulation

Back-to-Back CO

Partial Cumulation

Figure 5.5. Image of the ASEAN ATIGA Form D

1. Goods consigned from (Exporter’s business name,address, country)

Reference No.ASEAN TRADE IN GOODS AGREEMENT/

ASEAN INDUSTRIAL COOPERATION SCHEMECERTIFICATE OF ORIGIN

(Combined Declaration and Certificate)


2. Goods consigned to (Consignee’s name, address, country)

3. Means of transport and route (as far as known)Departure dateVessel’s name/ Aircraft etc.Port of Discharge

4. For Official Use

Preferential Treatment Given Under ASEAN Tradein Goods Agreement

Preferential Treatment Given Under ASEANIndustrial Cooperation Scheme

Preferential Treatment Not Given (Please statereason/s)

Signature of Authorised Signatory of the ImportingCountry

..................................................................................................................................................

5. Itemnumber

6. Marks andnumbers onpackages

7. Number and type ofpackages, description ofgoods (including quantitywhere appropriate and HSnumber of the importingcountry)

8. Origin criterion(see OverleafNotes)

9. Gross weight orother quantityand value(FOB)

10. Number anddate ofinvoices

11. Declaration by the exporter

The undersigned hereby declares that the above detailsand statement are correct; that all the goods wereproduced in

(Country)

and that they comply with the origin requirementsspecified for these goods in the ASEAN Trade inGoods Agreement for the goods exported to

(Importing Country)

Place and date, signature ofauthorised signatory

..........................................................................................................................

..........................................................................................................................

..........................................................................................................................

12. Certification

It is hereby certified, on the basis of control carried out,that the declaration by the exporter is correct.

Place and date, signature and stamp ofcertifying authority

..........................................................................................................................

Exhibition

De Minimis

Issued Retroactively

31

OVERLEAF NOTES1. Member States which accept this form for the purpose of preferential treatment under the ASEAN Trade in Goods

Agreement (ATIGA) or the ASEAN Industrial Cooperation (AICO) Scheme:

BRUNEI DARUSSALAM CAMBODIA INDONESIALAO PDR MALAYSIA MYANMARPHILIPPINES SINGAPORE THAILANDVIETNAM

2. CONDITIONS: The main conditions for admission to the preferential treatment under the ATIGA or the AICO Scheme arethat goods sent to any Member States listed above must:(i) fall within a description of products eligible for concessions in the country of destination;(ii) comply with the consignment conditions in accordance with Article 32 (Direct Consignment) of Chapter 3 of the ATIGA; and(iii) comply with the origin criteria set out in Chapter 3 of the ATIGA.

3. ORIGIN CRITERIA: For goods that meet the origin criteria, the exporter and/ or producer must indicate in Box 8 of thisForm, the origin criteria met, in the manner shown in the following table:

Figure 5.6. Overleaf Note of the ASEAN ATIGA Form D

Circumstances of production or manufacture in the first countrynamed in Box 11 of this form

(a) Goods wholly obtained or produced in the exporting MemberState satisfying Article 27 (Wholly Obtained) of the ATIGA

(b) Goods satisfying Article 28 (Non-wholly obtained) ofthe ATIGA

Regional Value Content

Change in Tariff Classification

Specific Processes

Combination Criteria

(c) Goods satisfying paragraph 2 of Article 30 (PartialCumulation) of the ATIGA

Insert in Box 8

“WO”

Percentage of Regional Value Content, example“40%”The actual CTC rule, example “CC” or “CTH” or“CTSH”“SP”The actual combination criterion, example “CTSH+ 35%”“PC x %, where x would be the percentage ofRegional Value Content of less than 40%,example “PC 25%”

4. EACH ARTICLE MUST QUALIFY: It should be noted that all the goods in a consignment must qualify separately in theirown right. This is of particular relevance when similar articles of different sizes or spare parts are sent.

5. DESCRIPTION OF PRODUCTS: The description of products must be sufficiently detailed to enable the products to beidentified by the Customs Officers examining them. Name of manufacturer and any trade mark shall also be specified.

6. HARMONISED SYSTEM NUMBER: The Harmonised System number shall be that of in ASEAN Harmonised TariffNomenclature (AHTN) Code of the importing Member State.

7. EXPORTER: The term “Exporter” in Box 11 may include the manufacturer or the producer.8. FOR OFFICIAL USE: The Customs Authority of the importing Member State must indicate () in the relevant boxes in

column 4 whether or not preferential treatment is accorded.

9. MULTIPLE ITEMS: For multiple items declared in the same Form D, if preferential treatment is not granted to any of theitems, this is also to be indicated accordingly in box 4 and the item number circled or marked appropriately in box 5.

10. THIRD COUNTRY INVOICING: in cases where invoices are issued by a third country, “the Third Country Invoicing” box shouldbe ticked () and such information as name and country of the company issuing the invoice shall be indicated in box 7.

11. BACK-TO-BACK CERTIFICATE OF ORIGIN: In cases of Back-to-Back CO, in accordance with Rule 11 (Back-to-backCO) of Annex 8 of the ATIGA, the “Back-to-Back CO” box should be ticked ().

12. EXHIBITIONS: In cases where goods are sent from the exporting Member State for exhibition in another country and soldduring or after the exhibition for importation into a Member State, in accordance with Rule 22 of Annex 8 of the ATIGA,the “Exhibitions: box should be ticked () and the name and address of the exhibition indicated in box 2.

13. ISSUED RETROACTIVELY: In exceptional cases, due to involuntary errors or omissions or other valid causes, theCertificate of Origin (Form D) may be issued retroactively, in accordance with paragraph 2 of Rule 10 of Annex 8 of theATIGA, the “Issued Retroactively” box should be ticked ().

14. Accumulation: In cases where goods originating in a Member State are used in another Member State as materials forfinished goods, in accordance with paragraph 1 of Article 30 of the ATIGA, the “Accumulation” box should be ticked ().

15. PARTIAL CUMULATION (PC): If the Regional Value Content of the material is less than forty percent (40%), theCertificate of Origin (Form D) may be issued for cumulation purposes, in accordance with paragraph 2 of Article 30 of theATIGA, the “Partial Cumulation” box should be ticked ().

16. DE MINIMIS: If a good that does not undergo the required change in tariff classification does not exceed ten percent(10%) of the FOB value, in accordance with Article 33 of the ATIGA, the “De Minimis” box should be ticked ().



32

The purpose of this step is to obtain a precisedescription of the data requirements. The datais described and specified using the definitionsand terminology of business users and ex-perts, for example buyer/seller, Customs officeror freight forwarder. This forms a basis for asolid understanding of the semantic of thedata, its type, representation, format, andconstraints, which is crucial for the automationof the information flow at a later stage. Anyambiguity in the meaning and the usage ofdata elements delays the process of harmo-nizing the attributes of these data elementswith the selected semantic rules, and createsinconsistency in the mapping.

When this step is completed, a data dictionaryis available for each document identified inStep 1, which describes in detail the dataelements contained in the document from auser point of view. A data dictionary providesdefinitions for the data elements in a form.Good sources to identify exact meaning ofdata are often collected during the businessprocess analysis, especially during Phase II.Examples are:

Document/form, with sample fill-in dataand/or box completion guideline if available

EDI Message Implementation Guide User Interface (Data Entry Screens), with

its data dictionary if available Interviews with users of the document

A Data Dictionary of one document can con-tain the following pieces of information:

Document title Document purpose Name of document owner Identification number for each data element

name such as the box number in the docu-ment

Name of each data element as it appearsin a document

Definition of each data element in locallanguage and/or English as given by theowner of the document and/or relevantstandard such as WCO Data Model,UNTDED, and UN/CEFACT Core Compo-nent Library

Format (alphabetic, numeric, alpha-nu-meric) and size (length of a data element,value in terms of digits or characters) ofeach data element

Constraint on the occurrence of each dataelement (MinOccurs, MaxOccurs)

Code lists and subsets of code lists

Data modellers must have a solid understand-ing of data elements in terms of definition,data type, data format, and data constraints inactual operation. They should maintain closeconsultation with the document owner whendefining the data elements of a specific docu-ment to ensure that the data definitions arecorrect.

Table 5.2 shows an example of a data dictio-nary. The data dictionary is made for theASEAN ATIGA Form D issued by ASEAN na-tional government (See Annex 1 for the fulldata dictionary). In this case, the definition anddata representation format of each dataelement are drawn from UNTDED and WCODM v3.0.

The data elements of the compiled datadictionary were primarily extracted from thedata element names specified on the paperform of ASEAN ATIGA Form D with additionalreference to the information provided inthe overleaf note. Correspondence of dataelements between paper form and thecompiled data dictionary is illustrated inFigure 5.7.


5.2 Step 2: Define Data in Each Document and Define the Semantic of the Dataand the Data Formats

33

The definitions required at this point are fromthe perspective of the users of the document.Depending on the circumstances of the dataharmonization project, it may be necessary toprovide more than one definition for the dataelement. For example:

The definition of the data element in thenational/original language, as given in thenational legislation, administrative instruc-tions, etc.; and,

The definition of this data element takenfrom an international repository of definition

of trade terms such as the UNTDED or theWCO Data Element Directory. Some docu-ments are governed by international con-ventions which include definitions of dataelements, for example the TIR, Conventionon International Trade in Endangered Spe-cies of Wild Fauna and Flora (CITES) orConvention on the Contract for the Interna-tional Carriage of Goods by Road (CMR).The data definitions could also be includedin the Data Dictionary. When defining thedata elements, definitions from an interna-tional standard should always be includedin the Data Dictionary.

Table 5.2. Example of document data dictionary (ASEAN ATIGA Form D)

Document Title ASEAN ATIGA FORM DDocument Purpose A Certificate of Origin is a document/message identifying goods, in which the

authority or body authorized to issue it, certifies expressly that the goods towhich the certificate relates originate in a specific country.

Name of Document Owner Issuing Authorities, ASEAN Nations

ASEAN ATIGA FORM D Data

0-1 Reference NumberTDED 1004: Reference number identifying a specific document. an..35(Min=1, Max=1)

1 Goods consigned from (Exporter’s business name, address, country)TDED 3036: Name (and address) of the party consigning the goods as stipulated in the contract by the partyordering the transport (This may be the exporter or seller.) an..35(Min=1, Max=1)

2 Goods consigned to (Consignee’s name, address, country)TDED 3132: Name and address of party to which goods are consigned an..512(Min=1, Max= 1)

3-1 Departure dateTDED 2380: The value of a date, a date and time, a time or of a period in a specified representation. an..35(Min=1, Max= 1)

3-2 Vessel’s name/aircraft etc.TDED 8212: Name of a specific means of transport such as the vessel name an..35(Min=1, Max= 1)

3-3 Port of dischargeTDED 3224: Name of a location. an..256(Min=1, Max=1)

4 For official use (Declaration Type)TDED 1001: Code specifying the name of a document. an..3(Min=1, Max=1)

5 Item No.TDED 1050: To identify a position within a sequence an..10(Min=1, Max=1)



34

Figure 5.7. Mapping of data between paper form and compileddata dictionary with UNTDED

13. Third Country

Invoicing

Accumulation

Back-to-Back CO

Partial Cumulation

1. Goods consigned from (Exporter’sbusiness name, address, country)

2. Goods consigned to (Consignee’sname, address, country)

Reference No.ASEAN TRADE IN GOODS

AGREEMENT/ ASEAN INDUSTRIALCOOPERATION SCHEMECERTIFICATE OF ORIGIN

(Combined Declaration andCertificate)


3. Means of transport and route(as far as known)

Departure date

Vessel’s name/ Aircraft etc.

Port of Discharge

4. For Official Use

Preferential Treatment GivenUnder ASEAN Trade in GoodsAgreement

Preferential Treatment GivenUnder ASEAN IndustrialCooperation Scheme

Preferential Treatment NotGiven (Please state reason/s)

Signature of AuthorisedSignatory of the ImportingCountry

...............................................................

5. Itemnumber

6. Marksandnum-bersonpack-ages

7. Number andtype ofpackages,description ofgoods(includingquantity whereappropriateand HSnumber of theimportingcountry)

8. Origincriterion(seeOverleafNotes)

9. Grossweightor otherquantityandvalue(FOB)

10. Numberanddate ofinvoices

11. Declaration by the exporter

The undersigned hereby declaresthat the above details andstatement are correct; that allthe goods were produced in

(Country)

and that they comply with theorigin requirements specified forthese goods in the ASEAN Tradein Goods Agreement for thegoods exported to

(Importing Country)

Place and date, signatureof authorised signatory

......................................................

......................................................

......................................................

12. Certification

It is hereby certified, on thebasis of control carried out, thatthe declaration by the exporter iscorrect.

Place and date, signature andstamp of certifying authority

...........................................................

Exhibition

De Minimis

IssuedRetroactively

ASEAN ATIGA FORM D Data

0-1 Reference NumberTDED 1004: Reference number identifying aspecific document. an..35(Min=1, Max=1)

1 Goods consigned from (Exporter’s businessname, address, country)TDED 3036: Name (and address) of the partyconsigning the goods as stipulated in the contractby the party ordering the transport (This may bethe exporter or seller.) an..35(Min=1, Max=1)

2 Goods consigned to (Consignee’s name,address, country)TDED 3132: Name and address of party to whichgoods are consigned an..512(Min=1, Max= 1)

3-1 Departure dateTDED 2380: The value of a date, a date and time,a time or of a period in a specified representation.an..35(Min=1, Max= 1)

3-2 Vessel’s name/aircraft etc.TDED 8212: Name of a specific means of trans-port such as the vessel name an..35(Min=1, Max= 1)

3-3 Port of dischargeTDED 3224: Name of a location. an..256(Min=1, Max=1)

4 For official use (Declaration Type)TDED 1001: Code specifying the name of adocument. an..3(Min=1, Max=1)

5 Item No.TDED 1050: To identify a position within a se-quence an..10(Min=1, Max=1)

35

The purpose of this step is to organize dataspecifications from different documents in acomparable manner. This step facilitates aconsistent mapping of the data elements to adata model, which is done in the next step.

The compilation of data requirements is basedon data definition, i.e. data elements from vari-ous documents with identical definition areplaced in the same row.

To ensure consistent mapping, Data Dictionar-ies should be compiled in such a way thatthey belong to the same type of tradedocument. The following categories aresuggested23:

Category 1 includes documents that arerelated to commercial transaction andpayment.

Category 2 includes documents for tran-sport and official control that provide infor-mation on a single consignment (e.g. cus-toms declaration).

Category 3 includes documents of transportand official control that provide informationon multiple consignments (e.g. manifest).

Organizing Data Dictionaries in this mannerfacilitates the mapping of the data elementswith the reference data model in step 4.

Table 5.3 provides an example of trade docu-ments and their categorization in documentfamilies Upon completion of this step, a datadictionary compilation is available for eachdocument family. Table 5.4 shows an exampleof a data dictionary compilation, illustrating thecomparison of ASEAN ATIGA Form D with twoThai export forms.

Data elements that occur in several docu-ments may have identical names but showdifferences in definitions, data representation,code lists, or usage. The difference impliesthat these data elements will be mappedto different data structures of the datamodel.

5.3 Step 3: Analyse Data Elements across Various Documents and OrganizeThem in a Comparable Manner


23 Annex IV-2 provides an example of trade documentsgrouped under the different document families. Anexample for the categorization of a set of nationaltrade documents used in the export of Jasmine Ricefrom Thailand into UNLK document families is givenin Annex IV-2 of this Guide.


5.4 Step 4: Map Data Elements to Reference Data Model


Mapping is the process of linking an elementin one dictionary with a semantically equivalentelement in another dictionary. A data dictionarycontains data element descriptions of nationaltrade documents defined from the perspective

of a business expert. In Step 4, these dataelements are mapped to semantically equiva-lent data elements in a reference data model.In this Guide, the WCO DM is used as areference data model for the purpose ofillustration. Data elements in the WCO DMdescribe the same data with the detailedstructure and precision required for automatedinformation processing.

The output of the mapping in Step 4 is the listof data elements of a reference data model,the WCO DM in the case of illustration in this


36

Table 5.3. Example of document categorization

Process UNLK Document Family Documents

• All documents exchanged between partners in international trade forthe invitation to tender, through the exchange between prospective

Buy Commercial Transaction seller and prospective buyer to the inclusion of contract, i.e.,Enquiry/Request for Quotation/Offer Invitation; Offer/Quotation; Order;Acknowledgement of Order/Pro-forma Invoice; Dispatch Advice

• Instructions from customers to forwarders, i.e., Forwardinginstructions

• Goods receipts, i.e., Forwarder’s warehouse receipt; Dock receipt;Warehouse (shed) receipt

Forwarding • Advice documents, i.e., Forwarder’s advice to import agent,and Cargo Forwarder’s advice to exporterHandling • Authorization and instructions, i.e., Delivery order; Handling order;

Gate pass• Administrative documents, i.e., Forwarder’s invoice; Port charges

documents

• Contract documents, i.e., Bill of Lading; Waybills; Rail and roadTransport consignment notes; Dispatch notes for post parcelsand Related • Receipt documents, i.e., Receipt of goods for carriage; Mate’sServices receipt; Certificate of transport

Transport • Contents documents listing foods in transport units or means oftransport, i.e., Cargo and freight manifests

• Administrative and legal documents, i.e., Road list; Discharge report• Notification documents, i.e., Booking confirmation, Arrival notice;

Delivery notices

• Insurance agreements, i.e., Insurance contract; Insurance policy;Ship Insurance Insurance certificate

• Notification documents, i.e., Insurance notice; Cover note• Administrative documents, i.e., Premium notice; Insurer’s invoice

• Collection of customs duties and taxes safeguarding of revenue, i.e.,Customs goods declaration; Cargo Declaration; Customs invoice;Transit bond-notes

• Quantitative restrictions on exports and imports, i.e., Application forexport/import licenses; Export/import licenses

• Controls and restrictions regarding exchange, i.e., Application forexchange allocation; Foreign exchange permit

• Sanitary, veterinary and plant controls, i.e., Phytosanitary, SanitaryOfficial Controls and Veterinary certificates; Application for such certificates

• Controls of quality and product standards, i.e., Goods control andinspection certificates; Application for such certificates

• Granting of preferential treatment for goods of certain origin, i.e.,Certificate of Origin; Application for such certificates

• Restrictions imposed to safeguard public security, cultural heritage,etc., i.e., Dangerous goods declaration

• Collection of foreign trade statistics, i.e., Statistical documents forexport/import

• Instructions (or applications) from customers to banks, i.e.,Instruction for bank transfer; Application for banker’s draft;Application for banker’s guarantee; Collection order; Documentarycredit application

Pay Payment • Advice or information from banks to customers or to beneficiaries ofpayment, i.e., Collection payment advice; Documentary creditpayment; Acceptance or negotiation advice; Documentary credit;Banker’s guarantee

• Information exchanged between banks

37

Guide, that are needed for national crossborder data exchange. These data elementsform a subset of the WCO DM. This subsetcan be called the national Data Model. Thenational data model will be used in the finalstep to produce the specifications for thenational electronic trade documents.

The main task in this step is to map the dataelements in the compiled data dictionarywith their corresponding components in theWCO DM. The corresponding component inthe WCO DM is identified with the WCO ID,an alphanumeric unique identifier of the dataelement in the Data Model. It is recommended

Table 5.4. Example of data dictionary compilation

ASEAN ATIGA FORM D Permit for the Export of Rice Certificate of Standards ofA Certificate of Origin certifies (A. 4) Products (MS. 24)expressly that the goods to Permit for the Export of Rice Certificate of Standards ofwhich the certificate relates (A. 4) is only given to rice Products (MS. 24) certifies thatoriginate in a the specific exporters who follow the Ministry rice to be exported has thecountry. Issuing Authorities, of Commerce’s Regulation quality set by importer.Thailand for Rice Exportation 1997. Board of Trade of Thailand

Department of Foreign Trade,Ministry of Commerce, Thailand

11 Place of departure 20 Place of departureTDED 3214: Name of the port, TDED 3214: Name of the port,airport or other type of location airport or other type of locationfrom which a means of transport is from which a means of transport isscheduled to depart or has scheduled to depart or hasdeparted departedan.. 256 (Min = 1, Max = 1) an.. 256 (Min = 1, Max = 1)

11-2 Country of Exportation 5 Destination country 21 Country of destination ofTDED 3229: Country subdivision TDED 3216:Name of the country to goodswhere goods begin their journey which the goods are to be TDED 3014: Name of the countryto export location delivered to the final consignee or to which a consignment of goodsan..9 (Min=1, Max=1) buyer is to be or has been delivered

an..35 (Min = 1, Max = 1) an..35 (Min = 1, Max = 1)

5 Item No. 12 Line itemTDED 1050: To identify TDED 1082: An identifiera position within a sequence. differentiating an individual linen..10 (Min = 1, MAX = unbounded) item from within a series

an..6 (Min = 1, Max = unbounded)

9-2 Item Price 17 Price (FOB) 13 FOB AmountTDED 5032: Amount declared for TDED 5032: Amount declared for TDED 5032: Amount declared forCustoms purposes of those goods customs purposes of those goods customs purposes of those goodsin a consignment which are in a consignment which are subject in a consignment which aresubject to the same Customs to the same customs procedure, subject to the same customsprocedure, and have the same and have the same tariff/statistical procedure, and have the sametariff/statistical heading, country heading, country information and tariff/statistical heading, countryinformation and duty regime. duty regime information and duty regimean..18 (Min = 1, Max = an..18 (Min = 1, Max = unbounded) an..18 (Min = 1, Max =unbounded) unbounded)

6 Marks and Numbers on 18 Marks and numbers onPackages packagesTDED 7102: Free form description TDED 7102: Marks and numbersof the marks and numbers on a identifying individual packagestransport unit or package. an..512 (Min = 1, Max = 1)an..512 (Min = 1, Max = 1)



38

that the data modellers record the mappingresult by extending the compiled data dictio-nary with an additional column containing theWCO ID. The sample output of the mapping is

shown in Table 5.5. Due to limitation in space,the Table includes only some part of onesample document, the Certificate of Origin(CoO) (See Annex II for fully mapped list).

Table 5.5. Data dictionary of Certificate of Origin (ASEAN ATIGA Form D)mapped to WCO Data Model 3.0

ASEAN ATIGA FORM D Data WCO Data Model WCO DictionaryID Classes Entry Name

0-1 Reference Number D014 Declaration Declaration.TDED 1004: Reference number identifying a Identification.specific document. an..35 Identifier(Min=1, Max=1)

1 Goods consigned from (Exporter’s business R031 Exporter Exporter. Name. Textname, address, country)TDED 3036: Name (and address) of the partyconsigning the goods as stipulated in the contractby the party ordering the transport (This may bethe exporter or seller.)(Min=1, Max=1)

2 Goods consigned to (Consignee’s name, R037 Importer Importer. Name. Textaddress, country)TDED 3132: Name and address of party to whichgoods are consigned an..256(Min=1, Max= 1)

3-1 Departure date 030 Goods Shipment GoodsShipment.TDED 2380: Date and optionally time of the Departure. Datetimedeparture of the goods from original consignor.an..35(Min=1, Max= 1)

3-2 Vessel’s name/aircraft etc. T001 Arrival Transport ArrivalTransportMeans.TDED 8212: name of specific means of transport Means Name. Textsuch as vessel name an..35(Min=1, Max= 1)

3-3 Port of discharge L012 Unloading Location UnloadingLocation.DED 3224: Name of a location an..256 Name. Text(Min=1, Max=1)

4 For official use (Declaration Type) D013 Declaration Declaration. Type.TDED 1001 : Code specifying the name of a Codedocument. an..3(Min=1, Max=1)

5 Item No. 006 Commodity Commodity.TDED 1050: Number indicating the position in a Sequence. Numericsequence n..10(Min=1, Max=1)

The following example explains how the map-ping process is done technically:

The data modelers map each data elementof the compiled Data Dictionary with theequivalent data element from the WCOData Model. The distribution of the WCODM includes the Data Model Class and

Dictionary entry name which are includedin an Excel table called the “Interactive DataSet”. Open the Excel file “WCO Data ModelVersion 3.0 – The Interactive Data Set” byclicking the green icon, the one circled inFigure 5.8. The spreadsheet also containsexplanatory notes that explain the data inthe spreadsheet.

39

Figure 5.8. WCO DM 3.0 with link to the Interactive Data Set

For the mapping exercise in this step themost important column is the “UID” Columnwhich identifies the UNTDED tag of the dataelement and the “WCO ID” column which

identifies the corresponding WCO ID. Theinformation can be found in the tabs “Data SetVersion 3” or in the “Super class” tabs markedin orange color.


When mapping to the WCO Data Model, thedata modeler need to deal with the followingcases:

One TDED Data Element maps toexactly one WCO Data Element

Ideally, by searching the column “UID” with aTDED tag, the data modeler obtains onesingle WCO Data Element. In Table 5.4 thedata element in box “Marks and numbers on

packages” of the CoO is mapped to TDED“7102” which corresponds to WCO ID “142”.

One TDED Data Element maps to morethan one WCO Data Element

In the WCO Data Model, one TDED ele-ment can be mapped to several WCO ID’s.For example, TDED element “7002” can bemapped to either WCO ID “137” or “258”as shown below. The two WCO Data Ele-


40

WCO details WCO details UNTDEDDetails

WCO Name Definition Data Model Format Code UID NameID Classes remarks

142 Shipping Free form Package x x x an. 512 UN/ECE 7102 Goods xmarks description of the Recom- Item.

marks and menda- Shippingnumbers on a tion 15 Marks. Texttransport unit orpackage.

Impo

rtEx

port

Con

veya

nce

Tran

sit

Res

pons

e

SAFE

DEN

s

WCO details WCO details UNTDEDDetails

WCO Name Definition Data Model Format UID NameID Classes

137 Description Plain language Commodity x x x an. 512 7002 Goods xof goods description of the Item.

nature of a goods Descriptionitem sufficient to Textidentify it forcustoms, statisticalor transportpurposes.

258 Commodity A name or a term Commodity x x an. 35 7002 Goodsname that identifies the Item.

goods are Descriptionassigned by a Textseller as distinctfrom those of othersellers, also knownin legal terms astrademark. A brandhelps to identifyone item, a familyof items, or allitems of that seller.

Impo

rtEx

port

Con

veya

nce

Tran

sit

Res

pons

e

SAFE

DEN

s

ments have a different semantic. The datamodeller needs to analyse how the dataelement is used in trade document anddecide which of the two mappings providesthe best match. Obviously, the BusinessProcess Analysis made in Step 1 can nowgive valuable information for the decision.For example the box “Description of goods”of the CoO should be mapped to WCO ID“137”.

One TDED Data Element does not havea direct mapping to a WCO Data ModelData Element

In the WCO DM, some data elements aremapped to a generic TDED tag instead ofa specified one. The box “Supplementarydetails” in CoO can be mapped to TDED“4142” (Document.Information.Text). Forthis data element there is no direct map-

41

ping in WCO DM V 3.0. Instead all relateddata elements of the WCO DM 3.0 aremapped to the generic TDED data element“4440” (Free Text. Text) as shown below.

In the example of the CoO Box “Supple-mentary Details,” the TDED 4142 shouldbe mapped to WCO ID “225” (Additionalstatement text).

WCO details WCO details UNDED1 Details

WCO Name Definition Data Model Format Code UID NameID Classes remarks

45 105 Free text Free text field Additional x x x x an. 512 4440 Free Text.available to the Information Textmessage senderfor information.

117 225 Additional Description of an Additional x x x x an. 512 Certifi- 4440 Free Text.Statement additional Information cate Texttext statement text

172 304 Criteria A statement Commodity x an. 512 4440 Free Text.confor- indicating specific Textmance conformance withtext statutory and

regulatoryrequirements

229 362 Package Free text Commodity x an. 256 4440 Free Text.filler description of the Related subjectdescription material found Packaging code

within a packageused to cushionthe commodity orotherwise emptyspace.

231 364 Ship-to-ship Text description of Border x an. 256 4440 Free Text.activity ship-to-ship activity Transport Text

Means

Impo

rtEx

port

Con

veya

nce

Tran

sit

Res

pons

e

SAFE

DEN

s

A B C D E F G H I J K L M N O

432


Data Element in Super Class Table

In the WCO Data Model Version 3.0, certaindata elements that belong to frequently usedobject classes are grouped together in socalled “Super Classes”. There are five superclasses in the Data Model: Document, Govern-ment Agency, Location, Party and TransportMeans. The data elements of the SuperClasses are located in separate tables of thespreadsheet with orange coloured tags. If aUNTDED element cannot be found in the table

“Data Set Version 3” then the table of theappropriate super class should be searched.

National Data Requirements that are notincluded in the WCO Data Model

There may be national data requirements thatare not included in the WCO Data Model.These data requirements need to be analysedcase by case. It is recommended to leavethese data elements to national/internationalexperts with advanced experience in building


42

Data Models. They can advise on the appro-priate way forward. An organization conductingnational data harmonization may submit arequest to the WCO for inclusion of the data

element into a future release of the WCOData Model. For this purpose, WCO hasdefined the procedure for submitting “DataMaintenance Requests”.

5.5 Step 5: Obtain the Structure of an Electronic Document


Once you are done with reconciling yournational data set with an internationally recog-nized data model, you can move to obtain thestructure of electronic document, which will beused for data interchange among stakeholders.Depending on your business requirements,specific syntax can be applied in obtaining thestructure of electronic document such as XMLand Electronic Data Interchange (EDI) (SeeBox 2). Obtaining the structure of an elec-tronic document demands technical capacity inavailable syntaxes and relevant technical stan-dards.

Though the ultimate purpose of data harmoni-zation is its use for obtaining the structure ofan electronic document in an interoperablemanner, it is beyond the scope of this Guideto cover the method to obtain the structureof an electronic document. However, in thisGuide, illustration serves to make readers

aware of how to obtain the structure of elec-tronic document using XML syntax, in particu-lar packages available in the WCO DM 3.0.

In the case of using the WCO DM, the ele-ments of the WCO DM can be mapped toXML structures to develop the XML Schemasfor the national trade documents at this step.An XML Schema is a specification thatdescribes the data structures of an electronicXML message. The Schema is the equivalentof the paper form in an electronic format. Thepublication of the WCO DM includes XMLSchemas that can be adapted to buildthe XML Schemas of the national tradedocuments.

The XML Schemas provided with the WCODM 3.0 include all data elements for a set oftop level business processes. These Schemasare generic because they can support the data

Box 2: XML and EDI

Extensible Markup Language (XML) is a set of rules for encoding documents in machine-readable form. It isdefined in XML Specifications, produced by the World Wide Web Consortium (W3C), and several other relatedtechnical specifications. http://www.w3.org/XML/

Due to its nature of extensibility, multiple entities, including standards bodies, define electronic messages withtheir own rules based on the XML specification. UN/CEFACT also publishes standard XML message schemasbiannually, which are available at http://www.unece.org/uncefact/xml_schemas/index.htm

Electronic Data Interchange (EDI) is the structured transmission of data between organisations by electronicmeans; i.e., the computer-to-computer interchange of strictly formatted messages that represent documentsother than monetary instruments. There exist multiple national EDI standards. However, the only internationalEDI standard is UN/EDIFACT (United Nations rules for Electronic Data Interchange for Administration,Commerce and Transport). More details on UN/EDIFACT can be found at http://live.unece.org/tradewelcome/areas-of-work/un-centre-for-trade-facil i tation-and-e-business-uncefact/outputs/standards/unedifact/tradeedifactwelcome.html

43

requirements of several trade documents. Theobjective of this step is to identify those dataelements in the WCO Schemas that are actu-ally used in the national trade documents andto remove those data elements from theSchema that are not used in the nationalcontext.

By eliminating all data elements from thegeneric Schema that are not used in thenational trade document, a specific Schema isgenerated that exactly matches the datarequirements of the national document suchas the electronic Certificate of Origin or theCustoms declaration. This Schema can beused directly for paperless trade. It should benoted that the modification of XML Schemasrequires some detailed work and technicalexpertise which are not within the scope ofthis Guide. Instead, this Guide outlines thegeneral steps to obtain the specific Schemafor the electronic document.

Select the appropriate WCO Schema

The WCO Data Model provides a set of XMLschemas that are oriented on the CustomsProcedures specified in the revised KyotoConvention. For each document in the DataDictionary, the data modeller needs to identifythe WCO Schema that most closely meets thedata requirements of the trade document. If adetermination can not be made, the Schemaof the Declaration “DEC” should be taken as

this Schema includes maximum data require-ments.

Customise the WCO Schema by removingunused data elements

The modeller needs to remove all datarequirements from the Schema that are notspecified in the national trade document.The data elements that are used in nationaltrade documents are listed in the DataDictionary.

To remove the unused data elements theSchema is opened in an XML Editor. The dataelement name in the XML Schema is thesame as the WCO Dictionary Entry Name. Foreach data element in the Data Dictionary, themodeller will search in the Schema using the“Dictionary Entry Name”. This data element isthen marked in the Schema. When all dataelements of the Data Dictionary are marked inthe Schema then the unmarked data elementsof the Schema are removed.

Example:In the data dictionary for the ASEAN ATIGAForm D, the element Exporter is with theWCO DEN “Exporter. Name. Text”

In the XML Schema this dictionary entry nameis associated with XML tag “NameText” of Ob-ject Class “Exporter”.

ASEAN ATIGA FORM D Data WCO ID Data Model WCO DictionaryClasses Entry Name

Goods consigned from (Exporter’s business name, address,country)TDED 3036: Name (and address) of the party consigning the R031 Exporter Exporter.goods as stipulated in the contract by the party ordering the Name. Texttransport (This may be the exporter or seller.) (Min=1, Max=1)



44

<xsd:element name=“Name” type=“ds:ExporterNameTextType” minOccurs=“0”> <xsd:annotation> <xsd:documentation xml:lang=“en”> <ccts:UniqueID>WCOIDR031</ccts:UniqueID> <ccts:DictionaryEntryName>Exporter. Name. Text</ccts:DictionaryEntryName> <ccts:Definition>Name [and address] of party who makes – or on whose behalf – theexport declaration – is made – and who is the owner of the goods or has similar right of disposalover them at the time when the declaration is accepted.</ccts:Definition> <ccts:Cardinality>0..1</ccts:Cardinality> <ccts:ObjectClassTerm>Exporter</ccts:ObjectClassTerm> <ccts:PropertyTerm>Name</ccts:PropertyTerm> <ccts:RepresentationTerm>Text</ccts:RepresentationTerm> </xsd:documentation> </xsd:annotation></xsd:element>

At the end of this procedure, the Schemacontains only the elements that correspond tothe data elements of the document in the DataDictionary. This means the Schema representsthe electronic equivalent of the informationcontained in the document.

Figure 5.9 illustrates trimming down of aschema for customization. In the overallschema, each data element in the datadictionary are marked to be remained; in

Figure 5.9, the part contained in a blackbox are elements to be remained. The cus-tomization process is completed when all theunnecessary elements are removed from aschema while all the marked ones remain.

After the trimming down process has beencompleted, a customized schema suitable forASEAN ATIGA Form D is obtained, as shownin Figure 5.10 (See Annex III for full Schema).

45

Figure 5.9 Example of Schema trim-down for customization


<?xml version=”1.0” encoding=”UTF-8”?><?xml-stylesheet href=”GenHTML(vH).xslt” type=”text/xsl”?><xsd:schema xmlns="urn:wco:datamodel:WCO:DEC:1" xmlns:ds="urn:wco:datamodel:WCO:DS:1" xmlns:ccts="urn:un:unece:uncefact:documentation:standard:CoreComponentsTechnicalSpecification:2" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:wco:datamodel:WCO:DEC:1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">    <xsd:import namespace="urn:wco:datamodel:WCO:DS:1" schemaLocation="..\common\DS_1p0.xsd"/>    <xsd:element name="Declaration"> <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:Definition>Any statement or action, in any form prescribed or accepted by the Governmental Agency, giving information or particulars required by the Governmental Agency.</ccts:Definition> <ccts:Cardinality>1</ccts:Cardinality> <ccts:ObjectClassTerm>Declaration</ccts:ObjectClassTerm> </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="AcceptanceDateTime" type="ds:DeclarationAcceptanceDateTimeType" minOccurs="0"> <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID>WCOID023</ccts:UniqueID> <ccts:DictionaryEntryName>Declaration. Acceptance. Date Time</ccts:DictionaryEntryName> <ccts:Definition>Date on which a Goods declaration has been or will be accepted by Customs in accordance with Customs legislation.</ccts:Definition> <ccts:Cardinality>0..1</ccts:Cardinality> <ccts:ObjectClassTerm>Declaration</ccts:ObjectClassTerm> <ccts:PropertyTerm>Acceptance</ccts:PropertyTerm> <ccts:RepresentationTerm>Date Time</ccts:RepresentationTerm> </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="Authentication" type="ds:DeclarationAuthenticationTextType" minOccurs="0"> <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID>WCOID104</ccts:UniqueID> <ccts:DictionaryEntryName>Declaration. Authentication. Text</ccts:DictionaryEntryName> <ccts:Definition>Proof that a document has been authenticated indicating where appropriate the authentication party.</ccts:Defi> <ccts:Cardinality>0..1</ccts:Cardinality> <ccts:ObjectClassTerm>Declaration</ccts:ObjectClassTerm> <ccts:PropertyTerm>Authentication</ccts:PropertyTerm> <ccts:RepresentationTerm>Text</ccts:RepresentationTerm> </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="CancellationDateTime" type="ds:DeclarationCancellationDateTimeType" minOccurs="0"> <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:UniqueID>WCOID373</ccts:UniqueID> <ccts:DictionaryEntryName>Declaration. Cancellation. Date Time</ccts:DictionaryEntryName> <ccts:Definition>Date and time when the document/message was cancelled.</ccts:Definition> <ccts:Cardinality>0..1</ccts:Cardinality> <ccts:ObjectClassTerm>Declaration</ccts:ObjectClassTerm> <ccts:PropertyTerm>Cancellation</ccts:PropertyTerm> <ccts:RepresentationTerm>Date Time</ccts:RepresentationTerm> </xsd:documentation> </xsd:annotation> </xsd:element>


46

Figure 5.10 XML Schema for ASEAN ATIGA Form D

<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet href="GenHTML(vH).xslt" type="text/xsl"?><xsd:schema xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:6" xmlns:ds="urn:wco:datamodel:standard:WCO:DS:1"xmlns:ccts="urn:un:unece:uncefact:documentation:standard:CoreComponentsTechnicalSpecification:2"xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">



<xsd:import namespace="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:6" schemaLocation="http://www.unece.org/uncefact/data/standard/UnqualifiedDataType_6p0.xsd"/>

<xsd:import namespace="urn:wco:datamodel:standard:WCO:DS:1" schemaLocation="..\common\DS_1p0.xsd"/>

<xsd:element name="Declaration"><xsd:complexType>

<xsd:sequence><xsd:element name="AcceptanceDateTime" type="ds:DeclarationAcceptanceDateTimeType"/><xsd:element name="DeclarationOfficeID" type="ds:DeclarationDeclarationOfficeIDType"/><xsd:element name="ID" type="ds:DeclarationIdentificationIDType"/><xsd:element name="IssueDateTime" type="ds:DeclarationIssueDateTimeType"/><xsd:element name="TypeCode" type="ds:DeclarationTypeCodeType"/><xsd:element name="AdditionalDocument">

<xsd:complexType><xsd:sequence><xsd:element name="AuthenticationLocationName" type="ds:AdditionalDocumentAuthenticationLocationNameTextType"/><xsd:element name="IssueLocationID" type="ds:AdditionalDocumentIssueLocationIDType"/><xsd:element name="IssueLocation" type="ds:AdditionalDocumentIssueLocationTextType" minOccurs="0"/></xsd:sequence>

</xsd:complexType></xsd:element><xsd:element name="AdditionalInformation" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType><xsd:sequence><xsd:element name="Content" type="ds:AdditionalInformationContentTextType" minOccurs="0"/><xsd:element name="StatementCode" type="ds:AdditionalInformationStatementCodeType" minOccurs="0"/>

</xsd:sequence>

47

6.1 GAINING SUPPORT FOR DATAHARMONIZATION

The issue of data harmonization remains pri-marily in the technical and operational domainand is often not adequately communicated topolicy makers who make decisions. Data har-monization has to deal with many technicaldecisions and involves numerous parties andkey players in practice. To secure propersupport for data harmonization, the followingactivities are recommended:24

Establish an institutional mechanism formanaging data harmonization – An institu-tional arrangement should be made for man-aging the data harmonization initiative in theform of a steering committee or taskforce. Itis crucial that such an institution includes astrong lead agency that can coordinate andsynchronize the simplification and harmoni-zation of the trade data of the variousindividual agencies. The data harmonizationsteering committee or taskforce should in-clude not only high-level policy implementersbut also mid-level managers whose positionsare usually more stable in their post over alonger period. The members of such amanagerial institution should be selectedfrom individuals with managerial, technicaland organizational expertise; these peopleshould also have collaboration and commu-nication skills, because they are responsiblefor successful stakeholder management andgaining interagency support throughout adata harmonization initiative.

Identify main stakeholders, define their rolesand accommodate their objectives and con-cerns – Stakeholders include organizationsor people who have influence, who are

affected by, or have some other interest ina data harmonization initiative and its re-sult. They can be divided into stakeholdersthat directly participate in the initiative (i.e.take part in development and implementa-tion) and the others that influence or areaffected by the initiative. It is important topay particular attention to the interests,viewpoints and concerns of stakeholders sothat their roles and responsibilities can beclearly defined for their support and activeinvolvement in specific phases of data har-monization throughout the initiative.

Pay due attention to regional and interna-tional initiatives that develop regulationsand standards affecting trade documents –Due attention should be given to regionaland international initiatives that can affectthe substance of trade documents. It isimportant to understand their influence onthe national data harmonization initiative.Due consideration should be given to activeuse of them. Highlighting their importancein developing a harmonized national dataset that can facilitate international informa-tion exchange can help gain policy supportfor data harmonization. To keep track ofdevelopment on regulations and standardsby such regional and international initia-tives, a list of projects being developed bythem that may influence the data harmoni-zation operation should be compiled andprioritized according to their importance.

6.2 COORDINATINGREQUIREMENTS OF NATIONALDATA HARMONIZATION WITHRELEVANT REGIONAL ANDINTERNATIONAL PARTNERS

In addition to coordination among nationalstakeholders, due attention should be also

6. PRACTICAL RECOMMENDATION FOR DATAHARMONIZATION

24 TOGAF (2009) and SWIF (2010).


48

given to cooperation with regional and interna-tional partners. It is recommended that nationaldata harmonization initiatives be aligned withregional and international initiatives as well asglobal standardization efforts. The following rec-ommendations are suggested in promoting coor-dination with regional and international partners:

Develop a strategy for involvement in inter-national initiatives – A strategy for activeinvolvement in regional and internationalinitiatives should be developed. The rel-evance of any national effort to interna-tional initiatives should be monitored andanalysed for their interdependence. Whenfound relevant, effort should be made tobuild a link between them to ensureharmonization, if possible, or at least align-ment, if total harmonization is not possible.

Establish a joint working group. – A work-ing group delegated to conduct develop-ment of harmonized national data set andharmonization of national data requirementswith regional and international develop-ments should be formed. Members ofsuch a joint working group should have the

relevant skills and capacities. The jointworking group should coordinate and com-municate regularly with relevant interna-tional partners so that their interests andconcerns are discussed, and expectationsare fulfilled in a timely manner.

Take into account regional and internationaltrade arrangement in developing a standarddata set – In developing a harmonizednational data set, Government shouldcarefully take into account any regional orinternational trade arrangements and pro-tocols, and ensure that the national dataset is aligned to the requirements of suchregional and international arrangements.

6.3 ITERATIVE AND INCREMENTALAPPROACH TO DATAHARMONIZATION

A Single Window, when it operates in fullscale, supports various business processes ofthe international supply chain from the timethat the goods are ordered until the paymentfor the goods is made.

Source: UNECE, 2001

Figure 6.1. Scope of Single Window and International Supply Chain

Supplier(exporter/seller)

Intermediary (freight forwarder,customs broker, 3rd party logisticsservice provider, express integrator,carrier of all modes, port, terminaloperator, inland container depot,

bank, insurance company, ITvalue-added service provider, bank

and financial Institutions)

Consumer(importer/buyer)

Authority(including authorized

private inspection agency)

Buy(commercial activitiesrelated to the ordering

of goods)

Pay(activities involved in

the payment forgoods)

Ship(activities involved inthe physical transferof goods and official

controls)

49

It should be noted that the scope of dataharmonization for a Single Window implemen-tation covers the documentary requirements ofthe whole international supply chain. Becausethe full scope of a Single Window is far reach-ing, harmonization of data elements that coverall documentary requirements of the interna-tional supply chain in one run may not befeasible, primarily due to resource constraints.Therefore, data harmonization for a SingleWindow implementation is often carried out ina number of phases.

Data requirements to be harmonized in thefirst phase are usually from documents thathold the greatest strategic importance. Thestrategic importance of a particular documentmay be measured using the estimation on thetotal number produced or issued per year.Documents that hold the greatest strategicimportance are usually those used in the Cus-toms domain, e.g., the customs declarationand supporting documents, the conveyancereport, and the manifest.

The degree to which document owners25 arewilling to participate in the data harmonizationprocess may be considered as anothercriterion for determining the scope of dataharmonization. Without support from documentowners, there is a risk that the data harmoni-zation project will not be successful and theproject outputs will not be used.

6.4 CRITERIA FOR STANDARDSELECTION

Prior to harmonizing data requirements, a datamodel that provides generic semantic rulesand that serves as a building block for aligningdefinition and representation as well as thecardinality and location of each data elementin the electronic message has to be identified,assessed and selected. Comprehensivenessand compliance with prevailing internationallyaccepted standards for electronic data ex-change are criteria that have to be taken intoconsideration when selecting the data stan-dards.

Comprehensiveness The selected datamodel should be generic yet sufficientlycontextualized that the documentary re-quirements of all stakeholders in the inter-national supply chain are covered.

Compliance with internationally acceptedstandards for electronic data exchange Theselected data model should comply withrelevant international recommendations andstandards that promote semantic intero-perability. They include:

– The UN/CEFACT Core ComponentTechnical Specification (CCTS: ISO15000-5/ebXML) which provides themethodology for the identification ofdictionary entry names (data elements)in the data model and the developmentof a data model that in turn defines thestructure of an electronic message;

– The UN/CEFACT Core Component Li-brary (CCL) which provides reusableCCTS-compliant dictionary entry namesand their standard definitions;

– The United Nations Layout Key (UNLK)which promotes the principle of reusabledocument template and outlines a set ofminimum data elements of key tradeand transport documents; and

– The WCO Data Model is an example ofstandard data model for B2G and G2Gdata exchange that cover data require-ments needed for Customs and regula-tory purposes. The WCO Data Modelsupports development of electronicdocuments in UN/EDIFACT and XMLsyntax.

The selected data model is built uponstable version of standards.

6.5 MAINTENANCE OF OUTPUTSFROM DATA HARMONIZATIONPROJECTS

The outputs of data harmonization projects,such as harmonized data set/data elements,data model and message implementationguides, should be properly maintained for theirreusability and sustainability. National specifica-

25 The Regulatory agency responsible for managing theregulations governing the description and use of adocument.

6. Practical Recommendation for Data Harmonization


50

tions providing mappings between national re-quirements and international standards shouldbe published and appropriately disseminated tokey stakeholders. Business environment andrequirements are continuously changing due tothe rapid development of technologies, shiftingof business practices, modification of legal andregulatory framework, organizational change,etc. When the outputs of data harmonizationare properly managed and updated, the out-puts can be continuously reused and accom-modate interoperability in future use. Forproper maintenance, the following recommen-dations are suggested:

Keep baselines of the project outputs in aplatform – A listing or collection of dataelements, data structure, standardized dataset, and data model produced as the out-puts of data harmonization projects shouldbe recorded as a database in a form ofdata registry and/or repository. The dataregistry and repository are platforms de-signed to support the management ofproject deliverables throughout their lifecycles. The physical location of the registrycould either be local or accessed over anetwork. The registry could easily be in theform of a simple web site or a more com-plicated database or repository system ac-cessible by intended beneficiaries. Govern-ment may decide to set up a responsibleunit, such as a National Data Registry andRepository Office, to take charge of moni-toring and controlling standards and out-puts related to data harmonization.

Facilitate adoption of the project outputs –The outputs of data harmonization projectsshould be presented to policy authoritiesfor their proper understanding and support,so that political support and funding forcontinuous implementation and mainte-nance of data harmonization can be se-cured. In addition, the project deliverablesshould be publicized and disseminated tostakeholders and agencies for their use. Itis recommended that the knowledge andexperiences gained from data harmoniza-

tion are publicly shared with interestedparties, and the application cases of theoutputs are presented to promote moredata harmonization activities.

Monitor and maintain changes in dataharmonization baselines – As mentionedearlier, there might be circumstances wheredevelopment of technologies, shifting ofbusiness practices, modification of the legaland regulatory framework, organizationalchange, etc. occur, which may affect dataharmonization baselines. It is important toconsistently monitor and maintain changesin data harmonization baselines. A compre-hensive maintenance process may inte-grate analysis of key issues, includingproblems of existing version, needs forchanges, impact of changes and so on,with a multi-stage review by relevant par-ties and stakeholders. Various measuressuch as surveys, interviews, focus groups,public hearings, and other communicationmedia should be used throughout theprocess in order to solicit inputs needed forchanges and to obtain feedback fromconcerned parties. A task force may beformed to:

1. Develop drafts,

2. Review all comments and suggestionsresulting from surveys, interviews, andfocus groups,

3. Conduct revisions,

4. Receive further reviews and feedbacks,and

5. Carry out testing or trials.

As a result of this process, the final versionscan be broadly accepted by the general publicand stakeholders. They should then be ap-proved by the relevant authority and an-nounced as new baselines. The new baselinesof data harmonization should be publicizedand promoted through public awareness rais-ing, seminars and publication, to facilitate theiradoption in businesses.

51

GLOSSARY

Aggregate Business Information Entity (ABIE)– A collection of related pieces of businessinformation that together convey a distinctbusiness meaning in a specific BusinessContext. Expressed in modelling terms, it isthe representation of an Object Class, in aspecific Business Context. (Source: UN/CEFACT CCTS V2.01)

Aggregate Core Component (ACC) – A collec-tion of related pieces of business informationthat together convey a distinct business mean-ing, independent of any specific Business Con-text. Expressed in modelling terms, it is therepresentation of an Object Class, independentof any specific Business Context. (Source: UN/CEFACT CCTS V2.01)

Association Business Information Entity(ASBIE) – A Business Information Entity thatrepresents a complex business characteristic ofa specific Object Class in a specific BusinessContext. It has a unique Business Semanticdefinition. An Association Business InformationEntity represents an Association Business In-formation Entity Property and is therefore asso-ciated to an Aggregate Business InformationEntity, which describes its structure. An Asso-ciation Business Information Entity is derivedfrom an Association Core Component. (Source:UN/CEFACT CCTS V2.01)

Association Core Component (ASCC) – ACore Component which constitutes a complexbusiness characteristic of a specific AggregateCore Component that represents an ObjectClass. It has a unique Business Semanticdefinition. An Association Core Componentrepresents an Association Core ComponentProperty and is associated to an AggregateCore Component, which describes its structure.(Source: UN/CEFACT CCTS V2.01)

Basic Business Information Entity (BBIE) – ABusiness Information Entity that represents asingular business characteristic of a specificObject Class in a specific Business Context. Ithas a unique Business Semantic definition. ABasic Business Information Entity represents aBasic Business Information Entity Property andis therefore linked to a Data Type, which de-scribes it values. A Basic Business Information

Entity is derived from a Basic Core Compo-nent. (Source: UN/CEFACT CCTS V2.01)

Basic Core Component (BCC) – A Core Com-ponent which constitutes a singular businesscharacteristic of a specific Aggregate CoreComponent that represents a Object Class. Ithas a unique Business Semantic definition. ABasic Core Component represents a BasicCore Component Property and is therefore ofa Data Type, which defines its set of values.Basic Core Components function as theproperties of Aggregate Core Components.(Source: UN/CEFACT CCTS V2.01)

Business Information Entity (BIE) – A piece ofbusiness data or a group of pieces of busi-ness data with a unique Business Semanticdefinition. A Business Information Entity canbe a Basic Business Information Entity (BBIE),an Association Business Information Entity(ASBIE), or an Aggregate Business InformationEntity (ABIE). (Source: UN/CEFACT CCTSV2.01)

Business Process Analysis (BPA) – A system-atic examination of business processes inorder to gain better understanding and todevelop improvement strategies. (Source:UNNeXT Business Process Analysis Guide toSimplify Trade Procedures. United Nations2009)

Core Component (CC) – A building block forthe creation of a semantically correct andmeaningful information exchange package. Itcontains only the information pieces necessaryto describe a specific concept. (Source: UN/CEFACT CCTS V2.01)

Core Component Library (CCL): The CoreComponent Library is the part of the registry/repository in which Core Components shallbe stored as Registry Classes. The CoreComponent Library will contain all the CoreComponent Types, Basic Core Components,Aggregate Core Components, Basic BusinessInformation Entities and Aggregate BusinessInformation Entities. (Source: UN/CEFACTCCTS V2.01)

Core Component Type (CCT): A Core Compo-nent, which consists of one and only oneContent Component, that carries the actual

Glossary


52

content plus one or more Supplementary Com-ponents giving an essential extra definition tothe Content Component. Core ComponentTypes do not have Business Semantics.(Source: UN/CEFACT CCTS V2.01)

Data: A representation of facts, concepts orinstructions in a formalized manner suitable forcommunication, interpretation, or processing byhuman being or by automatic means (Source:ISO 2382/I)

Data element: A unit of data that in a certaincontext is considered indivisible (Source: ISO2382/4). A basic container for data (Source:ISO 11179)

Data field: An area designated for a specifieddata entry (Source: UN/CEFACT Recommen-dation No. 1)

Data entry: Data entered on a data carrier(Source: UN/CEFACT Recommendation No. 1)

Data harmonization: An act of capturing, defin-ing, analysing and reconciling the definitionand representation of data elements in a do-main of interest.

Data model: A logical map that represents theinherent properties of the data independent ofsoftware, hardware or machine performanceconsiderations. The model shows data ele-ments grouped into records, as well as the

association around those records. (Source:http://www.information-management.com/glos-sary/d.html)

Data modelling: A method used to define andanalyse data requirements needed to supportthe business functions of an enterprise. Thesedata requirements are recorded as a concep-tual data model with associated data defini-tions. Data modelling defines the relationshipsbetween data elements and structures.(Source: http://www.information-management.com/glossary/d.html)

Field heading: A field identifier expressed inplain language, full or abbreviated (Source:UNECE Recommendation No. 1)

Form: A data carrier designed to carry a visiblerecord of data entries (Source: UNECE Rec-ommendation No. 1)

Extensible Markup Language (XML): A setof rules for encoding documents in machine-readable form. (Source: Wikipedia. http://en.wikipedia.org/wiki/XML)

XML schema – A generic term used to identifythe family of grammar based XML documentstructure validation languages to include themore formal W3C XML Schema TechnicalSpecification, Document Type Definition, Sche-matron, Regular Language Description for XML(RELAX), and the OASIS RELAX NG. (Source:UN/CEFACT CCTS V2.01).

53

REFERENCES

Asian Development Bank and United Nations Economic and Social Commission for Asia andthe Pacific. (2009). Designing and Implementing Trade Facilitation In Asia and the Pacific.Philippines: Asian Development Bank. Available at http://www.unescap.org/tid/projects/tfforum_adbescapbook.asp (last accessed: 2 April, 2010).

Asia Pacific Economic Cooperation Business Advisory Council. (1996). APEC Means Business:Building Prosperity for our Community. Report to the APEC Economic Leaders. Available at:http://www.acds.net/abachome.html (last accessed: 25 March 2010).

. (1999). Facilitating Cross-Border Flows: The True Measure of Liberalization, ABAC BusinessFacilitation Reports (Archives), Available at https://www.abaconline.org/v4/download.php?ContentID=945.

Asia Pacific Economic Cooperation Electronic Commerce Steering Group. (2009). Data Harmoniza-tion towards Single Window Paperless Environment, Singapore: APEC Secretariat. Availableat: http://publications.apec.org/publication-detail.php?pub_id=919 (last accessed: 2 April,2010).

Marchewka, J.T. (2006). Information Technology Project Management, 2nd ed. Hoboken, NJ:JohnWiley & Sons Inc

Organization for Economic Co-operation and Development. (2002). Business Benefits of TradeFacilitation. OECD Publications, Paris.

Simeon Djankov, Caroline Freund, and Cong S. Pham (2006 and revised in 2008), Trading onTime, The Review of Economics and Statistics, February 2010, Vol. 92 (1): Page 166-173

Stuhec, G. (2005). How to Solve Business Standards Dilemma: The Context-Driven BusinessExchange, SAP Developer Network.

United Nations Economic Commision for Europe (2003). Core Components Technical SpecificationVersion 2.01 – Part 8 of the ebXML Framework.

(2001). UNECE Recommendation No. 18: Facilitation Measures Related to InternationalTrade Procedures, 1-13, Available at: http://www.unece.org/cefact/recommendations/rec18/Rec18_pub_2002_ecetr271.pdf (last accessed: 25 March 2010).

(2011). UNECE Recommendation No. 33 – Single Window Recommendation Available at:http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec33/rec33_ trd352e.pdf.

(2011). UNECE Recommendation No. 34 Data Simplification and Standardization for Interna-tional Trade. Available at: http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec34/ECE_TRADE_C_CEFACT_2010_13E_r1.pdf.

(2002). United Nations Layout Key for Trade Documents: Guidelines For Application (Informa-tive Annex To Recommendation 1), New York and Geneva: United Nations.

(2002). Trade Facilitation: An Introduction to the Basic Concepts and Benefits. Geneva:United Nations. Available at: http://www.unece.org/forums/forum02/docs/02tfbroch.pdf (lastaccessed: 9 June 2010).

United Nations Conference on Trade and Development. (1994). Fact Sheet 5, United NationsInternational Symposium on Trade Efficiency, October 17-21, Ohio, USA.

References


54

United Nations Network of Experts for Paperless Trade in Asia and the Pacific. (2009). BusinessProcess Analysis Guide to Simplify Trade Procedures. Thailand: United Nations. Available at:http://www.unescap.org/tid/publication/tipub2558.asp (last accessed: 2 April, 2010).

United Nations Trade Data Element Directory. (2005). ISO 7372:2005. Trade Data ElementsDirectory (TDED) Vol. 1 – Data Elements. New York and Geneva: United Nations.

Woo, Y.P. and Wilson, J. (2000). Cutting Through Red Tape: New Directions for APEC’s TradeFacilitation Agenda. Vancouver: Asia Pacific Foundation of Canada.

World Bank. (2005). Trade Facilitation in the World Bank. Available at: http://siteresources.worldbank.org/INTRANETTRADE/Resources/Topics/Trade_Facilitation_Brochure_July_2005.pdf(last accessed: 9 June 2010).

World Customs Organization (2007), WCO Data Model, SINGLE WINDOW DATA HARMONIZA-TION. Available at: http://www.wcoomd.org/files/6.SW_Files/Data_Harmonisation.pdf.

World Customs Organization (2010), WCO Data Model 3. Available at: http://wcoomdpublica-tions.org/data-model-3.html.

World Trade Organization, Trade Facilitation: Introduction. Available at: http://www.wto.org/english/tratop_e/tradfa_e/tradfa_intro_e.htm (last accessed: 9 June 2010).

55

Annex I: Compiled Data Dictionary of ASEAN ATIGA Form D

Document Title ASEAN ATIGA FORM DDocument Purpose A Certificate of Origin is a document/message identifying goods, in which the

authority or body authorized to issue it, certifies expressly that the goods towhich the certificate relates originate in a specific country.

Name of Document Owner Issuing Authorities, ASEAN Nations

ID Data Element Name Data Element Definition Format Min Occur Max Occur

0 Declaration Type TDED 1001 : Code specifying the name of a an..3 1 1document.

0-1 Reference Number TDED 1004: Reference number identifying a an..35 1 1specific document.

1 Goods consigned TDED 3036: Name (and address) of the party an..35 1 1from (Exporter’s consigning the goods as stipulated in thebusiness name, contract by the party ordering the transportaddress, country) (This may be the exporter or seller.)

2 Goods consigned to TDED 3132: Name and address of party to an..512 1 1(Consignee’s name, which goods are consignedaddress, country)

3-1 Departure date TDED 2380: The value of a date, a date and an..35 1 1time, a time or of a period in a specifiedrepresentation.

3-2 Vessel’s name/ TDED 8212: name of specific means of an..35 1 1aircraft etc. transport such as vessel name

3-3 Port of discharge TDED 3224: Name of a location an..256 1 1

4 For official use TDED 1001 : Code specifying the name of a an..3 1 1(Declaration Type) document.

5 Item No TDED 1050: To identify a position within asequence. an..10 1 unbounded

6 Marks and Numbers TDED 7102: Free form description of the an..512 1 1on Packages marks and numbers on a transport unit or

package

7-1 Number of packages TDED 6061:Numeric representation of a n..16 1 1quantity value.

7-2 Type of packages TDED 7064: Description of the type of an..35 1 1packaging of an item.

7-3 Description of goods TDED 7357: Code specifying a type of goods an..35 1 unboundedfor Customs, transport or statistical purposes.

9-1 Gross Weight TDED 6018: Weight (mass) of line item n..16 1 1including packaging but excluding thetransport equipment

9-2 Item Price TDED 5032: Amount declared for Customs n..18 1 unboundedpurposes of those goods in a consignmentwhich are subject to the same Customsprocedure, and have the same tariff/statisticalheading, country information and duty regime

(continued)

Annexes


56

Annex I: (Continued)

ID Data Element Name Data Element Definition Format Min Occur Max Occur

9-3 Payment Currency TDED 6345: Code specifying a monetary unit An..3 1 1or currency.

10-1 Invoice Number TDED 1334 Reference number to identify an an..35 1 1invoice

10-2 Invoice Date TDED 2376 Date of issue of an invoice, in an..17 1 unboundedfigures and words

11-1 Country of Origin TDED 3225: Identification of the place in an..35 1 1country or country from which the goods wereinitially despatched to the importing country

11-2 Country of TDED 3229: Country subdivision where goods an..9 1 1Exportation begin their journey to export

12-1 Place of issue of TDED 3410: Name of the location where a an..256 1 1document document was issued and when appropriate,

signed or otherwise authenticated

12-2 Place/location TDED 3224: Name of a location. an..256 1 1

13 C/O Type TDED 4441: Code specifying the format of an..17 1 1free text

57

Annex II: ASEAN ATIGA Form D Data Mapped to WCO DM 3.0


0-1 Reference Number D014 Declaration Declaration.TDED 1004: Reference number identifying a specific Identification.document. an..35 Identifier(Min=1, Max=1)

1 Goods consigned from (Exporter’s business R031 Exporter Exporter.name, address, country) Name. TextTDED 3036: Name (and address) of the partyconsigning the goods as stipulated in the contract bythe party ordering the transport (This may be theexporter or seller.) an..35(Min=1, Max=1)

2 Goods consigned to (Consignee’s name, address, R037 Importer Importer.country) Name. TextTDED 3132: Name and address of party to whichgoods are consigned an..512(Min=1, Max= 1)

3-1 Departure date 030 Goods Shipment Goods Shipment.TDED 2380: The value of a date, a date and time, a Departure.time or of a period in a specified representation an..35 Date time(Min=1, Max= 1)

3-2 Vessel’s name/aircraft etc. T001 Arrival Transport Arrival TransportTDED 8212: name of specific means of transport such Means Means.as vessel name an..35 Name. Text(Min=1, Max= 1)

3-3 Port of discharge L012 Unloading Location Unloading Location.DED 3224: Name of a location. an..256 Name. Text(Min=1, Max=1)

4 For official use (Declaration Type) D013 Declaration Declaration.Type.TDED 1001 : Code specifying the name of a Codedocument an..3(Min=1, Max=1)

5 Item No. 006 Commodity Commodity.TDED 1050: To identify a position within a sequence Sequence. Numerican..10(Min=1, Max=unbounded)

6 Marks and Numbers on Packages 142 Packaging Packaging.TDED 7102: Free form description of the marks and Marks Numbers.numbers on a transport unit or package an..512 Identifier(Min=1, Max= 1)

7-1 Numbers of Packages 144 Packaging Packaging. Quantity.TDED 6061:Numeric representation of a quantity Quantityvalue. n..16(Min=1, Max= 1)

7-2 Type of packages 141 Packaging Packaging. Type.TDED 7064: Description of the type of packaging of Codean item. an..35(Min=1, Max= 1)

(continued)

Annexes


58

Annex II: (Continued)


7-3 Description of goods 145 Classification Classification.TDED 7357: Code specifying a type of goods for Identification. IdentifierCustoms, transport or statistical purposes. an.. 35(Min=1, Max=unbounded)

9-1 Gross weight 126 Goods Measure Goods Measure.TDED 6018: Weight (mass) of line item including Gross Mass. Measurepackaging but excluding the transport equipment n..16(Min=1, Max= 1)

9-2 Item Price 108 Government Agency Government AgencyTDED 5032: Amount declared for Customs purposes Goods Item GoodsItem. Customsof those goods in a consignment which are subject to Value. Amountthe same Customs procedure, and have the sametariff/statistical heading, country information and dutyregime an..18(Min=1, Max=unbounded)

9-3 Payment Currency 135 Currency Exchange Currency Exchange.TDED 6345: Code specifying a monetary unit or Currency Type. Codecurrency.an..3(Min=1, Max=1)

10-1 Invoice Number D016 Invoice Invoice. Identification.TDED 1334 Reference number to identify an invoice Identifieran.. 35(Min=1, Max=1)

10-2 Invoice Date D015 Invoice Invoice. Issue. DateTDED 2376 Date of issue of an invoice, in figures andwords an.. 17(Min=1, Max=1)

11-1 Country of Origin L024 Goods Consigned Goods ConsignedTDED 3225: Identification of the place in country or Place Place. Identification.country from which the goods were initially despatched Identifierto the importing country. an..35(Min=1, Max=1)

11-2 Country of Exportation 088 Goods Shipment Goods Shipment.TDED 3229: Country subdivision where goods begin Exportation Region.their journey to export location an..9 Code(Min=1, Max=1)

12-1 Place of issue of document D017 Additional Document Additional Document.TDED 3410: Name of the location where a document Authentication Locationwas issued and when appropriate, signed or otherwise Name. Textauthenticated. an..256(Min=1, Max=1)

12-2 Place/location D003 Additional Document Additional Document.TDED 3224: Name of a location. an..256 Issue Location. Text(Min=1, Max=1)

13 C/O Type 226 Additional Information Additional Information.TDED 4441: Code specifying the format of free text. Statement. Codean..17(Min=1, Max=1)

59

Annex III: ASEAN ATIGA Form D XML Schema from WCO DM 3.0

Annexes

<?xml version=”1.0” encoding=”UTF-8”?><?xml-stylesheet href=”GenHTML(vH).xslt” type=”text/xsl”?><xsd:schema xmlns:udt=”urn:un:unece:uncefact:data:standard:UnqualifiedDataType:6” xmlns:ds=”urn:wco:datamodel:standard:WCO:DS:1” xmlns:ccts=”urn:un:unece:uncefact:documentation:standard:CoreComponentsTechnicalSpecification:2” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” elementFormDefault=”qualified” attributeFormDefault=”unqualified” version=”1.0”>    <xsd:import namespace=”urn:un:unece:uncefact:data:standard:UnqualifiedDataType:6” schemaLocation=”http://www.unece.org/uncefact/data/standard/UnqualifiedDataType_6p0.xsd”/> <xsd:import namespace=”urn:wco:datamodel:standard:WCO:DS:1” schemaLocation=”..\common\DS_1p0.xsd”/>    <xsd:element name=”Declaration”> <xsd:complexType> <xsd:sequence>  <xsd:element name=”AcceptanceDateTime” type=”ds:DeclarationAcceptanceDateTimeType”/>  <xsd:element name=”DeclarationOfficeID” type=”ds:DeclarationDeclarationOfficeIDType”/>  <xsd:element name=”ID” type=”ds:DeclarationIdentificationIDType”/>  <xsd:element name=”IssueDateTime” type=”ds:DeclarationIssueDateTimeType”/>  <xsd:element name=”TypeCode” type=”ds:DeclarationTypeCodeType”/> <xsd:element name=”AdditionalDocument”> <xsd:complexType> <xsd:sequence>  <xsd:element name=”AuthenticationLocationName” type=”ds:AdditionalDocumentAuthenticationLocationNameTextType”/>  <xsd:element name=”IssueLocationID” type=”ds:AdditionalDocumentIssueLocationIDType”/>  <xsd:element name=”IssueLocation” type=”ds:AdditionalDocumentIssueLocationTextType” minOccurs=”0”/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name=”AdditionalInformation” minOccurs=”0” maxOccurs=”unbounded”> <xsd:complexType> <xsd:sequence>  <xsd:element name=”Content” type=”ds:AdditionalInformationContentTextType” minOccurs=”0”/>  <xsd:element name=”StatementCode” type=”ds:AdditionalInformationStatementCodeType” minOccurs=”0”/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name=”BorderTransportMeans” minOccurs=”0” maxOccurs=”unbounded”> <xsd:complexType> <xsd:sequence>  <xsd:element name=”Name” type=”ds:BorderTransportMeansNameTextType” minOccurs=”0”/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name=”Importer” minOccurs=”0” maxOccurs=”unbounded”>


60

Annex III: (Continued)

<xsd:complexType><xsd:sequence>

<xsd:element name="Name" type="ds:ImporterNameTextType" minOccurs="0"/><xsd:element name="ID" type="ds:ImporterIdentificationIDType" minOccurs="0"/><xsd:element name="Address" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="CityName" type="ds:AddressCityNameTextType" minOccurs="0"/><xsd:element name="CountryCode" type="ds:AddressCountryCodeType" minOccurs="0"/><xsd:element name="CountrySubDivisionName" type="ds:AddressCountrySubDivisionNameTextType" minOccurs="0"/>

<xsd:element name="PostcodeID" type="ds:AddressPostcodeIDType" minOccurs="0"/></xsd:sequence>

</xsd:complexType></xsd:element>

</xsd:sequence></xsd:complexType>

</xsd:element><xsd:element name="Exporter" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="Name" type="ds:ExporterNameTextType" minOccurs="0"/><xsd:element name="ID" type="ds:ExporterIdentificationIDType" minOccurs="0"/><xsd:element name="Address" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="CityName" type="ds:AddressCityNameTextType" minOccurs="0"/><xsd:element name="CountryCode" type="ds:AddressCountryCodeType" minOccurs="0"/><xsd:element name="CountrySubDivisionName" type="ds:AddressCountrySubDivisionNameTextType" minOccurs="0"/><xsd:element name="PostcodeID" type="ds:AddressPostcodeIDType" minOccurs="0"/>


</xsd:element></xsd:sequence>

</xsd:complexType></xsd:element><xsd:element name="GoodsConsignedPlace" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="Name" type="ds:ImporterNameTextType" minOccurs="0"/><xsd:element name="ID" type="ds:ImporterIdentificationIDType" minOccurs="0"/>


</xsd:element><xsd:element name="UnloadingLocation" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="Name" type="ds:ImporterNameTextType" minOccurs="0"/><xsd:element name="ID" type="ds:ImporterIdentificationIDType" minOccurs="0"/>


</xsd:element><xsd:element name="GoodsShipment" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="DepartureDateTime" type="ds:GoodsShipmentDepartureDateTimeType" minOccurs="0"/><xsd:element name="ExportationRegionCode" type="ds:GoodsShipmentExportationRegionCodeType" minOccurs="0"/><xsd:element name="GovernmentAgencyGoodsItem" minOccurs="0" maxOccurs="unbounded">

61

Annex III: (Continued)

Annexes


<xsd:element name="CustomsValueAmount" type="ds:GovernmentAgencyGoodsItemCustomsValueAmountType" minOccurs="0"/><xsd:element name="GoodsMeasure" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="GrossMassMeasure" type="ds:GoodsMeasureGrossMassMeasureType" minOccurs="0"/>


</xsd:element><xsd:element name="Packaging" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="MarksNumbers" type="ds:PackagingMarksNumbersTextType" minOccurs="0"/><xsd:element name="TypeCode" type="ds:PackagingTypeCodeType" minOccurs="0"/><xsd:element name="QuantityQuantity" type="ds:PackagingQuantityQuantityType" minOccurs="0"/>


</xsd:element><xsd:element name="Invoice" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="ID" type="ds:InvoiceIdentificationIDType" minOccurs="0"/><xsd:element name="IssueDate" type="ds:InvoiceIssueDateType" minOccurs="0"/>


</xsd:element><xsd:element name="Commodity" minOccurs="0" maxOccurs="unbounded">


<xsd:element name="SequenceNumeric" type="ds:CommoditySequenceNumericType" minOccurs="0"/><xsd:element name="Description" type="ds:CommodityDescriptionTextType" minOccurs="0"/><xsd:element name="Classification">


<xsd:element name="IdentificationType" type="ds:ClassificationIdentificationTypeCodeType" minOccurs="0"/><xsd:element name="ID" type="ds:ClassificationIdentificationIDType" minOccurs="0"/>







</xsd:sequence></xsd:complexType></xsd:element></xsd:schema>


62

Annex IV: Cases of Data Harmonization

This separate annex, available online, provides examples of cases that illustrate data harmoni-zation process conducted in accordance with the steps described in the Guide.

At the time of publication of this Guide, three cases are available as follows:

1) Annex IV-1: Data Harmonization Example on ASEAN ATIGA Form D

2) Annex IV-2: Country Case – Thai Data Harmonization Case

3) Annex IV-3: Country Case – Korean Data Harmonization Case

The three cases are available for view and download at: http://www.unescap.org/unnext/tools/data_harmonization.asp

More cases will be added on the same webpage as they become available.


8