generic message implementation guide and process
TRANSCRIPT
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.
Message Implementation Guide and Process Specifications
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
Message Implementation Guide and Process Specifications
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
Message Implementation Guide and Process Specifications
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).
Message Implementation Guide and Process Specifications
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;
Message Implementation Guide and Process Specifications
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:
Message Implementation Guide and Process Specifications
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
Message Implementation Guide and Process Specifications
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.
Message Implementation Guide and Process Specifications
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
Message Implementation Guide and Process Specifications
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
Message Implementation Guide and Process Specifications
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.
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 document being sent, including its unique reference number, its type and the date when it was sent.
Message Implementation Guide and Process Specifications
Step Description Implementation Notes
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.
The message must be the same as Step 2a.
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.
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 document being sent, including its unique reference number, its type 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.
The message must be the same as Step 4b.
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.
The message must be the same as Step 4b.
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,
Message Implementation Guide and Process Specifications
Step Description Implementation Notes
“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.
The message must be the same as Step 5b.
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.
The message must be the same as Step 5b.
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.
The message must be the same as Step 5b.
4.1.1.2 Sending a Response
As shown in Figure 1, and described in more detail in Table 3, the process for sending a
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
Step Description Implementation Notes
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.
Message Implementation Guide and Process Specifications
Step Description Implementation Notes
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.
The message must be the same as Step 7a.
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.
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 response being sent, including its unique reference number, its type and the date when it was sent.
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.
The message must be the same as Step 8b.
Message Implementation Guide and Process Specifications
Step Description Implementation Notes
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.
The message must be the same as Step 7a.
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.
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 response being sent, including its unique reference number, its type and the date when it was sent.
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.
The message must be the same as Step 9b.
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.
The message must be the same as Step 9b.
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.
Message Implementation Guide and Process Specifications
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.
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.
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
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 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.
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.
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 query to the NSW of the Receiving Country. Please note that this step is Mandatory.
The message must be the same as Step 2a.
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.
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
The message must be the same as Step 4b.
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
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.
The message must be the same as Step 4b.
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).
Message Implementation Guide and Process Specifications
Table 5: Step-by-Step Process for Responding to a Query
Step Description Guidance Notes
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.
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 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.
The message must be the same as Step 7a.
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 query response being sent, including its unique reference number, its type (i.e. “QRR”) and the date when it was sent.
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
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.
The message must be the same as Step 8b.
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.
The message must be the same as Step 7a.
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.
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 response being sent, including its unique reference number, its type (i.e. “QRR”) and the date when it was sent.
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.
The message must be the same as Step 9b.
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.
The message must be the same as Step 9b.
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.
Message Implementation Guide and Process Specifications
Figure 3 – Query Information Flow (Part 2)
As shown in Figure 3, and described in more detail in Table 6, the process for responding to
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
Step Description Guidance Notes
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.
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
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
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 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.
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.
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 9b.
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 message must be the same as Step 2a.
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.
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.
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.
The message must be the same as Step 4b.
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
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.
The message must be the same as Step 4b.
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.
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 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.
The message must be the same as Step 7a.
8b The ASW Gateway of the Sending Country returns an Acknowledgement Status to the ASW Gateway of the Receiving Country.
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.
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
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.
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.
The message must be the same as Step 8b.
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.
The message must be the same as Step 7a.
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.
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 response being sent, including its unique reference number, its type (i.e. “QRR”) and the date when it was sent.
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.
The message must be the same as Step 9b.
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.
The message must be the same as Step 9b.
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.
Message Implementation Guide and Process Specifications
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
Step Description Guidance Notes
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
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
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 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.
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.
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 cancellation request to the NSW of the Receiving Country. Please note that this step is Mandatory.
The message must be the same as Step 2a.
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.
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
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
being sent, including its unique reference number, its type (i.e. “CRQ”) 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.
The message must be the same as Step 4b.
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.
The message must be the same as Step 4b.
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
As shown in Figure 3, and described in more detail in Table 8, the process for responding to
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
Step Description Guidance Notes
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
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
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.
The message must be the same as Step 7a.
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.
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.
The message must be the same as Step 8b.
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.
The message must be the same as Step 7a.
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
Message Implementation Guide and Process Specifications
Step Description Guidance Notes
reference number, its type (i.e. “CAR”) and the date when it was sent.
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.
The message must be the same as Step 9b.
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.
The message must be the same as Step 9b.
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).
Message Implementation Guide and Process Specifications
Table 9: Step-by-Step Process for Replacing a Document
Step Description Implementation Notes
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 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.
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
Message Implementation Guide and Process Specifications
Step Description Implementation Notes
sent, including its unique reference number, its type and the date when it was sent.
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 replacement to the NSW of the Receiving Country. Please note that this step is Mandatory.
The message must be the same as Step 2a.
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.
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.
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.
The message must be the same as Step 4b.
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.
The message must be the same as Step 4b.
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.
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.
Message Implementation Guide and Process Specifications
Step Description Implementation Notes
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.
The message must be the same as Step 5b.
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.
The message must be the same as Step 5b.
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.
The message must be the same as Step 5b.
4.1.4.2 Sending a Response
As shown in Figure 10, and described in more detail in Table 3, the process for sending a
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
Step Description Implementation Notes
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
Message Implementation Guide and Process Specifications
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.
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.
The message must be the same as Step 7a.
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.
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 response being sent, including its unique reference number, its type and the date when it was sent.
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.
The message must be the same as Step 8b.
Message Implementation Guide and Process Specifications
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.
The message must be the same as Step 7a.
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.
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 response being sent, including its unique reference number, its type and the date when it was sent.
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.
The message must be the same as Step 9b.
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.
The message must be the same as Step 9b.
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.
Message Implementation Guide and Process Specifications
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.
Message Implementation Guide and Process Specifications
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.
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
<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.
Table 12: Acknowledgement Status (“AS2”)
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 Receiving Country.
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
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 "AS2".
<Name> Document Type Name 0..1 an..35 If used, this should be set to “AS2 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 "AS2".
<Remark> Remarks 0..1 an..512 If used, this should be set to “Message received by receiving 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.
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
<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.
Table 13: Acknowledgement Status (“AS3”)
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 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.
<TypeCode> Document Type Code 1..1 an..3 This must always be set to "AS3".
<Name> Document Type Name 0..1 an..35 If used, this should be set to “AS3 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 "AS3".
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
<Remark> Remarks 0..1 an..512 If used, this should be set to “Message received by NSW”.
<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.
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
<Name> Issuer Country Name 0..1 an..35 If used, this should be used to specify the country name, according to ISO 3166-2.
Table 14: Acknowledgement Status (“AS4”)
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 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.
<TypeCode> Document Type Code 1..1 an..3 This must always be set to "AS4".
<Name> Document Type Name 0..1 an..35 If used, this should be set to “AS4 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 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”.
<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.
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
<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.
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”)
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
<rsm:HeaderDocument> 1..1
<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.
<Document> 1..1 This group is used to identify the message being sent.
<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 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.
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
<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.
<IdentificationId> Unique Identification Number of a referenced document
1..1 an..35 This is used to specify the identification of the 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 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 " ".
<IssueDateTime> Issue Date and time of the referenced document
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”)
XML Tag Name Description Cardinality Format Guideline
<rsm:HeaderDocument> 1..1
<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
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
to uniquely identify the sending authority, as assigned by the NSW operator.
<Document> 1..1 This group is used to identify the message being sent.
<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 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.
<SequenceNo> Sequence Number of submission of the Document
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".
<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.
<IdentificationId> Unique Identification Number of a referenced document
1..1 an..35 This is used to specify the identification of the message to which this message refers.
<TypeCode> Document Type Code of the referenced document
1..1 an..3 This must be set to either; “QRY” = for a response to a query;
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
“QRR” = for a response to a query response
<SubTypeCode> Document Sub Type Code of the referenced document
1..1 an..5 This must always be set to " ".
<IssueDateTime> Issue Date and time of the referenced document
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 response to the query, in free text format.
Table 17: Cancellation Request (“CRQ”)
XML Tag Name Description Cardinality Format Guideline
<rsm:HeaderDocument> 1..1
<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.
<Document> 1..1 This group is used to identify the message being sent.
<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 NSW in the Sending Country.
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
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 "CRQ".
<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.
<IdentificationId> Unique Identification Number of a referenced document
1..1 an..35 This is used to specify the identification of the 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 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 " ".
<IssueDateTime> Issue Date and time of the referenced document
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 reason for the cancellation request, in free text format.
Table 18: Cancellation Response (“CAR”)
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
<rsm:HeaderDocument> 1..1
<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.
<Document> 1..1 This group is used to identify the message being sent.
<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 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.
<SequenceNo> Sequence Number of submission of the Document
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".
<SubTypeCode> Document Sub Type Code 1..1 an..5 This must always be set to " ".
Message Implementation Guide and Process Specifications
XML Tag Name Description Cardinality Format Guideline
<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.
<IdentificationId> Unique Identification Number of a referenced document
1..1 an..35 This is used to specify the identification of the message to which this message refers.
<TypeCode> Document Type Code of the referenced document
1..1 an..3 This must always be set to "CRQ".
<SubTypeCode> Document Sub Type Code of the referenced document
1..1 an..5 This must always be set to " ".
<IssueDateTime> Issue Date and time of the referenced document
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 a response to the cancellation request, in free text format.
Message Implementation Guide and Process Specifications
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
AS4 4th Acknowledgement Status Message – from Recipient to NSW
See Appendix
A.2 for
Valid Business Response
Type Codes
27 or 29 Business Document Response Response 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
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
Message Implementation Guide and Process Specifications
Primary Document
Type
Response Document
Types
Function Code
Description Name of Reference Field
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
Description Name of Reference Field
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.
Message Implementation Guide and Process Specifications
Primary Document
Type
Response Document
Types
Function Code
Description Name of Reference Field
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
Description Name of Reference Field
See Appendix
A.1 for
Valid Business Document
Types
5 Replacement Replacement 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
AS4 4th Acknowledgement Status Message – from Recipient to NSW
Message Implementation Guide and Process Specifications
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.
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
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]
6. The NSW of the Sending Country receives the “AS2” message and records it as a “received” transaction for reconciliation with the MIS Reports. [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.
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
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.
6. The ASW Gateway of the Sending Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.
7. The ASW Gateway of the Sending Country returns the “AS3” message to the NSW of the Sending Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]
8. The NSW of the Sending Country receives the “AS3” message and records it as a “received” transaction for reconciliation with the MIS Reports. [OPTIONAL]
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]
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
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.
4. The ASW Gateway of the Receiving Country receives the “AS2” message and records it as a “received” 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]
6. The NSW of the Receiving Country receives the “AS2” message and records it as a “received” transaction for reconciliation with the MIS Reports. [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.
4. The ASW Gateway of the Sending Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
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.
6. The ASW Gateway of the Receiving Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.
7. The ASW Gateway of the Receiving Country returns the “AS3” message to the NSW of the Receiving Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]
8. The NSW of the Receiving Country receives the “AS3” message and records it as a “received” transaction for reconciliation with the MIS Reports. [OPTIONAL]
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.
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 “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]
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.
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
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]
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 “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]
6. The NSW of the Sending Country receives the “AS2” message and records it as a “received” transaction for reconciliation with the MIS Reports. [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.
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.
6. The ASW Gateway of the Sending Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
7. The ASW Gateway of the Sending Country returns the “AS3” message to the NSW of the Sending Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]
8. The NSW of the Sending Country receives the “AS3” message and records it as a “received” transaction for reconciliation with the MIS Reports. [OPTIONAL]
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.
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]
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]
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.
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
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
NSW of the Receiving Country. [OPTIONAL]
Country and records it as a “sent” transaction for MIS Reporting.
4. The ASW Gateway of the Receiving Country receives the “AS2” message and records it as a “received” 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]
6. The NSW of the Receiving Country receives the “AS2” message and records it as a “received” transaction for reconciliation with the MIS Reports. [OPTIONAL]
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.
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.
4. The ASW Gateway of the Sending Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.
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.
6. The ASW Gateway of the Receiving Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.
7. The ASW Gateway of the Receiving Country returns the “AS3” message to the NSW of the Receiving Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]
8. The NSW of the Receiving Country receives the “AS3” message and records it as a “received” transaction
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
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.
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]
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.
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
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
records it as a “sent” transaction for MIS Reporting. [OPTIONAL]
6. The NSW of the Sending Country receives the “AS2” message and records it as a “received” transaction for reconciliation with the MIS Reports. [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.
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.
6. The ASW Gateway of the Sending Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.
7. The ASW Gateway of the Sending Country returns the “AS3” message to the NSW of the Sending Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]
8. The NSW of the Sending Country receives the “AS3” message and records it as a “received” transaction for reconciliation with the MIS Reports. [OPTIONAL]
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.
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
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.
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]
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]
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.
4. The ASW Gateway of the Receiving Country receives the “AS2” message and records it as a “received” transaction for MIS Reporting.
5. The ASW Gateway of the Receiving Country returns an “AS2” message to the NSW of the Receiving Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]
6. The NSW of the Receiving Country receives the “AS2” message and records it as a “received” transaction
Message Implementation Guide and Process Specifications
Test No.
Test Description Expected Outcomes
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.
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.
4. The ASW Gateway of the Sending Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.
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.
6. The ASW Gateway of the Receiving Country receives the “AS3” message and records it as a “received” transaction for MIS Reporting.
7. The ASW Gateway of the Receiving Country returns the “AS3” message to the NSW of the Receiving Country and records it as a “sent” transaction for MIS Reporting. [OPTIONAL]
8. The NSW of the Receiving Country receives the “AS3” message and records it as a “received” transaction for reconciliation with the MIS Reports. [OPTIONAL]
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
Message Implementation Guide and Process Specifications
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.
Test Description Expected Outcomes
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:
a. SequenceNo = “3” b. TypeCode = “QRR” c. SubTypeCode = “QRR” d. FunctionCode = “9”
2. A query response (“QRR”) message is received by the Sender with:
a. SequenceNo = “4” b. TypeCode = “QRR” c. SubTypeCode = “QRR” d. FunctionCode = “9”
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.
Message Implementation Guide and Process Specifications
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
Message Implementation Guide and Process Specifications
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
Message Implementation Guide and Process Specifications
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
Message Implementation Guide and Process Specifications
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>
<IdentificationId>XXXXXXXXXX</IdentificationId>
</RecipientParty>
<Document>
<IdentificationId>XXXXXXXXXX</IdentificationId>
<SequenceNo>1</SequenceNo>
<TypeCode>960</TypeCode>
<SubTypeCode>960</SubTypeCode>
<FunctionCode>9</FunctionCode>
<SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime>
</Document>
<Payload>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<Declaration xmlns="urn:wco:datamodel:WCO:Declaration:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:wco:datamodel:WCO:Declaration:1 Declaration_1p0.xsd">
<FunctionCode>5</FunctionCode>
<ID>XXXXXXXXXX</ID>
<IssueDateTime formatCode="102">2016-05-12</IssueDateTime>
<TypeCode>960</TypeCode>
<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>
<TypeCode>917</TypeCode>
</AdditionalDocument>
Message Implementation Guide and Process Specifications
<Control>
<AdditionalInformation>
<Content>XXXXXXXXXX</Content>
</AdditionalInformation>
</Control>
<CurrencyExchange>
<CurrencyTypeCode>USD</CurrencyTypeCode>
<RateNumeric>999999.99999</RateNumeric>
</CurrencyExchange>
<Declarant>
<Name>XXXXXXXXXX</Name>
<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>
<Name>XXXXXXXXXX</Name>
<ID>XXXXXXXXXX</ID>
</Warehouse>
</ExitOffice>
<Exporter>
<Name>XXXXXXXXXX</Name>
<ID>XXXXXXXXXX</ID>
<Address>
<CityName>XXXXXXXXXX</CityName>
<CountryCode>MY</CountryCode>
<Line>XXXXXXXXXX</Line>
<PostcodeID>XXXXXXXXXX</PostcodeID>
</Address>
</Exporter>
<GoodsShipment>
<ExitDateTime formatCode="102">2016-05-12</ExitDateTime>
<TransactionNatureCode>9</TransactionNatureCode>
<AdditionalInformation>
<Content>XXXXXXXXXX</Content>
Message Implementation Guide and Process Specifications
</AdditionalInformation>
<Consignment>
<ContainerCode>68</ContainerCode>
<AdditionalDocument>
<ID>XXXXXXXXXX</ID>
<TypeCode>785</TypeCode>
</AdditionalDocument>
<BorderTransportMeans>
<Name>XXXXXXXXXX</Name>
<ID>XXXXXXXXXX</ID>
<TypeCode>1</TypeCode>
<RegistrationNationalityCode>MY</RegistrationNationalityCode>
<JourneyID>XXXXXXXXXX</JourneyID>
</BorderTransportMeans>
<DepartureTransportMeans>
<Name>XXXXXXXXXX</Name>
<ID>XXXXXXXXXX</ID>
<RegistrationNationalityCode>SG</RegistrationNationalityCode>
<JourneyID>XXXXXXXXXX</JourneyID>
</DepartureTransportMeans>
<GoodsLocation>
<Name>XXXXXXXXXX</Name>
<ID>XXXXXXXXXX</ID>
</GoodsLocation>
<LoadingLocation>
<Name>KUALA LUMPUR</Name>
<ID>MYKUL</ID>
</LoadingLocation>
<TransportContractDocument>
<ID>XXXXXXXXXX</ID>
<TypeCode>704</TypeCode>
</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>
<AdditionalDocument>
Message Implementation Guide and Process Specifications
<ID>XXXXXXXXXX</ID>
<TypeCode>811</TypeCode>
</AdditionalDocument>
<AdditionalInformation>
<Content>XXXXXXXXXX</Content>
</AdditionalInformation>
<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>
<TypeCode>424</TypeCode>
</PreviousDocument>
</GovernmentAgencyGoodsItem>
Message Implementation Guide and Process Specifications
<Origin>
<CountryCode>ID</CountryCode>
</Origin>
<TradeTerms>
<ConditionCode>CIF</ConditionCode>
<Description>XXXXXXXXXX</Description>
</TradeTerms>
<UCR>
<ID>XXXXXXXXXX</ID>
</UCR>
</GoodsShipment>
<Importer>
<Name>XXXXXXXXXX</Name>
<ID>XXXXXXXXXX</ID>
<Address>
<CityName>XXXXXXXXXX</CityName>
<CountryCode>TH</CountryCode>
<Line>XXXXXXXXXX</Line>
<PostcodeID>XXXXXXXXX</PostcodeID>
</Address>
</Importer>
<Principal>
<Name>XXXXXXXXXX</Name>
<ID>XXXXXXXXXX</ID>
</Principal>
<SupervisingOffice>
<ID>XXXXXXXXXX</ID>
</SupervisingOffice>
<TransitOffice>
<ID>XXXXXXXXXXXXXXXXX</ID>
</TransitOffice>
<TransitOperationStartOffice>
<ID>XXXXXXXXXXXXXXXXX</ID>
</TransitOperationStartOffice>
<TransitOperationTerminationOffice>
<ID>XXXXXXXXXXXXXXXXX</ID>
</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"
Message Implementation Guide and Process Specifications
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>
Appendix B.3 – Acknowledgement Status (AS2)
<?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>
Message Implementation Guide and Process Specifications
</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.4 – Acknowledgement Status (AS3)
<?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>
Appendix B.5 – Acknowledgement Status (AS4)
<?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"
Message Implementation Guide and Process Specifications
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[
Message Implementation Guide and Process Specifications
<?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)
<?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>
<IdentificationId>XXXXXXXXXX</IdentificationId>
</RecipientParty>
<Document>
<IdentificationId>XXXXXXXXXX</IdentificationId>
<SequenceNo>1</SequenceNo>
<TypeCode>QRY</TypeCode>
<SubTypeCode> </SubTypeCode>
<FunctionCode>9</FunctionCode>
<SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime>
</Document>
<ReferenceDocument>
<IdentificationId>XXXXXXXXXX</IdentificationId>
<TypeCode>XXX</TypeCode>
<SubTypeCode>XXX</SubTypeCode>
<IssueDateTime>2002-07-01T05:10:10</IssueDateTime>
Message Implementation Guide and Process Specifications
</ReferenceDocument>
<Payload>I would like to query the authenticity of the referenced e-ATIGA Form D</Payload>
</rsm:HeaderDocument>
Appendix B.8 – Query Response (QRR)
<?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>
<IdentificationId>XXXXXXXXXX</IdentificationId>
</RecipientParty>
<Document>
<IdentificationId>XXXXXXXXXX</IdentificationId>
<SequenceNo>2</SequenceNo>
<TypeCode>QRR</TypeCode>
<SubTypeCode>QRR</SubTypeCode>
<FunctionCode>9</FunctionCode>
<SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime>
</Document>
<ReferenceDocument>
<IdentificationId>XXXXXXXXXX</IdentificationId>
<TypeCode>QRY</TypeCode>
<SubTypeCode>QRY</SubTypeCode>
<IssueDateTime>2002-07-01T05:10:10</IssueDateTime>
</ReferenceDocument>
<Payload>I can confirm that the queried e-ATIGA Form D is authentic</Payload>
</rsm:HeaderDocument>
Appendix B.9 – Cancellation Request (CRQ)
<?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>
<IdentificationId>XXXXXXXXXX</IdentificationId>
Message Implementation Guide and Process Specifications
</RecipientParty>
<Document>
<IdentificationId>XXXXXXXXXX</IdentificationId>
<SequenceNo>1</SequenceNo>
<TypeCode>CRQ</TypeCode>
<SubTypeCode>CRQ</SubTypeCode>
<FunctionCode>9</FunctionCode>
<SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime>
</Document>
<ReferenceDocument>
<IdentificationId>XXXXXXXXXX</IdentificationId>
<TypeCode>XXX</TypeCode>
<SubTypeCode>XXX</SubTypeCode>
<IssueDateTime>2002-07-01T05:10:10</IssueDateTime>
</ReferenceDocument>
<Payload>Please cancel the referenced ACDD</Payload>
</rsm:HeaderDocument>
Appendix B.10 – Cancellation Response (CAR)
<?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>
<IdentificationId>XXXXXXXXXX</IdentificationId>
</RecipientParty>
<Document>
<IdentificationId>XXXXXXXXXX</IdentificationId>
<SequenceNo>2</SequenceNo>
<TypeCode>CAR</TypeCode>
<SubTypeCode>CAR</SubTypeCode>
<FunctionCode>9</FunctionCode>
<SubmissionDateTime>2002-07-01T05:10:10</SubmissionDateTime>
</Document>
<ReferenceDocument>
<IdentificationId>XXXXXXXXXX</IdentificationId>
<TypeCode>CRQ</TypeCode>
<SubTypeCode>CRQ</SubTypeCode>
<IssueDateTime>2002-07-01T05:10:10</IssueDateTime>
</ReferenceDocument>
<Payload>I can confirm the cancelation of the ACDD as requested</Payload>
</rsm:HeaderDocument>
Message Implementation Guide and Process Specifications
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).
Message Implementation Guide and Process Specifications
Appendix C.2 – ASEAN Customs Declaration Document (ACDD)
Document Details Reference Document Details
TypeCode SubTypeCode IdentificationId FunctionCode SequenceNo IdentificationId TypeCode SubTypeCode
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
QRR QRR QRR0000001 9 2 QRY0000001 QRY QRY
Querying a Response to an ACDD Query
QRR QRR QRR0000002 9 2 + n QRR0000001 QRR QRR
Cancelling an ACDD
CRQ CRQ CRQ0000001 9 1 9600000001 960 <Three Spaces>
Responding to a Cancellation Request of an ACDD
CAR CAR CAR0000001 9 2 CRQ0000001 CRQ CRQ
Replacing an ACDD
960 <Three Spaces>
9600000002 5 1 9600000001 960 <Three Spaces>
Sending a Response to a Replacement of an ACDD – Accepted
Message Implementation Guide and Process Specifications
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>
Message Implementation Guide and Process Specifications
Appendix C.3 – Electronic Phytosanitary (e-Phyto) Certificate for Export
Document Details Reference Document Details
TypeCode SubTypeCode IdentificationId FunctionCode SequenceNo IdentificationId TypeCode SubTypeCode
Sending an Original e-Phyto Certificate for Export
851 <Three Spaces>
8520000001 9 1 NOT REQUIRED
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
QRY QRY QRY0000001 9 1 8510000001 851 <Three Spaces>
Responding to a Query of an e-Phyto Certificate for Export
QRR QRR QRR0000001 9 2 QRY0000001 QRY QRY
Querying a Response to an e-Phyto Certificate for Export
QRR QRR QRR0000002 9 2 + n QRR0000001 QRR QRR
Cancelling an e-Phyto Certificate for Export
CRQ CRQ CRQ0000001 9 1 8510000001 851 <Three Spaces>
Responding to a Cancellation Request of an e-Phyto Certificate for Export
CAR CAR CAR0000001 9 2 CRQ0000001 CRQ CRQ
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
Message Implementation Guide and Process Specifications
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>
Message Implementation Guide and Process Specifications
Appendix C.4 – Electronic Phytosanitary (e-Phyto) Certificate for Re-Export
Document Details Reference Document Details
TypeCode SubTypeCode IdentificationId FunctionCode SequenceNo IdentificationId TypeCode SubTypeCode
Sending an Original e-Phyto Certificate for Re-Export
849 <Three Spaces>
8490000001 9 1 NOT REQUIRED
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
QRY QRY QRY0000001 9 1 8490000001 849 <Three Spaces>
Responding to a Query of an e-Phyto Certificate for Re-Export
QRR QRR QRR0000001 9 2 QRY0000001 QRY QRY
Querying a Response to an e-Phyto Certificate for Re-Export
QRR QRR QRR0000002 9 2 + n QRR0000001 QRR QRR
Cancelling an e-Phyto Certificate for Re-Export
CRQ CRQ CRQ0000001 9 1 8490000001 849 <Three Spaces>
Responding to a Cancellation Request of an e-Phyto Certificate for Re-Export
CAR CAR CAR0000001 9 2 CRQ0000001 CRQ CRQ
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
Message Implementation Guide and Process Specifications
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
Document Details Reference Document Details
TypeCode SubTypeCode IdentificationId FunctionCode SequenceNo IdentificationId TypeCode SubTypeCode
Sending an Original e-AH Certificate
648 <Three Spaces>
6480000001 9 1 NOT REQUIRED
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
QRY QRY QRY0000001 9 1 6480000001 648 <Three Spaces>
Responding to a Query of e-AH Certificate
QRR QRR QRR0000001 9 2 QRY0000001 QRY QRY
Querying a Response to an e-AH Certificate
QRR QRR QRR0000002 9 2 + n QRR0000001 QRR QRR
Cancelling an e-AH Certificate
CRQ CRQ CRQ0000001 9 1 6480000001 648 <Three Spaces>
Message Implementation Guide and Process Specifications
Responding to a Cancellation Request of an e-AH Certificate
CAR CAR CAR0000001 9 2 CRQ0000001 CRQ CRQ
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
Document Details Reference Document Details
TypeCode SubTypeCode IdentificationId FunctionCode SequenceNo IdentificationId TypeCode SubTypeCode
Sending an Original e-FS Certificate
852 <Three Spaces>
8520000001 9 1 NOT REQUIRED
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
QRY QRY QRY0000001 9 1 8520000001 852 <Three Spaces>
Responding to a Query of an e-FS Certificate
Message Implementation Guide and Process Specifications
QRR QRR QRR0000001 9 2 QRY0000001 QRY QRY
Querying a Response to an e-FS Certificate
QRR QRR QRR0000002 9 2 + n QRR0000001 QRR QRR
Cancelling an e-FS Certificate
CRQ CRQ CRQ0000001 9 1 8520000001 852 <Three Spaces>
Responding to a Cancellation Request of an e-FS Certificate
CAR CAR CAR0000001 9 2 CRQ0000001 CRQ CRQ
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>