GENERIC Message Implementation Guide and Process

GENERIC Message Implementation Guide and Process Specifications Final Report Version No. 1.0 09 May 2018

May 2018

This publication was produced by Nathan Associates Inc. for review by the United States Agency for

International Development.

GENERIC

Message Implementation Guide and Process Specifications

Final Report

Version No. 1.0

DISCLAIMER

This document is made possible by the support of the American people through the United States Agency for

International Development (USAID). Its contents are the sole responsibility of the author or authors and do not

necessarily reflect the views of USAID or the United States government.


Table of Contents

Acronyms and Definitions ....................................................................................................... 5

1 Introduction ...................................................................................................................... 6

2 Terms of Reference ......................................................................................................... 7

2.1 Activity, Background & Justification .......................................................................... 7

2.2 Objectives, Activities, Deliverables & Indicators ....................................................... 7

Activities ............................................................................................................ 7

Deliverables ....................................................................................................... 8

3 Methodology Used ........................................................................................................... 9

3.1 Common Header ...................................................................................................... 9

Message Implementation Guide ........................................................................ 9

General Assumptions ...................................................................................... 10

3.2 References ............................................................................................................. 11

4 Technical Specifications ................................................................................................ 12

4.1 Process Specifications ........................................................................................... 12

Sending ........................................................................................................... 12

Querying .......................................................................................................... 17

Cancelling ........................................................................................................ 27

Replacing ........................................................................................................ 31

4.2 Message Implementation Guides ........................................................................... 36

Acknowledgement Status Messages .............................................................. 38

Query and Cancellation Messages ................................................................. 44

5 Regional Services MIS Reporting and Database .......................................................... 52

5.1 Document Reporting ............................................................................................... 52

5.2 Query Reporting ..................................................................................................... 52

5.3 Cancellation Reporting ........................................................................................... 53

5.4 Replacement Reporting .......................................................................................... 54

6 Implementation Activities ............................................................................................... 55

6.1 Timeline .................................................................................................................. 55

6.2 User Acceptance Process ...................................................................................... 55

Point-to-Point Tests ......................................................................................... 55

End-to-End Tests ............................................................................................ 66

Parallel Tests ................................................................................................... 67

6.3 Success Indicators ................................................................................................. 68


Acronyms and Definitions

ACDD ASEAN Customs Declaration Document

AMS ASEAN Member States

ASEAN Association of Southeast Asian Nations

ASW ASEAN Single Window

AS1 1st Acknowledgement Status Message – from ASW Gateway to NSW

AS2 2nd Acknowledgement Status Message – from ASW Gateway to ASW Gateway

AS3 3rd Acknowledgement Status Message – from NSW to ASW Gateway

AS4 4th Acknowledgement Status Message – from Recipient to NSW

CAR Cancellation Response Message

CRQ Cancellation Request Message

e-ATIGA Electronic ASEAN Trade In Goods Agreement

e-FS Electronic Food Safety

e-AH Electronic Animal Health

e-Phyto Electronic Phytosanitary

ISO International Organization for Standardization

MIG Message Implementation Guide

MIS Management Information System

NPPO National Plant Protection Organization

NSW National Single Window

QRR Query Response Message

QRY Query Message

TOR Terms of Reference

TWG Technical Working Group

UNCL United Nations Code List

US-ACTI United States - ASEAN Connectivity through Trade and Investment

WCO World Customs Organization

XML Extensible Markup Language

XSD XML Schema Definition


1 Introduction

This report provides a “Generic Message Implementation Guide and Process Specifications”

for all future documents to be exchanged via the ASEAN Single Window (ASW). It is based

on the new ASW Gateway Common Header, designed to supersede the pre-existing e-ATIGA

Form D process.

The purpose of this report is to, firstly, provide generic process flows for sending (and

receiving) valid business document types via the ASW using the Common Header. A valid

business document type means any mutually recognized business document, as agreed by

the ASEAN Member States (AMS). At the time of writing this report, the known business

document types are; Electronic ATIGA (e-ATIGA) Form D, ASEAN Customs Declaration

Document (ACDD), Electronic Phytosanitary (e-Phyto) Certificate for Export, Electronic

Phytosanitary (e-Phyto) Certificate for Re-Export, Electronic Animal Health (e-AH) Certificate

and Electronic Food Safety (e-FS) Certificate.

Secondly, the report also provides process flows and Message Implementation Guides (MIGs)

for the ASW’s generic messages, which are common to all business document types. These

generic messages include; Acknowledgement Status messages (“AS1”, “AS2”, “AS3” and

“AS4”); Query (“QRY”) and Query Response (“QRR”) messages and; Cancellation Request

(“CRQ”) and Cancellation Response (“CAR”) messages.

In addition to providing process flows and MIGs, the report also explains how the Common

Header can be used to differentiate between an original document and a replacement. This is

achieved using the United Nations Code List (UNCL) 1225, as recommended by the World

Customs Organization (WCO), whereby an original document is identified by the code “9” and

replacement by the code “5”.

The report that follows is divided into sections; “Terms of Reference” (Section 2),

“Methodology Used” (Section 3), “Business and Information Flow Procedures” (Section 4),

“Regional Services MIS Reporting and Database” (Section 5) and “Implementation Activities”

(Section 6). Additional information is also contained in the Appendices, including “Code Lists”

(Appendix A), “XML Examples” (Appendix B) and “Information Flow Matrices” (Appendix C).


2 Terms of Reference

This section outlines the Terms of Reference (TOR) for this report.

2.1 Activity, Background & Justification

The ASEAN Single Window live implementation is a core part of the ASEAN initiative to design

and implement the ASW enabling infrastructure that will facilitate the exchange of cargo

clearance information between AMS via their respective NSWs.

Indonesia, Malaysia, Singapore, Thailand and Vietnam confirmed their readiness to shift to e-

ATIGA Form D live operation by 1 January 2018, and Brunei Darussalam, Cambodia,

Indonesia, Malaysia, the Philippines, Thailand and Vietnam confirmed their readiness to join

the ACDD testing phase from 2 April to 15 June 2018.

2.2 Objectives, Activities, Deliverables & Indicators

The objective of this activity is to develop the Message Implementation Guide (MIG) for the

query, cancelation, and replacement procedures, as well as translating the MIGs into Excel

format for the ACDD and e-Phyto Certificate to assist Member States in developing their

required agency application that will be used for the exchange of the ACDD, e-Phyto, and

other cross border documents agreed by Member States.

Activities

US-ACTI’s Consultant will provide all the design requirements and the following tasks listed

below:

Provide the development methodology to be used;

Develop the Message Implementation Guide and Process Specifications to include the business and information flow procedures.

Identify the required enhancements for the Regional Services MIS Reporting and Database to reflect the additional cancelation and replacement data

Develop the implementation activities with timeline, user acceptance process and success indicators to ensure that these required procedures are met

Provide the Message Implementation Guide and Process Specifications including a) Query, Cancelation, and Replacement Information Flow b) Impact to the Regional Services MIS Database Structure and Report

Generation

Provide the MIGs in Excel format for ACDD and e-Phyto-sanitary Certificate by 23 January 2018

The above activities additionally should cover the following:

It is assumed that a common message exchange header will be adopted, which will ensure that both inbound and outbound flows of additional documents can support generic query, cancelation, and replacement procedures;

Identify the business responses required, and additional data elements needed in implementing query, cancelation, and replacement to ensure that they can be related to the correct document type, as each additional document have unique processes;


Design and implement a mechanism to support the operation of the query, cancelation, and replacement procedures for the implementation of the common message exchange header activity. This may include the required information flow at the national level on how to link the required procedures for each particular transaction since, query, cancelation, and a replacement might happen longer than a day, although in a sequential manner, but within a period required by national laws, usually within 30 days.

This will be coordinated with the contractor of the ASW gateway to ensure smooth implementation of this required MIG.

Recommend changes to the daily generalized report file generation module that are needed to capture the cancelation and replacement documents to be reflected in the report to assist Member States in managing their national database to ensure correct statistical data is provided.

Develop the XML Schema Definition for the ASEAN Customs Declaration Document and Electronic Phyto-sanitary Certificate in Excel format since Member States agreed to start the testing phase for the exchange of the ACDD by 2 April 2018.

The consultant will be required to present the draft Message Implementation Guide and Process Specifications at the 42nd TWG Meeting.

Deliverables

The following deliverables will be provided by the US-ACTI consultant:

1) Message Implementation Guide and Process Specifications including

a) Query, Cancelation, and Replacement Information Flow

b) Impact to the Regional Services MIS Database Structure and Report

Generation

The outline schedule is:

# Item Target Date

1 Sign agreement December 4,

2017

2 Submit the Preliminary Message Implementation Guide and Process

Specifications, draft MIGs in Excel format for ACDD and E-Phyto,

including the timeline for the testing phase of the new procedures.

Member States to revert with their feedback/comments within two

weeks

January 8, 2018

3 Submit the final MIGs in Excel format for the ACDD and e-Phyto January 23, 2018

4 Present the Message Implementation Guide and Process Specifications, including timeline at the 42nd TWG meeting

February 2018

6 Submit Draft Final Message Implementation Guide and Process

Specifications

Member States to revert with their feedback/comments within two

weeks

March 2018

7 Submit Final Message Implementation Guide and Process

Specifications

April 2018

The following documents can be used as references:


ACDD Draft Final Report - Message Implementation Guide and Process Specifications

The ASW transition to live operation scope of work

This activity TOR will be conducted in collaboration with the Member States. Throughout the

duration of the project, the Consultant/Company shall prepare and submit brief progress

reports to the ASEAN Secretariat, Member States, and ACTI Lead.

3 Methodology Used

This section outlines the approach of Task 1 of the TOR; “Provide the development

methodology to be used”.

3.1 Common Header

The methodology used for this report is to adopt the ASW Gateway’s Common Header for all

future document types, including generic query and cancellation messages.

Message Implementation Guide

As shown in Table 1 below, the Common Header contains only the “metadata” required for

message routing and MIS reporting, and a “Payload” element. The “Payload” element can be

used to either; encapsulate a valid XML document or; simply as free text, such as queries.

It is important to note that all Common Header data elements should be mandatory, except

when sending original business documents, when the group “ReferenceDocument” is not

required. For details on how to populate Common Header data elements for the query and

cancellation messages, please refer to the Message Implementation Guides in Section 4.2.2.

Table 1: Common Header Structure

XML Tag Name Description Cardinality

Format

HeaderDocument 1..1

SenderParty 1..1

IdentificationId Sender Identification Id 1..1 an..35

RecipientParty 1..1

IdentificationId Recipient Identification Id 1..1 an..35

Document 1..1

IdentificationId Unique Identification Number of this Document

1..1 an..35

SequenceNo Sequence Number of submission of the Document

1..1 n..2

TypeCode Document Type Code 1..1 an..3

SubTypeCode Document Sub Type Code 1..1 an..5

FunctionCode Message Function, Coded 1..1 an..2

SubmissionDateTime

Submission Date and Time 1..1 an19

ReferenceDocument 0..1


IdentificationId Unique Identification Number of a referenced document

1..1 an..35

TypeCode Document Type Code of the referenced document

1..1 an..3

SubTypeCode Document Sub Type Code of the referenced document

1..1 an..5

IssueDateTime Issue Date and time of the referenced document

1..1 an19

Payload Business / Application Content 1..1 Text

General Assumptions

The Common Header was designed to enable any business document type to be exchanged

between NSWs within the ASW environment. Previously, prior to the enhancement of the ASW

Gateways, the design of the ASW had only catered for e-ATIGA Form Ds to be exchanged.

In addition to enabling the exchange of business documents, which must be encapsulated as

XML documents within the “Payload”, the design of the Common Header also allows for

generic query and cancellation messages, whereby the “Payload” can be used to send free

text.

The following assumptions have been made about the Common Header:

The “IdentificationId” of both the “SenderParty” and “ReceipientParty” will be mutually

agreed between the participating AMS, and they should be able to uniquely identify

any party involved in the exchange of documents. For example, for the exchange of

e-Phyto Certificates, the senders and recipients are expected to be the National Plant

