Eectronic Commerce Client Requirements Document (ECCRD) Chapter 11

Advance Commercial Information (ACI)/eManifest Notices

Draft Version 6

2

3

Revision History

Date Changes Made

Version Changes Made Changes

Made By

September 2012 Draft 1.0 Draft version for Sept 2012 eSPN distribution EDI Reporting

October 2012 Draft 1.1 Draft version for distribution EDI Reporting

October, 2012 Draft 2.0 Draft for Distribution EDI Reporting

December 2012 Draft 3.0 Draft for Distribution EDI Reporting

January 2013 Draft 4.0 Draft for distribution EDI Reporting

December 2014 Draft 4.5 Draft for internal review EDI Reporting

January 2015 Draft 5 Draft for external distribution, see Summary of Changes EDI Reporting

December 2015 Draft 6 Draft for external distribution, see Summary of Changes EDI Reporting

4

TABLE of CONTENTS

PART I – INTRODUCTION ................................................................................................................. 6

PURPOSE.................................................................................................................................................. 6

SCOPE ...................................................................................................................................................... 7

INTENDED AUDIENCE ............................................................................................................................. 7

RELATED ECCRD CHAPTERS ................................................................................................................ 7

NOTICE DELIVERY CHANNELS ............................................................................................................... 8

FUTURE VERSIONS .................................................................................................................................. 8

PART II – EDI PROFILES ..................................................................................................................... 9

EDI PROFILES ......................................................................................................................................... 9

PART III – CONTEXT AND CONCEPTS........................................................................................ 10

EMANIFEST DEPLOYMENTS .................................................................................................................. 10

PRIMARY, SECONDARY, AND AUTOMATED NOTIFY PARTIES ............................................................. 11

SNP GROUP .......................................................................................................................................... 11

Deployment 4 Status Notice EDI Mapping Note for PNP/ANP/SNP ................................. 13

NOTICE DESCRIPTIONS ......................................................................................................................... 13

Validation Notices.......................................................................................................................... 14

Section 12.(1) Reported Notice ..................................................................................................... 15

Manifest Forward ........................................................................................................................... 16

Status Notices ................................................................................................................................. 16

A. Document Not on File .......................................................................................................... 17

B. Completeness Notices ........................................................................................................... 17

C. Disposition Notices ............................................................................................................... 19

PART IV – NOTICE BUSINESS REQUIREMENTS...................................................................... 23

SYSTEM RULES ...................................................................................................................................... 23

RECIPIENT BUSINESS RULES ................................................................................................................. 23

VALIDATION NOTIFICATION BUSINESS RULES .................................................................................... 23

MANIFEST FORWARD BUSINESS RULES ................................................................................................ 24

DOCUMENT NOT ON FILE BUSINESS RULES (DEPLOYMENT 4) ........................................................... 25

COMPLETENESS NOTIFICATION BUSINESS RULES ................................................................................ 25

SECTION 12.(1) REPORTED NOTICE BUSINESS RULES .......................................................................... 27

DISPOSITION BUSINESS RULES (DEPLOYMENT 4) ................................................................................ 28

PART V –RESPONSE NOTIFICATION PROCESSES AND SAMPLE SCENARIOS ........... 30

VALIDATION PROCESSES ...................................................................................................................... 30

Functional Validation Process ...................................................................................................... 30

Application Validation Process .................................................................................................... 31

VALIDATION ERRORS ........................................................................................................................... 32

Functional Errors ............................................................................................................................ 32

Application Errors ......................................................................................................................... 32

5

INSUFFICIENT REVIEW TIME NOTIFICATION SCENARIO ...................................................................... 33

MANIFEST FORWARD NOTIFICATION SCENARIOS ............................................................................... 33

DOCUMENT NOT ON FILE SCENARIOS ................................................................................................. 34

COMPLETENESS NOTIFICATION SCENARIOS ........................................................................................ 35

SECTION 12.(1) REPORTED NOTIFICATION SCENARIOS ....................................................................... 39

DISPOSITION NOTIFICATION SCENARIOS (DEPLOYMENT 4) ............................................................... 40

PART VI – FIGURES, CHARTS, AND APPENDICES ................................................................. 49

FIGURE 1 – COMPLETENESS NOTICE RELATIONSHIPS ....................................................................... 50

CHART 1 – EMANIFEST DEPLOYMENT 4 PRIMARY NOTIFY PARTY NOTICES BY DOCUMENT TYPE. 51

CHART 2 – EMANIFEST DEPLOYMENT 4 PRIMARY AND AUTOMATED NOTIFY PARTY NOTICES BY

CLIENT TYPE ......................................................................................................................................... 52

LIST OF APPENDICES ............................................................................................................................. 53

Appendix A – Glossary of Terms for Notices ............................................................................ 53

Appendix B – Status Notice Data Elements (Deployment 4 only) ............................................ 53

Appendix D – Code Tables for Notices ...................................................................................... 53

Appendix E –Legend, Use of Special Characters, and Possible Data Loss or Truncation .. 53

Appendix F – EDIFACT 96A, 99B, 08A, 11B Response Message ............................................ 53

Appendix G – EDIFACT GOVCBR 11B S12.(1) Response ....................................................... 53

Appendix J – ANSI ASC X12 997, 824, 350 S12.(1) Reported Notice 5040 ............................. 53

Appendix M – EDIFACT GOVCBR 11B House Bill Manifest Forward ................................. 53

Appendix N – ANSI ASC X12 309 5040 House Bill Manifest Forward ................................. 53

Appendix O – EDIFACT GOVCBR 13A Status Notice (Deployment 4 only) .......................... 53

Appendix P – ANSI ASC X12 350 7010 Status Notice (Deployment 4 only) ............................ 53

Appendix S - Status Notice Message Implementation Guide Samples (Deployment 4 only) 53

PART VII – CONTACTS ..................................................................................................................... 54

6

Part I – Introduction The Advance Commercial Information (ACI) Program introduced more effective risk management processes and tools to identify health, safety, and security threats prior to the arrival of specified goods and Conveyances in Canada. Phase 1 of the ACI Program was implemented in April 2004, requiring Marine Carriers where applicable, to electronically transmit Marine Cargo and Supplementary Cargo Data to the CBSA 24 hours prior to loading Cargo at a foreign port. Freight Forwarders were also permitted to send supplementary data. Implementation of Phase 2 of the ACI Program commenced in July 2006, and requires all Air Carriers where applicable, to electronically transmit Conveyance, Cargo, and Supplementary Cargo data to the CBSA four hours prior to arrival in Canada. ACI Phase 2 also expanded marine requirements to include shipments loaded in the United States. Phase 3 of the ACI Program, also known as eManifest, requires the electronic transmission of advance Cargo and Conveyance information from Carriers for all highway and rail shipments. In addition, the electronic transmission of advance secondary data will be required from Freight Forwarders, and the electronic transmission of Advance Trade Data (ATD) will be required from Importers or Brokers acting on their behalf. To complete the implementation of the eManifest project which includes the introduction of new notices, the CBSA has introduced various Deployments. As of Deployment 4, a limited set of new notices will be made available to registered clients. As of Deployment 5, the full set of new notices will be implemented and available to all registered clients.

Purpose The purpose of this Electronic Commerce Client Requirements Document (ECCRD) chapter is to provide technical user information that will enable clients to prepare their systems to receive various CBSA eManifest Notices sent in response to data that is transmitted via Electronic Data Interchange (EDI) as of Deployment 4. In addition, this document describes the functionality that will enable clients to share information with other trade chain partners who are also registered clients of the CBSA. The new notices are designed to improve the lines of communication between all parties and simplify the pre-arrival and reporting process.

7

Scope This document details the system and business requirements needed to successfully receive eManifest notices via EDI that are generated by the electronic transmission of data, and outlines various processes that generate these notices. The notices that will be described in Part III of this document are the Validation Notices (including the Insufficient Review Time Notice), the Section 12.(1) Reported Notice, and Status Notices which for Deployment 4 include Completeness Notices and a limited set of Disposition Notices. In addition, the Manifest Forward functionality will be discussed along with the Secondary Notify Party Group put in place to support these features, and the sending of notices to Automated Notify Parties. Although the Release Notification System (RNS) Notices will continue to be available to clients for a limited time until a full transition is made to the eManifest Notices, RNS Notices will not be discussed in this document. For further information on RNS Notices, refer to Chapter 21: Release Notification (RNS) of the ECCRD. The Current Risk Notices and the future Risk Notices that will be introduced in Deployment 5 that clients can receive to inform them of the decisions made by Customs officials will not be discussed at this time, but will be included in a future version of this document. For further information on the current Risk Notices, clients can visit these CBSA websites: http://www.cbsa.gc.ca/prog/aci-ipec/marmode_rep_notice_avis-eng.html or http://www.cbsa.gc.ca/prog/aci-ipec/airmode_rep_notice_avis-eng.html .

Intended Audience The information outlined in this document is for registered CBSA clients who transmit advance commercial information to the CBSA via EDI, and elect to receive electronic notification regarding their transmissions. It is also for clients who are certified to forward copies of eligible data through the Manifest Forward functionality, to other registered trade chain partners.

Related ECCRD Chapters This chapter describes the Notices and Manifest Forward functionality that will be applied to Cargo and Conveyance data transmissions as of Deployment 4, and should be used in conjunction with the mode specific ECCRD chapters. For more information on mode specific Cargo and Conveyance transmissions to which these notices apply, refer to the ACI/eManifest

8

Highway, Rail, House Bill, Marine, Air, and Single Window Initiative Integrated Import Declaration (IID) chapters of the ECCRD. In addition to these, Chapter 21: Release Notification (RNS) of the ECCRD will provide information about the RNS Notices that clients can receive until they are fully replaced by eManifest Notices. Copies of these documents can be obtained by contacting the Technical Commercial Client Unit (TCCU), or the eManifest Help Desk. Contact information can be found in Part VII of this chapter.

Notice Delivery Channels There are two delivery channels through which CBSA clients are able to receive notification regarding the status of their transmitted data: via EDI, and/or the eManifest Portal. For clients who choose to use EDI, their system must be able to translate ANSI ASC X12 or EDIFACT data into the standard format of their business application. For further information about EDI transmission options, please refer to the mode-specific ECCRD chapters, or these CBSA websites: http://www.cbsa-asfc.gc.ca/prog/manif/requirements-exigences-eng.html and http://www.cbsa-asfc.gc.ca/eservices/comm-eng.html . Clients may also choose to use the eManifest Portal, a web-based application that is available to clients transmitting Cargo and Conveyance data, to receive electronic notices. New notices introduced in Deployment 4 however, will not be available in the Portal until Deployment 5. For documents that are submitted through the Portal in Deployment 4, only designated

ANPs will receive Deployment 4 Notices via EDI and not PNPs. As of Deployment 5, the full set of new Notices will be available to registered clients of the Portal. To obtain further information regarding the registration process and the receipt of current notices via the eManifest Portal, please visit the eManifest section of the CBSA website at http://www.cbsa-asfc.gc.ca/prog/manif/portal-portail-eng.html .

Future Versions This ECCRD chapter is intended for processes in use today and processes that are about to be implemented, but is subject to revision. This document will be replaced with future versions as legislation comes into force, and eManifest processes evolve and advance towards end-state.

