Распоряжение Совета Евразийской экономической комиссии от 01.03.2024 № 7
Актуально на 11.11.2026.
Как цитировать: Распоряжение Совета Евразийской экономической комиссии от 01.03.2024 N 7. 7. 01.03.2024. https://bukva.ai/docs/rasporyazhenie-7-2024-sovet-evraziyskoy
«О проекте Протокола об электронном обмене информацией между Евразийским экономическим союзом и его государствами-членами, с одной стороны, и Социалистической Республикой Вьетнам, с другой стороны, в рамках электронной системы сертификации и верификации происхождения товаров»
(Вместе с проектом <Протокола> [англ.])
Примечание
В соответствии с пунктом 3 данный документ вступил в силу 1 марта 2024 года.
СОВЕТ ЕВРАЗИЙСКОЙ ЭКОНОМИЧЕСКОЙ КОМИССИИ
РАСПОРЯЖЕНИЕ № 7 О ПРОЕКТЕ ПРОТОКОЛА ОБ ЭЛЕКТРОННОМ ОБМЕНЕ ИНФОРМАЦИЕЙ МЕЖДУ ЕВРАЗИЙСКИМ ЭКОНОМИЧЕСКИМ СОЮЗОМ И ЕГО
ГОСУДАРСТВАМИ-ЧЛЕНАМИ, С ОДНОЙ СТОРОНЫ, И СОЦИАЛИСТИЧЕСКОЙ
РЕСПУБЛИКОЙ ВЬЕТНАМ, С ДРУГОЙ СТОРОНЫ, В РАМКАХ ЭЛЕКТРОННОЙ
СИСТЕМЫ СЕРТИФИКАЦИИ И ВЕРИФИКАЦИИ ПРОИСХОЖДЕНИЯ ТОВАРОВ
1. Одобрить проект Протокола об электронном обмене информацией между Евразийским экономическим союзом и его государствами-членами, с одной стороны, и Социалистической Республикой Вьетнам, с другой стороны, в рамках электронной системы сертификации и верификации происхождения товаров (прилагается) и направить его в государства — члены Евразийского экономического союза для проведения внутригосударственных процедур, необходимых для подписания указанного Протокола.
2. Просить государства — члены Евразийского экономического союза проинформировать до 15 мая 2024 г. Евразийскую экономическую комиссию о ходе выполнения внутригосударственных процедур, необходимых для подписания Протокола, указанного в пункте 1 настоящего распоряжения.
3. Настоящее распоряжение вступает в силу с даты его принятия.
Члены Совета Евразийской экономической комиссии:
| От Республики Армения | От Республики Беларусь | От Республики Казахстан | От Кыргызской Республики | От Российской Федерации |
|---|---|---|---|---|
| М.ГРИГОРЯН | И.ПЕТРИШЕНКО | С.ЖУМАНГАРИН | А.КАСЫМАЛИЕВ | А.ОВЕРЧУК |
PROTOCOL ON ELECTRONIC INFORMATION EXCHANGE BETWEEN THE EURASIAN ECONOMIC UNION AND ITS MEMBER STATES, OF THE ONE PART, AND
THE SOCIALIST REPUBLIC OF VIET NAM, OF THE OTHER PART,
WITHIN THE ELECTRONIC ORIGIN CERTIFICATION AND VERIFICATION
SYSTEM
The Governments of the Member States of the Eurasian Economic Union (hereinafter referred to as «the EAEU Member States») and the Eurasian Economic Union, of the one part, and the Government of the Socialist Republic of Viet Nam (hereinafter referred to as «Viet Nam»), of the other part (hereinafter referred to as «the Parties»):
Recalling Article 4.29 (Development and Implementation of Electronic Origin Certification and Verification System) of the Free Trade Agreement between the Eurasian Economic Union and its Member States, of the one part, and the Socialist Republic of Viet Nam, of the other part, on 29 May 2015;
Welcoming the reduction of the costs relating to the documentary proof of origin used for the purposes of application of tariff preferences;
Aiming at simplifying the procedures and reducing the time for the application of tariff preferences; and
Desiring to strengthen cooperation between the customs authorities and the bodies and organisations authorised to issue certificates of origin of the Parties,
For the purposes of this Protocol:
«Authorised Body» means a body or an organisation authorised the EAEU Member State or by Viet Nam to issue a certificate of origin, generate and maintain information resources containing information on issued certificates of origin, and to provide information on certificates of origin, for their verification in response to the requests of the customs authorities;
«Integrated information system of the EAEU» means a set of geographically distributed state information resources and information systems of authorised authorities, information resources and information systems of the Eurasian Economic Commission, combined by the national segments of the EAEU Member States and the integration segment of the Eurasian Economic Commission; and
«National Single Window of Viet Nam» means the mechanism of Viet Nam which allows the customs declarants to send the information and electronic documents for completion of customs procedures and procedures of state management agencies related to exported and imported goods through an integrated information system.
1. For the purpose of this Article, the exchange of information shall be carried out via the Integrated Information System of the EAEU and the National Single Window of Viet Nam based on the requirements of the Technical Specifications specified in the Annex to this Protocol.
2. The Authorised Body of Viet Nam shall transmit to the relevant central customs authority of the EAEU Member States the information contained in the certificates of origin issued for goods exported from the territory of Viet Nam to the territory of this EAEU Member State.
3. The relevant Authorised Body of the EAEU Member State shall transmit to the central customs authority of Viet Nam the information contained in the certificates of origin issued for goods exported from the territory of this EAEU Member State to the territory of Viet Nam.
All information provided in accordance with this Protocol shall be treated by the Parties as confidential in accordance with their respective domestic laws and regulations. It shall not be disclosed by the customs authorities of a Party without the written permission of the Authorised Bodies of the other Party which provided such information except to the extent that it may be required to be disclosed in the context of judicial proceedings.
1. This Protocol may be amended by mutual consent of the Parties.
2. Such amendments shall be formalised by separate protocols and constitute an integral part of this Protocol.
1. Any matters related to the implementation of this Protocol shall be settled through consultations or negotiations between the Parties.
2. If a Party considers that the matter cannot be settled through consultations or negotiations as provided for in paragraph 1 of this Article, that Party shall have the right to seek resolution in the Joint Committee established in accordance with Article 1.4 (Joint Committee) of the Free Trade Agreement between the Eurasian Economic Union and its Member States, of the one part, and the Socialist Republic of Viet Nam, of the other part, on 29 May 2015.
1. This Protocol shall enter into force on the date of receipt, through diplomatic channels, of the last written notification certifying that the Parties have completed their respective internal legal procedures necessary for entry into force of this Protocol.
2. The exchange of notifications provided for in paragraph 1 of this Article shall be performed by Viet Nam and the Eurasian Economic Commission as the custodian of this Protocol authorised by the Republic of Armenia, the Republic of Belarus, the Republic of Kazakhstan, the Kyrgyz Republic and the Russian Federation.
Done at ___, this _____ day of ______ 20, in two originals in the English language, both texts being equally authentic.
on electronic information exchange between the Eurasian Economic Union and its Member States, of the one part, and the Socialist Republic of Viet Nam, of the other part, within the Electronic Origin Certification and Verification System
I. PURPOSE OF THE DOCUMENT
These Technical Specifications set technical requirements and conditions for the implementation of the electronic information exchange between the central customs authorities of the Member States of the Eurasian Economic Union (hereinafter referred to as «the Member States», «the Union») and of the Socialist Republic of Viet Nam within the Electronic Origin Certification and Verification System (hereinafter referred to as «the Parties», «the EOCVS») in accordance with Article 4.29 of the Free Trade Agreement between the Eurasian Economic Union and its Member States, of the one part, and the Socialist Republic of Viet Nam, of the other part, dated May 29, 2015 (hereinafter referred to as «the Agreement»).
These Technical Specifications define participants, procedures and regulations of the electronic information exchange, content and structure of transmitted information and messages, used classifiers and directories, security requirements for information exchange and technical aspects and interaction parameters within the EOCVS for exchanging information on certificates of origin issued by the authorized bodies of one Party and used by the customs authorities of the other Party in order to verify validity and content of the issued certificates of origin.
II. CHRONOLOGY OF THE DOCUMENT'S REVISIONS
III. TERMS AND ABBREVIATIONS
The following terms and definitions are used in these Technical Specification:
«SOAP» (Simple Object Access Protocol) — message-exchange protocol in the distributed computing environment;
«UML» — Unified Modeling Language;
«UUID» — Universally Unique Identifier;
«XML» (Extensible Markup Language) — recommended by the World Wide Web Consortium (W3C) Extensible Markup Language;
«Asynchronous Interaction» — a kind of electronic data exchange, in which the Sender resumes his work immediately after sending the message, without waiting for a response from the receiver;
«Business process» — a set of interrelated operations and procedures for implementation of the electronic information exchange;
«Verification» — the procedure for confirming the authenticity of the certificate of origin;
«External Gateway» — a subsystem of the Integrated information system of the Union that provides interaction with the National Single Window of Viet Nam;
«Information Protection» — development and implementation of a set of legal, organizational and technical measures to identify, achieve and maintain the confidentiality, integrity and availability of information and processing facilities in order to eliminate or minimize unacceptable risks for the participants of information exchange;
«Initiator» — a participant of electronic information exchange initiating the transaction;
«Information system» — a set of information technologies and technical means to ensure the processing of information resources;
«Information resource» — an ordered set of documented information (databases, other information arrays) contained in Information Systems;
«Communication channel» — the unidirectional network connection for transmitting electronic messages;
«Classifier» — a systematic, structured and codified list of names of items of classification;
«Commission» — the Eurasian Economic Commission which is a permanent regulatory body of the Eurasian Economic Union in accordance with the Treaty on the Eurasian Economic Union dated May 29, 2014;
«Integrated information system of the Union» — a set of geographically distributed state information resources and information systems of authorized authorities, information resources and information systems of the Eurasian Economic Commission, combined by the national segments of the Member States of the Eurasian Economic Union and the integration segment of the Eurasian Economic Commission;
«National Single Window of Viet Nam» — the mechanism which allows customs declarant on the Viet Nam side to send information and electronic documents for performing of customs procedures and procedures of state management agencies related to exported and imported goods, as well as which allows the Authorised Bodies of Viet Nam to receive the information necessary for performing of customs procedures, providing the information exchange with the external gateway of the Integrated information system of the Union;
«Business Process Operation» — a regular, repetitive action, which is part of the range of functions, tasks of a certain Participant of the Business Process;
«Control Error» — a type of exception signals that occurs when the notice received by the Respondent is checked, or the waiting time of the notice that the Respondent accepts the received information for processing expires;
«Business process procedure» — a set of interrelated operations performed by participants of the business process and aimed at solving a specific task within a business process;
«Respondent» — a participant of electronic information exchange exchanging messages with the Initiator within the transaction;
«Service» — the process of providing users with information technology resources to ensure the performance of their business functions, which has the ability to perform the required functions in a given period of time;
«Certificate of origin» — certificate of origin form EAV issued by an authorized body of the Party in accordance with Section 2 of Chapter 4 of the Agreement;
«Message» — a formalised information transmitted from the sender to the receiver using information and telecommunications networks;
«Directory» — a systematic, structured and codified list of information, that is homogeneous in its content or substance;
«Transaction» — an elementary information interaction between two participants of business process, which is carried out by each participant within its Business Process Operation;
«Participant of the business process» — a participant of electronic information exchange within the business process.
In order to provide clear presentation of transferred information and message structures, tables are used. These tables contain the following columns:
«requisite name/element» — common or official verbal mark of an electronic information requisite or a message element;
«requisite description/description» — a text defining the meaning (semantology) of an electronic information requisite or a message element;
«data type» — a verbal mark of possible values of an electronic information requisite or a message element;
«mult.» — requisite multiplicity — necessity (optionality) and the number of possible requisite or message element repetitions.
To indicate the necessity of filling electronic information or message element structure requisites, the following notations are used in «mult.» column:
1 — a requisite (element) is obligatory, no repetitions are allowed;
n — a requisite (element) is obligatory, shall be repeated n times, n > 1;
0..1 — a requisite (element) is optional, no repetitions are allowed;
0.. - a requisite (element) is optional, can be repeated without restrictions;*
0..m — a requisite (element) is optional, can be repeated no more than m times, m > 1;
1..* — a requisite (element) is obligatory, can be repeated without restrictions;
n..* — a requisite (element) is obligatory, shall be repeated at least n times, n > 1;
n..m — a requisite (element) is obligatory, must be repeated at least n times and not more than m times, n > 1, m > n.
IV. GENERAL INFORMATION
4.1. General principles of the electronic information exchange
Electronic information exchange within the EOCVS is intended to ensure the possibility to verify authenticity, issuance and content of the issued certificates of origin.
EOCVS is developed to create databases of certificates of origin issued by authorized bodies of exporting countries available for customs authorities of importing countries to verify the issuance and the content of issued certificates of origin.
Information from certificates of origin is exchanged between the participants within the EOCVS on a regular basis by means of electronic messages exchange.
Participants of electronic information exchange ensure the development and maintenance of structured information resources containing current information on certificates of origin, as well as information systems that support services for electronic information exchange.
Requirements for composition and structure of data used in data exchange are defined based on international standards and generally accepted initiatives in the field of electronic data exchange (including the Data Model of the World Customs Organization).
These Technical Specifications do not include requirements for unification of database structures and rules for their organization and functioning. Such requirements are defined at the national level.
Electronic information exchange participants shall protect transmitted information (including protection of information authenticity and integrity), as well as protect information from unauthorised access, destruction, change and prevent inappropriate storage.
Electronic information exchange participants submitting information shall ensure the completeness and correctness of information on issued certificates of origin provided within the EOCVS to enable the participants receiving information to check the issuance of certificates of origin and the authenticity of information contained.
Electronic information exchange participants shall provide 24-hour functioning of information resources and information systems, as well as related services.
4.2. Participants of electronic information exchange
The electronic information exchange involves:
1. Central customs authorities of the Member States and Viet Nam receiving information on the issued certificates of origin for their verification:
The State Revenue Committee of the Republic of Armenia;
The State Customs Committee of the Republic of Belarus;
The State Revenue Committee of the Ministry of finance of the Republic of Kazakhstan;
The Customs Service under the Ministry of Finance of the Kyrgyz Republic;
The Federal Customs Service (the Russian Federation);
The Ministry of Finance (General Department of Viet Nam Customs) of the Socialist Republic of Viet Nam.
2. Authorized bodies of the Member States and Viet Nam providing information on certificates of origin:
The Chamber of Commerce and Industry of the Republic of Armenia;
The Chamber of Commerce and Industry of the Republic of Belarus;
The National Chamber of Entrepreneurs of the Republic of Kazakhstan;
The Chamber of Commerce and Industry of the Kyrgyz Republic;
The Chamber of Commerce and Industry of the Russian Federation;
The Ministry of Industry and Trade of the Socialist Republic of Viet Nam.
4.3. The main technical solutions
Electronic information exchange within the EOCVS is carried out by its participants using the Integrated Information System of the Union (hereinafter referred to as «the IIS») and the National Single Window of Viet Nam.
The information transmitted by the authorized bodies of Viet Nam, using the National Single Window of Viet Nam facilities through the External Gateway services is received by the IIS and then it is routed to the central customs authorities of the Member States through the relevant national segments of the Member States.
The information transmitted by the authorized bodies of the Member States through the relevant national segments of the Member States, is transmitted to the IIS, enters the External Gateway and then it is transmitted through the services of the National Single Window of Viet Nam to the customs authorities of Viet Nam. Electronic information exchange within the EOCVS is carried out by its participants at the logic levels, such as transport, technological and application levels.
Procedures of electronic information exchange at the transport level between the External Gateway and the National Single Window of Viet Nam ensure data delivery via HTTP protocol.
Electronic information exchange between the External Gateway and the National Single Window of Viet Nam at the technological level is implemented by means of messages in the SOAP format.
Procedures of electronic information exchange at the application level provide exchanging of electronic data (hereinafter referred to as «the applied data») between the participants of electronic information exchange through messaging.
Electronic information exchange at the application level is carried out by asynchronous interaction in which the sender resumes his work immediately after sending the message without waiting for the response from the recipient.
The requirements to the structure and format of messages as well as the procedure of messaging at the technological level are established in accordance with Sections VI and VII of these Technical Specifications.
4.4. Requirements for unique identification of information
A unique identifier is assigned to each document in electronic form used within the electronic information exchange.
The following information is used as a unique identifier of the certificate of origin issued by the authorized body of the Party:
Registration number of the certificate of origin;
Date of certification (issuance of the certificate of origin);
The unique identifier of an electronic message specified in the header block at the technological level is the UUID electronic message identifier as RFC 4122 Specification (http://www.ietf.org/rfc/rfc4122.txt).
Cohesiveness of electronic messages at the technological level is determined by the identifier of cohesive message sent in the header block.
V. DESCRIPTION OF BUSINESS PROCESSES OF ELECTRONIC INFORMATION EXCHANGE (INFORMATION EXCHANGE REGULATIONS)
5.1. Description of electronic information exchange participants' roles within business process implementation
The list of business process participants' roles
Within the EOCVS the authorized bodies develop and maintain their own information resources containing electronic information on certificates of origin. During business process execution customs authorities-information receivers develop and maintain the information resources containing electronic information about certificates of origin provided by authorized bodies-information owners.
Business process procedures are provided in Table 2.
| Designation | Name |
|---|---|
| ESS.VN.PRC.001 | providing information on the issued certificate of origin |
| ESS.VN.PRC.002 | receiving information on the certificate of origin |
Description of the business process structure is shown in Figure 1.
Figure 1. Business process structure
5.2. Business process procedures
5.2.1. The procedure «Providing information on the issued certificate of origin»
The procedure «Providing information on the issued certificate of origin» shall be carried out within 4 hours after the authorized body-information owner performs one of the following procedures:
issuance of the certificate of origin in substitution of the original certificate of origin;
annulment (recall) of the previously issued original certificate of origin, the duplicate of certificate of origin, or the certificate of origin in substitution of the original certificate of origin;
inclusion of information related to it in the information resource containing information about certificates of origin.
The scheme of the procedure «Providing information on the issued certificate of origin» is provided in Figure 2.
Figure 2. Scheme of the procedure «Providing information on the issued certificate of origin»
The operation «Transferring information on the issued certificate of origin» is carried out first, followed by preparing and providing information on the issued (annulled, recalled) certificate of origin to the receiving customs authority by the authorized owning body.
When the receiving customs authority receives information on the issued (annulled, recalled) certificate of origin, the procedure «Receiving and processing of information on the issued certificate of origin» shall be carried out, followed by receiving, processing and providing notice on the results of processing to the authorized owning body by the receiving customs authority.
When the authorized owning body receives the notice on the results of processing from the receiving customs authority, the procedure «Receiving and processing of the notice on the results of processing of information on the issued certificate» is carried out. Based on the results of this operation, the authorized owning body processes the received notice.
The result of the procedure «Providing information on the issued certificate of origin» is the provision of information on the issued (annulled, recalled) certificate of origin by the authorized owning body and its processing by the receiving customs authority.
The list of operations carried out under the procedure «Providing information on the issued certificate of origin» is given in Table 3.
List of business process operations carried out within the procedure «Providing information on the issued certificate of origin» (ESS.VN.PRC.001)
The description of the operation «Transferring information on the issued certificate of origin» (ESS.VN.OPR.001) is given in Table 4.
Description of the operation «Transferring information on the issued certificate of origin» (ESS.VN.OPR.001)
The description of the operation «Receiving and processing of information on the issued certificate of origin» (ESS.VN.OPR.002) is given in Table 5.
Description of the operation «Receiving and processing of information on the issued certificate of origin» (ESS.VN.OPR.002)
The description of the operation «Receiving and processing of the notice on the results of processing of information on the issued certificate of origin» (ESS.VN.OPR.003) is given in Table 6.
Description of the operation «Receiving and processing of the notice on the results of processing of information on the issued certificate of origin» (ESS.VN.OPR.003)
5.2.2. The procedure «Receiving information on the certificate of origin»
If necessary the receiving customs authority can generate a request to confirm the authenticity of a certain certificate of origin. The scheme of the procedure «Receiving information about the certificate of origin» is given in Figure 3.
The procedure «Receiving information on the certificate of origin» is carried out by the receiving customs authority upon the request, if the information on the issued certificate of origin is necessary. The authorized body-information owner, having received such a request, generates the response containing the requested data or information about their absence.
Figure 3. Scheme of the procedure «Receiving information on the certificate of origin»
The operation «Requesting information about the certificate of origin» is carried out first, according to the results of which the customs recipient body forms and sends to the authorized authority-owner of the information request to provide information about the certificate of origin.
When the request for providing information on the certificate of origin is received by the authorized owning body, the operation «Providing information on the certificate of origin» is carried out, based on the results of which the authorized owning body generates and sends current information on the certificate of origin or notice on absence of information complying with the parameters of the request to the receiving customs authority.
When the receiving customs authority receives current information on the certificate of origin or the notice on absence of information complying with the parameters of request, the operation «Receiving and processing of information on the certificate of origin» is carried out, followed by the processing of received information by the receiving customs authority.
The result of the procedure «Receiving information on the certificate of origin» is the receiving and processing of current information on the certain certificate of origin or notice on the absence of information complying with the request parameters by the receiving customs authority.
The list of business process operations carried out within the procedure «Receiving information on the certificate of origin» (ESS.VN.PRC.002) is given in Table 7.
List of business process operations carried out within the
procedure «Receiving information on the certificate of
origin» (ESS.VN.PRC.002)
The description of the operation «Requesting for information on the certificate of origin» (ESS.VN.OPR.004) is given in Table 8.
Description of the operation «Requesting for information on the certificate of origin» (ESS.VN.OPR.004)
The description of the operation «Providing information on the certificate of origin» (ESS.VN.OPR.005) is given in Table 9.
Description of the operation «Providing information on the certificate of origin» (ESS.VN.OPR.005)
The description of the operation «Receiving and processing of information on the certificate of origin» (ESS.VN.OPR.006) is given in Table 10.
Description of the operation «Receiving and processing of
information on the certificate of origin» (ESS.VN.OPR.006)
5.3. Regulation of interaction during the implementation of the business process
Information interaction of participants during the implementation of the business process is carried out through transactions.
Information interaction defines the order of execution of transactions. Each transaction is the exchange of messages between the participants of electronic information exchange in order to synchronize the statuses of information resources containing information on certificates of origin. For each information interaction, the relationships between operations and the corresponding transactions are defined.
Within the operation (the initiating operation) one participant of the electronic information exchange (the initiator) shall provide another participant of electronic information exchange (the respondent) with a message, in response to which the respondent shall send a response message within the operation he performs (the receiving operation).
Messages exchanged within the business process shall be formed in accordance with the requirements specified in Section VI of these Technical specifications.
Table 11 presents a relationship between the operations, intermediate and resulting states of information objects of business process and transactions for each Business Process Procedure.
The scheme of the transaction «Providing information on the issued certificate of origin» (ESS.VN.TRN.001) is provided in Figure 4.
Figure 4. Scheme of the transaction «Providing information on the issued certificate of origin» (ESS.VN.TRN.001)
The scheme of the transaction «Receiving information on the certificate of origin» (ESS.VN.TRN.002) is provided in Figure 5.
Figure 5. Scheme of the transaction «Receiving information on the certificate of origin» (ESS.VN.TRN.002)
The parameters of the transactions «Providing information on the issued certificate of origin» (ESS.VN.TRN.001) and «Receiving information on the certificate of origin» (ESS.VN.TRN.002) are listed in Subsection 9.4 of these Technical Specifications.
VI. CONTENT AND STRUCTURE OF INFORMATION TRANSMITTED
6.1. Content of information transmitted
6.2. Structure of information transmitted
Description of structures of information transmitted and rules for their filling out and control is provided in a set of tables in Appendix B.
Description of the structure of transmitted information and messages in W3C language notation of XML-schemes is provided in Appendix C.
Examples of transmitted information and messages in the form of XML-documents are provided in Appendix D.
Information about web services standards is provided in Appendix F.
VII. STRUCTURE AND FORMAT OF MESSAGES
7.1. General requirements and applicable standards
The information transmitted as a part of the described business process, shall be XML-formatted in accordance with the Extensible Markup Language (XML) 1.0 standard (Fifth Edition) that can be found at: http://www.w3.org/TR/REC-xml.
When describing the structure and format of messages, the namespaces given in Table 12 are used, as well as the specifications provided in Table 13.
List of XML-document namespaces
| Prefix | Address |
|---|---|
| soap | http://www.w3.org/2003/05/soap-envelope |
| wsa | http://www.w3.org/2005/08/addressing |
| xs | http://www.w3.org/2001/XMLSchema |
A message in SOAP format transmitted between electronic information exchange participants is made in accordance with the SOAP 1.2 specification and consists of a header block (soap:Header) and a body block (soap:Body).
The header block contains technological information required for routing and processing of a message, as well as for monitoring of electronic information exchange.
Specifications used to describe structure and format of
messages
| Short name | Full name |
|---|---|
| SOAP 1.2 | SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). W3C Recommendation 27 April 2007. http://www.w3.org/TR/soap12-part1 |
| WS-Addressing 1.0 — Core | Web Services Addressing 1.0 — Core. W3C Recommendation 9 May 2006. http://www.w3.org/TR/ws-addr-core |
| XML 1.0 | Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C Recommendation 26 November 2008. http://www.w3.org/TR/2008/REC-xml-20081126 |
The body block includes the application or technological information important for the participants of electronic information exchange and shall conform with the structure of transmitted data specified in Appendix B and W3C language notation of XML-schemes specified in Appendix C.
UTF-8 encoding shall be used for generating messages and contents of their blocks. The maximum length of a message transmitted is 100 MB.
The list of business process messages transmitted within the information interaction when implementing the business process is given in Table 14.
Table 14
The list of messages transmitted
7.2. The structure of header blocks
The header block contains headers in accordance with WS-Addressing 1.0 — Core specification, as well as specialized headers used to organize interaction.
The header block includes the following headers:
a) wsa:To — a header containing information on the receiver;
b) wsa:From — a header containing logical address of the sender, to which the response message should be sent;
c) wsa:MessageID — a header containing message identifier;
d) wsa:RelatesTo — a header containing message reference identifier;
e) wsa:Action — a header identifying message content.
The wsa:To header is obligatory to fill out and shall include the logical address of the receiver. The logical address is used to identify the receiver in messages between the External Gateway and electronic information exchange services provided by the National Single Window of Viet Nam.
The wsa:From header is obligatory to fill out and shall include the logical address of the sender.
The list of logical addresses of participants of electronic information exchange within the Electronic Origin Certification and Verification System is given in Table 15.
The wsa:MessageID header is obligatory to fill out and is intended for unique identification of separate message instances. Values of message identifiers shall be globally unique and be UUID in accordance with RFC 4122 specification.
The wsa:Action header is intended for informing participants of the electronic information exchange on the business process procedure within which a message was sent.
The wsa:RelatesTo header is intended for message chains creation.
The wsa:RelatesTo header shall contain a value of the wsa:MessageID header of the original message. In this case, the wsa:MessageID header shall be filled with a new value.
The wsa:Action header of an applied message transmitted as part of a business process is filled out by the uniform resource identifier (URI), consisting of the following components, divided by slash-symbol «/»:
Components of information about the contents of the message are specified in the following order:
a) version of the interaction services;
b) procedure code defined in Table 2 of these Technical Specifications;
c) transaction code defined in Table 11 of these Technical Specifications;
d) message code defined in Table 14 of these Technical Specifications.
Example of filling out the wsa:Action header: tr://CERTIFICATE/0.1/ESS.VN.PRC.001/ESS.VN.TRN.001/ESS.VN.MSG.001.
VIII. USE OF DIRECTORIES AND CLASSIFIERS
Special directories and classifiers are used for electronic information exchange.
Lists of directories and classifiers used within the electronic information exchange are provided in Tables 16 — 18.
The list of main directories and classifiers used by all electronic information exchange participants
| Name | Type | Description | |
|---|---|---|---|
| country classifier | the classifier | contains the list of codes and names of countries (used in accordance with ISO 3166) | https://www.iso.org/obp/ui/#iso:std:iso:3166:-1:ed-3:v1:en,fr |
| language classifier | the classifier | contains the list of codes and names of languages in accordance with IETF RFC 5646 and IANA Language Subtag Registry | https://tools.ietf.org/html/rfc5646 and https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry |
| classifier of cargoes, packages and packaging materials | the classifier | contains the list of codes and names of types of cargo, packages and packaging materials | https://www.unece.org/fileadmin/DAM/cefact/recommendations/rec21/rec21rev1_ecetrd195e.pdf |
| UN EDIFACT Code list 3031 Types of addresses | the classifier | contains the list of codes and names of address types | https://unece.org/fileadmin/DAM/trade/untdid/d15a/tred/tred3131.htm |
| UN EDIFACT Code list 3155 Types of communications | the classifier | contains the list of codes and names of communication types | https://unece.org/fileadmin/DAM/trade/untdid/d13a/tred/tred3155.htm |
List of directories and classifiers used by the Socialist Republic of Viet Nam
The contents of detailed information from directories and classifiers and their structures are defined in Appendix E.
Directories and classifiers shall be updated when new versions are released.
Participants of electronic information exchange routinely exchange updated versions of directories and classifiers defined in Appendix E.
The participants of electronic information exchange shall solely track changes of versions of the directories and classifiers defined in tables 16 — 18 using open sources.
IX. TECHNICAL ASPECTS AND INTERACTION PARAMETERS
9.1. General information
The procedure of information interaction during the implementation of the business processes is defined in Section V of these Technical Specifications.
When a transaction is executed, each of the sent messages shall be processed successfully, or all the application-level changes in the systems of the participants of electronic information exchange made due to processing of the transaction messages shall be cancelled.
As a part of the transactions, the following types of messages are used: business process messages, acknowledgment signals, exception signals.
The list of business process messages is provided in Table 18 of these Technical Specifications.
A business process message is an applied message, which contains a set of applied data transmitted between the participants of electronic information exchange in accordance with the rules given in Section 5.3 of these Technical Specifications.
The acknowledgment signal is an applied message reporting on successful stage of business process message processing.
The exception signal is an applied message reporting on deviation from the business process message routine processing.
Description of acknowledgment and exception signals is provided in Section 9.5 of these Technical Specifications.
In order to implement a reliable information interaction it is possible to resend a business process message, if no response or an error process message was received.
When resending the message, a new wsa:MessageID identifier shall be generated.
To ensure communication between the messages within a transaction, wsa:RelatesTo field is filled out for all the business process messages, except those initiating a transaction.
Wsa:RelatesTo field contains a wsa:MessageID identifier obtained by the participant of electronic information exchange at the previous stage of the transaction.
In order to ensure control (tracking) of duplicates (resent messages), the applied data structures shall be controlled. In this case, if the Respondent finds that the message is resent by the Initiator, the Respondent shall regenerate and send a response.
9.2. Message exchange procedure
During the execution of a transaction (for all transactions defined in Section 5.3 of these Technical Specifications), the following messaging sequence is implemented:
the initiator sends a request to the respondent and waits for confirmation of receipt of the request till the time determined in the scope of transaction parameters as a deadline for confirmation of receipt expires;
the respondent receives the request and conducts the process and structural control in accordance with the rules specified in Section 9.3 of these Technical Specifications, and sends a «Received» acknowledgment signal to the initiator;
after processing of the «Received» acknowledgment signal from the respondent, the Initiator waits for confirmation of acceptance of the information contained in the request for processing till the time determined in the scope of transaction parameters as a deadline for confirmation of processing expires;
the respondent controls the data in the request in accordance with the rules specified in Section 9.3 of these Technical Specifications, and confirms the acceptance of information received for processing by sending an «Accepted for processing» acknowledgment signal to the Initiator;
after processing the «Accepted for processing» acknowledgment signal from the respondent, the initiator waits for a response with information till the time determined in the scope of transaction parameters as a deadline for receiving a response expires;
the respondent processes the received request and sends a response to the initiator;
the initiator controls data contained in the response in accordance with the rules specified in Section 9.3 of these Technical Specifications.
The order of transaction is given in Figure 6.
Figure 6. The order of transaction
9.3. Procedure of message processing by receiver
Message processing is performed by the receiver (the respondent) in accordance with the following standard stages:
a) process control of the message;
b) structural control of the body block;
c) processing of the body block data.
The process control of a message involves checking the message structure for compliance with the established formats and structures of messages without regard to the applied data transmitted, as well as checking the connectivity of messages at the message header level.
If process control of a message results in errors and checked message is not an error process message, the respondent shall send a soap:Sender error message to the initiator in accordance with the WS-Addressing 1.0 — Binding specification under the terms specified in Section 9.6 of these Technical Specifications.
The structural control of the body block involves checking its structure for compliance with the established data structures (according to XSD schema).
9.4. Parameters of transactions
Transactions shall be carried out in accordance with the given transaction parameters.
The parameter «Time to confirm receipt» sets the maximum time period between sending a business process message by the initiator and the time of receipt of the acknowledgment signal «Received».
The initiator of the business process message shall resend the message if the respondent has not confirmed the receipt within an agreed period of time. The number of retries is set using the parameter «Number of retries».
The parameter «Time to confirm acceptance for processing» sets the maximum period of time between sending a business process message by the initiator and the time of receipt of the acknowledgment signal «Accepted for processing».
The initiator of request shall resend the message if the respondent has not confirmed the receipt within the agreed period of time. The number of retries is set using the parameter «Number of retries».
The parameter «Time to respond» sets the maximum period of time between sending a business process message (request) by the initiator and the time of receipt of the respondent's response with the information on the results of processing of the request (response).
The initiator shall resend the request, if no response has been received from the respondent within the agreed period of time. The number of retries is set using the parameter «Number of retries».
Control over the observance of procedural deadlines set by the parameters «Time to confirm receipt», «Time to confirm acceptance for processing» and «Time to respond» is the initiator's responsibility. The Respondent bears no responsibility for control of these parameters.
The parameter «Number of retries» sets the maximum number of retries of business process messages.
The situation when all the retries of sending a business process message have been exhausted and the required messages have not been received by the initiator is emergency. The procedure for actions performed by the parties in emergency situations is specified in Section XI of these Technical Specifications.
9.4.1 Parameters of the transaction «Providing information on the issued certificate of origin»
Parameters of the transaction «Providing information on the issued certificate of origin» (ESS.VN.TRN.001) are given in Table 19.
Description of the transaction «Providing information on the
issued certificate of origin» (ESS.VN.TRN.001)
9.4.2 Parameters of the transaction «Receiving information on the certificate of origin»
Parameters of the transaction «Receiving information on the certificate of origin» (ESS.VN.TRN.002) are given in Table 20.
Description of the transaction «Receiving information on the certificate of origin» (ESS.VN.TRN.002)
9.5. Acknowledgment signals and exception signals
The namespaces used for description of the structure and the requisite composition of acknowledgment signals and exception signals are given in Table 21.
| Prefix | Address |
|---|---|
| xs | http://www.w3.org/2001/XMLSchema |
| sgn | urn:certificate:signal:v1.0 |
The base data types used for description of the structure and the requisite composition of acknowledgment signals and exception signals are given in Table 22.
9.5.1. The acknowledgment signal «Received»
The respondent will send the acknowledgment signal «Received» at the moment when the step of the structural block content control is made.
P.MSG.RCV message code for the acknowledgment signal «Received» will be used when the wsa:Action header, identifying the contents of the business process message, is formed. Other components of the data on message content are specified in accordance with the rules for forming the wsa:Action header for applied messages as described in Section 7.2.
The structure and requisite composition of the acknowledgment signal «Received» are given in Table 23.
The structure and requisite composition of the acknowledgment signal «Received»
9.5.2. The acknowledgment signal «Accepted for processing»
The acknowledgment signal «Accepted for processing» is sent by a respondent before processing of the body block data.
P.MSG.PRS message code for the acknowledgment signal «Accepted for processing» will be used when the wsa:Action header, identifying the contents of the business process message, is formed.
Other components of the data on message content are specified in accordance with the rules of forming of the wsa:Action header for applied messages as described in Section 7.2 of these Technical Specifications.
The structure and requisite composition of the acknowledgment signal «Accepted for processing» are given in Table 24.
9.5.3. The exception signal «Error»
The situation, when the respondent sends the exception signal «Error» to the initiator, occurs in the following cases:
a) the respondent has accepted the business process message, which was not expected to be received within a transaction execution;
b) the respondent has found errors during the structural control of the body block or format-logic control of the body block;
c) an unrecoverable error, making it impossible to perform applied data processing, occurred on the applied data processing step.
The situation, when the respondent has received the business process message, which was not expected to be received within a transaction execution, occurs in the following cases:
the message received is a business process message or an acknowledgment signal, and thus it does not apply to transactions executed by the respondent;
the respondent is not authorized to process the message received (if they do not participate in information interaction, procedure or transaction).
In these cases, the value (code) «Common:UnexpectedMessage» is assigned to the designation of Control Error (field sgn:Code) of the exception signal «Error».
If the respondent finds an error during the structural control of the body block, the value (code) «Common:DataError» is assigned to the designation of Control Error (box sgn:Code) of the exception signal «Error».
If the respondent finds an error during the format-logical control of the business process message, the value of rule code is assigned to the designation of Control Error (sgn:Code field) of the exception signal «Error», within checking of which an error occurred according to Table 29.
If there is a situation, when an unrecoverable error occurred on the step of body block data processing, making it impossible to perform data processing, the value (code) «Common:FatalError» is assigned to the designation of Control Error (field sgn:Code) of the exception signal «Error».
List of unrecoverable errors is determined by the participant of electronic information exchange independently.
P.MSG.ERR message code for the exception signal «Error» will be used when the wsa:Action header, identifying the contents of the business process message, is formed. Other components of the data on message content are specified in accordance with the rules of forming of the header wsa:Action for applied messages.
The structure and requisite composition of the exception signal «Error» are given in Table 25.
The structure and requisite compositon of the exception signal «Error»
To participate in the information interaction, the participants of electronic information exchange shall implement the services enforcing Business Process Procedures on their side.
Description of services in WSDL-format is given in Appendix F.
9.6. Error process message
If an error occurs at the step of the process control of a message, an error process message shall be formed. Error process message body block shall contain elements specified in Table 26.
The soap:Code/soap:Value element shall be completed in accordance with SOAP 1.2 specification.
The soap:Code/soap:Subcode/soap:Value element shall contain an error code.
The list of standard error codes and rules on the use of codes from WS-Addressing 1.0 — Binding specification are provided in Table 27.
The soap:Text element shall contain the error text description.
Each soap:Text element shall contain the xml:lang language identifier, formed in accordance with XML 1.0 specification.
If there is a set of soap:Text elements in the error process message, each of these elements shall contain the xml:lang language identifier, that differs from the IDs of other soap:Text elements.
The error process message shall contain at least one soap:Text element, the contents of which is presented in English, and the xml:lang language identifier shall contain «en» value.
The soap:Detail optional element shall include information detailing the error.
9.7. Services technical implementation
Electronic information exchange between the External Gateway and information interaction services provided by National Single Window of Viet Nam is performed using SOAP services.
The SOAP service shall be implemented on each side, both the External Gateway and Viet Nam side.
To implement electronic information exchange within the EOCVS defined in these Technical Specifications, EECVNCERTIFICATION service shall be used.
The list of EECVNCERTIFICATION service methods is given in Table 28.
9.7.1. The method «sendCertificateDetails»
Purpose: implementation of the operation «Receiving and processing of information on the issued certificate of origin» (ESS.VN.OPR.002)
Business process procedure: ESS.VN.PRC.001
SOAP method: sendCertificateDetails
Description: providing information on the issued certificate of origin (carried out by calling the sendCertificateDetails method by the respondent (receiver) of the message «Information on the issued certificate of origin» (ESS.VN.MSG.001)).
Input parameters: ESS.VN.MSG.001 (Certificate)
Description of the operation algorithm:
Message processing steps within the execution of the service shall comply with the rules specified in Section 9.3 of these Technical Specifications:
1. Process control of the message;
For the services, being implemented on Viet Nam side, all the message processing stages shall be executed.
For the services implemented on the External Gateway, steps 1 and 2 shall be executed. Processing step 3 is implemented and executed within Information Systems of the receiving customs authorities of the Member States.
Structural control of the body block involves the check of the message structure «Information on the issued certificate of origin» (ESS.VN.MSG.001) for compliance with the structure «Information on the certificate of origin» (Certificate) provided in Appendices B and C of these Technical Specifications.
If the results of message process control and body block structural control are successful, the acknowledgment signal «Received» shall be generated and sent. The acknowledgement signal «Received» is transmitted by calling the method «Receiving of signals on the current processing status» (sendSignal) on the side of the original message sender.
If process control of the message resulted in errors, the receiver shall send an error process message of the soap:Sender class to the sender. A detailed description of the error process message is provided in Section 9.6 of these Technical Specifications.
Before processing of the body block data, the acknowledgment signal «Accepted for processing» shall be generated and sent. The acknowledgement signal «Accepted for processing» is transmitted by calling the method «Receiving of signals on the current processing status» (sendSignal) on the side of the original message sender.
Requirements for the method of message body block data processing and requirements for the storage of message processing results are defined by information interaction participants.
If the body block data is processed successfully, the message «Notice on the results of processing of information» (ESS.VN.MSG.002) containing results of processing of information on the certificate of origin shall be prepared and sent. The message is transmitted using the method «Receiving of processing result» (sendResult) on the side of the original message sender.
If an error occurred during the body block data processing, the exception signal «Error» shall be prepared and sent in accordance with the rules from Section 9.5.3 of these Technical Specifications.
The list of potential errors within the implementation of the transaction «Providing information on the issued certificate of origin» (ESS.VN.TRN.001) is given in Table 29.
Table 29
The exception signal «Error» is transmitted by calling the method «Receiving of signals on the current processing status» (sendSignal) on the side of the original message sender.
9.7.2. The method «sendRequestCertificateDetails»
Purpose: implementation of the operation «Providing information on the certificate of origin» (ESS.VN.OPR.005)
Business process procedure: ESS.VN.PRC.002
SOAP method: sendRequestCertificateDetails
Description: receiving information on the certificate of origin (carried out by calling the sendRequestCertificateDetails method on the receiver side of the message «Request for information on the certificate of origin» (ESS.VN.MSG.004)).
Input parameters: ESS.VN.MSG.004 (Request)
Description of the operation algorithm:
Message processing steps within the execution of the service shall comply with the rules specified in Section 9.3 of these Technical Specifications:
1. Process control of the message;
2. Structural control of the body block;
3. Processing of the data block.
For the services, being implemented on Viet Nam side, all the message processing stages shall be executed.
For the services implemented on the External Gateway, steps 1 and 2 shall be executed. Processing stage 3 is implemented and executed in information systems of the authorized body-information owner of Member States.
Structural control of the body block involves the check of the message structure «Request for information on the certificate of origin» (ESS.VN.MSG.004) for compliance with the structure «Request for information on certificates of origin» (Request) provided in Appendices B and C of these Technical Specifications.
If the results of message process control and body block structural control are successful, the acknowledgment signal «Received» shall be generated and sent. The acknowledgement signal «Received» is transmitted by calling the method «Receiving of signals on the current processing status» (sendSignal) on the side of the original message sender.
If process control of the message resulted in errors, the receiver shall send an error process message of the soap:Sender class to the sender. A detailed description of the error process message is provided in Section 9.6 of these Technical Specifications.
Before processing of the body block data, the acknowledgment signal «Accepted for processing» shall be generated and sent. The acknowledgement signal «Accepted for processing» is transmitted by calling the method «Receiving of signals on the current processing status» (sendSignal) on the side of the original message sender.
If the information that satisfies the request was found, the message «Providing information on the certificate of origin» (ESS.VN.MSG.005) containing the information found shall be generated and sent. The message is transmitted using the method «Receiving of processing results containing information on the certificate of origin» (sendResultCertificateDetails) on the side of the original message sender.
If the information that satisfies the request was not found, the message «Notice on absence of information» (ESS.VN.MSG.003) shall be generated and sent. The message is transmitted using the method «Receiving of processing result» (sendResult) on the side of the original message sender.
If an error occurred during the body block data processing, the exception signal «Error» shall be prepared and sent in accordance with the rules from Section 9.5.3 of these Technical Specifications.
9.7.3. The method «sendResultCertificateDetails»
Purpose: implementation of the operation «Receiving and processing of information on the issued certificate of origin» (ESS.VN.OPR.006);
Business process procedure: ESS.VN.PRC.002;
SOAP method: sendResultCertificateDetails
Description: receiving the results of processing containing information on the certificate of origin (carried out by calling the sendResultCertificateDetails method on the receiver side of the message «Information on the certificate of origin provided in response to the request» (ESS.VN.MSG.005)).
Description of the operation algorithm:
Message processing steps within the execution of the service shall comply with the rules specified in Section 9.3 of these Technical Specifications:
1. Process control of the message;
2. Structural control of the body block;
3. Processing of the data block.
For the services, being implemented on Viet Nam side, all the message processing stages shall be executed.
For the services implemented on the External Gateway, steps 1 and 2 shall be executed. Processing step 3 is implemented and executed within Information Systems of the receiving customs authorities of the Member States.
Structural control of the body block involves the check of the message structure «Information on the issued certificate of origin provided in response to the request» (ESS.VN.MSG.005) for compliance with the structure «Information on the certificate of origin» (Certificate) provided in Appendices B and C of these Technical Specifications.
If process control of the message resulted in errors, the receiver shall send an error process message of the soap:Sender class to the sender. A detailed description of the error process message is provided in Section 9.6 of these Technical Specifications.
Requirements for the method of message body block data processing and requirements for the storage of message processing results are defined by information interaction participants.
If an error occurred during the body block data processing, the exception signal «Error» shall be prepared and sent in accordance with the rules from Section 9.5.3 of these Technical Specifications.
The exception signal «Error» is transmitted by calling the method «Receiving of signals on the current processing status» (sendSignal) on the side of the original message sender.
9.7.4. The method «sendSignal»
Purpose: Implementation of receiving and processing of acknowledgment signals and exception signals.
Description of the operation algorithm:
The procedure is defined by the signal type and transaction during which the signal was received (see Section 5.3 of these Technical Specifications).
9.7.5. The method «sendResult»
Purpose: Implementation of the following operations:
«Receiving and processing of the notice on the results of processing of information on the issued certificate of origin» (ESS.VN.OPR.003);
«Receiving and processing of information on the certificate of origin» (ESS.VN.OPR.006);
Description: Receiving of data processing result
Description of the operation algorithm:
The procedure is defined by the message code and transaction, during which the signal was received (see Section 5.3 of these Technical Specifications).
X. INFORMATION PROTECTION
The information transmitted within the business process is the information of restricted access (confidential information), the access of third parties to this information is limited, and its uncontrolled distribution is not allowed.
The Member States, the Socialist Republic of Viet Nam and the Commission shall protect information in its transferring, receiving and processing within their area of responsibility.
When information is transferred within the information space of the Member State, it is protected in accordance with the legislation and technical requirements for ensuring information protection in force on the territory of the Member State concerned.
When transmitting information within the information space of Viet Nam, the protection is ensured in accordance with the legislation and the technical requirements for information protection in force on the territory of Viet Nam.
The Commission and the General Department of Viet Nam Customs shall protect information transmitted between the IIS and the National Single Window of Viet Nam.
When transmitting information using IIS functions of protection of information from unauthorized access, information security and permanence upon unauthorized or accidental impacts is provided by means of IIS.
When transmitting and receiving information through communication channels between the External Gateway and the National Single Window of Viet Nam, the information shall be protected by means of virtual private network (VPN) using hardware-software and/or software solutions. The authentication of the interacting parties and the encryption of the transmitted data shall be organized using the IPSec (RFC 2401-2412) and IPlir (P1323565.1.034-2020) protocols.
To implement cooperation with the services two cryptographic data channels shall be used:
channel for transferring data from Viet Nam to the Commission built on the Pulse Secure Gateway VPN gateway and controlled by Viet Nam;
channel for transferring data from the Commission to Viet Nam built on the VipNet Coordinator HW VPN gateway and controlled by the Commission.
Cryptographic keys for VPN channel organization are issued and withdrawn by:
from the side of the Union — by the verification center of the Commission;
from the side of Viet Nam — by the verification center of the National Single Window of Viet Nam.
To ensure the decryption of traffic and its redirection to the service, the objects of Pulse Secure Ipsec VPN Endpoint and VipNet Client Endpoint shall be used. These objects are dedicated workstations with installed VPN gateway software client.
To ensure the flotation of data through encrypted channels, asymmetric routing shall be used.
To ensure the transmission of data from the National Single Window of Viet Nam to the IIS and from the IIS to the National Single Window of Viet Nam, source and destination IP-addresses shall be defined at the electronic information exchange implementation stage.
The applicable parameters of VPN data channels are given in Table 30.
Table 30
The information security solutions defined by these Technical Specifications shall be synchronized with the information security solutions implemented for exchange of customs information between the customs authorities of the Member States and Viet Nam and are determined by these customs authorities.
XI. EMERGENCY PROCEDURES
The emergency situations (the situations when data cannot be processed correctly) can arise during information interaction within the Business Process Procedures. Emergency situations appear due to technical faults, timeout, Control Error structure and in other cases.
Receiving any error process messages when performing Business Process Procedures is an emergency situation.
In order to resolve emergency situations, the Parties and the Commission shall provide each other with the information on the persons responsible for providing technical support during the electronic information exchange, their contact details and working hours (providing for timezone differences).
If an emergency situation is not caused by the availability of specific resources, the recipient of the exception signal «Error» and/or error process message (hereinafter referred to as «the Error notice») shall review the message, in regard to which the error notification was received, for compliance with the description of formats and structures of electronic documents, information and requirements for the message control specified in these Technical Specifications, particularly in Appendices B and C. If the non-compliance with specified requirements is detected, the recipient shall take all necessary measures to eliminate the error and send the message again. If non-compliances are not detected, the error notice recipient shall send the message containing information on the emergency situation and the inspection results to the IIS technical support.
The IIS technical support shall review the description of the emergency situation considering the information on the results of inspection carried out by the error notification recipient, prepare guidelines for its elimination, and carry out and/or coordinate works on the elimination in cooperation with the recipient and the sender of the error notice.
If an emergency situation is caused by the unavailability of certain resources, the recipient shall inform the IIS technical support on the emergency situation. If necessary, the IIS technical support shall request additional information from the error notice sender, review the emergency situation, prepare guidelines for its elimination, and carry out and/or coordinate works on the elimination in cooperation with the recipient and the sender of the error notice.
The authorized bodies and central customs authorities of the Member States, Viet Nam and the Commission shall inform each other about maintenance works on their information systems, while these information systems are unable to send and receive messages, not later than 24 hours before these works start.
General recommendations for resolving emergency situations are given in Table 31.
XII. APPLICABLE STANDARDS
The list of international and industrial standards used in the electronic information exchange implementation and these Technical Specifications development is given in Table 32.
The list of applicable standards
XIII. IMPLEMENTATION ORDER
To implement the electronic information exchange, the Parties shall:
appoint persons on the part of the Participants of electronic information exchange, as well as on the part of the Commission responsible for ensuring the electronic information exchange, and perform mutual exchange of information about persons mentioned above;
synchronize directories and classifiers specified in Appendix E hereto between the Parties;
synchronize information from national directories and classifiers used for the formation of electronic messages;
modify the software of authorized bodies and central customs authorities of the Member States and Viet Nam in terms of formation and maintenance of information resources containing information on certificates of origin;
develop software components that implement the electronic information exchange;
provide secure communication channels between the External gateway and the National Single Window of Viet Nam;
STRUCTURE OF INFORMATION TRANSMITTED
Requisite composition of an electronic document (data) structure «Information about certificate of origin» (Certificate)
Requisite composition of an electronic document (data)
structure «Notification on absence of information»
(Response)
Requisite composition of an electronic document (data) structure «Request for information about certificates of origin» (Request)
<*> There are the format rules explanations:
an..k, where k > 0 — string of characters and digits with length less than k + 1.
Requisite of an electronic document (information) structure «Information about certificates of origin» (Certificate)
<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«urn:wco:datamodel:WCO:Declaration:2» xmlns:ds=«urn:wco:datamodel:WCO:DS:1» targetNamespace=«urn:wco:datamodel:WCO:Declaration:2»>
<xs:import namespace=«urn:wco:datamodel:WCO:DS:1» schemaLocation=«DS_1p0.xsd»/>
<xs:element name=«RootDocument» type=«RootDocumentType»/>
<xs:complexType name=«RootDocumentType»>
<xs:element name=«CancellationDateTime» type=«ds:RootDocumentCancellationDateTimeType» minOccurs=«0»/>
<xs:element name=«EffectiveDateTime» type=«ds:RootDocumentEffectiveDateTimeType» minOccurs=«0»/>
<xs:element name=«ExpirationDateTime» type=«ds:RootDocumentExpirationDateTimeType»/>
<xs:element name=«FunctionCode» type=«ds:RootDocumentFunctionCodeType»/>
<xs:element name=«FunctionalReferenceID» type=«ds:RootDocumentFunctionalReferenceIDType» minOccurs=«0»/>
<xs:element name=«ID» type=«ds:RootDocumentIdentificationIDType»/>
<xs:element name=«IssueDateTime» type=«ds:RootDocumentIssueDateTimeType»/>
<xs:element name=«issueLocationID» type=«ds:RootDocumentIssueLocationIdentificationIDType»/>
<xs:element name=«TypeCode» type=«ds:RootDocumentTypeCodeType»/>
<xs:element name=«AdditionalDocument»>
<xs:element name=«IssueDateTime» type=«ds:AdditionalDocumentIssueDateTimeType»/>
<xs:element name=«issueLocationID» type=«ds:AdditionalDocumentIssueLocationIdentificationIDType»/>
<xs:element name=«IssueLocationName» type=«ds:AdditionalDocumentIssueLocationNameTextType»/>
<xs:element name=«Authenticator»>
<xs:element name=«Name» type=«ds:AuthenticatorNameTextType»/>
<xs:element name=«ID» type=«ds:AuthenticatorIdentificationIDType»/>
<xs:element name=«RoleCode» type=«ds:AuthenticatorRoleCodeType»/>
<xs:element name=«TypeCode» type=«ds:AddressTypeCodeType» minOccurs=«0»/>
<xs:element name=«CityName» type=«ds:AddressCityNameTextType» minOccurs=«0»/>
<xs:element name=«CountryCode» type=«ds:AddressCountryCodeType»/>
<xs:element name=«CountrySubDivisionCode» type=«ds:AddressCountrySubDivisionCodeType» minOccurs=«0»/>
<xs:element name=«CountrySubDivisionName» type=«ds:AddressCountrySubDivisionNameTextType» minOccurs=«0»/>
<xs:element name=«Line» type=«ds:AddressLineTextType» minOccurs=«0»/>
<xs:element name=«PostcodeID» type=«ds:AddressPostcodeIDType» minOccurs=«0»/>
<xs:element name=«LPCOAuthorizedParty»>
<xs:element name=«Name» type=«ds:LPCOAuthorizedPartyNameTextType»/>
<xs:element name=«ID» type=«ds:LPCOAuthorizedPartyIdentificationIDType» minOccurs=«0»/>
<xs:element name=«RoleCode» type=«ds:LPCOAuthorizedPartyRoleCodeType»/>
<xs:element name=«TypeCode» type=«ds:AddressTypeCodeType» minOccurs=«0»/>
<xs:element name=«CityName» type=«ds:AddressCityNameTextType» minOccurs=«0»/>
<xs:element name=«CountryCode» type=«ds:AddressCountryCodeType»/>
<xs:element name=«CountrySubDivisionCode» type=«ds:AddressCountrySubDivisionCodeType» minOccurs=«0»/>
<xs:element name=«CountrySubDivisionName» type=«ds:AddressCountrySubDivisionNameTextType» minOccurs=«0»/>
<xs:element name=«Line» type=«ds:AddressLineTextType» minOccurs=«0»/>
<xs:element name=«PostcodeID» type=«ds:AddressPostcodeIDType» minOccurs=«0»/>
<xs:element name=«AdditionalInformation»>
<xs:element name=«StatementCode» type=«ds:AdditionalInformationStatementCodeType» minOccurs=«0»/>
<xs:element name=«StatementDescription» type=«ds:AdditionalInformationStatementDescriptionTextType» minOccurs=«0»/>
<xs:element name=«LimitDateTime» type=«ds:AdditionalInformationLimitDateTimeType»/>
<xs:element name=«GoodsShipment»>
<xs:element name=«ExportationCountryCode» type=«ds:GoodsShipmentExportationCountryCodeType»/>
<xs:element name=«AdditionalInformation» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«Content» type=«ds:AdditionalInformationContentTextType»/>
<xs:element name=«StatementCode» type=«ds:AdditionalInformationStatementCodeType»/>
<xs:element name=«StatementDescription» type=«ds:AdditionalInformationStatementDescriptionTextType»/>
<xs:element name=«Consignee» minOccurs=«0»>
<xs:element name=«Name» type=«ds:ConsigneeNameTextType»/>
<xs:element name=«ID» type=«ds:ConsigneeIdentificationIDType» minOccurs=«0»/>
<xs:element name=«RoleCode» type=«ds:ConsigneeRoleCodeType»/>
<xs:element name=«TypeCode» type=«ds:AddressTypeCodeType» minOccurs=«0»/>
<xs:element name=«CityName» type=«ds:AddressCityNameTextType» minOccurs=«0»/>
<xs:element name=«CountryCode» type=«ds:AddressCountryCodeType»/>
<xs:element name=«CountrySubDivisionCode» type=«ds:AddressCountrySubDivisionCodeType» minOccurs=«0»/>
<xs:element name=«CountrySubDivisionName» type=«ds:AddressCountrySubDivisionNameTextType» minOccurs=«0»/>
<xs:element name=«Line» type=«ds:AddressLineTextType» minOccurs=«0»/>
<xs:element name=«Contact» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«Name» type=«ds:ContactNameTextType» minOccurs=«0»/>
<xs:element name=«Communication» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«ID» type=«ds:CommunicationIdentificationIDType»/>
<xs:element name=«TypeID» type=«ds:CommunicationTypeIDType» minOccurs=«0»/>
<xs:element name=«Communication» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«ID» type=«ds:CommunicationIdentificationIDType»/>
<xs:element name=«TypeID» type=«ds:CommunicationTypeIDType» minOccurs=«0»/>
<xs:element name=«Consignment» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«BorderTransportMeans» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«Name» type=«ds:BorderTransportMeansNameTextType» minOccurs=«0»/>
<xs:element name=«ID» type=«ds:BorderTransportMeansIdentificationIDType» minOccurs=«0»/>
<xs:element name=«TypeCode» type=«ds:BorderTransportMeansTypeCodeType»/>
<xs:element name=«LoadingLocation» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«Name» type=«ds:LoadingLocationNameTextType»/>
<xs:element name=«ID» type=«ds:LoadingLocationIdentificationIDType»/>
<xs:element name=«DepartureDateTime» type=«ds:LoadingLocationDepartureDateTimeType» minOccurs=«0»/>
<xs:element name=«UnloadingLocation» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«ID» type=«ds:UnloadingLocationIdentificationIDType»/>
<xs:element name=«DeliveryDestination»>
<xs:element name=«CountryCode» type=«ds:AddressCountryCodeType»/>
<xs:element name=«Name» type=«ds:ExporterNameTextType»/>
<xs:element name=«ID» type=«ds:ExporterIdentificationIDType» minOccurs=«0»/>
<xs:element name=«RoleCode» type=«ds:ExporterRoleCodeType»/>
<xs:element name=«TypeCode» type=«ds:AddressTypeCodeType» minOccurs=«0»/>
<xs:element name=«CityName» type=«ds:AddressCityNameTextType» minOccurs=«0»/>
<xs:element name=«CountryCode» type=«ds:AddressCountryCodeType»/>
<xs:element name=«CountrySubDivisionCode» type=«ds:AddressCountrySubDivisionCodeType» minOccurs=«0»/>
<xs:element name=«CountrySubDivisionName» type=«ds:AddressCountrySubDivisionNameTextType» minOccurs=«0»/>
<xs:element name=«Line» type=«ds:AddressLineTextType» minOccurs=«0»/>
<xs:element name=«PostcodeID» type=«ds:AddressPostcodeIDType» minOccurs=«0»/>
<xs:element name=«GovernmentAgencyGoodsItem» maxOccurs=«unbounded»>
<xs:element name=«SequenceNumeric» type=«ds:CommoditySequenceNumericType»/>
<xs:element name=«Description» type=«ds:CommodityDescriptionTextType»/>
<xs:element name=«CountQuantity» type=«ds:CommodityCountQuantityType» minOccurs=«0»/>
<xs:element name=«StatementCode» type=«ds:AdditionalInformationStatementCodeType»/>
<xs:element name=«StatementDescription» type=«ds:AdditionalInformationStatementDescriptionTextType»/>
<xs:element name=«Classification»>
<xs:element name=«ID» type=«ds:ClassificationIdentificationIDType»/>
<xs:element name=«IdentificationTypeCode» type=«ds:ClassificationIdentificationTypeCodeType»/>
<xs:element name=«GoodsMeasure» minOccurs=«0»>
<xs:element name=«GrossMassMeasure» type=«ds:GoodsMeasureGrossMassMeasureType»/>
<xs:element name=«NetNetWeightMeasure» type=«ds:GoodsMeasureNetNetWeightMeasureType»/>
<xs:element name=«ProductName» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«Name» type=«ds:ProductNameNameTextType»/>
<xs:element name=«NameQualifierCode» type=«ds:ProductNameNameQualifierCodeType» minOccurs=«0»/>
<xs:element name=«RuleCode» type=«ds:OriginRuleCodeType»/>
<xs:element name=«Packaging» maxOccurs=«unbounded»>
<xs:element name=«MarksNumbersID» type=«ds:PackagingMarksNumbersIDType» minOccurs=«0»/>
<xs:element name=«QuantityQuantity» type=«ds:PackagingQuantityQuantityType»/>
<xs:element name=«TypeCode» type=«ds:PackagingTypeCodeType»/>
<xs:element name=«Name» type=«ds:ImporterNameTextType»/>
<xs:element name=«ID» type=«ds:ExporterIdentificationIDType» minOccurs=«0»/>
<xs:element name=«RoleCode» type=«ds:ImporterRoleCodeType»/>
<xs:element name=«TypeCode» type=«ds:AddressTypeCodeType» minOccurs=«0»/>
<xs:element name=«CityName» type=«ds:AddressCityNameTextType» minOccurs=«0»/>
<xs:element name=«CountryCode» type=«ds:AddressCountryCodeType»/>
<xs:element name=«CountrySubDivisionCode» type=«ds:AddressCountrySubDivisionCodeType» minOccurs=«0»/>
<xs:element name=«CountrySubDivisionName» type=«ds:AddressCountrySubDivisionNameTextType» minOccurs=«0»/>
<xs:element name=«Line» type=«ds:AddressLineTextType» minOccurs=«0»/>
<xs:element name=«PostcodeID» type=«ds:AddressPostcodeIDType» minOccurs=«0»/>
<xs:element name=«Invoice» maxOccurs=«unbounded»>
<xs:element name=«ID» type=«ds:InvoiceIdentificationIDType»/>
<xs:element name=«IssueDateTime» type=«ds:InvoiceIssueDateTimeType»/>
<xs:element name=«TypeCode» type=«ds:InvoiceTypeCodeType»/>
<xs:element name=«SequenceNumeric» type=«ds:InvoiceSequenceNumericType»/>
<xs:element name=«PreviousDocument» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«ID» type=«ds:PreviousDocumentIdentificationIDType»/>
<xs:element name=«IssueDateTime» type=«ds:PreviousDocumentIssueDateTimeType»/>
<xs:element name=«TypeCode» type=«ds:PreviousDocumentTypeCodeType»/>
The scheme of electronic document data (information) «Notification on absence of information» (Response)
<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«urn:wco:datamodel:WCO:Declaration:3» xmlns:ds=«urn:wco:datamodel:WCO:DS:1» targetNamespace=«urn:wco:datamodel:WCO:Declaration:3»>
<xs:import namespace=«urn:wco:datamodel:WCO:DS:1» schemaLocation=«DS_1p0.xsd»/>
<xs:complexType name=«RootDocumentType»>
<xs:element name=«FunctionalReferenceID» type=«ds:RootDocumentFunctionalReferenceIDType»/>
<xs:element name=«IssueDateTime» type=«ds:RootDocumentIssueDateTimeType» minOccurs=«0»/>
<xs:element name=«AdditionalInformation» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«StatementDescription» type=«ds:AdditionalInformationStatementDescriptionTextType»/>
<xs:element name=«ContactOffice» minOccurs=«0»>
<xs:element name=«Contact» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«ID» type=«ds:CommunicationIdentificationIDType»/>
<xs:element name=«TypeID» type=«ds:CommunicationTypeIDType» minOccurs=«0»/>
<xs:element name=«Error» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«ValidationCode» type=«ds:ErrorValidationCodeType»/>
<xs:element name=«Pointer» minOccurs=«0» maxOccurs=«unbounded»>
<xs:element name=«SequenceNumeric» type=«ds:PointerSequenceNumericType»/>
<xs:element name=«DocumentSectionCode» type=«ds:PointerDocumentSectionCodeType»/>
The scheme of electronic document data (information) «Request for information about certificates of origin» (Request)
<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns=«urn:wco:datamodel:WCO:Declaration:1» xmlns:ds=«urn:wco:datamodel:WCO:DS:1» targetNamespace=«urn:wco:datamodel:WCO:Declaration:1»>
<xs:import namespace=«urn:wco:datamodel:WCO:DS:1» schemaLocation=«DS_1p0.xsd»/>
<xs:element name=«RootDocument» type=«RootDocumentType»/>
<xs:complexType name=«RootDocumentType»>
<xs:element name=«ID» type=«ds:RootDocumentIdentificationIDType» minOccurs=«0»/>
<xs:element name=«IssueDateTime» type=«ds:RootDocumentIssueDateTimeType»/>
<xs:element name=«issueLocationID» type=«ds:RootDocumentIssueLocationIdentificationIDType» minOccurs=«0»/>
<xs:element name=«TypeCode» type=«ds:RootDocumentTypeCodeType»/>
The scheme of acknowledgment and exception signals data
Structure and requisite composition of acknowledgment and exception signals
<xs:schemaxmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns:sgn=«urn:EEC:signal:v1.0» targetNamespace=«urn:EEC:signal:v1.0» elementFormDefault=«qualified» attributeFormDefault=«unqualified»>
<xs:simpleType name=«EDocIdType»>
xs:documentationDocument ID</xs:documentation>
<xs:restriction base=«xs:token»>
<xs:pattern value=«[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-»
<xs:simpleType name=«DateTimeType»>
xs:documentationDate by the Gregorian calendar and time in the Standard ISO 8601 format</xs:documentation>
<xs:restriction base=«xs:dateTime»/>
<xs:simpleType name=«ErrorCodeType»>
xs:documentation Error code designation </xs:documentation>
<xs:restriction base=«xs:token»>
<xs:simpleType name=«StringType»>
xs:documentation Arbitrary information in text form </xs:documentation>
<xs:restriction base=«xs:string»/>
<xs:complexType name=«DeliveryReceiptType»>
xs:documentation>«Receipt» confirmation signal Type </xs:documentation>
<xs:element name=«SignalId» type=«sgn:EDocIdType»/>
<xs:element name=«DateTime» type=«sgn:DateTimeType»/>
<xs:element name=«DeliveryReceipt» type=«sgn:DeliveryReceiptType»>
xs:documentation«Receipt» confirmation signal </xs:documentation>
<xs:complexType name=«ProcessingReceiptType»>
xs:documentation«Processing Receipt» confirmation signal Type </xs:documentation>
<xs:element name=«SignalId» type=«sgn:EDocIdType»/>
<xs:element name=«DateTime» type=«sgn:DateTimeType»/>
<xs:element name=«ProcessingReceipt» type=«sgn:ProcessingReceiptType»>
xs:documentation«Processing Receipt» confirmation signal </xs:documentation>
<xs:complexType name=«ValidationErrorType»>
xs:documentation«Error» Signal-exception Type </xs:documentation>
<xs:element name=«SignalId» type=«sgn:EDocIdType»>
xs:documentation Signal-exception ID </xs:documentation>
<xs:element name=«DateTime» type=«sgn:DateTimeType»>
xs:documentation Date and Time </xs:documentation>
<xs:element name=«Error» type=«sgn:ErrorType» maxOccurs=«unbounded»>
xs:documentation Error Details </xs:documentation>
<xs:complexType name=«ErrorType»>
xs:documentation Error Type </xs:documentation>
<xs:element name=«Code» type=«sgn:ErrorCodeType»>
xs:documentation Control Error Code Designation </xs:documentation>
<xs:element name=«Description» type=«sgn:StringType»>
xs:documentation Control Error Code Designation </xs:documentation>
<xs:element name=«Details» type=«sgn:StringType» minOccurs=«0»>
xs:documentation Error Detailed Information </xs:documentation>
<xs:element name=«EDocId» type=«sgn:EDocIdType» minOccurs=«0»>
xs:documentation Identifier of the document in which the error occurred </xs:documentation>
<xs:element name=«Reference» type=«sgn:StringType» minOccurs=«0»>
xs:documentation String of characters that makes it possible to locate unambiguously an element in the document that caused an error </xs:documentation>
<xs:element name=«ValidationError» type=«sgn:ValidationErrorType»>
xs:documentation«ControlError» Signal-exception </xs:documentation>
EXAMPLES OF ELECTRONIC DOCUMENTS
Example of electronic message «Information on the issued certificate of origin» (ESS.VN.MSG.001)
<soap:Envelope xmlns:soap=«http://www.w3.org/2003/05/soap-envelope» xmlns:urn=«urn:EEC:Interaction:v1.0» xmlns:wsa=«http://www.w3.org/2005/08/addressing»>
wsa:ToESS.VN.VN</wsa:To>
wsa:AddressESS.VN.RU</wsa:Address>
wsa:Actiontr://CERTIFICATE/0.1/ESS.VN.PRC.001/ESS.VN.TRN.001/ESS.VN.MSG.001</wsa:Action>
wsa:MessageIDurn:uuid:dba8fff6-bbb3-47c3-afb2-a9a9accce8dd</wsa:MessageID>
<n1:RootDocument xsi:schemaLocation=«urn:wco:datamodel:WCO:Declaration:2 Certificate.xsd» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xmlns:n1=«urn:wco:datamodel:WCO:Declaration:2»>
Example of electronic message «Notice on the results of processing of information» (ESS.VN.MSG.002)
<soap:Envelope xmlns:soap=«http://www.w3.org/2003/05/soap-envelope» xmlns:urn=«urn:EEC:Interaction:v1.0» xmlns:wsa=«http://www.w3.org/2005/08/addressing»>
wsa:ToESS.VN.VN</wsa:To>
wsa:AddressESS.VN.RU</wsa:Address>
wsa:Actiontr://CERTIFICATE/0.1/ESS.VN.PRC.001/ESS.VN.TRN.001/ESS.VN.MSG.002</wsa:Action>
wsa:MessageIDurn:uuid:55cc3611-b3b4-4cfa-aebb-e12c4a48d20e</wsa:MessageID>
wsa:RelatesTourn:uuid:dba8fff6-bbb3-47c3-afb2-a9a9accce8dd</wsa:RelatesTo>
<n1:RootDocument xsi:schemaLocation=«urn:wco:datamodel:WCO:Declaration:3 Response.xsd» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xmlns:n1=«urn:wco:datamodel:WCO:Declaration:3»>
Example of electronic message «Notice on absence of information» (ESS.VN.MSG.003)
<soap:Envelope xmlns:soap=«http://www.w3.org/2003/05/soap-envelope» xmlns:urn=«urn:EEC:Interaction:v1.0» xmlns:wsa=«http://www.w3.org/2005/08/addressing»>
wsa:ToESS.VN.VN</wsa:To>
wsa:AddressESS.VN.RU</wsa:Address>
wsa:Actiontr://CERTIFICATE/0.1/ESS.VN.PRC.002/P.EE.02.TRN.002/ESS.VN.MSG.003</wsa:Action>
wsa:MessageIDurn:uuid:55cc3611-b3b4-4cfa-aebb-e12c4a48d20e</wsa:MessageID>
wsa:RelatesTourn:uuid:23ccf7cb-c507-404f-aa78-4f0152a6633a</wsa:RelatesTo>
<n1:RootDocument xsi:schemaLocation=«urn:wco:datamodel:WCO:Declaration:3 Response.xsd» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xmlns:n1=«urn:wco:datamodel:WCO:Declaration:3»>
Example of electronic message «Request for information on the certificate of origin» (ESS.VN.MSG.004)
<soap:Envelope xmlns:soap=«http://www.w3.org/2003/05/soap-envelope» xmlns:urn=«urn:EEC:Interaction:v1.0» xmlns:wsa=«http://www.w3.org/2005/08/addressing»>
wsa:ToESS.VN.RU</wsa:To>
wsa:AddressESS.VN.VN</wsa:Address>
wsa:Actiontr://CERTIFICATE/0.1/ESS.VN.PRC.002/ESS.VN.TRN.002/ESS.VN.MSG.004</wsa:Action>
wsa:MessageIDurn:uuid:23ccf7cb-c507-404f-aa78-4f0152a6633a</wsa:MessageID>
<ns1:RootDocument xsi:schemaLocation=«urn:wco:datamodel:WCO:Declaration:1 Request.xsd» xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:ns1=«urn:wco:datamodel:WCO:Declaration:1»>
Example of electronic message «Information on the issued certificate of origin provided in response to the request» (ESS.VN.MSG.005)
<soap:Envelope xmlns:soap=«http://www.w3.org/2003/05/soap-envelope» xmlns:urn=«urn:EEC:Interaction:v1.0» xmlns:wsa=«http://www.w3.org/2005/08/addressing»>
wsa:ToESS.VN.VN</wsa:To>
wsa:AddressESS.VN.RU</wsa:Address>
wsa:Actiontr://CERTIFICATE/0.1/ESS.VN.PRC.002/ESS.VN.TRN.002/ESS.VN.MSG.005</wsa:Action>
wsa:MessageIDurn:uuid:84cec07f-122f-459e-a5ef-707188452691</wsa:MessageID>
wsa:RelatesTourn:uuid:23ccf7cb-c507-404f-aa78-4f0152a6633a</wsa:RelatesTo>
<n1:RootDocument xsi:schemaLocation=«urn:wco:datamodel:WCO:Declaration:2 Certificate.xsd» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xmlns:n1=«urn:wco:datamodel:WCO:Declaration:2»>
Units of measurement Classifier (used in the Union)
Units of measurement Classifier (used in the Viet Nam)
Classifier of transport and transportation of goods (used in the Union)
<*> Including any vehicle which is transported by said transport type.
Classifier of transport and transportation of goods (used in the Viet Nam)
| Code | Name |
|---|---|
| 1 | Air route |
| 2 | Sea route (container) |
| 3 | Sea route (un-container) |
| 4 | Land route (truck) |
| 5 | Rail way |
| 6 | River route |
| 9 | Others |
Classifier of documents types used for customs declaration (used in the Union)
(used in Viet Nam)
| Code | Name |
|---|---|
| INV | Invoice |
| BOL | B/L (Bill of Lading) |
| AWB | AWB (Air Waybill) |
| INS | Details of insurance |
| CON | Contract |
| ALL | All application dossier |
| ETC | Other |
THE DESCRIPTION OF WEB-SERVICES
Description of Web-services in WSDL-format
<wsdl:definitions xmlns:tns=«http://tempuri.org/» xmlns:ls_1=«urn:wco:datamodel:WCO:Declaration:1» xmlns:ls_2=«urn:wco:datamodel:WCO:Declaration:2» xmlns:ls_3=«urn:wco:datamodel:WCO:Declaration:3» xmlns:sgn=«urn:EEC:signal:v1.0» xmlns:wsdl=«http://schemas.xmlsoap.org/wsdl/» xmlns:wsam=«http://www.w3.org/2007/05/addressing/metadata» xmlns:soap12=«http://schemas.xmlsoap.org/wsdl/soap12/» name=«EECVNCertificateService» targetNamespace=«http://tempuri.org/»>
<xsd:schema xmlns:xsd=«http://www.w3.org/2001/XMLSchema» targetNamespace=«http://tempuri.org/» xmlns:ls_1=«urn:wco:datamodel:WCO:Declaration:1» xmlns:ls_2=«urn:wco:datamodel:WCO:Declaration:2» xmlns:ls_3=«urn:wco:datamodel:WCO:Declaration:3» xmlns:sgn=«urn:EEC:signal:v1.0» elementFormDefault=«qualified»>
<xsd:import namespace=«urn:wco:datamodel:WCO:Declaration:1» schemaLocation=«Request.xsd»/>
<xsd:import namespace=«urn:wco:datamodel:WCO:Declaration:2» schemaLocation=«Certificate.xsd»/>
<xsd:import namespace=«urn:wco:datamodel:WCO:Declaration:3» schemaLocation=«Response.xsd»/>
<xsd:import namespace=«urn:EEC:signal:v1.0» schemaLocation=«EECSoapSignal.xsd»/>
<xsd:element name=«sendCertificateDetails»>
<xsd:element name=«RootDocument» type=«ls_2:RootDocumentType»/>
<xsd:element name=«sendRequestCertificateDetails»>
<xsd:element name=«RootDocument» type=«ls_1:RootDocumentType»/>
<xsd:element name=«sendResultCertificateDetails»>
<xsd:element name=«RootDocument» type=«ls_2:RootDocumentType»/>
<xsd:element name=«sendSignal»>
<xsd:element name=«Signal» type=«sgn:Signal»/>
<xsd:element name=«sendResult»>
<xsd:element name=«ls_3RootDocument» type=«ls_3:RootDocumentType»/>
<wsdl:message name=«sendCertificateDetails»>
<wsdl:part name=«parameters» element=«tns:sendCertificateDetails»/>
<wsdl:message name=«sendRequestCertificateDetails»>
<wsdl:part name=«parameters» element=«tns:sendRequestCertificateDetails»/>
<wsdl:message name=«sendResultCertificateDetails»>
<wsdl:part name=«parameters» element=«tns:sendResultCertificateDetails»/>
<wsdl:message name=«sendSignal»>
<wsdl:part name=«parameters» element=«tns:sendSignal»/>
<wsdl:message name=«sendResult»>
<wsdl:part name=«parameters» element=«tns:sendResult»/>
<wsdl:portType name=«EECVNCertificateService_PortType»>
<wsdl:operation name=«sendCertificateDetails»>
wsdl:documentation«Providing information on the issued certificate of origin» service</wsdl:documentation>
<wsdl:input name=«sendCertificateDetails» message=«tns:sendCertificateDetails» wsam:Action=«http://tempuri.org/EECVNCertificateService/sendCertificateDetails»/>
<wsdl:operation name=«sendRequestCertificateDetails»>
wsdl:documentation«Receiving information about the certificate of origin» service</wsdl:documentation>
<wsdl:input name=«sendRequestCertificateDetails» message=«tns:sendRequestCertificateDetails» wsam:Action=«http://tempuri.org/EECVNCertificateService/sendRequestCertificateDetails»/>
<wsdl:operation name=«sendResultCertificateDetails»>
wsdl:documentation«Receiving results of processing containing information on the certificate of origin» service</wsdl:documentation>
<wsdl:input name=«sendResultCertificateDetails» message=«tns:sendResultCertificateDetails» wsam:Action=«http://tempuri.org/EECVNCertificateService/sendResultCertificateDetails»/>
<wsdl:operation name=«sendSignal»>
wsdl:documentation«Receiving of signals on the current processing status» service</wsdl:documentation>
<wsdl:input name=«sendSignal» message=«tns:sendSignal» wsam:Action=«http://tempuri.org/EECVNCertificateService/sendSignal»/>
<wsdl:operation name=«sendResult»>
wsdl:documentation«Receiving of the processing result» service</wsdl:documentation>
<wsdl:input name=«sendResult» message=«tns:sendResult» wsam:Action=«http://tempuri.org/EECVNCertificateService/sendResult»/>
<wsdl:binding name=«EECVNCertificateService_Binding» type=«tns:EECVNCertificateService_PortType»>
<soap12:binding style=«document» transport=«http://schemas.xmlsoap.org/soap/http»/>
<wsdl:operation name=«sendCertificateDetails»>
<soap12:operation soapActionRequired=«false» style=«document»/>
<wsdl:input name=«sendCertificateDetails»>
<wsdl:operation name=«sendRequestCertificateDetails»>
<soap12:operation soapActionRequired=«false» style=«document»/>
<wsdl:input name=«sendRequestCertificateDetails»>
<wsdl:operation name=«sendResultCertificateDetails»>
<soap12:operation soapActionRequired=«false» style=«document»/>
<wsdl:input name=«sendResultCertificateDetails»>
<wsdl:operation name=«sendSignal»>
<soap12:operation soapActionRequired=«false» style=«document»/>
<wsdl:input name=«sendSignal»>
<wsdl:operation name=«sendResult»>
<soap12:operation soapActionRequired=«false» style=«document»/>
<wsdl:input name=«sendResult»>
<wsdl:service name=«EECVNCertificateService»>
<wsdl:port name=«EECVNCertificateService» binding=«tns:EECVNCertificateService_Binding»>