Protection Organizations (NPPOs).

The “Document” group will be used to specify metadata about the document (or

message) being sent. This includes:

o An “IdentificationId” to uniquely identify the document.

o A “SequenceNo” to maintain the sequence of a series of messages within the

same conversation. For example, a conversation may start when a document

is issued by the Sender and end when they receive a response from the

Recipient. Similarly, a conversation may start when a query is initiated by the

Sender and continue until the query is ended by either the Sender or the

Recipient.

o A “TypeCode” to identify the type of document which should, unless it is not

possible to do so, be based on the United Nations Code List (UNCL) 1001.

o A “SubTypeCode”, which will be dependent on the type of document,

otherwise (if not used) it should be set to three spaces (i.e. “ “).

o An “IssueDateTime”, which should be set to the date and time when the initial

document (or message) was submitted.

The “ReferenceDocument” group will be used to specify metadata about the

document (or message) being referred to (or responded to). This includes:

o An “IdentificationId” to uniquely identify the document.

o A “TypeCode” to identify the type of document which should, unless it is not

possible to do so, be based on the United Nations Code List (UNCL) 1001.


o A “SubTypeCode”, which will be dependent on the type of document,

otherwise (if not used) it should be set to three spaces (i.e. “ “).

o An “IssueDateTime”, which should be set to the date and time when the initial

document (or message) was submitted.

The “Payload” will be used for the actual business content, which may be either;

o A valid XML document, in accordance with the associated Message

Implementation Guide, such as an e-ATIGA Form D, an ACDD, an e-Phyto

Certificate etc. or;

o Free text, such as a query, a response to a query, a reason for a cancellation

request or a response to a cancellation request.

3.2 References

The following references were used in the preparation of this report.

Technical Design Specification for ASW Common Header Enhancements ASW Technical Specification for Common Header Enhancements (Draft) 2017-10-30.docx

o Generic Message Header – Message Implementation Guide Appendix A ASW Generic Message Header-Message Implementation Guide v0.03 2017-10-25.xlsx

o Generic Message Header - Regional Services Portal - Generic Daily Transaction Report Guidance Appendix B ASW Generic Message Header-Regional Services Portal - Generic Daily Transaction Report Guidance v03.docx

e-ATIGA Form D – Message Implementation Guide v0.14 ASWSC 17 11 - Appendix 6 ATIGA Form D-Message Implementation Guide v0 14 2015-11-19

ACDD Final Report v1.08 ACDD - Final Report v1.08.docx

Electronic Phytosanitary Certificate - Final Report v1.00 Electronic Phytosanitary Certificate - Final Report v1.00.docx

Electronic Animal Health Certificate - Final Report v1.04 Electronic Animal Health Certificate - Final Report v1.04.docx

Electronic Food Safety Certificate - Draft Final Report v0.01 Electronic Food Safety Certificate - Draft Final Report v0.01.docx


4 Technical Specifications

This section outlines the approach of Task 2 of the TOR; “Develop the Message Implementation Guide and Process Specifications to include the business and information flow procedures”.

4.1 Process Specifications

The process specifications provided in this section describe the generic processes, using the

Common Header, for sending (see Section 4.1.1), querying (see Section 4.1.2), cancelling

(see Section 4.1.3) and replacing documents (see Section 4.1.4).

Sending

The Common Header can be used to send any type of electronic business document

including, but not limited to; e-ATIGA Form Ds, ACDDs, e-Phyto Certificates, e-AH Certificates

and e-FS Certificates.

When sending a business document, or a response to a business document, the ASW

Gateway’s common Acknowledgement Status messages also play an important role in the

end-to-end process, as shown in Figure 1 below.

Figure 1 – Document Information Flow

The step-by-step processes for sending a document and sending a response are detailed

below.

4.1.1.1 Sending a Document

As shown in Figure 1, and described in more detail in Table 2, the process for sending a

document starts with the Sender (Step 1) and ends when they receive an Acknowledgement

Status (“AS4”) message from the Recipient (Step 5e).

Table 2: Step-by-Step Process for Sending a Document


Step Description Implementation Notes

1 The Sender sends a document to the Recipient via the NSW of the Sending Country. Please note that this step is Mandatory.

A document is sent by the Sender either from a back-end system or using a facility within the NSW.

2a The NSW of the Sending Country sends the document to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.

The document is sent to the ASW Gateway of the Sending Country as a message, in accordance with the associated Message Implementation Guide. It is recommended that XML schemas are used to validate the document before it is encapsulated within the Common Header. Appendix B.1 provides an example of a business document, encapsulated within the Common Header, where “SequenceNo” should be set to “1” and “FunctionCode” should be set to “9” to indicate an original document.

2b The ASW Gateway of the Sending Country returns an Acknowledgement Status to the NSW of the Sending Country. Please note that this step is Optional.

The ASW Gateway’s “AS1” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 11. Appendix B.2 provides an example of an “AS1” message, where the “Reference Document” must specify the details of the document being sent, including its unique reference number, its type and the date when it was sent.

3a The ASW Gateway of the Sending Country sends the document to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.

The message must be the same as Step 2a.

3b The ASW Gateway of the Receiving Country returns an Acknowledgement Status to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.




3c The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. Please note that this step is Optional.

The message must be the same as Step 3b.

4a The ASW Gateway of the Receiving Country sends the document to the NSW of the Receiving Country. Please note that this step is Mandatory.


4b The NSW of the Receiving Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.


4c The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.


4d The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. Please note that this step is Optional.


5a The Recipient receives the document from the Sender via the NSW of the Receiving Country. Please note that this step is Mandatory.

The document is received from the Sender either into a back-end system or using a facility within the NSW. It is recommended that XML schemas are used to validate the document after it is has been extracted from the Common Header.

5b The Recipient returns an Acknowledgement Status to the NSW of the Receiving Country. Please note that this step is Mandatory.

The ASW Gateway’s “AS4” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 14. At this point, if the XML was successfully validated in Step 5a and processed by the Recipient,



“CategoryCode” should be set to “REC”. If the XML could not be processed, “CategoryCode” should be set to “NOT”. Appendix B.5 provides an example of an “AS4” message, where the “Reference Document” must specify the details of the document being sent, including its unique reference number, its type and the date when it was sent.

5c The NSW of the Receiving Country returns the Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.


5d The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.


5e The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. Please note that this step is Mandatory.


4.1.1.2 Sending a Response


response starts with the Recipient (Step 6) and ends when the Sender receives it (Step 10).

Table 3: Step-by-Step Process for Sending a Response


6 The Recipient sends a response to the Sender via the NSW of the Receiving Country. Please note that this step is Optional, as it is dependent on the type of business document.

A response is sent by the Sender either from a back-end system or using a facility within the NSW.

7a The NSW of the Receiving Country sends the response to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory, if a response has been sent in Step 6.

The response is sent to the ASW Gateway of the Receiving Country as a message, in accordance with the associated Message Implementation Guide.



It is recommended that XML schemas are used to validate the response before it is encapsulated within the Common Header. Appendix B.6 provides an example of a business response, encapsulated within the Common Header, where “SequenceNo” should be incremented by “1” and “FunctionCode” should be set to either “29” to indicate the message was accepted or; “27” to indicate that the message was not accepted.

7b The ASW Gateway of the Receiving Country returns an Acknowledgement Status to the NSW of the Receiving Country. Please note that this step is Optional.

The ASW Gateway’s “AS1” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 11. Appendix B.2 provides an example of an “AS1” message, where the “Reference Document” must specify the details of the response being sent, including its unique reference number, its type and the date when it was sent.

8a The ASW Gateway of the Receiving Country sends the response to the ASW Gateway of the Sending Country. Please note that this step is Mandatory, if a response has been sent in Step 6.


8b The ASW Gateway of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory, if a response has been sent in Step 6.


8c The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the NSW of the Receiving Country. Please note that this step is Optional.




9a The ASW Gateway of the Sending Country sends the response to the NSW of the Sending Country. Please note that this step is Mandatory, if a response has been sent in Step 6.


9b The NSW of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Sending Country. Please note that this step is Mandatory, if a response has been sent in Step 6.


9c The ASW Gateway of the Sending Country returns the Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory, if a response has been sent in Step 6.


9d The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the NSW of the Receiving Country. Please note that this step is Optional.


10 The Sender receives the response from the Recipient via the NSW of the Receiving Country. Please note that this step is Mandatory, if a response has been sent in Step 6.

The response is received from the Sender either into a back-end system or using a facility within the NSW. It is recommended that XML schemas are used to validate the response after it is has been extracted from the Common Header.

Querying

Any electronic business document can be queried using the Common Header. The process is

the same for all business document types, as shown in Figure 2.


Figure 2 – Query Information Flow (Part 1)

The step-by-step processes for querying a document, responding to a query and querying a

response are detailed below.

4.1.2.1 Querying a Document

As shown in Figure 2, and described in more detail in Table 4, the process for querying a

document starts when the Sender initiates a query (Step 1) and ends when the Recipient

receives it (Step 5).

Table 4: Step-by-Step Process for Querying a Document

Step Description Guidance Notes

1 The Sender initiates a query to the Recipient via the NSW of the Sending Country. Please note that this step is Mandatory.

A free text query is initiated by the Sender either from a back-end system or using a facility within the NSW.

2a The NSW of the Sending Country sends the query to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.

The query is sent to the ASW Gateway of the Sending Country as a “QRY” message, in accordance with the associated Message Implementation Guide – see Section 4.2.2, Table 15. Appendix B.7 provides an example of a “QRY” message using the Common Header, where “SequenceNo” should be set to “1” and “FunctionCode” should be set to “9” to indicate an original query.


The ASW Gateway’s “AS1” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 11.



Appendix B.2 provides an example of an “AS1” message, where the “Reference Document” must specify the details of the query being sent, including its unique reference number, its type (i.e. “QRY”) and the date when it was sent.

3a The ASW Gateway of the Sending Country sends the query to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.



The ASW Gateway’s “AS2” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 12. Appendix B.3 provides an example of an “AS2” message, where the “Reference Document” must specify the details of the query being sent, including its unique reference number, its type (i.e. “QRY”) and the date when it was sent.



4a The ASW Gateway of the Receiving Country sends the query to the NSW of the Receiving Country. Please note that this step is Mandatory.



The ASW Gateway’s “AS3” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 13. Appendix B.4 provides an example of an “AS3” message, where the “Reference Document” must specify the details of the query being sent, including its unique reference number, its type (i.e. “QRY”) and the date when it was sent.

4c The ASW Gateway of the Receiving Country returns the Acknowledgement




Status to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.



5 The Recipient receives the query from the Sender via the NSW of the Receiving Country. Please note that this step is Mandatory.

The free text query is received by the Recipient either into a back-end system or using a facility within the NSW.

4.1.2.2 Responding to a Query

As shown in Figure 2, and described in more detail in Table 5, the process for responding to

a query starts when the Recipient sends a response (Step 6) and ends when the Sender

receives it (Step 10).


Table 5: Step-by-Step Process for Responding to a Query


6 The Recipient sends a query response to the Sender (of the original query) via the NSW of the Receiving Country. Please note that this step is Mandatory.

A free text query response is sent by the Recipient either from a back-end system or using a facility within the NSW.

7a The NSW of the Receiving Country sends the query response to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.

The query response is sent to the ASW Gateway of the Receiving Country as a “QRR” message, in accordance with the associated Message Implementation Guide – see Section 4.2.2, Table 16. Appendix B.8 provides an example of a “QRR” message using the Common Header, where “SequenceNo” should be incremented by “1” and “FunctionCode” should be set to “9” to indicate an original query response.


The ASW Gateway’s “AS1” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 11. Appendix B.2 provides an example of an “AS1” message, where the “Reference Document” must specify the details of the query response being sent, including its unique reference number, its type (i.e. “QRR”) and the date when it was sent.

8a The ASW Gateway of the Receiving Country sends the query response to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.


8b The ASW Gateway of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.






9a The ASW Gateway of the Sending Country sends the query response to the NSW of the Sending Country. Please note that this step is Mandatory.


9b The NSW of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.


9c The ASW Gateway of the Sending Country returns the Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.