9

Part II – EDI Profiles This section outlines key information regarding client communication profiles used to receive electronic notices from the CBSA via EDI.

EDI Profiles In order to be eligible to receive electronic notification about the status of transmitted data, all clients (Primary Notify Parties, Secondary Notify Parties, and Automated Notify Parties) must be registered with the CBSA, and have their EDI communications profiles set up to receive EDI notification. An EDI profile is a set of data that identifies clients EDI communication preferences and methods with the CBSA, and EDI Addresses to which notices are to be sent. Along with the implementation of a new set of notices, the CBSA has also created the External Client Notice Profile (ECNP) System that will change the way that profiles are configured. The CBSA will be able to customize the delivery of notices on clients behalf based on the configuration of their profiles, and clients will be able to choose which optional notices to receive (some notices however will become mandatory). Clients will also be able to specify their preferences for notices related to documents that were not sent by them, but for which they are recipients. Clients can contact the Technical Commercial Client Unit (TCCU) for information on becoming an EDI client and registering to receive the notices currently available to clients. Contact information can be found in Part VII of this document. For information on the receipt and processing of EDI data, transmission options, and message formats, clients can refer to the mode-specific ECCRD chapters, or visit the CBSA website at http://www.cbsa-asfc.gc.ca/eservices/menu-eng.html . For more information on Primary Notify Parties, Secondary Notify Parties, and Automated Notify Parties, see Part III of this document.

10

Part III – Context and Concepts

eManifest Deployments For the completion of eManifest, Deployments were introduced and will be used to implement the remaining functionality of eManifest. As of Deployments 4 and 5, new notices will become available to clients to inform them of the status of their shipments. In addition to these new notices, the existing RNS Notices along with the existing Matched and Not Matched Completeness Notices previously introduced in June 2013 will continue to be available to clients. As a result of the old and new notices running concurrently, clients will have some flexibility of when to transition from the old notices to the new end-state notices for a limited time until the RNS Notices and June 2013 Completeness Notices are retired. Clients will also continue to receive the current Risk Assessment Notices, which will eventually be replaced by newer eManifest notices. In Deployment 4 of the eManifest project, the Manifest Forward functionality will continue to be available to forward only House Bill data to Secondary and Automated Notify Parties, however as of Deployment 5, it will also be available in all modes to forward End-state Multi-modal Cargo (MMC) data. Deployment 4 will also provide a means of sharing Status Notices with other CBSA clients through the Automated Notify Party functionality, and both the Automated and Secondary Notify functionality as of Deployment 5. As of Deployment 4, the current Matched and Not Matched Completeness Notices that were introduced in June 2013 will continue to be available to existing clients to inform them that their transmitted data has been linked to applicable related trade data transmitted by another party pre-arrival. As of Deployment 4, additional Completeness Notices will become available along with new Not Matched and Matched Notices that will also notify CBSA clients whether or not all of their required pre-arrival data has been transmitted and linked. Clients who are already registered for the June 2013 version of the Completeness Notices will be able to continue to receive them as well as sign up for the new full suite of Deployment 4 Completeness Notices, or switch over to the new Completeness Notices altogether. Clients who are not yet registered for the June 2013 Completeness Notices will only be able to sign up for the new full suite of Deployment 4 Completeness Notices. In addition to the new Completeness Notices, the Document Not on File Notice and a limited set of Disposition Notices will be introduced as of Deployment 4: the Reported Notice, Arrived Notice, Released Notice, Authorized to Deliver Notice, Held for CBSA Notice, and the Deconsolidation Notice. These Disposition Notices will be sent to clients after Cargo has been reported or arrived in Canada.

11

Primary, Secondary, and Automated Notify Parties The Manifest Forward, a copy of transmitted data (currently only House Bills) sent to nominated registered clients, and Status Notices, which inform clients as well as their registered business partners about the level of pre-arrival completeness and/or decisions made against shipments, will be available to clients to improve the lines of communication between all parties. To help facilitate the ability to distinguish between the different parties who will be in receipt of the various notices and the Manifest Forward, three types of notify parties have been identified: the Primary Notify Party (PNP), the Secondary Notify Party (SNP), and the Automated Notify Party (ANP). A PNP is the client that has been designated as the key recipient of notices, whose unique ID is used to identify that client’s EDI profile settings, which is associated with an EDI Address in the External Client Notice Profile (ECNP) System. Through ECNP, clients who register will be able to designate the address(es) to which they want their Deployment 4 notices delivered. A SNP is a client who has been identified by another client to receive a Manifest Forward or Status Notice. In Deployment 4, clients who transmit House Bill data will continue to be able to identify registered CBSA clients with whom they want to share a copy of their House Bill data (Manifest Forward) through the use of the SNP functionality, but will not be able to designate SNPs to receive Status Notices for any type of data transmissions until Deployment 5. As of Deployment 5, clients who also transmit End-state MMC data will be able to send a Manifest Forward to registered clients as well as Status Notices regarding their eligible data transmissions to the CBSA. An ANP is a client who has been identified by the CBSA to receive a Manifest Forward or a Status Notice automatically. Clients who fall in this category must also be registered to receive notices sent via this functionality. As of Deployment 4, Warehouse Operators are deemed to be ANPs for the receipt of Manifest Forwards and Status Notices when the Manifest Movement Type of the Cargo or House Bill is in-bond and there is a valid Port of Destination Sub-loc on the Cargo or House Bill data transmissions.

SNP Group

Clients who choose to identify SNPs to receive Manifest Forwards (or Status Notices as of Deployment 5) are required to transmit the Secondary Notify Party Group in their eligible data transmissions. In Deployment 4, the only eligible document that contains the SNP functionality is the House Bill. This group consists of the Notice Type, Client Type, and SNP Client Identifier. Using valid CBSA SNP client identifiers, clients can currently designate up to a maximum of 99 SNPs to receive Manifest Forwards. As of Deployment 5, clients will be able to designate up to a maximum of 99 SNPs to receive Manifest Forwards and/or Status Notices combined. For further information on Status Notices, refer to Notice Descriptions in this section. Notice Types

12

The two types of notices that clients can select to send to SNPs are:

a. Manifest Forward b. Status Notice (Deployment 5)

Client Types The client types differ depending on the transmission standard being used. For CBSA clients using EDIFACT GOVCBR to transmit data to the CBSA, the SNP Client Types are:

1. CA for Carrier 2. FW for Freight Forwarder 3. CB for Broker 4. WH for Warehouse Operator

For CBSA clients using ANSI ASC X12 to transmit data to the CBSA, the SNP Client Types are:

1. C for Carrier 2. F for Freight Forwarder 3. A for Broker 4. W for Warehouse Operator

Note: In Deployment 4, the SNP functionality will not be available for any types of transmissions other than Manifest Forward (House Bill only).

SNP Client Identifiers (ID) The formats for SNP Client IDs are as follows:

1. Carrier – a CBSA-issued Carrier Code (4 alphanumeric characters) 2. Freight Forwarder – a CBSA-issued Freight Forwarder Code (4 alphanumeric

characters) 3. Broker/Account Security Holder – a CBSA-issued account security number (5 numeric

characters) 4. Warehouse Operator – a CBSA-issued sub-location code (4 alphanumeric characters)

To avoid trade data being distributed to the wrong party or not at all, all identified SNPs must be registered with the CBSA and a valid SNP Notice Type, Client Type, and Client ID must be transmitted on the inbound document to the CBSA. Failure to provide valid and correct SNP Group information will result in the non-receipt of the Manifest Forward or Status Notice by the identified SNP. Note: Notification will not be provided to clients to inform them that a Notice was not delivered to an identified SNP.

13

Deployment 4 Status Notice EDI Mapping Note for PNP/ANP/SNP Please note that CBSA currently will not provide separate Client Identification in a PNP-directed outbound Notice. CBSA expects clients to know their own Client ID if it is their request that is found in either the BGM (EDIFACT) or M10 (ANSI X12) segment of the message. However, where an ANP or SNP is involved, CBSA will use the NAD segment (EDIFACT GOVCBR) or M1017/M1012 (ANSI X12) to notify the notice recipient as to which alternate party CBSA expects the notice to be delivered. For the EDIFACT GOVCBR, to determine whether a notice is for a PNP or not, look for the NAD segment in the message:

1. If NAD segment is populated with data, then the notice is to the ANP or SNP. The value found in the NAD will be the Client ID info for the ANP or SNP.

2. If there is no NAD segment in the message, then the notice is for the PNP. For ANSI ASC X12, to determine whether a notice is for a PNP or not, look at the value in M1017.

1. If M1017 is either blank or contains the value “S” in the message, then the notice is for the PNP. Note that if M1017 = “S”, then the value found in M1012 will be the inbound message’s Secondary Business ID reference number, i.e. the unique transmission identifier that was originally assigned to the inbound transaction.

2. If M1017 is populated with any value other than “S”, then the notice is to the ANP or SNP. The value found in M1012 will be the Client ID for the ANP or SNP.

Notice Descriptions In Deployment 4, PNPs will continue to receive existing notices such as Validation Notices, which includes the Insufficient Review Time Notice, for most data transmitted to the CBSA. The Section 12.(1) Reported Notice will also be available that lists reported Cargo, and clients will continue to be able to identify other registered CBSA clients to receive a Manifest Forward of their House Bill data transmissions. New eManifest notices that will be available as of Deployment 4 are also known as Status Notices and include Document Not on File, Completeness, and Disposition Notices. The new expanded set of Completeness Notices available will be Not Matched, Matched, Cargo Complete, and Document Package Complete. The Disposition Notices that will be available are the Reported, Arrived, Released, Authorized to Deliver, Held for CBSA, and Deconsolidation Notices. Following is a description of these notices.

14

Validation Notices All data that is transmitted to the CBSA must undergo a validation process (see Part IV of this document). Clients are informed of the results of this validation process through a series of Validation Notices that are sent by the CBSA in response to data transmissions. These notices are currently available to clients and will continue to be available upon full implementation of eManifest. These existing Validation Notices are as follows: Positive Functional Acknowledgment Notice Applicable MIG(s) – EDIFACT GOVCBR v.11B, EDIFACT CUSRES v.96A, EDIFACT CUSRES v.99B, EDIFACT CUSRES v.08A, ANSI X12 997 v.5040

The Positive Functional Acknowledgment Notice is sent to clients to acknowledge the acceptance of correct functional group syntax data, transaction set syntax data, segment syntax data, and data element syntax data. Though always generated, this is an optional notice and clients must have their EDI profile configured to receive it. Negative Functional Acknowledgment Notice Applicable MIG(s) – EDIFACT GOVCBR v.11B, EDIFACT CUSRES v.96A, EDIFACT CUSRES v.99B, EDIFACT CUSRES v.08A, ANSI X12 997 v.5040

The Negative Functional Acknowledgment Notice informs clients that their data contains a functional group syntax error, transaction set syntax error, segment syntax error, and/or data element syntax error. The receipt of this notice indicates CBSA systems were not able to process and store the transmitted data. To correct the error, a new EDI transmission must be transmitted in its place. Note: This notice is not optional and clients cannot choose to suppress it.

