Return to Index
To ensure EDI transactions sent to Customs, and their responses, are processed accurately and meaningfully the CCF will apply common messaging standards for all ICS functions. This section defines the rules and protocols for implementation by both industry and Customs for EDI communications.
NOTE: For use with the Integrated Cargo System an interchange may not exceed 10MB in size.
Message Management Topics
The ICS will provide a facility for testing and development alongside production. This is to support initial and ongoing development and testing of the ICS.
External users wishing to gain access to test and / or develop should contact the ICS Business Support Unit via email.
ICS EDI Interchanges will be carried as attachments to SMTP e-mails in S-MIME format.
E-mails are to be formatted as follows:
One attachment per e-mail.
One Interchange per attachment.
No text to be included in the body of the e-mail . E-mails with text will be rejected without acknowledgement.
The e-mail body and attachment will be encrypted and signed as per Customs PKI requirements.
The subject line in e-mails carrying EDI interchanges to and from
Customs will contain plain text data identifying the Interchange.
The data will comprise:
<Interchange Creator ID>_<Interchange Control Reference Number>_<Recipient Site ID>
They will be inserted in the subject line separated with the underscore character with no leading, trailing or included spaces or other symbols. These values are also contained in the Interchange UNB Segment.
The file name of the attachment for Inbound e-mails (to Customs)
<Interchange Creator ID>_<Interchange Control Reference Number>.edi
The file name of the attachment for Outbound e-mails (from Customs)
<Recipient Site ID>_<Interchange Control Reference Number>.edi
For Inbound e-mails (to Customs) the Recipient Site ID will always be the Customs ID, for Outbound (from Customs) the Interchange Creator ID will always be the Customs ID.
Interchanges will be transmitted as an SMTP e-mail attachment to an established e-mail address using TCP/IP protocols.This format and address will be common for communicating with the ICS.
Customs addresses will be included in this guide and published on the Customs CMR web site when available.
Processing times for the CCF and external users should be reported as the date and time for the place of processing.
The CCF will use AEST/AEDST to record dates and times in the UNB segments of Interchanges.
The valid reporting range for times is 0000 - 2359. 2400 is NOT a valid time.
The Data item to be reported for document naming is the document name for the message type. Eg, Air Cargo Report document name usage is AIRCR.
Each Interchange will contain one or more EDI Messages, formatted according to the UN/EDIFACT Version 3 Syntax rules (ISO 9735).
The number of messages in an Interchange should be limited so that the resulting e-mail attachment is not so large as to become difficult to transport or process. For use with the Integrated Cargo System an interchange may not exceed 10MB in size.
Incoming interchanges should not contain both business messages and control (ICONTROL) messages.
The default size of outbound Interchanges from Customs will be one message.
Clients can specify that their outbound messages are to be batched by Customs on a time and/or message count basis.
Messages can be accumulated for a specified time period or until a specified count is reached, or both, whichever occurs first.
Accumulated Messages will be formed into an Interchange, attached to an e-mail and sent to the client at their nominated e-mail address for responses.
The time setting for accumulating outbound messages will be limited to 10 minutes maximum with a default of zero.
The accumulation count setting will be limited to a maximum of 999 with a default of one.
Response Message batching parameters will be accessible for modification by authorised clients via the Client Register.
Although the message count per Interchange sent by Industry to Customs can be greater than one, as described above, the current advice from Customs is to recommend to clients to use only one. Interchanges containing one message only are processed more efficiently than interchanges containing more than one message.
The CCF will respond to all valid Interchanges, containing business transactions, by sending a CONTRL message. The CONTRL message will notify users of gateway receipt and syntactical checking, including limited error reporting.
Interchanges initiating or responding to a business transaction (to and from Customs) must include element 0031 (Acknowledgement Request) in the UNB Interchange header.
Customs responds to inbound EDI messages with two distinct message types, these are CONTRL messages and Error/Response Messages.
CONTRL messages are generated by the CCF in response to all inbound interchanges.
The CONTRL message acknowledges receipt of the interchange and provides
information about the acceptance/rejection of the interchange based on its
compliance/non-compliance with EDIFACT syntax.
At the CCF CONTRL message level no validation of “business” information is undertaken only compliance with EDIFACT syntax is checked.
After a message has passed through EDIFACT processing (ie EDI validation and the transformation into XML/Business Specific Format (BSF) is completed) CCF undertakes second level validation of the content of the BSF message before passing it through to ICS. BSF represents the format in which information is processed within the ICS.
Second level CCF validation is based on rules provided in the ICS documentation for each release which defines the specific structure and format of each BSF message. The validation encompasses basic syntax checks, including the following:
If any fields/elements within a message fail a validation check CCF will
generate an error response to send back to the client. The response message
will be labelled as a genuine response to the inbound message type received
(eg CTOREC will be responded to with CTORECR).
Apart from CCF generating its own Document Message Number (prepended with "CCF") a CCF Error/Response message be the same in format and content as the equivalent ICS response message.
If a message has passed CCF primary EDIFACT syntax validation and secondary BSF validation the information is then passed to the ICS where is will undertake ICS “business level” validation.
The ICS may then generate a CUSRES response message containing errors or
a business response to the inbound message. Eg. EXD - EXDR
General Response Business Rules.
The CCF will acknowledge received Interchanges with a CONTRL Response message sent to the Interchange Creators sending address.
Duplicate Interchanges will be responded to with a CONTRL response message but not processed. Duplicate interchanges will be identified by the interchange creator site id and the ICR.
Interchanges using an incorrect format, or lacking a valid digital signature and certificate will be recorded by Customs, but not acknowledged, or processed.
Where Message signatories are not registered on the Customs Client Register a CONTRL error acknowledgement (Code 23) will be sent to the sending address to advise that the signatory is unknown.
The Interchange Control Reference (ICR) from the received UNB will be used to identify the Interchange being acknowledged.
Interchanges may be rejected with a CONTRL error if major structural faults are found.
The CONTRL Response message will contain notification of all Messages in violation of EDIFACT syntax within the Interchange.
All error free messages reported in the CONTRL response have been passed to the ICS for processing.
The CONTRL Response message will use the senders MRN to identify Messages in error within Interchanges. Messages that are not in error will be passed to the ICS for processing.
Error checking at the CCF is limited to structure and syntax, not data content. Errors relating to business content will be responded to by the ICS, in a CUSRES message.
Unacknowledged Interchanges should be re-sent to Customs after a defined timeout period. This action should be repeated a defined maximum number of times.
CONTRL messages received by Customs will not be acknowledged.
CONTRL messages sent by Customs are not to be acknowledged.
Customs EDI Interchanges responding to a business transaction are to be acknowledged on receipt and safe storage with an ICONTRL Message.
Interchanges not acknowledged with an ICONTROL message will be resent by Customs after a timeout period. This will be repeated a defined number of times. In order to avoid resends and hence to reduce message traffic Customs recommends that an ICONTROL is sent to all Customs messages except the CONTROL message.
Duplicate Interchanges should be responded to with a ICONTRL message but not processed.
The ICONTRL Message will reference the Interchange Owner identity and the Interchange Control Reference from the Interchange UNB received from Customs.
Interchanges are to be numbered sequentially via the Interchange Control Reference (ICR in the UNB at 0020) starting at 1 and incrementing by 1 for each new Interchange.
Interchange Creators are to maintain their own (ICR) sequence, which is to wrap around at 99999999999999 (n14).
Interchanges with an invalidly formatted ICR will not be responded to by Customs.
Customs will maintain a separate sequence for each Interchange Creator.
Customs will process EDI Interchanges in the order they are received by the CCF, on an Interchange Owner (client-by-client) site basis.
The CCF will not wait for a CONTRL acknowledgement to the previous Interchange sent to that client before sending the next Interchange.
Interchanges not acknowledged will be resent when the timeout occurs (see Batching of Messages).
Messages within Interchanges are to be numbered sequentially within the Interchange, using the Message Reference Number (MRN in the UNH at 0062). Hence for each Interchange sent the first message will be numbered 1 and incremented by 1 for subsequent Messages contained in the Interchange. The site ID, ICR and the MRN will be needed to identify a particular Message from any one Interchange Creator (client site).
The Messages within Interchanges will be processed by Customs, by message type, in the order they are contained within the Interchange.
Customs responses may not be sent in the order that the originating Message was received. Responses will be sent to the client, as they are made available to the CCF for transmission.
Where the third integer to the right hand side of a decimal indicator is 5 or greater, then the second integer to the left of the decimal point shall be increased by 1 and the third shall be deleted.
5.555 = 5.56
5.668 = 5.67
5.779 = 5.78
Where the third integer to the right hand side of a decimal indicator is 4 or less, then the second integer to the left of the decimal point shall remain unchanged and the third shall be deleted.
5.554 = 5.55
5.663 = 5.66
5.772 = 5.77
Numeric data element values shall be regarded as positive. Although conceptually a deduction is negative, it shall be represented by a positive value and such cases shall be indicated in the data elements directory.
If a value is to be indicated to be negative, it shall in transmission be immediately preceded by a minus sign e.g. -112
The minus sign should not be counted when computing the maximum field length of a data element. However, allowance has to be made for the character in transmission and reception.
Interchanges sent via the Internet may arrive in a different order to when they left the sender (or even go missing). Customs will process in the order of receipt; hence if multiple Interchanges, without intervening CONTRL response messages, are sent some erroneous processing sequences may be attempted. Such errors will receive a CUSRES error response from the ICS application.
Responses to clients sent via the Internet could result in out of sequence replies arriving, particularly Status messages. Client software should be aware of this possibility and process accordingly. For example only record a new Status for an entry if it was sent after (based on time and date) the last Status recorded for the same entry on the client database.
To increase efficiency of transmission and to limit processing overheads at reception, it is recommended that only the significant characters of data elements and component data elements defined as being variable length, should be transmitted. It should be pointed out however, that recipients must have the capability of accepting either suppressed or non-suppressed variable length data, accepting however that processing overheads will be increased if suppression is not used.
V2.4 15 AUG 2011