10 The Sender receives the query response from the Recipient via the NSW of the Sending Country. Please note that this step is Mandatory.

The free text query response is received by the Sender either into a back-end system or using a function within the NSW.

4.1.2.3 Querying a Response

Following an initial query from the Sender, the query process becomes iterative, when both

the Sender and Recipient will be able to query a response, as shown in Figure 3. Therefore,

this process is a continuation of the conversation between the Sender and Recipient, whereby

their respective NSWs (or back-end systems) should link each response using the Common

Header’s metadata and continue to increment the “SequenceNo” to maintain the sequence of

the conversation.


Figure 3 – Query Information Flow (Part 2)


a query starts when the Sender sends a response (Step 1) and may either end when the

Sender receives a response from the Recipient (Step 10) or, if required, the process may be

repeated.

Table 6: Step-by-Step Process for Querying a Response


1 The Sender sends a query response to the Recipient via the NSW of the Sending Country. Please note that this step is Mandatory.

A free text query response is sent by the Sender either from a back-end system or using a facility within the NSW.

2a The NSW of the Sending Country sends the query response to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.

The query response is sent to the ASW Gateway of the Sending Country as a “QRR” message, in accordance with the associated Message Implementation Guide – see Section 4.2.2, Table 16. Appendix B.8 provides an example of a “QRR” message using the Common Header, where “SequenceNo” should be incremented by “1” and “FunctionCode” should be set to “9” to indicate an original query response.


The ASW Gateway’s “AS1” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 11. Appendix B.2 provides an example of an “AS1” message, where the “Reference Document” must specify



the details of the query being sent, including its unique reference number, its type (i.e. “QRR”) and the date when it was sent.

3a The ASW Gateway of the Sending Country sends the query response to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.



The ASW Gateway’s “AS2” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 12. Appendix B.3 provides an example of an “AS2” message, where the “Reference Document” must specify the details of the query being sent, including its unique reference number, its type (i.e. “QRR”) and the date when it was sent.



4a The ASW Gateway of the Receiving Country sends the query response to the NSW of the Receiving Country. Please note that this step is Mandatory.



The ASW Gateway’s “AS3” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 13. Appendix B.4 provides an example of an “AS3” message, where the “Reference Document” must specify the details of the query being sent, including its unique reference number, its type (i.e. “QRR”) and the date when it was sent.







5 The Recipient receives the query response from the Sender via the NSW of the Receiving Country. Please note that this step is Mandatory.

The free text query response is received by the Recipient either into a back-end system or using a facility within the NSW.

6 The Recipient sends a query response to the Sender (of the original query) via the NSW of the Receiving Country. Please note that this step is Mandatory.

A free text query response is sent by the Recipient either from a back-end system or using a facility within the NSW.

7a The NSW of the Receiving Country sends the query response to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.

The query response is sent to the ASW Gateway of the Receiving Country as a “QRR” message, in accordance with the associated Message Implementation Guide – see Section 4.2.2, Table 16. Appendix B.8 provides an example of a “QRR” message using the Common Header, where “SequenceNo” should be incremented by “1” and “FunctionCode” should be set to “9” to indicate an original query response.



8a The ASW Gateway of the Receiving Country sends the query response to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.


8b The ASW Gateway of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country.




Please note that this step is Mandatory. Appendix B.3 provides an example of an “AS2” message, where the “Reference Document” must specify the details of the query response being sent, including its unique reference number, its type (i.e. “QRR”) and the date when it was sent.



9a The ASW Gateway of the Sending Country sends the query response to the NSW of the Sending Country. Please note that this step is Mandatory.


9b The NSW of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.






10 The Sender receives the query response from the Recipient via the NSW of the Sending Country. Please note that this step is Mandatory.

The free text query response is received by the Sender either into a back-end system or using a function within the NSW.


Cancelling

Any electronic business document can be cancelled (and replaced) using the Common

Header. The process is the same for all document types, as shown in Figure 4.

Figure 4 – Cancellation Information Flow

The step-by-step processes for cancelling a document, responding to a cancellation request

and replacing a document are detailed below.

4.1.3.1 Cancelling a Document

As shown in Figure 3, and described in more detail in Table 7, the process for cancelling a

document starts when the Sender sends a cancellation request (Step 1) and ends when the

Recipient receives it (Step 5).

Table 7: Step-by-Step Process for Requesting the Cancellation of a Document


1 The Sender sends a cancellation request to the Recipient via the NSW of the Sending Country. Please note that this step is Mandatory.

A cancellation request is initiated by the Sender either from a back-end system or using a facility within the NSW.

2a The NSW of the Sending Country sends the cancellation request to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.

The cancellation request is sent to the ASW Gateway of the Sending Country as a “CRQ” message, in accordance with the Message Implementation Guide – see Section 4.2.2, Table 17. Appendix B.9 provides an example of a “CRQ” message using the Common Header, where “SequenceNo” should be set to “1” and “FunctionCode” should be set to “9” to indicate an original cancellation request.

2b The ASW Gateway of the Sending Country returns an Acknowledgement

The ASW Gateway’s “AS1” message will be used for this Acknowledgement



Status to the NSW of the Sending Country. Please note that this step is Optional.

Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 11. Appendix B.2 provides an example of an “AS1” message, where the “Reference Document” must specify the details of the cancellation request being sent, including its unique reference number, its type (i.e. “CRQ”) and the date when it was sent.

3a The ASW Gateway of the Sending Country sends the cancellation request to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.



The ASW Gateway’s “AS2” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 12. Appendix B.3 provides an example of an “AS2” message, where the “Reference Document” must specify the details of the cancellation request being sent, including its unique reference number, its type (i.e. “CRQ”) and the date when it was sent.



4a The ASW Gateway of the Receiving Country sends the cancellation request to the NSW of the Receiving Country. Please note that this step is Mandatory.



The ASW Gateway’s “AS3” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 13. Appendix B.4 provides an example of an “AS3” message, where the “Reference Document” must specify the details of the cancellation request



being sent, including its unique reference number, its type (i.e. “CRQ”) and the date when it was sent.





5 The Recipient receives the cancellation request from the Sender via the NSW of the Receiving Country. Please note that this step is Mandatory.

The cancellation request is received by the Recipient either into a back-end system or using a function within the NSW.

4.1.3.2 Responding to a Cancellation Request


a cancellation request starts when the Recipient sends a cancellation response (Step 6) and

ends when the Sender receives it (Step 10).

Table 8: Step-by-Step Process for Responding to a Cancellation Request


6 The Recipient sends a cancellation response to the Sender via the NSW of the Receiving Country. Please note that this step is Mandatory.

A cancellation response is sent by the Recipient either from a back-end system or using a facility within the NSW.

7a The NSW of the Receiving Country sends the cancellation response to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.

The cancellation response is sent to the ASW Gateway of the Receiving Country as a “CAR” message, in accordance with the Message Implementation Guide – see Section 4.2.2, Table 18. Appendix B.10 provides an example of a “CAR” message using the Common Header, where “SequenceNo” should be incremented by “1” and “FunctionCode” should be set to “9” to indicate an original cancellation response.

7b The ASW Gateway of the Receiving Country returns an Acknowledgement

The ASW Gateway’s “AS1” message will be used for this Acknowledgement Status, in accordance with the



Status to the NSW of the Receiving Country. Please note that this step is Optional.

associated Message Implementation Guide – see Section 4.2.1, Table 11. Appendix B.2 provides an example of an “AS1” message, where the “Reference Document” must specify the details of the cancellation response being sent, including its unique reference number, its type (i.e. “CAR”) and the date when it was sent.

8a The ASW Gateway of the Receiving Country sends the cancellation response to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.


8b The ASW Gateway of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.

The ASW Gateway’s “AS2” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 12. Appendix B.3 provides an example of an “AS2” message, where the “Reference Document” must specify the details of the cancellation response being sent, including its unique reference number, its type (i.e. “CAR”) and the date when it was sent.



9a The ASW Gateway of the Sending Country sends the cancellation response to the NSW of the Sending Country. Please note that this step is Mandatory.


9b The NSW of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.

The ASW Gateway’s “AS3” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 13. Appendix B.4 provides an example of an “AS3” message, where the “Reference Document” must specify the details of the cancellation response being sent, including its unique



reference number, its type (i.e. “CAR”) and the date when it was sent.





10 The Sender receives the cancellation response from the Recipient via the NSW of the Sending Country. Please note that this step is Mandatory.

The cancellation response is received by the Sender either into a back-end system or using a facility within the NSW.

Replacing

Following a confirmed cancellation, documents can be replaced using the Common Header

and the same process as the original document (see Section 4.1.1). However, in order to

distinguish between an original and a replacement, the “FunctionCode” must always be set to

“5”.

Figure 5 – Replacement Information Flow

The step-by-step processes for sending a replacement and sending a response are detailed

below.

4.1.4.1 Sending a Replacement

As shown in Figure 5, and described in more detail in Table 9, the process for replacing a

document starts with the Sender (Step 1) and ends when they receive an Acknowledgement

Status (“AS4”) message from the Recipient (Step 5e).


Table 9: Step-by-Step Process for Replacing a Document


1 The Sender sends a replacement to the Recipient via the NSW of the Sending Country. Please note that this step is Mandatory.

The replacement is sent by the Sender either from a back-end system or using a facility within the NSW.

2a The NSW of the Sending Country sends the replacement to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.

The replacement is sent to the ASW Gateway of the Sending Country as a message, in accordance with the associated Message Implementation Guide. It is recommended that XML schemas are used to validate the replacement before it is encapsulated within the Common Header. Appendix B.1 provides an example of a business document, encapsulated within the Common Header, where “SequenceNo” should be set to “1” and “FunctionCode” should be set to “5” to indicate a replacement document.

2b The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. Please note that this step is Optional.

The ASW Gateway’s “AS1” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 11. Appendix B.2 provides an example of an “AS1” message, where the “Reference Document” must specify the details of the replacement being sent, including its unique reference number, its type and the date when it was sent.

3a The ASW Gateway of the Sending Country sends the replacement to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.



The ASW Gateway’s “AS2” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 12. Appendix B.3 provides an example of an “AS2” message, where the “Reference Document” must specify the details of the replacement being



sent, including its unique reference number, its type and the date when it was sent.



4a The ASW Gateway of the Receiving Country sends the replacement to the NSW of the Receiving Country. Please note that this step is Mandatory.



The ASW Gateway’s “AS3” message will be used for this Acknowledgement Status, in accordance with the associated Message Implementation Guide – see Section 4.2.1, Table 13. Appendix B.4 provides an example of an “AS3” message, where the “Reference Document” must specify the details of the replacement being sent, including its unique reference number, its type and the date when it was sent.





5a The Recipient receives the replacement from the Sender via the NSW of the Receiving Country. Please note that this step is Mandatory.

The replacement is received from the Sender either into a back-end system or using a facility within the NSW. It is recommended that XML schemas are used to validate the replacement after it is has been extracted from the Common Header.

5b The Recipient returns an Acknowledgement Status to the NSW of the Receiving Country. Please note that this step is Mandatory.




At this point, if the XML was successfully validated in Step 5a and processed by the Recipient, “CategoryCode” should be set to “REC”. If the XML could not be processed, “CategoryCode” should be set to “NOT”. Appendix B.5 provides an example of an “AS4” message, where the “Reference Document” must specify the details of the replacement being sent, including its unique reference number, its type and the date when it was sent.

5c The NSW of the Receiving Country returns the Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory.


5d The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the ASW Gateway of the Sending Country. Please note that this step is Mandatory.


5e The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. Please note that this step is Mandatory.


4.1.4.2 Sending a Response


response starts with the Recipient (Step 6) and ends when the Sender receives it (Step 10).

Table 10: Step-by-Step Process for Sending a Response


6 The Recipient sends a response to the Sender via the NSW of the Receiving Country. Please note that this step is Optional, as it is dependent on the type of document.

The response is sent by the Recipient either from a back-end system or using a facility within the NSW.

7a The NSW of the Receiving Country sends the response to the ASW Gateway of the Receiving Country.

The response is sent to the ASW Gateway of the Receiving Country in