Application Acknowledgement Notice Applicable MIG(s) – EDIFACT GOVCBR v.11B EDIFACT CUSRES v.08A, ANSI X12 824 v.5040

The Application Acknowledgement Notice informs clients that their transmitted data has been validated for specific edits by CBSA business systems and has passed those edits. This notice does not indicate that any other level of completeness has been achieved, and therefore should not be construed as an authorization to load or move a shipment. Assessment must still be performed by CBSA Officers to determine the admissibility of Cargo and Conveyances. Please note that an Application Acknowledgement Notice will not be sent to clients for the transmission of a Conveyance Arrival Certification Message (CACM). Instead clients will receive a Section 12.(1) Reported Notice that will serve as an acknowledgment of receipt of the CACM.

15

Application Reject Notice Applicable MIG(s) – EDIFACT GOVCBR v.11B, EDIFACT CUSRES v.08A, ANSI X12 824 v.5040

The Application Reject Notice is sent to clients after transmitted data has been validated for system edits and one or more errors have been detected. This notice will be accompanied by a coded field which will identify the invalid data element and an explanation of the error.

Note: This notice is not optional and clients cannot choose to suppress it.

Insufficient Review Time Notice Applicable MIG(s) – EDIFACT GOVCBR v.11B, EDIFACT CUSRES v.08A, ANSI X12 824 v.5040

The Insufficient Review Time Notice informs clients that they have not met their requirement to transmit their Highway and/or Rail Conveyance, or their MMC documents within the prescribed time limits. In Deployment 4, this notice will be sent to the PNPs of these documents when they are transmitted and the CBSA receipt time of the first accepted transmission is less than the prescribed reporting times for the mode. This notice will not be sent to ANPs in this Deployment. Note: This notice is not optional and clients cannot choose to suppress it.

For more information on the Functional and Application Validation processes, refer to Part V of this ECCRD chapter.

Section 12.(1) Reported Notice Applicable MIG(s) - EDIFACT GOVCBR v.11B S12.(1) Notice, EDIFACT CUSRES v.08A, ANSI X12 350 v.5040

The Section 12.(1) Reported Notice informs clients that they have met their obligation to report under Section 12.(1) of the Customs Act. This notice is generated upon the arrival of a Conveyance through a CACM, or operation of a CBSA Officer at First Point of Arrival (FPOA), and serves as the only acknowledgment that clients will receive for this arrival. An Application Acknowledgement will not be sent to clients for this transmission. Please note that this notice does not indicate that the shipment has been released from Customs control. There will be one notice sent for each trip containing 200 related CCNs or less. Additional Section 12.(1) Notices for the same Conveyance will be generated when there are more than 200 related CCNs in increments of 200 CCNs per notice. Note: This notice is not optional and clients cannot choose to suppress it.

16

Manifest Forward Available MIG(s) - EDIFACT GOVCBR v.11B House Bill Manifest Forward, ANSI X12 309 v. 5040 House Bill Manifest Forward

The SNP functionality makes it possible for clients to share House Bill and End-state MMC (Deployment 5) data with their trade chain partners who are also registered with the CBSA to receive electronic notices via a Manifest Forward. The Manifest Forward is a reconstructed version of House Bill and End-state MMC data, and will only be assigned the business data elements that were captured by the CBSA for these electronic transmissions. In order to be forwarded, the data must pass validation by CBSA systems. The CBSA is not responsible for the accuracy of transmitted data, therefore clients must ensure the transmissions are correct, as the information will be forwarded to SNPs as received. In Deployment 4, Carriers, Freights Forwarders, Account Security Holders, and Warehouse Operators in all modes are the only client types eligible to receive a Manifest Forward. Even though Warehouse Operators will receive a Manifest Forward of eligible House Bill transmissions automatically, clients can choose to designate other Warehouse Operators to receive a Manifest Forward by providing valid SNP Group information for the designated warehouse on their House Bill data transmissions. As of Deployment 5, all eligible clients will be able to be identified to receive the End-state MMC Manifest Forward.

For the House Bill and MMC Manifest Forward, as they are a copy of the inbound documents, a list of data elements can be found in the respective inbound ECCRD chapters. The outbound Manifest Forward will contain all of the same data elements as the corresponding inbound House Bill or MMC document with the exception of the SNP Group.

Status Notices Status Notices are electronic notices that are sent to PNPs, ANPs, and/or SNPs to inform them of the level to which their pre-arrival data has been transmitted, and/or the decisions that have been made with regard to their data transmissions to the CBSA. For Deployment 4, Status Notices include but are not limited to the Document Not on File Notice, the full suite of Completeness Notices (Not Matched, Matched, Cargo Complete, Document Package Complete), and Disposition Notices (Reported, Arrived, Released, Authorized to Deliver, Held for CBSA, and Deconsolidation). In Deployment 4, only PNPs and ANPs will be able to receive these notices which represent an optional suite of notices that clients must have their EDI profile configured to receive. When introduced in Deployment 5, various additional Status Notices (including all notices relating to Held, Request for Information, and Do Not Load/Unload) will become mandatory. Following is a description of the various Status Notices that PNPs and/or ANPs will be eligible to receive as of Deployment 4.

17

A. Document Not on File Applicable MIG(s) - ANSI X12 350 v.7010, EDIFACT GOVCBR v.13A The Document Not on File Notice informs clients that a Cargo Control Number (CCN) that is not in good standing was quoted on a trade document which has been submitted to the CBSA. When clients transmit documents that reference another trade document that it is expected to link to, a Document Not on File Notice will be sent automatically to the ANP of the referenced document that is not in good standing. This notice will be available only as of Deployment 4, and documents that will trigger the creation of this notice are a House Bill Close Message, Pre-arrival Review System (PARS), IID, RMD, and B3. Designated ANPs of this notice are Carriers and Freight Forwarders who are quoted on these submitted documents. They will receive this notice for CCNs that have been cancelled, are rejected, or are not on file. Note: Clients will also receive this notice when electronic Releases submitted to the CBSA quote paper Cargo documents. This does not however mean that requirements have not been met. As these Cargo documents are replaced by end state electronic Cargo documents, this occurrence will become less prevalent.

B. Completeness Notices In addition to the Matched and Not Matched Completeness Notices that some existing clients currently receive that were introduced in June 2013, a new set of Completeness Notices will also be available to all clients as of Deployment 4. This new set of Completeness Notices has been expanded and includes new Matched and Not Matched Notices, Cargo Complete, and Document Package Complete Notices. These Completeness Notices will inform clients regarding the fulfillment of CBSA pre-arrival document requirements, up to the arrival of the Cargo at its stated Port of Destination. They will be triggered upon the transmission of Cargo, House Bill, PARS, and IID data, however will only be created and sent prior to the arrival of the Cargo or House Bill to all eligible parties. Note that these Completeness Notices do not indicate that a final determination has been made regarding the admissibility or release of the shipment. In Deployment 4, clients who are already in receipt of the June 2013 set of Completeness Notices can choose to continue to receive it, opt to receive both sets of Completeness Notices, or switch to the Deployment 4 set. The June 2013 Completeness Notices however, will eventually be sunset. Once the Deployment 4 Completeness Notices are available, newly registered clients will only be able to register to receive this new set. Please note that clients who choose to receive either Completeness Notice sets will receive all of the Notices within that set and will not be able to opt out of individual Completeness Notices. For a list of the relationships that can trigger a Completeness Notice, see Part VI, Figure 1 – Completeness Notice Relationships. The following is a description of the Completeness Notices Suite:

18

Not Matched Notice Applicable MIG(s) - EDIFACT GOVCBR v.11B, EDIFACT GOVCBR v.13A, ANSI X12 350 v.5040, ANSI X12 350 v.7010

The Not Matched Notice informs clients that either no links to a related trade document have been established, or that a document that has previously been matched to another document becomes unlinked through a change or cancellation. As of Deployment 4, there will be two versions of the Not Matched Notice that PNPs of these documents will be eligible to receive. The June 2013 version of the Not Matched Notice will continue to be available in EDIFACT v11B and ANSI 350 v.5040 to those already in receipt of them, and the Deployment 4 version of Not Matched Notice will be available in EDIFACT v13A and ANSI 350 v.7010 to all registered clients. Documents to which this notice can apply are Air and Marine Cargo, MMC, House Bills, House Bill Close Message, PARS, and the IID. PNPs will be eligible to receive this notice prior to the arrival of the (related) Cargo or House Bill(s) at the stated Port of Destination. Note 1: For the June 2013 Not Matched Notice, PARS transmissions will not receive a Not Matched Notice upon initial capture. Note 2: The Deployment 4 Not Matched Notice will be sent for PARS or IID transmissions that quote paper Cargo documents.

Matched Notice Applicable MIG(s) - EDIFACT GOVCBR v.11B, EDIFACT GOVCBR v.13A, ANSI X12 350 v.5040, ANSI X12 350 v.7010

The Matched Notice informs clients that a specific trade document is linked to a related trade document. It also informs PNPs of eligible Release documents that all necessary pre-arrival trade documents related to the Release (i.e. related Cargo) have been received and accepted by the CBSA. In Deployment 4, there will be two versions of the Matched Notice that PNPs will be eligible to receive. The June 2013 version of the Matched Notice will continue to be available in EDIFACT v11B and ANSI 350 v.5040 to those already in receipt of them, and the Deployment 4 version of Matched Notice will be available in EDIFACT v13A and ANSI 350 v.7010 to all registered clients. Documents to which this notice can apply are Air and Marine Cargo, MMC, House Bills, House Bill Close Message, PARS, and the IID. PNPs who transmit them will be eligible to receive this notice prior to the arrival of the (related) Cargo or House Bill(s) at the stated Port of Destination.

19

Cargo Complete Notice Applicable MIG(s) - ANSI X12 350 v.7010, EDIFACT GOVCBR v.13A

The Cargo Complete Notice informs clients that a non-consolidated Cargo document has been transmitted to the CBSA and accepted. If consolidated, it indicates that all of the related Secondary Cargo (i.e. House Bills) has been transmitted as well. Documents that have achieved this status have not yet been linked to related PARS or IID documents. This notice will be available as of Deployment 4 only. Documents to which this notice can apply are Air and Marine Cargo, MMC, and House Bills. PNPs will be eligible to receive this notice prior to the arrival of the Cargo or House Bill(s) at the stated Port of Destination. Document Package Complete Notice Applicable MIG(s) - ANSI X12 350 v.7010, EDIFACT GOVCBR v.13A

The Document Package Complete Notice informs clients that the Cargo and all other mandated pre-arrival trade documents (House Bills, House Bill Close Message), as well as all related Release documentation necessary for CBSA to determine if the goods can be released into the Canadian economy (PARS/IID), have been received and accepted by the CBSA. This notice will be available as of Deployment 4 only. Documents to which this notice can apply are Air and Marine Cargo, MMC, and House Bills. PNPs who transmit them will be eligible to receive this notice prior to the arrival of the Cargo or House Bill(s) at the stated Port of Destination.

