To ensure EDI transactions sent to the Department, 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 the Department for EDI communications.
NOTE : For use with the Integrated Cargo System an interchange
may not exceed 10MB in size.
Message Management Topics
Testing and Development
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.
Email
icsbus@abf.gov.au
E-mail Structure
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 the Department's PKI requirements.
The subject line in e-mails carrying EDI interchanges to and from the Department 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.
-
NOTE: If plain text responses have been requested spaces will be present in the outbound email subject line.
The file name of the attachment for Inbound e-mails (to the Department) will be:
<Interchange Creator ID>_<Interchange Control Reference Number>.edi
The file name of the attachment for Outbound e-mails (from the Department) will be:
<Recipient Site ID>_<Interchange Control Reference Number>.edi
For Inbound e-mails (to the Department) the Recipient Site ID will always be the Customs ID, for Outbound (from the Department) the Interchange Creator ID will always be the Customs ID.
E-mail Address
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.
The Department's addresses will be included in this guide and published on the the Department's CMR web site when available.
Reporting and Recording of Gateway Times
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.
Format of Times for EDI Messaging
The valid reporting range for times is 0000 - 2359. 2400 is
NOT a valid time.
Document Naming Convention
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.
Batching of Messages
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 the Department will be one message.
Clients can specify that their outbound messages are to be batched by the Department 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 the Department can be greater than one, as described above, the current advice from the Department 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.
In addition the message count per Interchange sent by the Department to Industry can also be set to greater than one, as described above, the current the Department advice is to recommend to clients to leave this count at the default value of one. A single message interchange provides the best outcome in terms of overall efficiency of interactions between your system and the Department's Cargo systems.
Interchange Acknowledgement
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 the Department) must include element 0031 (Acknowledgement Request) in the UNB Interchange header.
Responses to Inbound Messages.
Overview
The Department 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:
Mandatory/conditional rules for each element/field
eg. fields that are defined as mandatory must be present in the message.
Specific type checks for each element/field
eg. numeric fields are validated to have only numeric values.
Checks on the field lengths supplied in a message, including fixed length and variable length fields
eg. fields that have fixed lengths defined must not contain values that have varied lengths.
Repeat loops for fields and groups of fields
Some fields (and groups of fields) can be repeated a defined number of times. CCF checks that repeats are within the defined limits.
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 the Department, 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 the Department after a defined timeout period. This action should be repeated a defined maximum number of times.
CONTRL messages received by the Department will not be acknowledged.
Responses to the CCF/ICS for Outbound Messages
CONTRL messages sent by the Department are not to be acknowledged.
The Department's 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 the Department after a timeout period. This will be repeated a defined number of times. In order to avoid resends and hence to reduce message traffic the Department recommends that an ICONTROL is sent to all Department 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 the Department.
- As detailed in Batching Messages it is advised that ICONTROL messages not be sent with other business messages.
Interchange Sequencing
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 the Department.
The Department will maintain a separate sequence for each Interchange Creator.
The Department 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).
Message Sequencing
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 the Department, by message type, in the order they are contained within the Interchange.
The Department's 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.
Rounding
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.
Eg.
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.
Eg.
5.554 = 5.55
5.663 = 5.66
5.772 = 5.77
Negative Values
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.
Notes
Interchanges sent via the Internet may arrive in a different order to when they left the sender (or even go missing). The Department 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.
Users sending test messages to the Department should be aware that interchanges sent to production with the test indicator set will not be processed by the Department. Interchanges sent to the development/test system without the test indicator set will be processed by the Department, and the resulting response will include a test indicator in the interchange header.
V2.4 15 AUG 2011