Please note that this step is Mandatory, if a response has been sent in Step 6.

accordance with the associated Message Implementation Guide. It is recommended that XML schemas are used to validate the response before it is encapsulated within the Common Header. Appendix B.6 provides an example of an business response, encapsulated within the Common Header, where “SequenceNo” should be incremented by “1” and “FunctionCode” should be set to either “29” to indicate the message was accepted or; “27” to indicate that the message was not accepted.



8a The ASW Gateway of the Receiving Country sends the response to the ASW Gateway of the Sending Country. Please note that this step is Mandatory, if a response has been sent in Step 6.


8b The ASW Gateway of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory, if a response has been sent in Step 6.





9a The ASW Gateway of the Sending Country sends the response to the NSW of the Sending Country. Please note that this step is Mandatory, if a response has been sent in Step 6.


9b The NSW of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Sending Country. Please note that this step is Mandatory, if a response has been sent in Step 6.


9c The ASW Gateway of the Sending Country returns the Acknowledgement Status to the ASW Gateway of the Receiving Country. Please note that this step is Mandatory, if a response has been sent in Step 6.




10 The Sender receives the response from the Recipient via the NSW of the Receiving Country. Please note that this step is Mandatory, if a response has been sent in Step 6.

The response is received from the Sender either into a back-end system or using a facility within the NSW. It is recommended that XML schemas are used to validate the response after it is has been extracted from the Common Header.

4.2 Message Implementation Guides

The Message Implementation Guides provided in this section contain detailed technical specifications for the Acknowledgement Status messages (“AS1”, “AS2”, “AS3” and “AS4”) and the generic query and cancellations messages (“QRY”, “QRR”, “CRQ” and “CAR”). Details of how to create the XML instance files for each message are provided in Tables 11-18. Each table consists of 5 columns:

XML Tag Name – the name of the XML tag as defined in the relevant XML schemas

(XSDs).

Description – a short description of the data element.


Cardinality – the minimum and maximum number of occurrences of the data element

(or group of data elements). For example, the cardinalities “0..1” and “0..n” are used to

indicate a minimum occurrence of zero (i.e. optional) with maximum occurrences of

one or unlimited, respectively. Mandatory data elements are indicated using “1..1” or

“1..n”.

Format – the recommended format of the data element, where “an” is used to specify

alpha-numeric characters, “n” is used to specify numeric characters and “Text” is used

to specify unlimited free text. For example, “an3” indicates 3 fixed length alpha-numeric

characters, whereas “an..3” indicated 3 variable length alpha-numeric characters.

Similarly, n2 indicates 2 fixed length digits.

Guideline – contains further information about the data element, such as the expected

value, date format or a reference to a code list.


Acknowledgement Status Messages

The Acknowledgement Status messages (“AS1”, “AS2”, “AS3” and “AS4”) are described in more detail in Tables 11-14 below.

Table 11: Acknowledgement Status (“AS1”)

XML Tag Name Description Cardinality Format Guideline

<HeaderDocument>

<IdentificationId> Unique Identification Number of this Document

1..1 an..35 This is used to specify the identification of the message as assigned by the ASW Gateway in the Sending Country. The identification of each message should be unique to facilitate tracking of the message. However, it is not expected that the receiving system will reject the message if the identification is not unique.

<TypeCode> Document Type Code 1..1 an..3 This must always be set to "AS1".

<Name> Document Type Name 0..1 an..35 If used, this should be set to “AS1 Response”.

<SubmissionDateTime> Submission Date and Time 1..1 an19 This specifies the date/time the message is sent, in the format; CCYY-MM-DDTHH:MM:SS.

<CategoryCode> Status 1..1 an..3 This must always be set to "AS1".

<Remark> Remarks 0..1 an..512 If used, this should be set to “Message received by sending ASW Gateway”.

<ReasonCode> Reason Code 0..1 an..3 If used, this should be set to “006”.

<ReferenceDocument> 1..1 This group is used to identify the original message to which this message refers to.

<IdentificationId> Unique Identification Number of a referenced document

1..1 an..35 This is used to specify the identification of the original message to which this message refers.

<TypeCode> Document Type Code of the referenced document

1..1 an..3 This must contain a valid message type code of either “QRY”, “QRR”, “CRQ”, “CAR” or from the list of codes in Appendix A.1.



<IssueDateTime> Issue Date and time of the referenced document

1..1 an19 This specifies the date/time the original message was sent, in the format; CCYY-MM-DDTHH:MM:SS.

<SenderParty> 1..1 This group is used to identify the Sender.

<IdentificationId> Sender Identification Id 1..1 an..35 This is used to specify the identification of the Sender. The first 2 characters must be the country code and characters 3 -35 must be able to uniquely identify the sending authority, as assigned by the NSW operator.

<RecipientParty> 1..1 This group is used to identify the Recipient.

<IdentificationId> Recipient Identification Id 1..1 an..35 This is used to specify the identification of the Recipient. The first 2 characters must be the country code and characters 3 -35 must be able to uniquely identify the sending authority, as assigned by the NSW operator.

<IssueCountry> 1..1 This group is used to identify the issuing country.

<IdentificationId> Issuer Country Code 1..1 an..2 This is used to specify the identification of the sending country using the ISO 3166-2 country code.

<Name> Issuer Country Name 0..1 an..35 If used, this should be used to specify the country name, according to ISO 3166-2.



<HeaderDocument>


1..1 an..35 This is used to specify the identification of the message as assigned by the ASW Gateway in the Receiving Country.



The identification of each message should be unique to facilitate tracking of the message. However, it is not expected that the receiving system will reject the message if the identification is not unique.





<Remark> Remarks 0..1 an..512 If used, this should be set to “Message received by receiving ASW Gateway”.




















<HeaderDocument>


1..1 an..35 This is used to specify the identification of the message as assigned by the NSW in the Receiving Country. The identification of each message should be unique to facilitate tracking of the message. However, it is not expected that the receiving system will reject the message if the identification is not unique.







<Remark> Remarks 0..1 an..512 If used, this should be set to “Message received by NSW”.




















<HeaderDocument>


1..1 an..35 This is used to specify the identification of the message as assigned by the Recipient in the Receiving Country. The identification of each message should be unique to facilitate tracking of the message. However, it is not expected that the receiving system will reject the message if the identification is not unique.




<CategoryCode> Status 1..1 an..3 This must be set to either; “REC” = Received or; “NOT” = Not Processed

<Remark> Remarks 0..1 an..512 If used, this should be set to “Message received by recipient”.


















Query and Cancellation Messages

The query and cancellation messages (“QRY”, “QRR”, “CRQ” and “CAR”) are described in more detail in Tables 15-18 below.

Table 15: Query (“QRY”)



<rsm:HeaderDocument> 1..1





<Document> 1..1 This group is used to identify the message being sent.


1..1 an..35 This is used to specify the identification of the message as assigned by the NSW in the Sending Country. The identification of each message should be unique to facilitate tracking of the message. However, it is not expected that the receiving system will reject the message if the identification is not unique.

<SequenceNo> Sequence Number of submission of the Document

1..1 n..2 This must always be set to “1”, to indicate the start of a sequence of messages within a new conversation.

<TypeCode> Document Type Code 1..1 an..3 This must always be set to "QRY".

<SubTypeCode> Document Sub Type Code 1..1 an..5 This must always be set to " ".

<FunctionCode> Message Function, Coded 1..1 an..2 This must always be set to "9", to indicate an original.



<SubmissionDateTime> Submission Date and Time 1..1 an19 This specifies the date/time the message is sent, in the format; CCYY-MM-DDTHH:MM:SS

<ReferenceDocument> 1..1 This group is used to identify the message to which this message refers to.


1..1 an..35 This is used to specify the identification of the message to which this message refers.


1..1 an..3 This must contain a valid message type code from the list of codes in Appendix A.1.

<SubTypeCode> Document Sub Type Code of the referenced document

1..1 an..5 This must always be set to " ".


1..1 an19 This specifies the date/time of the message to which this message refers to was sent, in the format; CCYY-MM-DDTHH:MM:SS.

<Payload> Business / Application Content

1..1 Text This must contain the query, in free text format.

Table 16: Acknowledgement Status (“QRR”)






<IdentificationId> Recipient Identification Id 1..1 an..35 This is used to specify the identification of the Recipient. The first 2 characters must be the country code and characters 3 -35 must be able



to uniquely identify the sending authority, as assigned by the NSW operator.



1..1 an..35 This is used to specify the identification of the message as assigned by the NSW in the Receiving Country or, if sent by the Sender, as assigned by the NSW in the Sending Country. The identification of each message should be unique to facilitate tracking of the message. However, it is not expected that the receiving system will reject the message if the identification is not unique.


1..1 n..2 This should be used to indicate the next sequence number within a conversation by incrementing the sequence number specified in the previous message, to which this message refers to.

<TypeCode> Document Type Code 1..1 an..3 This must always be set to "QRR".








1..1 an..3 This must be set to either; “QRY” = for a response to a query;



“QRR” = for a response to a query response






1..1 Text This must contain the response to the query, in free text format.

Table 17: Cancellation Request (“CRQ”)









1..1 an..35 This is used to specify the identification of the message as assigned by the NSW in the Sending Country.



The identification of each message should be unique to facilitate tracking of the message. However, it is not expected that the receiving system will reject the message if the identification is not unique.


1..1 n..2 This must always be set to “1”, to indicate the start of a sequence of messages within a new conversation.

<TypeCode> Document Type Code 1..1 an..3 This must always be set to "CRQ".








1..1 an..3 This must contain a valid message type code from the list of codes in Appendix A.1.






1..1 Text This must contain the reason for the cancellation request, in free text format.

Table 18: Cancellation Response (“CAR”)










1..1 an..35 This is used to specify the identification of the message as assigned by the NSW in the Receiving Country. The identification of each message should be unique to facilitate tracking of the message. However, it is not expected that the receiving system will reject the message if the identification is not unique.


1..1 n..2 This should be used to indicate the next sequence number within a conversation by incrementing the sequence number specified in the previous message, to which this message refers to.

<TypeCode> Document Type Code 1..1 an..3 This must always be set to "CAR".










1..1 an..3 This must always be set to "CRQ".






1..1 Text This must contain a response to the cancellation request, in free text format.


5 Regional Services MIS Reporting and Database

This section outlines the approach of Task 3 of the TOR; “Identify the required enhancements

for the Regional Services MIS Reporting and Database to reflect the additional cancelation

and replacement data”.

5.1 Document Reporting

With reference to the ASW Gateway’s “Technical Design Specification for ASW Common

Header Enhancements”, the Document Type Lookup Table must be configured for all valid

business document types to enable MIS reporting, as shown in Table 19.

Table 19: Configuration of the Document Type Lookup Table for Document Reporting

Primary Document

Type

Response Document

Types

Function Code

Description Name of Reference Field

See Appendix

A.1 for

Valid Business Document

Type Codes

9 Original Business Document Document No.

AS1 1st Acknowledgement Status Message - from ASW Gateway to NSW

AS2 2nd Acknowledgement Status Message - from ASW Gateway to ASW Gateway

AS3 3rd Acknowledgement Status Message - from NSW to ASW Gateway


See Appendix

A.2 for

Valid Business Response

Type Codes

27 or 29 Business Document Response Response No.




5.2 Query Reporting

For Query (“QRY”) and Query Response (“QRR”) messages, the Document Type Lookup

Table must be configured as shown in Table 20.

Table 20: Configuration of the Document Type Lookup Table for Query Reporting


Primary Document

Type

Response Document

Types

Function Code


QRY 9 Query Query No.

QRY AS1 1st Acknowledgement Status Message - from ASW Gateway to NSW

QRY AS2 2nd Acknowledgement Status Message - from ASW Gateway to ASW Gateway

QRY AS3 3rd Acknowledgement Status Message - from NSW to ASW Gateway

QRR 9 Query Response Query Response No.

QRR AS1 1st Acknowledgement Status Message - from ASW Gateway to NSW

QRR AS2 2nd Acknowledgement Status Message - from ASW Gateway to ASW Gateway