C. Disposition Notices Disposition Notices inform clients of decisions that have been made with regard to their Cargo data transmitted to the CBSA. The Reported Notice will only be sent after the Conveyance has arrived at FPOA; and the Arrived, Released, Authorized to Deliver, Held for CBSA, and Deconsolidation Notices will only be sent after Cargo has arrived at its destination. The following Disposition Notices will be available for PNPs and ANPs as of Deployment 4: Reported Notice Applicable MIG(s) - ANSI X12 350 v.7010, EDIFACT GOVCBR v.13A

The Reported Notice informs clients that their Cargo has been presented to the CBSA at the Port of Report or FPOA. As of Deployment 4, once the Cargo, House Bill, or Empty Marine Container has achieved reported status, the Reported Notice will be sent to PNPs of these documents. If the Cargo is destined inland, Warehouse Operators identified on the inbound Cargo or House Bill document have been designated by CBSA as ANPs to receive this notice. Receipt of this notice

20

can indicate to clients that any required updates to documents must now be made using the “Amend” instead of “Change” message function (where applicable). Note 1: Under certain circumstances where the goods are destined for a Frontier port, if a Cargo achieves both reported and arrived status simultaneously, the Reported Notice may be suppressed, and only the Arrived Notice be sent. Note 2: Under certain circumstances e.g. when there is a split involved in a shipment, or where there may be timing delays between Cargo capture and processing of the CACM, the Port of Report may not display correctly (i.e. may indicate Port 1000).

Arrived Notice Applicable MIG(s) - ANSI X12 350 v.7010, EDIFACT GOVCBR v.13A

The Arrived Notice informs clients that their Cargo has arrived at its Port of Destination. As of Deployment 4, upon arrival of Cargo, PNPs of Prime Cargo or House Bill(s) will be eligible to receive this notice. If the Cargo is arrived at a warehouse, Warehouse Operators identified on the inbound Cargo or House Bill document have been designated by CBSA as ANPs to receive this notice. Released Notice Applicable MIG(s) - ANSI X12 350 v.7010, EDIFACT GOVCBR v.13A

The Released Notice informs clients when goods have been authorized to be removed from a CBSA office, a sufferance warehouse, or a bonded warehouse for use in Canada. As of Deployment 4, the Released Notice will be sent to PNPs whose non-consolidated Cargo or non-consolidated House Bill has been acquitted by a Release. It will also be sent to PNPs of Release data, when the data achieves a final status of released. Designated ANPs who are eligible to receive this notice are Warehouse Operators, Account Security Holders as defined by the Account Security Number on the applicable Release, and Carriers or Freight Forwarders as defined by the Carrier/Freight Forwarder Code of the CCN on the applicable Release document. The Warehouse Operator will be identified by the Port of Release Sub-location Code on the Release document, or if unavailable, the Port of Destination Sub-location Code on the related Cargo or House Bill document. Note: Under certain circumstances, there may be a delay in sending the Deployment 4 Released Notice, which will result in a Deployment 4 Held for CBSA Notice being issued to clients in the brief interim. As a result, clients are advised to wait a few minutes to verify that the shipment is indeed held.

21

Authorized to Deliver Notice Applicable MIG(s) - ANSI X12 350 v.7010, EDIFACT GOVCBR v.13A

The Authorized to Deliver Notice informs Customs Self-Assessment (CSA) clients that their CSA goods can be delivered to the intended recipient. As of Deployment 4, the Authorized to Deliver Notice will be sent to PNPs of CSA EDI Non-highway Clearance documents that are arrived and have achieved Authorized to Deliver status. It will also be sent to PNPs whose Cargo documents are arrived and related to CSA EDI Non-highway Clearance documents that have been arrived and have achieved Authorized to Deliver status. PNPs of MMCs with a CSA Indicator that are arrived and have achieved Authorized to Deliver status will also receive it. Designated ANPs who are eligible to receive this notice are Carriers, Account Security Holders, and Warehouse Operators identified on the inbound Cargo documents, or on the paper CSA Arrival document, or on the CSA Highway Clearance if a Cargo Control Number is provided for scanning at FPOA. Held for CBSA Applicable MIG(s) - ANSI X12 350 v.7010, EDIFACT GOVCBR v.13A

The Held for CBSA Notice informs clients that their goods are being held for further determination or processing and cannot be released. As of Deployment 4, this Notice will be sent to PNPs of electronic Release documents and the arrived non-consolidated Cargo that is related to it. Designated ANPs who are eligible to receive this notice are Warehouse Operators identified on the inbound Cargo or House Bill document if destined inland. Note: Under certain circumstances, there may be a delay in sending the Deployment 4 Released Notice, which will result in a Deployment 4 Held for CBSA Notice being issued to clients in the brief interim. As a result, clients are advised to wait a few minutes to verify that the shipment is indeed held.

Deconsolidation Notice Applicable MIG(s) - ANSI X12 350 v.7010, EDIFACT GOVCBR v.13A

The Deconsolidation Notice informs clients that the CBSA has authorized the transfer of Cargo control from a consolidated shipment to its related secondary House Bills that were submitted to the CBSA. This notice can serve as electronic notification to the Warehouse Operator to allow the Freight Forwarder to take control of the goods within the consolidation. The information in this notice informs the Warehouse Operator of the further breakdown of the consolidated shipment they have entered into their warehouse. This information allows the Warehouse Operator to determine to which consolidated shipment a specific House Bill is related.

22

This notice can also serve as electronic notification to the party liable for Customs duty and taxes on the consolidated shipment that the consolidated Cargo or House Bill has been acquitted and liability has been transferred. As of Deployment 4, the Deconsolidation Notice will be sent to PNPs of consolidated Cargo or consolidated House Bill, and to PNPs of House Bill Close Messages. Designated ANPs who are eligible to receive this notice are Warehouse Operators identified on the inbound consolidated Cargo or consolidated House Bill document. For a listing of the Status Notices for PNPs listed by Document Type, and a listing of eligible ANPs by Notice Type, refer to Charts 1 and 2 in Part VI of this document. For a listing of Deployment 4 Status Notice Data Elements, refer to Appendices B, O, or P.

23

Part IV – Notice Business Requirements This section provides a general guideline of system requirements and outlines key business rules clients need to know to communicate electronically with the CBSA.

System Rules General transmission rules of which CBSA clients should be aware of is as follows:

1. The June 2013 Completeness Notices can be transmitted to clients in ANSI ASC X12 350 version 5040 or UN/EDIFACT GOVCBR version 11B, and a Manifest Forward can be transmitted to clients in ANSI ASC X12 309 version 5040 or UN/EDIFACT GOVCBR version 11B.

2. Deployment 4 Completeness and Disposition Notices can be transmitted to the client in ANSI ASC X12 350 version 7010 or UN/EDIFACT GOVCBR version 13A.

3. Acknowledgements and Rejects to the PNP will be returned in the same standard (ANSI ASC X12 or UN/EDIFACT) in which the inbound data was received. All other outbound Deployment 4 Notices to clients will be based on their profile.

4. All information must be submitted to the CBSA in either English or French.

Recipient Business Rules

1. PNPs, ANPs, and SNPs will receive electronic notices via EDI or the eManifest Portal only if they are registered to receive them.

2. The new eManifest Deployment 4 Notices introduced in this document (Document Not on File, Cargo Complete, Document Package Complete, Reported, Arrived, Released, Authorized to Deliver, Held for CBSA) will not be available in the Portal (until Deployment 5). Existing notices however will continue to be available in the Portal.

3. If a client submits documents through the Portal, they will not receive notices related to that document via EDI. For example, if the original is transmitted through EDI and then changed through Portal, all subsequent eligible notices will be available via the Portal only. If another change is done via EDI then all notices generated after the last change will be available via EDI.

Validation Notification Business Rules 1. Application Acknowledgement Notices will not be sent for CACMs. The S12.(1)

Reported Notice will serve as the only application acknowledgement for these messages.

2. Application Acknowledgement Notices will not be sent for Warehouse Arrival Certification Messages (WACM) or PARS transmitted to the CBSA. As of Deployment 4, Completeness (pre-arrival only) and/or Disposition Notices can serve as application

24

acknowledgements for these messages. Note: RNS Status Response Notices (as applicable) currently serve as application acknowledgements for these messages.

3. When an Application Reject Notice is received for a non-key error, clients must transmit a changed transmission with the corrected data. When an Application Reject Notice is received for a key error (e.g. CCN/CRN), an original transmission is required.

4. When a Negative Functional Acknowledgment Notice is received, clients must transmit an original transmission, as the rejected transmission will not be stored in CBSA systems.

5. The Insufficient Review Time Notice will be sent to the PNP of the MMC or Conveyance when the following occurs:

a) The CBSA receipt time of the first accepted submission of the Highway MMC or Conveyance is less than 1 hr from the estimated time of arrival (ETA) reported on the Conveyance.

b) The CBSA receipt time of the first accepted submission of the Rail MMC or Conveyance is less than 2 hrs from the ETA reported on the Conveyance.

Manifest Forward Business Rules

1. House Bill data must pass all validation processes for a Manifest Forward to be sent. 2. The CBSA can send a Manifest Forward to any SNP who wish to receive the notice, if

they are registered to receive notices via EDI or the eManifest Portal. 3. If a SNP is listed on a House Bill to receive a Manifest Forward but is not registered to

receive EDI notifications, the Manifest Forward will not be sent. Also, notification will not be sent to inform the PNP of the House Bill that the Manifest Forward was not sent.

4. The CBSA will not process any acknowledgement or reject messages from the Manifest Forward recipient confirming the receipt of the Manifest Forward.

5. The Manifest Forward Notice transmitted to the SNP will for the most part contain all of the business data in the original transmission, with the exception of the inbound looping segment that contains the SNP ID(s), and will only be transmitted if the House Bill data has been accepted by the CBSA. For additional exceptions to the business data content, see Appendix E of this ECCRD chapter.

6. A Manifest Forward of the House Bill is generated regardless of whether or not the House Bill is matched with related data.

7. If Cargo reported on a House Bill is moving in-bond to a warehouse, upon arrival at FPOA, a Manifest Forward will be sent to the Warehouse Operator (ANP) identified on the Cargo document. A Manifest Forward will also be re-transmitted to the Warehouse Operator identified on a changed or amended House Bill.

8. In cases where a House bill is changed or amended and a Manifest Forward is to be sent to SNPs, the changed or amended House Bill must contain the applicable SNP data elements.

9. In Deployment 4, if a House bill is cancelled, there will be no notification to the recipient of the Manifest Forward informing them that it has been cancelled.

25

10. A Manifest Forward cannot be cancelled or recalled once it is sent.

Note: Due to differences between various EDI standards, some of the House Bill data that is transmitted on a Manifest Forward may be truncated if transmitted in one EDI format, and translated and forwarded into another EDI format. For further information on the potential data truncation due to the translation of data, refer to Appendix E of this ECCRD chapter.

Document Not on File Business Rules (Deployment 4) 1. A Document Not on File Notice will be sent when a PARS, IID, or House Bill Close

Message quotes a CCN that is not in good standing. 2. For the Document Not on File Notice to be sent, the document triggering the notice

must be in good standing. 3. This notice will only be sent to the quoted Carrier (ANP) for CCNs that are not in good

standing (not on file, rejected, and/or cancelled). 4. If a client submits paper Cargo documents that are related to an electronic Release