QRR AS3 3rd Acknowledgement Status Message - from NSW to ASW Gateway

5.3 Cancellation Reporting

For the Cancellation Request (“CRQ”) and Cancellation Response (“CAR”) messages, the

Document Type Lookup Table must be configured as shown in Table 21.

Table 21: Configuration of the Document Type Lookup Table for Cancellation Reporting

Primary Document

Type

Response Document

Types

Function Code


CRQ 9 Cancellation Request Cancellation Request No.

CRQ AS1 1st Acknowledgement Status Message - from ASW Gateway to NSW

CRQ AS2 2nd Acknowledgement Status Message - from ASW Gateway to ASW Gateway

CRQ AS3 3rd Acknowledgement Status Message - from NSW to ASW Gateway

CAR 9 Cancellation Response Cancellation Response No.


Primary Document

Type

Response Document

Types

Function Code


CAR AS1 1st Acknowledgement Status Message - from ASW Gateway to NSW

CAR AS2 2nd Acknowledgement Status Message - from ASW Gateway to ASW Gateway

CAR AS3 3rd Acknowledgement Status Message - from NSW to ASW Gateway

5.4 Replacement Reporting

For replacements, in addition to the configuration of original business documents (see Section

5.1), the Document Type Lookup Table must also include additional configuration as shown

in Table 22.

Please note that the main difference between the configuration for original business

documents and replacements is that the “Function Code” must be set to “5” for replacements.

Table 22: Configuration of the Document Type Lookup Table for Replacements

Primary Document

Type

Response Document

Types

Function Code


See Appendix

A.1 for

Valid Business Document

Types

5 Replacement Replacement Document No.






6 Implementation Activities

This section explains the approach of Task 4 of the TOR; “Develop the implementation

activities with timeline, user acceptance process and success indicators to ensure that these

required procedures are met”.

6.1 Timeline

The target date for the implementation of the query process, as outlined in this report, is the

28th January 2019. At least 3 participating AMS should be ready to start the End-to-End tests

(see Section 6.2.2) by the 29th October 2018, before the formal user acceptance process

should commence.

The target date for the implementation of the cancellation and replacement process, as

outlined in this report, is the 29th April 2019. At least 3 participating AMS should be ready to

start the End-to-End tests (see Section 6.2.2) by the 28th January 2019, before the formal user

acceptance process should commence.

6.2 User Acceptance Process

The User Acceptance process for the query, cancellation and replacement involves carrying

out End-to-End Tests in the test environment, followed by Parallel Tests in the production

environment. In addition, it is also recommended that Point-to-Point tests should be carried

out by each Member State before starting the End-to-End tests.

Point-to-Point Tests

In the first phase, “Point-to-Point” tests should be carried out to ensure that each step in the

process described in Sections 4.1.2, 4.1.3 and 4.1.4 are working satisfactorily within each

AMS’ own test environment.

The proposed tests are provided in Table 23 below, which contains 3 columns:

Test No. – the unique number to identify the Point-to-Point test

Test Description – the description of each “send” process, as described in Section 4

Expected Outcomes – the main outcomes of each test, including the expected

message types, recipient parties and MIS reporting requirements

Table 23: Point-to-Point Tests

Test No.

Test Description Expected Outcomes

1 Querying a Document: 1. The Sender initiates a query to the Recipient via the NSW of the Sending Country.

1. The Sender initiates a query and a message is generated with the document type code “QRY”.

2 Querying a Document: 2a. The NSW of the Sending Country sends the query to the ASW Gateway of the Sending Country.

1. The NSW of the Sending Country sends the “QRY” message to the ASW Gateway of the Sending Country and records it as a “sent” transaction for reconciliation with the MIS Reports.


Test No.


2b. The ASW Gateway of the Sending Country returns an Acknowledgement Status to the NSW of the Sending Country. [OPTIONAL]

2. The ASW Gateway of the Sending Country receives the “QRY” message and records it as a “received” transaction for MIS Reporting.

3. The ASW Gateway of the Sending Country returns an “AS1” message to the NSW of the Sending Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]

4. The NSW of the Sending Country receives the “AS1” message and records it as a “received” transaction for reconciliation with the MIS Reports. [OPTIONAL]

3 Querying a Document: 3a. The ASW Gateway of the Sending Country sends the query to the ASW Gateway of the Receiving Country. 3b. The ASW Gateway of the Receiving Country returns an Acknowledgement Status to the ASW Gateway of the Sending Country. 3c. The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. [OPTIONAL]

1. The ASW Gateway of the Sending Country sends the “QRY” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for MIS Reporting.

2. The ASW Gateway of the Receiving Country receives the “QRY” message and records it as a “received” transaction for MIS Reporting.

3. The ASW Gateway of the Receiving Country returns an “AS2” message to the ASW Gateway of the Sending Country and records it as a “sent” transaction for MIS Reporting.

4. The ASW Gateway of the Sending Country receives the “AS2” message and records it as a “received” transaction for MIS Reporting.

5. The ASW Gateway of the Sending Country returns the “AS2” message to the NSW of the Sending Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]


4 Querying a Document: 4a. The ASW Gateway of the Receiving Country sends the query to the NSW of the Receiving Country. 4b. The NSW of the Receiving Country returns an Acknowledgement Status to the

1. The ASW Gateway of the Receiving Country sends the “QRY” message to the NSW of the Receiving Country and records it as a “sent” transaction for MIS Reporting.

2. The NSW of the Receiving Country receives the “QRY” message and records it as a “received” transaction for reconciliation with the MIS Reports.


Test No.


ASW Gateway of the Receiving Country. 4c. The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the ASW Gateway of the Sending Country. 4d. The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. [OPTIONAL]

3. The NSW of the Receiving Country returns an “AS3” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for reconciliation with the MIS Reports.

4. The ASW Gateway of the Receiving Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.

5. The ASW Gateway of the Receiving Country returns the “AS3” message to the ASW Gateway of the Sending Country and records it as a “sent” transaction for MIS Reporting.




5 Querying a Document: 5. The Recipient receives the query from the Sender via the NSW of the Receiving Country.

1. The NSW of the Receiving Country extracts the contents of the “QRY” message and makes it available to the Recipient.

6 Responding to a Query: 6. The Recipient sends a query response to the Sender (of the original query) via the NSW of the Receiving Country.

1. The Recipient responds to the query and a message is generated with the document type code “QRR”.

7 Responding to a Query: 7a. The NSW of the Receiving Country sends the query response to the ASW Gateway of the Receiving Country. 7b. The ASW Gateway of the Receiving Country returns an Acknowledgement Status to the NSW of the Receiving Country. [OPTIONAL]

1. The NSW of the Receiving Country sends the “QRR” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for reconciliation with the MIS Reports.

2. The ASW Gateway of the Receiving Country receives the “QRR” message and records it as a “received” transaction for MIS Reporting.

3. The ASW Gateway of the Receiving Country returns an “AS1” message to the NSW of the Receiving Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]


Test No.


4. The NSW of the Receiving Country receives the “AS1” message and records it as a “received” transaction for reconciliation with the MIS Reports. [OPTIONAL]

8 Responding to a Query: 8a. The ASW Gateway of the Receiving Country sends the query response to the ASW Gateway of the Sending Country. 8b. The ASW Gateway of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. 8c. The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the NSW of the Receiving Country. [OPTIONAL]

1. The ASW Gateway of the Receiving Country sends the “QRR” message to the ASW Gateway of the Sending Country and records it as a “sent” transaction for MIS Reporting.

2. The ASW Gateway of the Sending Country receives the “QRR” message and records it as a “received” transaction for MIS Reporting.

3. The ASW Gateway of the Sending Country returns an “AS2” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for MIS Reporting.


5. The ASW Gateway of the Receiving Country returns the “AS2” message to the NSW of the Receiving Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]


9 Responding to a Query: 9a. The ASW Gateway of the Sending Country sends the query response to the NSW of the Sending Country. 9b. The NSW of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. 9c. The ASW Gateway of the Sending Country returns the Acknowledgement Status to the ASW Gateway of the Receiving Country. 9d. The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the

1. The ASW Gateway of the Sending Country sends the “QRR” message to the NSW of the Sending Country and records it as a “sent” transaction for MIS Reporting.

2. The NSW of the Sending Country receives the “QRR” message and records it as a “received” transaction for reconciliation with the MIS Reports.

3. The NSW of the Sending Country returns an “AS3” message to the ASW Gateway of the Sending Country and records it as a “sent” transaction for reconciliation with the MIS Reports.



Test No.


NSW of the Receiving Country. [OPTIONAL]

5. The ASW Gateway of the Sending Country returns the “AS3” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for MIS Reporting.




10 Responding to a Query: 10. The Sender receives the query response from the Recipient via the NSW of the Sending Country.

1. The NSW of the Sending Country extracts the contents of the “QRR” message and makes it available to the Sender.

11 Querying a Response: 1. The Sender sends a query response to the Recipient via the NSW of the Sending Country.

1. The Sender sends a query response and a message is generated with the document type code “QRR”.

12 Querying a Response: 2a. The NSW of the Sending Country sends the query response to the ASW Gateway of the Sending Country. 2b. The ASW Gateway of the Sending Country returns an Acknowledgement Status to the NSW of the Sending Country.

1. The NSW of the Sending Country sends the “QRR” message to the ASW Gateway of the Sending Country and records it as a “sent” transaction for reconciliation with the MIS Reports.




13 Querying a Response: 3a. The ASW Gateway of the Sending Country sends the query response to the ASW Gateway of the Receiving Country.

1. The ASW Gateway of the Sending Country sends the “QRR” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for MIS Reporting.


Test No.


3b. The ASW Gateway of the Receiving Country returns an Acknowledgement Status to the ASW Gateway of the Sending Country. 3c. The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. [OPTIONAL]






14 Querying a Response: 4a. The ASW Gateway of the Receiving Country sends the query response to the NSW of the Receiving Country. 4b. The NSW of the Receiving Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. 4c. The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the ASW Gateway of the Sending Country. 4d. The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. [OPTIONAL]

1. The ASW Gateway of the Receiving Country sends the “QRR” message to the NSW of the Receiving Country and records it as a “sent” transaction for MIS Reporting.

2. The NSW of the Receiving Country receives the “QRR” message and records it as a “received” transaction for reconciliation with the MIS Reports.






Test No.




15 Querying a Response: 5. The Recipient receives the query response from the Sender via the NSW of the Receiving Country.

1. The NSW of the Receiving Country extracts the contents of the “QRR” message and makes it available to the Recipient.

16. Querying a Response: 6. The Recipient sends a query response to the Sender (of the original query) via the NSW of the Receiving Country.

1. The Recipient sends a query response and a message is generated with the document type code “QRR”.

17 Querying a Response: 7a. The NSW of the Receiving Country sends the query response to the ASW Gateway of the Receiving Country. 7b. The ASW Gateway of the Receiving Country returns an Acknowledgement Status to the NSW of the Receiving Country. [OPTIONAL]

1. The NSW of the Receiving Country sends the “QRR” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for reconciliation with the MIS Reports.




18 Querying a Response: 8a. The ASW Gateway of the Receiving Country sends the query response to the ASW Gateway of the Sending Country. 8b. The ASW Gateway of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. 8c. The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the

1. The ASW Gateway of the Receiving Country sends the “QRR” message to the ASW Gateway of the Sending Country and records it as a “sent” transaction for MIS Reporting.


3. The ASW Gateway of the Sending Country returns an “AS2” message to the ASW Gateway of the Receiving


Test No.


NSW of the Receiving Country. [OPTIONAL]

Country and records it as a “sent” transaction for MIS Reporting.




19 Querying a Response: 9a. The ASW Gateway of the Sending Country sends the query response to the NSW of the Sending Country. 9b. The NSW of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. 9c. The ASW Gateway of the Sending Country returns the Acknowledgement Status to the ASW Gateway of the Receiving Country. 9d. The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the NSW of the Receiving Country. [OPTIONAL]

1. The ASW Gateway of the Sending Country sends the “QRR” message to the NSW of the Sending Country and records it as a “sent” transaction for MIS Reporting.

2. The NSW of the Sending Country receives the “QRR” message and records it as a “received” transaction for reconciliation with the MIS Reports.






8. The NSW of the Receiving Country receives the “AS3” message and records it as a “received” transaction


Test No.


for reconciliation with the MIS Reports. [OPTIONAL]

20 Querying a Response: 10. The Sender receives the query response from the Recipient via the NSW of the Sending Country.

1. The NSW of the Sending Country extracts the contents of the “QRR” message and makes it available to the Sender.

21 Cancelling a Document: 1. The Sender sends a cancellation request to the Recipient via the NSW of the Sending Country.

1. The Sender initiates a cancellation request and a message is generated with the document type code “CRQ”.

22 Cancelling a Document: 2a. The NSW of the Sending Country sends the cancellation request to the ASW Gateway of the Sending Country. 2b. The ASW Gateway of the Sending Country returns an Acknowledgement Status to the NSW of the Sending Country. [OPTIONAL]

1. The NSW of the Sending Country sends the “CRQ” message to the ASW Gateway of the Sending Country and records it as a “sent” transaction for reconciliation with the MIS Reports.

2. The ASW Gateway of the Sending Country receives the “CRQ” message and records it as a “received” transaction for MIS Reporting.



23 Cancelling a Document: 3a. The ASW Gateway of the Sending Country sends the cancellation request to the ASW Gateway of the Receiving Country. 3b. The ASW Gateway of the Receiving Country returns an Acknowledgement Status to the ASW Gateway of the Sending Country. 3c. The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. [OPTIONAL]

1. The ASW Gateway of the Sending Country sends the “CRQ” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for MIS Reporting.

2. The ASW Gateway of the Receiving Country receives the “CRQ” message and records it as a “received” transaction for MIS Reporting.



5. The ASW Gateway of the Sending Country returns the “AS2” message to the NSW of the Sending Country and


Test No.


records it as a “sent” transaction for MIS Reporting. [OPTIONAL]


24 Cancelling a Document: 4a. The ASW Gateway of the Receiving Country sends the cancellation request to the NSW of the Receiving Country. 4b. The NSW of the Receiving Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. 4c. The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the ASW Gateway of the Sending Country. 4d. The ASW Gateway of the Sending Country returns the Acknowledgement Status to the NSW of the Sending Country. [OPTIONAL]

1. The ASW Gateway of the Receiving Country sends the “CRQ” message to the NSW of the Receiving Country and records it as a “sent” transaction for MIS Reporting.

2. The NSW of the Receiving Country receives the “CRQ” message and records it as a “received” transaction for reconciliation with the MIS Reports.







25 Cancelling a Document: 5. The Recipient receives the cancellation request from the Sender via the NSW of the Receiving Country.

1. The NSW of the Receiving Country extracts the contents of the “CRQ” message and makes it available to the Recipient.


Test No.


26 Responding to a Cancellation Request: 6. The Recipient sends a cancellation response to the Sender via the NSW of the Receiving Country.

1. The Recipient sends a cancellation response and a message is generated with the document type code “CAR”.

27 Responding to a Cancellation Request: 7a. The NSW of the Receiving Country sends the cancellation response to the ASW Gateway of the Receiving Country. 7b. The ASW Gateway of the Receiving Country returns an Acknowledgement Status to the NSW of the Receiving Country. [OPTIONAL]

1. The NSW of the Receiving Country sends the “CAR” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for reconciliation with the MIS Reports.

2. The ASW Gateway of the Receiving Country receives the “CAR” message and records it as a “received” transaction for MIS Reporting.



28 Responding to a Cancellation Request: 8a. The ASW Gateway of the Receiving Country sends the cancellation response to the ASW Gateway of the Sending Country. 8b. The ASW Gateway of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country. 8c. The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the NSW of the Receiving Country. [OPTIONAL]

1. The ASW Gateway of the Receiving Country sends the “CAR” message to the ASW Gateway of the Sending Country and records it as a “sent” transaction for MIS Reporting.

2. The ASW Gateway of the Sending Country receives the “CAR” message and records it as a “received” transaction for MIS Reporting.

3. The ASW Gateway of the Sending Country returns an “AS2” message to the ASW Gateway of the Receiving Country and records it as a “sent” transaction for MIS Reporting.



6. The NSW of the Receiving Country receives the “AS2” message and records it as a “received” transaction


Test No.


for reconciliation with the MIS Reports. [OPTIONAL]

29 Responding to a Cancellation Request: 9a. The ASW Gateway of the Sending Country sends the cancellation response to the NSW of the Sending Country. 9b. The NSW of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Sending Country. 9c. The ASW Gateway of the Sending Country returns the Acknowledgement Status to the ASW Gateway of the Receiving Country. 9d. The ASW Gateway of the Receiving Country returns the Acknowledgement Status to the NSW of the Receiving Country. [OPTIONAL]

1. The ASW Gateway of the Sending Country sends the “CAR” message to the NSW of the Sending Country and records it as a “sent” transaction for MIS Reporting.

2. The NSW of the Sending Country receives the “CAR” message and records it as a “received” transaction for reconciliation with the MIS Reports.







30 Responding to a Cancellation Request: 10. The Sender receives the cancellation response from the Recipient via the NSW of the Sending Country.

1. The NSW of the Sending Country extracts the contents of the “CAR” message and makes it available to the Sender.

End-to-End Tests

Once the Point-to-Point Tests have been completed, the next phase would be to carry out

End-to-End Tests with other participating AMS, one-by-one. There are 4 main tests to be


carried out, as shown in Table 24. It is recommended that each test should be repeated at

least 10 times for each type of certificate until both the sender and recipient are satisfied.

Table 24: End-to-End Tests

Test No.


1

The Sender sends a query to the Recipient.

1. A query (“QRY”) message is received by the Recipient with:

a. SequenceNo = “1” b. TypeCode = “QRY” c. SubTypeCode = “QRY” d. FunctionCode = “9”

2. A query response (“QRR”) message is received by the Sender with:

a. SequenceNo = “2” b. TypeCode = “QRR” c. SubTypeCode = “QRR” d. FunctionCode = “9”

2

The Sender queries the response from the Recipient.

1. A query response (“QRR”) message is received by the Recipient with:


2. A query response (“QRR”) message is received by the Sender with:


3 The Sender sends a cancellation request to the Recipient.

1. A cancellation request (“CRQ”) message is received by the Recipient with:

a. SequenceNo = “1” b. TypeCode = “CRQ” c. SubTypeCode = “CRQ” d. FunctionCode = “9”

2. A cancellation response (“CAR”) message is received by the Sender with:

a. SequenceNo = “2” b. TypeCode = “CAR” c. SubTypeCode = “CAR” d. FunctionCode = “9”

4 The Sender sends a replacement to the Recipient.

Please refer to the Message Implementation Guide for the relevant business document e.g. e-ATIGA Form D, ACDD, e-Phyto Certificate, e-AH Certificate etc.

Parallel Tests

In the final phase, the same End-to-End Tests should be repeated in the production

environment, to simulate live Parallel Tests. It is recommended that each test should be

repeated at least 10 times until both the sender and recipient are satisfied.


6.3 Success Indicators

The success indicators for the User Acceptance Process should cover all of the expected

outcomes described in Section 6.2. It is also recommended that they should cover other areas

as well, such as the successful implementation of the XSDs.

The proposed acceptance criteria is provided in Table 25 below. There are 3 columns:

No. – the unique number used to identify the success indicator

Success Indicator – a description of each success indicator

Requirement – Mandatory or Optional, to indicate whether the success indicator must

be satisfied or not

Table 25: Acceptance Criteria

No. Description Requirement

1 The Sender sends a query to the Recipient

1.1 A query (“QRY”) message is received by the Recipient Mandatory

1.2 A query response (“QRR”) message is received by the Sender Mandatory

2 The Sender queries the response from the Recipient

2.1 A query response (“QRR”) message is received by the Recipient Mandatory

2.2 A query response (“QRR”) message is received by the Sender Mandatory

3 The Sender sends a cancellation request to the Recipient

3.1 A cancellation request (“CRQ”) message is received by the Recipient Mandatory

3.2 A cancellation request message (“CAR”) is received by the Sender Mandatory

4 End-to-end test of a replacement sent by the Sender

4.1 A replacement is received by the Recipient Mandatory

4.2 A response is received by the Sender Optional

5 Acknowledgement Status messages

5.1 AS1: ASW Gateway of Sending Country to NSW of Sending Country Mandatory

5.2 AS1: ASW Gateway of Receiving Country to NSW of Receiving Country

Mandatory

5.3 AS2: ASW Gateway of Receiving Country to ASW Gateway of Sending Country

Mandatory

5.4 AS2: ASW Gateway of Sending Country to ASW Gateway of Receiving Country

Mandatory

5.5 AS3: NSW of Receiving Country to ASW Gateway of Sending Country Mandatory

5.6 AS3: NSW of Sending Country to ASW Gateway of Receiving Country Mandatory

6 Common Header

6.1 Implementation of the Query and Query Response Mandatory

6.2 Implementation of the Cancellation Request and Cancellation Response

Mandatory

7 MIS reporting

7.1 The number of “QRY” messages sent by the NSW of the Sending Country is equal to the number of “QRY” messages received by the

Mandatory


No. Description Requirement

NSW of the Receiving Country and also equal to the number of “AS1”, “AS2” and “AS3” messages

7.2 The number of “QRR” messages sent by the NSW of the Receiving Country is equal to the number of “QRR” messages received by the NSW of the Sending Country and also equal to the number of “AS1”, “AS2” and “AS3” messages

Mandatory

7.3 The number of “QRR” messages sent by the NSW of the Sending Country is equal to the number of “QRR” messages received by the NSW of the Receiving Country and also equal to the number of “AS1”, “AS2” and “AS3” messages

Mandatory

7.4 The number of “CRQ” messages sent by the NSW of the Sending Country is equal to the number of “QRY” messages received by the NSW of the Receiving Country and also equal to the number of “AS1”, “AS2” and “AS3” messages

Mandatory

7.5 The number of “CAR” messages sent by the NSW of the Receiving Country is equal to the number of “CAR” messages received by the NSW of the Sending Country and also equal to the number of “AS1”, “AS2” and “AS3” messages

Mandatory


Appendix A Code Lists

Appendix A.1 – Valid Business Document Type Codes

Code Name

648 Electronic Animal Health (e-AH) Certificate

849 Electronic Phytosanitary (e-Phyto) Certificate for Re-Export

851 Electronic Phytosanitary (e-Phyto) Certificate for Export

852 Electronic Food Safety (e-FS) Certificate

864 Electronic ATIGA (e-ATIGA) Form D

960 ASEAN Customs Declaration Document (ACDD)

Appendix A.2 – Valid Business Response Type Codes

Code Name

312 Generic Electronic Sanitary and Phytosanitary (e-SPS) Acknowledgement

961 Generic Customs Response

RES e-ATIGA Form D Response


Appendix B XML Examples

Appendix B.1 – Business Document

<?xml version="1.0" encoding="UTF-8"?>

<rsm:HeaderDocument xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:rsm="urn:un:unece:uncefact:data:draft:generalheader:0:1"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:un:unece:uncefact:data:draft:generalheader:0:1

GenericHeaderMessage_V1.03.xsd">

<SenderParty>

<IdentificationId>XXXXXXXXXX</IdentificationId>

</SenderParty>

<RecipientParty>


</RecipientParty>

<Document>


<SequenceNo>1</SequenceNo>

<TypeCode>960</TypeCode>

<SubTypeCode>960</SubTypeCode>

<FunctionCode>9</FunctionCode>

<SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime>

</Document>

<Payload>