document, clients will still receive the Document Not on File Notice. In such cases this may not mean that reporting requirements have not been met.

5. Where an EDI Cargo/House Bill is linked to a PARS/IID pre-arrival and then the EDI Cargo is cancelled pre-arrival, the Carrier/Freight Forwarder will receive a Document Not on File Notice since the related PARS/IID is now quoting a CCN that is not in good standing.

Completeness Notification Business Rules

1. Completeness Notices will not be sent for Cargo and House Bill transmissions that have obtained an arrived status, and they will not be sent for House Bill Close Messages and Release documents associated with Cargo or House Bills that have obtained an arrived status.

2. The Completeness Notices introduced in June 2013 will only apply to House Bills, House Bill Close Messages, MMC, PARS, and IID(s). As of Deployment 4, the new expanded set of Completeness Notices will apply to Air and Marine Cargo, MMC, House Bills, House Bill Close Messages, PARS, and IID(s).

3. For the Matched, Cargo Complete, and Document Package Complete Notices, all documents must be in good standing for the appropriate Completeness Notice relationship to be created (see Part VI, Figure 1 Completeness Notice Relationship), and appropriate notice sent. For the Not Matched Notice to be created, the document that triggers this notice must be in good standing.

4. During the pre-cargo arrival timeframe, a Completeness Notice can be generated when a trade document is submitted (i.e. original, change, or amend), adjusted, cancelled, or manually changed.

26

5. When an applicable document, which is not previously linked to a related document, is changed pre-arrival and remains unlinked, a subsequent June 2013 Not Matched Notice will be sent. The Deployment 4 version of the Not Matched Notice however will not be sent when this occurs.

6. A Deployment 4 Completeness Notice will be sent if a change in the version of a document causes the document’s Completeness status to change.

7. Paper PARS documents will trigger a Completeness Notice to the PNP of the related electronic document, but not to the submitter of the Paper PARS.

8. Paper Cargo/House Bill documents will not affect the Completeness status of electronic PARS/IID to which they are linked, instead the electronic PARS/IID will still receive a Not Matched Notice as if the Cargo/House Bill is not on file.

9. The IID and the non-consolidated Cargo document it links to will only receive Completeness Notices prior to the arrival of the Cargo.

10. For Deployment 4 Completeness Notices, if the Related Reference ID on a document is changed but the Completeness status of the document remains the same, a new Completeness Notice will not be sent quoting the new Related Reference ID.

11. The hierarchy for Completeness Notices from lowest to highest is as follows: Not Matched, Matched, Cargo Complete, and Document Package Complete. When multiple statuses are achieved for a data transmission, only the highest notice will be sent to CBSA clients.

12. The June 2013 Not Matched Notices will be sent to PNPs when the following occurs: a) A non-consolidated MMC or House Bill is transmitted and not linked with a

related PARS, or becomes unlinked through a change or cancellation of one of the documents.

b) A consolidated MMC or House Bill is transmitted and not linked with a related House Bill Close Message, or becomes unlinked through a change or cancellation of one of the documents.

c) A House Bill Close Message is transmitted and not linked with a related consolidated MMC or House Bill, or becomes unlinked through a change or cancellation of one of the documents.

d) A PARS that was previously linked to a non-consolidated MMC or House Bill becomes unlinked through a change or cancellation of one of the documents. Note: This version of the Not Matched Notice will not be sent to the PNP of the PARS when a PARS is originally transmitted and not linked to a related MMC or House Bill.

13. As of Deployment 4, the new set of Not Matched Notices will be sent to PNPs for documents that are in good standing when the following occurs:

a) An Air or Marine Cargo is transmitted but not linked to a related House Bill Close Message, PARS, or IID.

b) A consolidated MMC or consolidated House Bill is transmitted but not linked to a related House Bill Close Message.

c) A House Bill Close Message is not linked to a related consolidated Air or Marine Cargo, consolidated MMC, or consolidated House Bill.

27

d) A PARS is not linked to a related non-consolidated Air or Marine Cargo, MMC, or House Bill.

e) An IID is not linked to at least one of its related non-consolidated Air or Marine Cargo, MMC, or House Bill(s).

f) A PARS is linked to a Paper Cargo/House Bill. g) An IID is linked to at least one Paper Cargo/House Bill.

14. The June 2013 set of Matched Notices will be sent to PNPs when the following occurs:

a) An EDI PARS is linked to a related non-consolidated MMC or House Bill. b) A House Bill Close Message is linked to a related consolidated MMC or

consolidated House Bill.

15. As of Deployment 4, the new set of Matched Notices will be sent to PNPs whose documents are in good standing when the following occurs:

a) A House Bill Close Message is linked to an Air or Marine Cargo, or a consolidated MMC or consolidated House Bill.

b) An Air or Marine Cargo, MMC, or House Bill is linked to a House Bill Close Message, and at least one lower level Secondary Cargo documents has achieved Not Matched Completeness status.

c) A PARS is linked to its related non-consolidated EDI Cargo. d) An IID is linked to all of its related non-consolidated EDI Cargo.

16. As of Deployment 4, a Cargo Complete Notice will be sent to the PNPs of MMC and/or

House Bills when the following occurs: a) A non-consolidated MMC or House Bill is transmitted and accepted and not

linked to a related PARS or IID. b) An Air or Marine Cargo, MMC, or House Bill is linked to a related House Bill

Close Message, and all of the related House Bills on the next level below have achieved at least Cargo Complete status.

17. As of Deployment 4, a Document Package Complete Notice will be sent to the PNPs of MMC and/or House Bills in when the following occurs:

a) An Air or Marine Cargo, or MMC, or House Bill is linked to a related PARS or IID.

b) An Air or Marine Cargo, or MMC, or House Bill is linked to a related House Bill Close Message, and all of the House Bills on the next level below have achieved Document Package Complete status.

c) When a MMC is transmitted with a CSA Indicator set to ‘yes’.

Section 12.(1) Reported Notice Business Rules

1. This notice will only be assigned CCN references for the Cargo documents that are directly related to the arrived Conveyance Report.

28

2. This notice will include the CCNs of all split shipments, but will not include the CCNs for the associated master Air Cargo Reports.

3. This notice will not include the CCNs of Secondary Cargo documents such as Supplementary Cargo Reports and House Bills that are associated with the reported Cargo listed therein.

4. This notice will serve as the only acknowledgement sent to clients in response to their CACMs, as an Application Acknowledgement Notice will not be sent.

Disposition Business Rules (Deployment 4)

1. Cargo must be in good standing for the Reported and Arrived Notices to be sent. 2. In Good standing for data acquisition purposes refers to documents that are on file, not

rejected, and not cancelled. 3. The Released, Held for CBSA, and Authorized to Deliver Notices will only be sent upon

arrival of the Cargo or House Bill. 4. The Reported, Released, and Held for CBSA Notices will only be sent up to the time of

acquittal of the Cargo or House Bill. 5. The Reported Notice will be sent to PNPs when the Cargo or House Bills have achieved

reported status, and also to Warehouse Operators (ANP) when the Cargo is destined inland.

6. The Arrived Notice will be sent to PNPs when the Cargo or House Bills have achieved arrived status, and will also be sent to Warehouse Operators (ANP) if the Cargo or House Bills have been arrived at a warehouse.

7. The Released Notice will only be sent if all related shipments have achieved released status.

8. The Released Notice will be sent to PNPs of Cargo or House Bills when a non-consolidated Air or Marine Cargo, MMC or House Bill is acquitted by a Release document.

9. The Released Notice will be sent to PNPs when an electronic Release document achieves a final status of released. When this occurs, it will also be sent to Account Security Holders (ANP) as defined by the Account Security Number on all Releases, the Carrier (ANP) as defined by the Carrier Code of the CCN quoted on the Release document, and the Warehouse Operator (ANP) as defined by the Port of Release Sub-location on the Release. If this Sub-location is unavailable, the Port of Destination Sub-location Code on the Cargo will be used.

10. An Authorized to Deliver Notice will be sent to PNPs of CSA EDI Non-highway Clearances when Clearances are arrived and achieve Authorized to Deliver status. If there are related Cargo documents on file that are arrived, this notice will also be sent to the PNPs of the related Cargo, and to the Warehouse Operator (ANP) identified by the Port of Destination Sub-location Code on the Cargo.

11. An Authorized to Deliver Notice will be sent to PNPs of a MMC that contains a CSA Indicator when the Cargo is arrived and achieves Authorized to Deliver status. When

29

this occurs, the notice will also be sent to the Warehouse Operator (ANP) identified by the Port of Destination Sub-location Code on the MMC.

12. An Authorized to Deliver Notice will be sent to the Carrier (ANP) referenced by the CCN quoted on a CSA Paper Clearance document, when the Clearance is arrived and has achieved Authorized to Deliver status.

13. An Authorized to Deliver Notice will be sent to an Account Security Holder (ANP), when a CSA Paper Clearance is arrived, has achieved Authorized to Deliver status, and both a CCN and Account Security Number is provided.

14. A Held for CBSA Notice will only be sent if the related Release is in good standing. 15. A Held for CBSA Notice will be sent to the PNP of a PARS or IID when the related non-

consolidated Cargo is in arrived status, and the PARS or IID cannot be released. If the related Cargo/House Bill is in good standing, the notice will also be sent to the PNP of the related Cargo/House Bill, and to the Warehouse Operator (ANP) identified on the Cargo/House Bill if destined inland.

16. Where there are multiple CCNs on the Release document, the Held for CBSA notice will not be sent to any party until all related CCNs have arrived.

17. A Deconsolidation Notice will be sent to the PNP of a consolidated Cargo/House Bill that is quoted on a House Bill Close Message (as the Previous CCN), and has achieved acquitted status. This notice will also be sent to the PNP of the related House Bill Close Message, and to the Warehouse Operator (ANP) identified on the consolidated. Cargo/House Bill.

30

Part V –Response Notification Processes and Sample Scenarios

The notices contained in this ECCRD are generated in response to the electronic transmission of Cargo, Conveyance, and Release data sent to the CBSA by clients.

Validation Processes Once clients have completed the registration process and have been approved by the CBSA to transmit data and receive notices, a series of notices will be sent to clients in response to their transmitted data. Data that is transmitted to the CBSA as an original, change, or amendment, must conform to CBSA standards. To verify this, functional and application validation processes are applied to all transmitted data regardless of mode or type of data.

Functional Validation Process Functional validation is the first process that is applied to all data that is transmitted to the CBSA electronically. To ensure the transmitted data is syntactically correct, the CBSA EDI standard translator validates the following:

1. Segment syntax – the way a series of data elements or fields are strung together. 2. Data element syntax – specific fields 3. Transaction set syntax – the way a specific message is structured – e.g. a Conveyance or

Cargo transmission. 4. Functional group syntax – the way a transmission is structured.

The following describes the functional validation process flow that occurs when data is transmitted to the CBSA:

1. A CBSA client transmits data to the CBSA and the CBSA receives transmission(s) from the client.

2. The CBSA system authenticates the sender by verifying against the sender profile. This will confirm that the sender is valid for the specific message standard.

3. The CBSA accepts sender if authentication proves valid, or rejects sender if authentication proves invalid.

4. The CBSA verifies that: a) The transmission contains the appropriate number of segments. b) The data elements in each segment are present and that the structure of the Cargo or

Conveyance data meets syntax rules.

31

c) The size (min/max) and format (numeric/alphanumeric/coded values) requirements are met.

d) The segments are properly defined. e) The segments appear in proper order. f) Document contains the correct number of loops.

5. The CBSA converts the data to readable format for the next steps in processing. 6. The CBSA sends an optional Functional Acknowledgment Notice to the sender if no

syntax errors are found and the clients profile is configured to receive them. 7. The CBSA sends a Negative Functional Acknowledgment Notice with the appropriate

reason code to the sender if any syntax errors are found via the same route as the incoming transmission.

For both positive and negative Functional Acknowledgements, clients using the ANSI ASC X12 transmission standard will receive an ANSI X12 997 (4010, 5020, 5040) notice. For clients using the EDIFACT transmission standard, an EDIFACT GOVCBR (11B, 13A) or EDIFACT CUSRES (08A, 96A, 99B) notice will be returned in response.

Application Validation Process Once data has passed the functional validation process, the data must undergo the application validation process. For this validation process, the transmitted data is checked against CBSA system edits and various business rules (Part IV of this document). The following describes the application validation process flow that occurs after data has passed functional validation:

1. Syntactically correct data has been received by the CBSA. 2. The CBSA validates the data against business rules and system edits.

If the data passes the validation process, the CBSA sends an Application Acknowledgement Notice to the CBSA client to acknowledge the data has been accepted (with exceptions*).

3. If the data fails the validation process, the CBSA sends an Application Reject Notice to the transmitting CBSA client with the corresponding error code(s) informing clients of the discrepancy with the data.

For both Application Acknowledgement and Reject responses, with the exception of the Section 12.(1) Reported Notice, clients using the ANSI ASC X12 transmission standard will receive an ANSI X12 824 notice (4010, 5020, 5040). For the Section 12.(1) Reported Notice, clients using the ANSI X12 transmission standard will receive an ANSI X12 350 notice (5040). For clients using the EDIFACT standard, an EDIFACT GOVCBR (11B) or EDIFACT CUSRES (08A) notice will be returned in response.

32

* Exceptions to this are that no Application Acknowledgement Notices are sent for CACM, WACM, or any EDI Release document such as PARS or RMD.

Validation Errors When CBSA systems detect that data is invalid or has been omitted, a Functional or Application Reject Notice is sent to clients. These notices indicate the nature of any error and may identify the type of error and/or the data that was transmitted in error. Specific errors will cause only the specific transmission within which it occurred to be rejected. For example, if a transmission contains several Cargo submissions where one submission contains a syntax error, only that specific Cargo submission will be rejected. The exception to this occurs when an error is made in the functional group syntax, in which case the entire transmission will be rejected.

Functional Errors CBSA systems check for syntax errors in the segments, data elements, transactions sets, and functional groups. If there is a syntax error, a code or text will be returned in the Negative Functional Acknowledgment Notice indicating what the error is. To correct it, clients must transmit a new data transmission to replace the one with errors as CBSA systems cannot process nor store data with syntax errors. For a listing of ANSI X12 997 error codes, refer to Appendix J (AK3, AK4, AK5, AK9 segments). EDIFACT Functional Error message text can be found in the FTX segment of Appendix F.

Application Errors When data fails the application validation process, a 3-digit error code will be returned in the Application Reject Notice. The one exception is that the arrival application error codes produced in the EDIFACT 96A MIG will not contain the alpha character “R” and thus will only be two digits (e.g. R18 will be returned as 18*). To correct key application errors, a completely new data transmission needs to be sent to the CBSA. To correct non-key application errors, a changed transmission must be sent to the CBSA. For a listing of ANSI X12 824 and EDIFACT application error codes including arrival-related error codes that begin with “R”, refer to the Outbound Error Code table on CBSA’s website at http://cbsa.gc.ca/eservices/error-erreur.pdf . The “Group” column of this table identifies if the error is on a key data element. * An exception to this is if error code 34 is delivered, the actual error code is W34, not R34.

33

Insufficient Review Time Notification Scenario This notice serves as a warning message but is sent as an Application Reject Notice with error code V67 for certain Cargo and Conveyance transmissions, although the transmission may not have been rejected. Generated independently of any other Acknowledgement or Reject Notices, it is a completely separate notice that is based on the ETA of the Cargo or Conveyance, and no further action is required on the part of the CBSA client. The following is a description of the general process flow when data is transmitted outside of the prescribed timeframes:

1. Data is transmitted to the CBSA in violation of the reporting timeframes for that mode. 2. Once the data passes functional validation and undergoes application validation

processes (i.e. resulting in an Application Acknowledgment or Reject Notice), CBSA systems determine that the transmission time of the data does not comply with the requirements for the mode indicated.

3. An Application Reject Notice (separate transmission) with error code V67 is sent to the CBSA client who transmitted the data.

Manifest Forward Notification Scenarios These scenarios describe the transmission of a House Bill where SNPs have been identified to receive a Manifest Forward. The application validation process is incorporated into the scenarios, however it is assumed that all data transmitted has passed functional validation and is syntactically correct. SCENARIO 1 Manifest Forward Sent on Original Transmission:

1. A Freight Forwarder transmits House Bill data with identified SNPs. 2. If the data fails application validation, an Application Reject Notice is sent to the Freight

Forwarder for the House Bill and a Manifest Forward is not generated. 3. If the data passes application validation, the CBSA sends an Application

Acknowledgement Notice to the Freight Forwarder for the House Bill, and a Manifest Forward is sent to the SNPs and automatically to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-location Code of the House Bill if destined inland.

34

SCENARIO 2 Manifest Forward Sent on Changed Transmission:

1. A Freight Forwarder changes or amends previously transmitted House Bill data with identified SNPs.

2. If the data fails application validation, an Application Reject Notice is sent to the freight forwarder and a Manifest Forward is not sent.

3. If the data passes application validation, the CBSA sends an Application Acknowledgement Notice to the Freight Forwarder for the House Bill, and a Manifest Forward is sent to the SNPs and automatically to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-location Code of the House Bill if destined inland.

Document Not on File Scenarios These scenarios describe the submission of a Release document and House Bill Close Message, and assume both submitted documents have passed Functional and Application validation processes, and applicable Validation and Completeness Notices have been sent. SCENARIO 1 Transmission of an EDI PARS that quotes a MMC that is not on file:

1. A Broker transmits a PARS that quotes a MMC* that is not on file. 2. A Document Not on File Notice is sent to the Carrier identified by the CCN quoted on

the PARS. * In Deployment 4, clients will also receive a Document Not on File Notice if the EDI PARS quotes a paper Cargo. This does not however mean that requirements have not been met.

SCENARIO 2 Transmission of a House Bill Close Message that quotes a cancelled consolidated Prime Cargo:

1. A Carrier transmits a consolidated Prime Cargo to the CBSA that is not linked to a House Bill Close Message that quotes it as its previous CCN.

2. The Carrier transmits a Cancel request for the Prime Cargo which is accepted by the CBSA.

3. A Freight Forwarder transmits a House Bill Close Message that quotes the consolidated Prime Cargo (previous CCN) that was cancelled by the Carrier.

4. A Document Not on File Notice is sent to the Carrier (previous CCN quoted on the House Bill Close Message).

35

Completeness Notification Scenarios Once data has undergone validation processing, CBSA systems determine if there are established relationships between transmitted data that warrant the issuance of Completeness Notices pre-cargo Arrival. The following sample scenarios outline the notification processes for possible trade relationships that will generate Completeness Notices. These scenarios assume that all transmitted data has passed functional and application validation processes and applicable Validation Notices have been sent. For certain detailed sample EDI Message Maps, refer to Appendix S. SCENARIO 1 Consolidated MMC and House Bill Close Message: June 2013 Completeness Notices

1. A Carrier transmits consolidated MMC data to the CBSA. 2. If no related trade data is on file, a Not Matched Notice is sent to the Carrier. 3. A Freight Forwarder transmits a non-consolidated House Bill and a House Bill Close

Message indicating no further House Bills are to be transmitted. (This House Bill is not related to a Release document).

4. CBSA systems establish the relationship between the MMC and the House Bill Close Message.

5. Matched Notices are sent to both the Carrier (for the MMC) and Freight Forwarder (for the House Bill Close Message). A Not Matched Notice is also sent to the Freight Forwarder for the House Bill that is not linked to a Release.

Deployment 4 Completeness Notices

1. A Carrier transmits consolidated MMC data to the CBSA. 2. If no related trade data is on file, a Not Matched Notice is sent to the Carrier. 3. A Freight Forwarder transmits a non-consolidated House Bill and a House Bill Close

Message indicating no further House Bills are to be transmitted. (This House Bill is not related to a Release document).

4. CBSA systems establish the relationship between the MMC and the House Bill Close Message.

5. A Matched Notice is sent to the Freight Forwarder for the House Bill Close Message. A Cargo Complete Notice is sent to the Freight Forwarder for the unlinked House Bill, and to the Carrier for the MMC.

36

SCENARIO 2 Consolidated House Bill, House Bill Close Message, and EDI PARS/IID: June 2013 Completeness Notices

1. Freight Forwarder A transmits a consolidated House Bill to the CBSA. 2. No related House Bill Close Message is on file, therefore a Not Matched Notice is sent to

Freight Forwarder A. 3. Freight Forwarder B transmits a non-consolidated House Bill to the CBSA and House

Bill Close Message indicating no further House Bills are to be transmitted. (This House Bill is not related to a Release document)

4. CBSA systems establish the relationship between the consolidated House Bill and the House Bill Close Message.

5. Matched Notices are sent to Freight Forwarder A for the consolidated House Bill and to Freight Forwarder B for the House Bill Close Message. A Not Matched Notice is also sent to Freight Forwarder B for the non-consolidated House Bill.

6. Broker C transmits a PARS/IID that is related to the non-consolidated House Bill. 7. CBSA systems establish the relationship between the non-consolidated House Bill and

the PARS/IID. 8. Matched Notices are sent to the Broker for the PARS/IID and to Freight Forwarder B

for the non-consolidated House Bill. Deployment 4 Completeness Notices

1. Freight forwarder A transmits a consolidated House Bill to the CBSA. 2. No related House Bill is on file, therefore a Not Matched Notice is sent to Freight

Forwarder A. 3. Freight Forwarder B transmits a non-consolidated House Bill to the CBSA and House

Bill Close Message indicating no further House Bills are to be transmitted. (This House Bill is not related to a Release document.)

4. CBSA systems establish the relationship between the consolidated House Bill and the House Bill Close Message.

5. A Matched Notice is sent to Freight Forwarder B for the House Bill Close Message, and Cargo Complete Notices are sent to Freight Forwarder A for the consolidated House Bill and to Freight Forwarder B for the non-consolidated House Bill.

6. Broker C transmits a PARS/IID that is related to the non-consolidated House Bill. 7. CBSA systems establish the relationship between the non-consolidated House Bill and

the PARS/IID. 8. A Matched Notice is sent to the Broker for the PARS/IID. Document Package Complete

Notices are sent to Freight Forwarders A for the consolidated House Bill and to Freight Forwarder B for the non-consolidated House Bill.