<![CDATA[


<Declaration xmlns="urn:wco:datamodel:WCO:Declaration:1"


xsi:schemaLocation="urn:wco:datamodel:WCO:Declaration:1 Declaration_1p0.xsd">


<ID>XXXXXXXXXX</ID>

<IssueDateTime formatCode="102">2016-05-12</IssueDateTime>


<DeclarationOfficeID>XXXXXXXXXX</DeclarationOfficeID>

<GoodsItemQuantity>99999</GoodsItemQuantity>

<InvoiceAmount currencyID="USD">999999.999</InvoiceAmount>

<TotalPackageQuantity>99999999</TotalPackageQuantity>

<Authentication>

<ActualDateTime formatCode="102">2016-05-12</ActualDateTime>

<Authentication>XXXXXXXXXX</Authentication>

<LocationName>XXXXXXXXXX</LocationName>

<Authenticator>

<Name>XXXXXXXXXX</Name>

<Designation>XXXXXXXXXX</Designation>

</Authenticator>

</Authentication>

<AdditionalDocument>

<ID>XXXXXXXXXX</ID>

<IssueDateTime formatCode="102">2016-05-12</IssueDateTime>


</AdditionalDocument>


<Control>

<AdditionalInformation>

<Content>XXXXXXXXXX</Content>

</AdditionalInformation>

</Control>

<CurrencyExchange>

<CurrencyTypeCode>USD</CurrencyTypeCode>

<RateNumeric>999999.99999</RateNumeric>

</CurrencyExchange>

<Declarant>


<ID>XXXXXXXXXX</ID>

<Address>

<CityName>XXXXXXXXXX</CityName>

<CountryCode>MY</CountryCode>

<Line>XXXXXXXXXX</Line>

<PostcodeID>XXXXXXXXX</PostcodeID>

</Address>

</Declarant>

<DeclarationGuarantee>

<ReferenceID>XXXXXXXXXX</ReferenceID>

<SecurityDetailsCode>M</SecurityDetailsCode>

</DeclarationGuarantee>

<DutyTaxFee>

<Payment>

<MethodCode>F</MethodCode>

<ReferenceID>XXXXXXXXXX</ReferenceID>

<PaymentAmount currencyID="USD">999999.999</PaymentAmount>

</Payment>

</DutyTaxFee>

<ExitOffice>

<ID>XXXXXXXXXX</ID>

<Warehouse>


<ID>XXXXXXXXXX</ID>

</Warehouse>

</ExitOffice>

<Exporter>


<ID>XXXXXXXXXX</ID>

<Address>


<CountryCode>MY</CountryCode>


<PostcodeID>XXXXXXXXXX</PostcodeID>

</Address>

</Exporter>

<GoodsShipment>

<ExitDateTime formatCode="102">2016-05-12</ExitDateTime>

<TransactionNatureCode>9</TransactionNatureCode>





<Consignment>

<ContainerCode>68</ContainerCode>


<ID>XXXXXXXXXX</ID>



<BorderTransportMeans>


<ID>XXXXXXXXXX</ID>


<RegistrationNationalityCode>MY</RegistrationNationalityCode>

<JourneyID>XXXXXXXXXX</JourneyID>

</BorderTransportMeans>

<DepartureTransportMeans>


<ID>XXXXXXXXXX</ID>

<RegistrationNationalityCode>SG</RegistrationNationalityCode>

<JourneyID>XXXXXXXXXX</JourneyID>

</DepartureTransportMeans>

<GoodsLocation>


<ID>XXXXXXXXXX</ID>

</GoodsLocation>

<LoadingLocation>

<Name>KUALA LUMPUR</Name>

<ID>MYKUL</ID>

</LoadingLocation>

<TransportContractDocument>

<ID>XXXXXXXXXX</ID>


</TransportContractDocument>

<TransportEquipment>

<ID>XXXXXXXXXXXXXXXXX</ID>

</TransportEquipment>

<UnloadingLocation>

<Name>BANGKOK</Name>

<ID>THBKK</ID>

</UnloadingLocation>

</Consignment>

<Destination>

<CountryCode>CN</CountryCode>

<CountryName>CHINA</CountryName>

</Destination>

<ExportCountry>

<ID>MY</ID>

<Name>MALAYSIA</Name>

</ExportCountry>

<GovernmentAgencyGoodsItem>

<SequenceNumeric>99999</SequenceNumeric>

<StatisticalValueAmount currencyID="USD">999999.999</StatisticalValueAmount>



<ID>XXXXXXXXXX</ID>






<Commodity>

<Description>XXXXXXXXXX</Description>

<Classification>

<ID>XXXXXXXXXX</ID>

<IdentificationTypeCode>AHTN</IdentificationTypeCode>

</Classification>

<DutyTaxFee>

<DutyRegimeCode>2</DutyRegimeCode>

<Payment>

<MethodCode>A</MethodCode>

<TaxAssessedAmount currencyID="USD">999999.999</TaxAssessedAmount>

</Payment>

</DutyTaxFee>

<InvoiceLine>

<ItemChargeAmount currencyID="USD">999999.999</ItemChargeAmount>

</InvoiceLine>

</Commodity>

<CustomsValuation>

<MethodCode>138</MethodCode>

<ChargeDeduction>

<ChargesTypeCode>64</ChargesTypeCode>

<OtherChargeDeductionAmount

currencyID="USD">999999.999</OtherChargeDeductionAmount>

</ChargeDeduction>

</CustomsValuation>

<GoodsMeasure>

<GrossMassMeasure unitCode="KGM">999999.999999</GrossMassMeasure>

<NetNetWeightMeasure unitCode="KGM">999999.999999</NetNetWeightMeasure>

<TariffQuantity unitCode="KGM">999999.999999</TariffQuantity>

</GoodsMeasure>

<GovernmentProcedure>

<CurrentCode>X</CurrentCode>

</GovernmentProcedure>

<Origin>

<CountryCode>ID</CountryCode>

</Origin>

<Packaging>

<MarksNumbersID>XXXXXXXXXX</MarksNumbersID>

<QuantityQuantity>99999999</QuantityQuantity>

<TypeCode>BX</TypeCode>

</Packaging>

<PreviousDocument>

<ID>XXXXXXXXXX</ID>


</PreviousDocument>

</GovernmentAgencyGoodsItem>


<Origin>

<CountryCode>ID</CountryCode>

</Origin>

<TradeTerms>

<ConditionCode>CIF</ConditionCode>

<Description>XXXXXXXXXX</Description>

</TradeTerms>

<UCR>

<ID>XXXXXXXXXX</ID>

</UCR>

</GoodsShipment>

<Importer>


<ID>XXXXXXXXXX</ID>

<Address>


<CountryCode>TH</CountryCode>


<PostcodeID>XXXXXXXXX</PostcodeID>

</Address>

</Importer>

<Principal>


<ID>XXXXXXXXXX</ID>

</Principal>

<SupervisingOffice>

<ID>XXXXXXXXXX</ID>

</SupervisingOffice>

<TransitOffice>


</TransitOffice>

<TransitOperationStartOffice>


</TransitOperationStartOffice>

<TransitOperationTerminationOffice>


</TransitOperationTerminationOffice>

<UCR>

<TraderAssignedReferenceID>XXXXXXXXXX</TraderAssignedReferenceID>

</UCR>

</Declaration>

]]>

</Payload>

</rsm:HeaderDocument>

Appendix B.2 – Acknowledgement Status (AS1)

<?xml version="1.0" encoding="UTF-8" ?> <rsm:UNeDocsShipBIM xmlns="urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInformationEntitySchemaModule:0:8" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rsm="urn:un:unece:uncefact:data:draft:UNeDocsShipBIM:0:8"


xsi:schemaLocation="urn:un:unece:uncefact:data:draft:UNeDocsShipBIM:0:8 UNeDocsShipBIM-0.8.xsd"> <rsm:HeaderDocument> <IdentificationId>XXXXXXXXXXX</IdentificationId> <TypeCode>AS1</TypeCode> <Name>AS1 Response</Name> <SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime> <CategoryCode>AS1</CategoryCode> <Remark>Message received by sending ASW Gateway</Remark> <ReasonCode>006</ReasonCode> <ReferenceDocument> <IdentificationId>XXXXXXXXXXX</IdentificationId> <TypeCode>XXX</TypeCode> <IssueDateTime>2002-07-01T05:10:10</IssueDateTime> </ReferenceDocument> <SenderParty> <IdentificationId schemeId="1" schemeAgencyId="ASEAN">XXXXXXXXXXX</IdentificationId> </SenderParty> <RecipientParty> <IdentificationId schemeId="1" schemeAgencyId="ASEAN">XXXXXXXXXXX</IdentificationId> </RecipientParty> <IssueCountry> <IdentificationId schemeId="3" schemeAgencyId="UNECE" schemeVersionId="15">ID</IdentificationId> <Name>XXXXXXXXXXX</Name> </IssueCountry> </rsm:HeaderDocument>

</rsm:UNeDocsShipBIM>


<?xml version="1.0" encoding="UTF-8" ?> <rsm:UNeDocsShipBIM xmlns="urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInformationEntitySchemaModule:0:8" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rsm="urn:un:unece:uncefact:data:draft:UNeDocsShipBIM:0:8" xsi:schemaLocation="urn:un:unece:uncefact:data:draft:UNeDocsShipBIM:0:8 UNeDocsShipBIM-0.8.xsd"> <rsm:HeaderDocument> <IdentificationId>XXXXXXXXXXX</IdentificationId> <TypeCode>AS2</TypeCode> <Name>AS2 Response</Name> <SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime> <CategoryCode>AS2</CategoryCode> <Remark>Message received by receiving ASW Gateway</Remark> <ReasonCode>006</ReasonCode> <ReferenceDocument> <IdentificationId>XXXXXXXXXXX</IdentificationId> <TypeCode>XXX</TypeCode> <IssueDateTime>2002-07-01T05:10:10</IssueDateTime> </ReferenceDocument> <SenderParty> <IdentificationId schemeId="1" schemeAgencyId="ASEAN">XXXXXXXXXXX</IdentificationId>


</SenderParty> <RecipientParty> <IdentificationId schemeId="1" schemeAgencyId="ASEAN">XXXXXXXXXXX</IdentificationId> </RecipientParty> <IssueCountry> <IdentificationId schemeId="3" schemeAgencyId="UNECE" schemeVersionId="15">ID</IdentificationId> <Name>XXXXXXXXXXX</Name> </IssueCountry> </rsm:HeaderDocument> </rsm:UNeDocsShipBIM>


<?xml version="1.0" encoding="UTF-8" ?> <rsm:UNeDocsShipBIM xmlns="urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInformationEntitySchemaModule:0:8" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rsm="urn:un:unece:uncefact:data:draft:UNeDocsShipBIM:0:8" xsi:schemaLocation="urn:un:unece:uncefact:data:draft:UNeDocsShipBIM:0:8 UNeDocsShipBIM-0.8.xsd"> <rsm:HeaderDocument> <IdentificationId>XXXXXXXXXXX</IdentificationId> <TypeCode>AS3</TypeCode> <Name>AS3 Response</Name> <SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime> <CategoryCode>AS3</CategoryCode> <Remark>Message received by NSW</Remark> <ReasonCode>006</ReasonCode> <ReferenceDocument> <IdentificationId>XXXXXXXXXXX</IdentificationId> <TypeCode>XXX</TypeCode> <IssueDateTime>2002-07-01T05:10:10</IssueDateTime> </ReferenceDocument> <SenderParty> <IdentificationId schemeId="1" schemeAgencyId="ASEAN">XXXXXXXXXXX</IdentificationId> </SenderParty> <RecipientParty> <IdentificationId schemeId="1" schemeAgencyId="ASEAN">XXXXXXXXXXX</IdentificationId> </RecipientParty> <IssueCountry> <IdentificationId schemeId="3" schemeAgencyId="UNECE" schemeVersionId="15">ID</IdentificationId> <Name>XXXXXXXXXXX</Name> </IssueCountry> </rsm:HeaderDocument> </rsm:UNeDocsShipBIM>


<?xml version="1.0" encoding="UTF-8" ?> <rsm:UNeDocsShipBIM xmlns="urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInformationEntitySchemaModule:0:8" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"


xmlns:rsm="urn:un:unece:uncefact:data:draft:UNeDocsShipBIM:0:8" xsi:schemaLocation="urn:un:unece:uncefact:data:draft:UNeDocsShipBIM:0:8 UNeDocsShipBIM-0.8.xsd"> <rsm:HeaderDocument> <IdentificationId>XXXXXXXXXXX</IdentificationId> <TypeCode>AS4</TypeCode> <Name>AS4 Response</Name> <SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime> <CategoryCode>REC</CategoryCode> <Remark>Message received by recipient</Remark> <ReasonCode>006</ReasonCode> <ReferenceDocument> <IdentificationId>XXXXXXXXXXX</IdentificationId> <TypeCode>XXX</TypeCode> <IssueDateTime>2002-07-01T05:10:10</IssueDateTime> </ReferenceDocument> <SenderParty> <IdentificationId schemeId="1" schemeAgencyId="ASEAN">XXXXXXXXXXX</IdentificationId> </SenderParty> <RecipientParty> <IdentificationId schemeId="1" schemeAgencyId="ASEAN">XXXXXXXXXXX</IdentificationId> </RecipientParty> <IssueCountry> <IdentificationId schemeId="3" schemeAgencyId="UNECE" schemeVersionId="15">ID</IdentificationId> <Name>XXXXXXXXXXX</Name> </IssueCountry> </rsm:HeaderDocument> </rsm:UNeDocsShipBIM>

Appendix B.6 – Business Response

<?xml version="1.0" encoding="UTF-8"?> <rsm:HeaderDocument xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:rsm="urn:un:unece:uncefact:data:draft:generalheader:0:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:un:unece:uncefact:data:draft:generalheader:0:1 GenericHeaderMessage_V1.04.xsd"> <SenderParty> <IdentificationId>XXXXXXXXXX</IdentificationId> </SenderParty> <RecipientParty> <IdentificationId>XXXXXXXXXX</IdentificationId> </RecipientParty> <Document> <IdentificationId>XXXXXXXXXX</IdentificationId> <SequenceNo>2</SequenceNo> <TypeCode>961</TypeCode> <SubTypeCode> </SubTypeCode> <FunctionCode>29</FunctionCode> <SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime> </Document> <Payload> <![CDATA[


<?xml version="1.0" encoding="UTF-8"?> <Response xmlns="urn:wco:datamodel:WCO:Response:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:wco:datamodel:WCO:Response:1 Response_1p0.xsd"> <Function>29</Function> <ID>XXXXXXXXXX</ID> <IssueDateTime formatCode="102">2016-05-12</IssueDateTime> <TypeCode>961</TypeCode> <Error> <Description>XXXXXXXXXX</Description> <ValidationCode>XXXXXXXXXX</ValidationCode> </Error> <Declaration> <FunctionCode>9</FunctionCode> <ID>XXXXXXXXXX</ID> <IssueDateTime formatCode="102">2016-05-12</IssueDateTime> <TypeCode>960</TypeCode> </Declaration> </Response> ]]> </Payload> </rsm:HeaderDocument>

Appendix B.7 – Query (QRY)







<SenderParty>


</SenderParty>

<RecipientParty>


</RecipientParty>

<Document>



<TypeCode>QRY</TypeCode>

<SubTypeCode> </SubTypeCode>



</Document>

<ReferenceDocument>


<TypeCode>XXX</TypeCode>

<SubTypeCode>XXX</SubTypeCode>

<IssueDateTime>2002-07-01T05:10:10</IssueDateTime>


</ReferenceDocument>

<Payload>I would like to query the authenticity of the referenced e-ATIGA Form D</Payload>


Appendix B.8 – Query Response (QRR)







<SenderParty>


</SenderParty>

<RecipientParty>


</RecipientParty>

<Document>



<TypeCode>QRR</TypeCode>

<SubTypeCode>QRR</SubTypeCode>



</Document>

<ReferenceDocument>


<TypeCode>QRY</TypeCode>

<SubTypeCode>QRY</SubTypeCode>



<Payload>I can confirm that the queried e-ATIGA Form D is authentic</Payload>


Appendix B.9 – Cancellation Request (CRQ)







<SenderParty>


</SenderParty>

<RecipientParty>



</RecipientParty>

<Document>



<TypeCode>CRQ</TypeCode>

<SubTypeCode>CRQ</SubTypeCode>



</Document>

<ReferenceDocument>


<TypeCode>XXX</TypeCode>

<SubTypeCode>XXX</SubTypeCode>



<Payload>Please cancel the referenced ACDD</Payload>


Appendix B.10 – Cancellation Response (CAR)







<SenderParty>


</SenderParty>

<RecipientParty>


</RecipientParty>

<Document>



<TypeCode>CAR</TypeCode>

<SubTypeCode>CAR</SubTypeCode>



</Document>

<ReferenceDocument>


<TypeCode>CRQ</TypeCode>

<SubTypeCode>CRQ</SubTypeCode>



<Payload>I can confirm the cancelation of the ACDD as requested</Payload>



Appendix C Information Flow Matrices

Appendix C.1 – Electronic ATIGA (e-ATIGA) Form D

Document Details Reference Document Details

TypeCode SubTypeCode IdentificationId FunctionCode SequenceNo IdentificationId TypeCode SubTypeCode

Querying an e-ATIGA Form D

QRY QRY QRY0000001 9 1 8640000001 864 NOR

Responding to a Query of an e-ATIGA Form D

QRR QRR QRR0000001 9 2 QRY0000001 QRY QRY

Querying a Response to an e-ATIGA Form D Query

QRR QRR QRR0000002 9 2 + n QRR0000001 QRR QRR

Cancelling an e-ATIGA Form D

CRQ CRQ CRQ0000001 9 1 8640000001 864 NOR

Responding to a Cancellation Request of an e-ATIGA Form D

CAR CAR CAR0000001 9 2 CRQ0000001 CRQ CRQ

Please note that the information flow matrix above shows how the generic query and cancellation messages can be used in

conjunction with the current e-ATIGA Form D process. However, because the current e-ATIGA Form D process does not use the

Common Header, the sending of original and replacement e-ATIGA Form Ds, and their corresponding responses, is not within the

scope of this report.

The Information Flow Matrices that follow show how the data elements in the Common Header should be used for the known business

document types, including the ACDD (960 and 961), the e-Phyto Certificate for Export (851 and 312), the e-Phyto Certificate for Re-

Export (849 and 312), the e-AH Certificate (648 and 312) and the e-FS Certificate (849 and 312).


Appendix C.2 – ASEAN Customs Declaration Document (ACDD)



Sending an Original ACDD

960 <Three Spaces>

9600000001 9 1 NOT REQUIRED

Sending a Response to an Original ACDD – Accepted

961 <Three Spaces>

9610000001 29 2 9600000001 960 <Three Spaces>

Sending a Response to an Original ACDD – Not Accepted

961 <Three Spaces>

9610000001 27 2 9600000001 960 <Three Spaces>

Querying an ACDD

QRY QRY QRY0000001 9 1 9600000001 960 <Three Spaces>

Responding to a Query of an ACDD


Querying a Response to an ACDD Query


Cancelling an ACDD

CRQ CRQ CRQ0000001 9 1 9600000001 960 <Three Spaces>

Responding to a Cancellation Request of an ACDD


Replacing an ACDD

960 <Three Spaces>

9600000002 5 1 9600000001 960 <Three Spaces>

Sending a Response to a Replacement of an ACDD – Accepted


961 <Three Spaces>

9610000002 29 2 9600000002 960 <Three Spaces>

Sending a Response to a Replacement of an ACDD – Not Accepted

961 <Three Spaces>

9610000002 27 2 9600000002 960 <Three Spaces>


Appendix C.3 – Electronic Phytosanitary (e-Phyto) Certificate for Export



Sending an Original e-Phyto Certificate for Export

851 <Three Spaces>


Sending a Response to an Original e-Phyto Certificate for Export – Accepted

312 <Three Spaces>

3120000001 29 2 8510000001 851 <Three Spaces>

Sending a Response to an Original e-Phyto Certificate for Export – Not Accepted

312 <Three Spaces>

3120000001 27 2 8510000001 851 <Three Spaces>

Querying an e-Phyto Certificate for Export


Responding to a Query of an e-Phyto Certificate for Export


Querying a Response to an e-Phyto Certificate for Export


Cancelling an e-Phyto Certificate for Export


Responding to a Cancellation Request of an e-Phyto Certificate for Export


Replacing an e-Phyto Certificate for Export

851 <Three Spaces>

8520000002 5 1 8510000001 851 <Three Spaces>

Sending a Response to a Replacement of an e-Phyto Certificate for Export – Accepted


312 <Three Spaces>

3120000002 29 2 8510000002 851 <Three Spaces>

Sending a Response to a Replacement of an e-Phyto Certificate for Export – Not Accepted

312 <Three Spaces>

3120000002 27 2 8510000002 851 <Three Spaces>


Appendix C.4 – Electronic Phytosanitary (e-Phyto) Certificate for Re-Export



Sending an Original e-Phyto Certificate for Re-Export

849 <Three Spaces>


Sending a Response to an Original e-Phyto Certificate for Re-Export – Accepted

312 <Three Spaces>

3120000001 29 2 8490000001 849 <Three Spaces>

Sending a Response to an Original e-Phyto Certificate for Re-Export – Not Accepted

312 <Three Spaces>

3120000001 27 2 8490000001 849 <Three Spaces>

Querying an e-Phyto Certificate for Re-Export


Responding to a Query of an e-Phyto Certificate for Re-Export


Querying a Response to an e-Phyto Certificate for Re-Export


Cancelling an e-Phyto Certificate for Re-Export


Responding to a Cancellation Request of an e-Phyto Certificate for Re-Export


Replacing an e-Phyto Certificate for Re-Export

849 <Three Spaces>

8490000002 5 1 8490000001 849 <Three Spaces>

Sending a Response to a Replacement of an e-Phyto Certificate for Re-Export – Accepted


312 <Three Spaces>

3120000002 29 2 8490000002 849 <Three Spaces>

Sending a Response to a Replacement of an e-Phyto Certificate for Re-Export – Not Accepted

312 <Three Spaces>

3120000002 27 2 8490000002 849 <Three Spaces>

Appendix C.5 – Electronic Animal Health (e-AH) Certificate



Sending an Original e-AH Certificate

648 <Three Spaces>


Sending a Response to an Original e-AH Certificate – Accepted

312 <Three Spaces>

3120000001 29 2 6480000001 648 <Three Spaces>

Sending a Response to an Original e-AH Certificate – Not Accepted

312 <Three Spaces>

3120000001 27 2 6480000001 648 <Three Spaces>

Querying an e-AH Certificate


Responding to a Query of e-AH Certificate


Querying a Response to an e-AH Certificate


Cancelling an e-AH Certificate



Responding to a Cancellation Request of an e-AH Certificate


Replacing an e-AH Certificate

648 <Three Spaces>

8490000002 5 1 6480000001 648 <Three Spaces>

Sending a Response to a Replacement of an e-AH Certificate – Accepted

312 <Three Spaces>

3120000002 29 2 6480000002 648 <Three Spaces>

Sending a Response to a Replacement of an e-AH Certificate – Not Accepted

312 <Three Spaces>

3120000002 27 2 6480000002 648 <Three Spaces>

Appendix C.6 – Electronic Food Safety (e-FS) Certificate



Sending an Original e-FS Certificate

852 <Three Spaces>


Sending a Response to an Original e-FS Certificate – Accepted

312 <Three Spaces>

3120000001 29 2 8520000001 852 <Three Spaces>

Sending a Response to an Original e-FS Certificate – Not Accepted

312 <Three Spaces>

3120000001 27 2 8520000001 852 <Three Spaces>

Querying an e-FS Certificate


Responding to a Query of an e-FS Certificate



Querying a Response to an e-FS Certificate


Cancelling an e-FS Certificate


Responding to a Cancellation Request of an e-FS Certificate


Replacing an e-FS Certificate

852 <Three Spaces>

8520000002 5 1 8520000001 852 <Three Spaces>

Sending a Response to a Replacement of an e-FS Certificate – Accepted

312 <Three Spaces>

3120000002 29 2 8520000002 852 <Three Spaces>

Sending a Response to a Replacement of an e-FS Certificate – Not Accepted

312 <Three Spaces>

3120000002 27 2 8520000002 852 <Three Spaces>

Documents

GENERIC Message Implementation Guide and Process