37

SCENARIO 3 Non-consolidated MMC and EDI PARS: June 2013 Completeness Notices

1. A Broker transmits a PARS that quotes a CCN that is not on file. (A Not Matched Notice is not sent.)

2. A Carrier transmits a non-consolidated MMC. 3. CBSA systems establish the relationship between the non-consolidated MMC and the

PARS. 4. Matched Notices are sent to both the Carrier and the Broker.

Deployment 4 Completeness Notices

1. A Broker transmits a PARS that quotes a CCN that is not on file. 2. A Not Matched Notice is sent to the Broker for the PARS 3. The Carrier transmits the quoted non-consolidated MMC. 4. CBSA systems establish the relationship between the non-consolidated MMC and the

PARS. 5. A Matched Notice is sent to the Broker for the PARS, and a Document Package

Complete Notice is sent to the Carrier for the MMC. SCENARIO 4 Change to Non-consolidated Marine Cargo June 2013 Completeness Notices and Deployment 4 Completeness Notices

1. Prior to load, a Carrier changes a previously transmitted non-consolidated Marine Cargo that was linked to an EDI PARS and remains linked to the PARS after the change.

2. CBSA systems determine that though the version of the Marine Cargo has changed, the Completeness status remains the same and therefore no new Completeness Notices are sent to the Carrier or to the Broker.

Note: June 2013 and Deployment 4 Completeness Notices previously issued would be the same in this scenario as in scenario 3.

SCENARIO 5 Change to EDI PARS Linked to a Non-consolidated Rail Cargo June 2013 Completeness Notices

1. PARS X is transmitted and quotes CCN D which is on file. 2. Matched Notices are sent to the Broker and the Carrier for both documents. 3. The Broker transmits a change for PARS X to now quote CCN K. 4. CCN D becomes unlinked from PARS X and a Not Matched Notice is sent to Carrier D

for CCN D.

38

5. A Matched Notice is sent to Carrier K for CCN K. 6. CBSA systems determine that though the version of PARS X has changed, the

Completeness status of PARS X remains the same and therefore a new Matched Notice is not sent to the Broker.

Deployment 4 Completeness Notices 1. PARS X is transmitted and quotes CCN D, which is on file. 2. The Broker is sent a Matched Notice for PARS X, and Carrier D is sent a Document

Package Complete Notice for CCN D. 3. The Broker transmits a change for PARS X to now quote CCN K. 4. CCN D becomes unlinked from PARS X, and a Cargo Complete Notice is sent to Carrier

D for CCN D. 5. A Document Package Complete Notice is sent to Carrier K for CCN K. 6. CBSA systems determine that though the version of PARS X has changed, the

Completeness status of PARS X remains the same and therefore a new Matched Notice is not sent to Broker X.

SCENARIO 6 Cancellation of House Bill Close Message: June 2013 Completeness Notices

1. Consolidated House Bill P is linked to a House Bill Close Message that quotes non-consolidated House Bill T as a related CCN.

2. Matched Notices are sent to Freight Forwarder P and Freight Forwarder T for the consolidated House Bill P and the House Bill Close Message. A Not Matched Notice is also sent to Freight Forwarder T for House Bill T (House Bill is not related to a Release document).

3. Freight Forwarder T cancels the House Bill Close Message pre-arrival. 4. A Not Matched Notice is sent to Freight Forwarder P for the consolidated House Bill P.

Deployment 4 Completeness Notices

1. Consolidated House Bill P is linked to a House Bill Close Message that quotes non-consolidated House Bill T as a related CCN.

2. A Cargo Complete Notice is sent to Freight Forwarder P for the consolidated House Bill P (House Bill is not related to a Release document).

3. A Matched Notice is sent to Freight Forwarder T for the House Bill Close Message, and also a Cargo Complete Notice for House Bill T.

4. Freight Forwarder T cancels the House Bill Close Message pre-arrival. 5. A Not Matched Notice is sent to Freight Forwarder P for consolidated House Bill P.

39

SCENARIO 7 Amendment of a Non-consolidated MMC Destined Inland June 2013 Completeness Notices

1. A non-consolidated MMC that is destined inland is reported at FPOA and the description is then amended. (A Not Matched Notice was previously sent for the MMC, therefore a new Not Matched Notice is not generated because the Completeness status remains the same.)

2. An IID is transmitted to the CBSA prior to arrival at its Port of Destination and linked to the MMC.

3. A Matched Notice is sent to both the Carrier and the Broker for each document respectively.

Deployment 4 Completeness Notices

1. A non-consolidated MMC that is destined inland is reported at FPOA and the description is then amended. (A Cargo Complete Notice was previously sent for the MMC, therefore a new Cargo Complete Notice is not generated because the Completeness status remains the same.)

2. An IID is transmitted to the CBSA at its Port of Destination and linked to the MMC. 3. A Matched Notice is sent to the Broker for the IID and a Document Package Complete

Notice is sent to the Carrier for the MMC. A pictorial view of these relationships can be found in Part VI Figure 1. For additional notices that are sent through the Release Notification System with regard to Release documents, refer to Chapter 21: ACI/eManifest Release Notification System (RNS) Client Document of the ECCRD.

Section 12.(1) Reported Notification Scenarios This process describes when a S12.(1) Reported Notice is sent to clients upon the arrival of a Conveyance at FPOA, and assumes that all transmitted data has passed functional and application validation processes. The air, marine, and rail process:

1. A Carrier transmits a CACM to the CBSA. 2. A S12.(1) Reported Notice is generated and sent to the PNP of the Conveyance Report.

The highway process:

1. A Conveyance is reported at FPOA and is arrived in CBSA systems by a Border Services Officer (BSO).

2. A S12.(1) Reported Notice is generated and sent to the PNP of the Conveyance Report.

40

Disposition Notification Scenarios (Deployment 4) Once Cargo or Conveyances are reported and/or arrived in Canada, Disposition Notices are sent to clients. Under certain circumstances where the goods are destined for a Frontier port, if a Cargo achieves both reported and arrived status simultaneously, the Reported Notice may be suppressed, and only the Arrived Notice be sent. In addition, there may be a delay in sending the Deployment 4 Released Notice, which will result in a Deployment 4 Held for CBSA Notice being issued to clients in the brief interim. As a result, clients are advised to wait a few minutes to verify that the shipment is indeed held. For these scenarios, it is assumed that all transmitted data has passed functional and application validation processes and the applicable Validation Notices have been sent. The following details only those Disposition Notices that will be generated as of Deployment 4, and not all applicable Deployment 4 Notices are detailed in each scenario. For additional notices that are sent through the Release Notification System with regard to Release documents, refer to Chapter 21: ACI/eManifest Release Notification System (RNS) Client Document of the ECCRD.

Reported and Arrived Notices SCENARIO 1 Highway Shipment Destined Inland:

1. Cargo, Conveyance, and Release data is transmitted to the CBSA prior to arrival of the Conveyance.

2. The Conveyance is arrived at FPOA by a BSO, and the associated Cargo achieves reported status.

3. A Reported Notice is sent to the PNP of the Cargo, and to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-location Code of the Cargo.

4. The Cargo is arrived at a warehouse through the transmission and acceptance of a WACM.

5. Arrived Notices are sent to the PNP of the Cargo, and to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-location Code of the Cargo.

SCENARIO 2 Air/Marine/Rail Shipment Destined for FPOA:

1. Cargo, Conveyance, and Release data is transmitted to the CBSA prior to arrival of the Conveyance.

2. A CACM is transmitted for the Conveyance, and the associated Cargo achieves reported and arrived status.

3. An Arrived Notice is sent to the PNP of the Cargo.

41

Released Notice SCENARIO 1 Cargo Destined for FPOA (Paper Release with no Port of Release Sub-location Code):

1. A paper Release document is presented to the CBSA upon arrival to Canada. 2. The associated Cargo is arrived at FPOA and a release determination is made on the

shipment. 3. A Released Notice is sent to the Account Security Holder (ANP) as defined by the

Account Security Number on the Paper Release, and to the Carrier (ANP) as defined by the Carrier Code of the CCN quoted on the Paper Release.

SCENARIO 2 Cargo Destined Inland (Electronic Release with Port of Release Sub-location Code):

1. Cargo, Conveyance, and Release data is transmitted to the CBSA prior to arrival of the Conveyance and a release determination is made on the shipment.

2. The Conveyance is arrived at FPOA and associated Cargo is reported. 3. A Reported Notice is sent to the PNP of the Cargo, and to the Warehouse Operator

(ANP) as defined by the Port of Destination Sub-location Code of the Cargo document. 4. The Cargo is arrived at a warehouse through the transmission and acceptance of a

WACM. 5. An Arrived Notice is sent to the PNP of the Cargo, and to the Warehouse Operator

(ANP) as defined by the Port of Destination Sub-location Code of the Cargo document. 6. Released Notices are sent to the PNPs of the Cargo and the Release document, as well

as to the Warehouse Operator (ANP) as defined by the Port of Release Sub-location Code on the Release*.

*Note: In this instance, if there was no Port of Release Sub-location Code listed on the Release document, the Released Notice would have been sent to the Sub-location from the Cargo document.

Authorized to Deliver Notice (CSA only) SCENARIO 1 Destined for FPOA:

1. A CSA paper Highway Clearance document that contains a CCN and an Account Security Number is submitted to the CBSA.

2. The shipment is arrived and an Authorized to Deliver decision is made on the shipment.

3. An Authorized to Deliver Notice is sent to the Carrier (ANP) referenced by the Carrier Code used to create the CCN, and to the Account Security Holder (ANP).

42

SCENARIO 2 Destined FPOA:

1. A CSA MMC is transmitted prior to arrival of the Conveyance. 2. The Conveyance and associated Cargo is reported and arrived at FPOA and the Arrived

Notice is sent to the PNP of the Cargo. 3. An Authorized to Deliver Notice is sent to the PNP of the MMC, and to the Warehouse

Operator (ANP) as defined by the Port of Destination Sub-location Code on the MMC.

SCENARIO 3 Destined Inland:

1. Cargo and Conveyance data is transmitted to the CBSA prior to arrival of the Conveyance.

2. The Conveyance is arrived and the Cargo is reported, and a Reported Notice is sent to the Carrier for the Cargo.

3. A CSA Non-Highway Clearance is transmitted to the CBSA and the shipment is arrived and achieves Authorized to Deliver status.

4. An Arrived and an Authorized to Deliver Notice is sent to the PNP of the Cargo, the PNP of the CSA Non-Highway Clearance, and to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-location Code on the Cargo document.

SCENARIO 4 Destined Inland (no Cargo on file):

1. A CSA Non-Highway Clearance is transmitted to the CBSA and the shipment is arrived.

2. The shipment achieves Authorized to Deliver Status. 3. An Authorized to Deliver Notice is sent to the PNP of the CSA Non-Highway

Clearance.

Held for CBSA Notice SCENARIO 1 Destined for FPOA:

1. Cargo, Conveyance, and Release data is transmitted to the CBSA prior to arrival of the Conveyance. A Held for CBSA determination is made on the shipment.

2. The Conveyance and associated Cargo is arrived at FPOA and the Arrived Notice is sent to the PNP of the Cargo.

3. Held for CBSA Notices are sent to PNPs of the Cargo and the Release document.

43

SCENARIO 2 Destined Inland:

1. Cargo, Conveyance, and Release data is transmitted to the CBSA prior to arrival of the Conveyance.

2. The Conveyance is arrived at FPOA and associated Cargo is reported. A Reported Notice is sent to the PNP of the Cargo, and to the Warehouse Operator as defined by the Port of Destination Sub-location Code of the Cargo.

3. A Held for CBSA determination is made on the shipment. 4. The Cargo is arrived at a warehouse through the transmission and acceptance of a

WACM, and Arrived Notices are sent to the PNP of the Cargo, and to the Warehouse Operator as defined by the Port of Destination Sub-location Code of the Cargo.

5. Held for CBSA Notices are sent to the PNPs of the Cargo and the Release document, as well as to the Warehouse Operator as defined by the Port of Destination Sub-location Code of the Cargo.

SCENARIO 3 Destined Inland - Release not in good standing:

1. Conveyance and Release data is transmitted to the CBSA prior to arrival of the Conveyance, and the Release is in reject status. (No Cargo document has been transmitted.)

2. The Conveyance is arrived at FPOA. 3. A Held for CBSA determination is made on the shipment. 4. A WACM is transmitted and accepted for the Cargo quoted on the Release document*. 5. A Held for CBSA Notice is sent to the PNP of the Release document.

*Note, as of Deployment 5, this may no longer occur as Cargo may not be arrived without the Cargo being on file.

44

Deconsolidation Notice SCENARIO 1 Consolidated Rail MMC destined for FPOA:

1. A Consolidated MMC is transmitted to the CBSA prior to the arrival of the related Conveyance.

2. Non-Consolidated House Bill X and then a House Bill Close Message 1 that quotes the consolidated MMC as its previous CCN are transmitted to the CBSA.

3. The Related Conveyance is transmitted to the CBSA. 4. The Conveyance is arrived at FPOA (through CACM), and the consolidated MMC

achieves arrived and acquitted status. Non-consolidated House Bill X achieves reported and arrived status.

5. An Arrived Notice is sent to the PNP of the MMC, and Reported and Arrived Notices are sent to the PNP of House Bill X, and to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on the House Bill X.

6. Deconsolidation Notices are sent to the PNP of the MMC, the PNP of the House Bill Close Message 1, and the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on the MMC.

45

SCENARIO 2 Consolidated Marine Cargo destined inland:

1. A consolidated Marine Cargo document is transmitted to the CBSA prior to the arrival of the related conveyance.

2. Related non-consolidated House Bill T and consolidated House Bill Q are also transmitted to the CBSA prior to the arrival of the related Conveyance.

3. House Bill Close Message 1 that quotes consolidated the Marine Cargo as its previous CCN is transmitted to the CBSA.

4. Non-consolidated House Bill P followed by House Bill Close Message 2 are transmitted as well.

5. The Related Conveyance is then transmitted to the CBSA. 6. The Conveyance is arrived at FPOA (through CACM), and the Marine Cargo and

House Bills T, Q, and P all achieve reported status. Reported Notices are sent to the PNP of the Marine Cargo, and House Bills T, Q and P, and to the Warehouse Operators (ANP) as defined by the Port of Destination Sub-locs on the Marine Cargo and House Bills T, Q, and P.

7. The Marine Cargo is arrived at a warehouse through the transmission and acceptance of a WACM, and the Marine Cargo achieves arrived and acquitted status. An Arrived Notice is sent to the PNP of the Marine Cargo, and to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on the Marine Cargo.

8. Deconsolidation Notices are sent to the PNP of the Marine Cargo, the PNP of the House Bill Close Message 1, and the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on the Marine Cargo.

9. House Bills T and Q are arrived (through WACMs) and Arrived Notices are sent to the PNP of these House Bills as well as to the Warehouse Operators (ANP) as defined by the Port of Destination Sub-locs on House Bills T and Q.

10. House Bill Q achieves acquitted status and Deconsolidation Notices are sent to the PNP of House Bill Q, the PNP of the House Bill Close Message 2, and the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on House Bill Q.

11. House Bill P is then arrived at a warehouse through the transmission and acceptance of a WACM, and achieves arrived status. An Arrived Notice is sent to the PNP of House Bill P, as well as to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on House Bill P.

46

47

SCENARIO 3 Consolidated Air Cargo destined for FPOA with House Bills destined inland:

1. A consolidated Air Cargo document is transmitted to the CBSA prior to the arrival of the related conveyance.

2. Related non-consolidated House Bill T (destined for FPOA) and consolidated House Bill Q (destined inland) are also transmitted to the CBSA prior to the arrival of the related Conveyance.

3. House Bill Close Message 1 that quotes consolidated the Air Cargo as its previous CCN are transmitted to the CBSA.

4. Non-consolidated House Bill P (destined inland) followed by House Bill Close Message 2 are transmitted as well.

5. The Related Conveyance is then transmitted to the CBSA. 6. The Conveyance is arrived at FPOA (through CACM), and the Air Cargo and House

Bill T achieve arrived status. House Bills Q and P both achieve reported status. 7. Arrived Notices are sent to the PNP of the Air Cargo and the PNP of House Bill T.

Reported Notices are sent to the PNPs of House Bills Q and P, and to the Warehouse Operators (ANP) as defined by the Port of Destination Sub-loc on House Bills Q and P.

8. The Air Cargo achieves acquitted status and Deconsolidation Notices are sent to the PNP of the Air Cargo, the PNP of the House Bill Close Message 1, and the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on the Air Cargo.

9. House Bill Q is arrived at a warehouse through the transmission and acceptance of a WACM and achieves arrived and acquitted status. An Arrived Notice is sent to the PNP of House Bill Q, and to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on House Bill Q.

10. House Bill Q achieves acquitted status and Deconsolidation Notices are sent to the PNP of House Bill Q, the PNP of the House Bill Close Message 2, and the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on House Bill Q.

11. House Bill P is then arrived at a warehouse through the transmission and acceptance of a WACM. An Arrived Notice is sent to the PNP of House Bill P, and to the Warehouse Operator (ANP) as defined by the Port of Destination Sub-loc on House Bill P.

48

49

PART VI – FIGURES, CHARTS, and APPENDICES

50

FIGURE 1 – Completeness Notice Relationships

Non-Consolidated

House Bill T

Consolidated

Cargo XYZ

Non-Consolidated

House Bill X

Consolidated

House Bill Y

House Bill

Close 1

PARS XHouse Bill

Close 2

Consolidated

House Bill Z

IID A

This figure outlines the document relationships that will generate Completeness Notices when they are received pre-cargo arrival and accepted by the CBSA. Consolidated House Bill Z, once transmitted and accepted, will receive a Not Matched Notice (for both June 2013 and Deployment 4 Completeness Notices). Note: RMD and OGD RMD are not a part of the Completeness Notice relationship as they are post-arrival documents.

51

CHART 1 – eManifest Deployment 4 Primary Notify Party Notices by Document Type

This chart displays the various Deployment 4 Notices that PNPs are eligible to receive based on document type.

DOCUMENT TYPE

C O M P

R P T D

A R V D

R L S D

A 2 D E L

H E L D

D E C O N

NM M CC DPC CBSA

Legacy Marine Cargo Consolidated

Y Y Y Y Y Y

Y

Legacy Marine Cargo Non-consolidated

Y Y Y Y Y Y Y

Legacy Air Cargo Consolidated

Y Y Y Y Y Y

Y

Legacy Air Cargo Non-consolidated

Y Y Y Y Y Y Y

Empty Marine Container

Y

Legacy Multi-Modal Cargo Consolidated

Y Y Y Y Y Y

Y

Legacy Multi-Modal Cargo Non-consolidated

Y Y Y Y Y Y Y

Consolidated House Bill Y Y Y Y Y Y

Y

Non-consolidated House Bill Y Y Y Y Y Y

House Bill Close Message Y Y

Y

PARS - EDI Y Y

Y

Y

OGD PARS - EDI Y Y

Y

Y

RMD - EDI

Y

Y

OGD RMD - EDI

Y

Y

Integrated Importer Declaration (IID)

Y Y

Y

Y

CSA – Non-Highway EDI

Y

COMP –Completeness NM - Not Matched M – Matched CC – Cargo Complete DPC – Document Package Complete

RPTD – Reported ARVD – Arrived RLSD – Released A2DEL – Authorized to Deliver DECON - Deconsolidation

52

CHART 2 – eManifest Deployment 4 Primary and Automated Notify Party Notices by Client Type

This chart represents the Deployment 4 Notices that PNPs and ANPs are eligible to receive.

CLIENT TYPE COMP

N O F

R P T D

A R V D

R L S D

A 2 D E L

H E L D

D E C O N

NM M CC DPC CBSA

Primary Notify Party

Carriers Y Y Y Y Y Y Y Y Y Y

Freight Forwarders Y Y Y Y Y Y Y Y Y

Account Security Holders

Y Y Y Y Y

Automated Notify Party

Carriers Y Y Y

Freight Forwarders Y Y

Account Security Holders

Y Y

Warehouse Operators Y Y Y Y Y Y

COMP –Completeness NM - Not Matched M – Matched CC – Cargo Complete DPC – Document Package Complete NOF – Document Not on File

RPTD – Reported ARVD – Arrived RLSD – Released A2DEL – Authorized to Deliver DECON - Deconsolidation

53

List of Appendices Appendix A – Glossary of Terms for Notices Appendix B – Status Notice Data Elements (Deployment 4 only) Appendix D – Code Tables for Notices Appendix E –Legend, Use of Special Characters, and Possible Data Loss or Truncation Appendix F – EDIFACT 96A, 99B, 08A, 11B Response Message Appendix G – EDIFACT GOVCBR 11B S12.(1) Response Appendix J – ANSI ASC X12 997, 824, 350 S12.(1) Reported Notice 5040 Appendix M – EDIFACT GOVCBR 11B House Bill Manifest Forward Appendix N – ANSI ASC X12 309 5040 House Bill Manifest Forward Appendix O – EDIFACT GOVCBR 13A Status Notice (Deployment 4 only) Appendix P – ANSI ASC X12 350 7010 Status Notice (Deployment 4 only) Appendix S - Status Notice Message Implementation Guide Samples (Deployment 4 only)

54

PART VII – CONTACTS For questions on EDI registration and requirements for receiving notices, please contact the following Unit:

Technical Commercial Client Unit (TCCU)* Canada Border Services Agency Place Vanier, Tower B 355 North River Road, 6th floor Ottawa, ON K1A 0L8 EDI Hotline: 1.888.957-7224 (option 1 for EDI / Option 2 for Technical Portal Assistance) 1-613-946-0762 for overseas callers between 08:00 to 17:00 ET Fax: 343.291.5482 E-mail: TCCU-USTCC@cbsa-asfc.gc.ca Website: http://cbsa-asfc.gc.ca/eservices/ * Formally known as the Electronic Commerce Unit (ECU) and the Technical Support Unit (TSU)

General eManifest Questions: eManifest Help Desk E-mail: eManifest-manifestelectronique@cbsa-asfc.gc.ca