ICS2 Error Codes

72

Explanation:

 The operation attempted (for example an amendment or cancellation) is not allowed because the ENS/Entry Summary Declaration is not in the required lifecycle state.

Reason:

 ENS filing in a wrong state.

Step-by-step solution:
 

1. Check the current ENS lifecycle status (accepted, lodged, etc.).
2. Confirm the operation allowed for that status in your ICS2 interface guide.
3. If the ENS is in an earlier state, wait or re-submit the correct message type (e.g., use amendment flow only when amendment is permitted).
4. If the state looks incorrect, retrieve prior messages/notifications for this ENS and raise a support ticket with the timestamps and message IDs.

 80

Explanation:
 
 The transport document number supplied in the message does not match any known transport document reference for the expected context (master/house) for that Declarant or filing.
 

Reason:

 Unknown Transport Document Reference.

Step-by-step solution:

1. Verify the transport document number (B/L, AWB, CMR) against the carrier paperwork.
2. Ensure you are populating the correct field (master vs house).
3. If correct, check whether the transport document was filed under a different Declarant or with a different reference; correct the declarant or reference as necessary.
4. Contact carrier/shipper if the document number cannot be found.

81

Explanation:
 
 The Transport Document Number for the consignment has already been used in another Entry Summary Declaration by the same Declarant (uniqueness rules for master and house levels violated).
 

Reason:
 
 Duplicate Transport Document Reference.
 

Step-by-step solution:
 

1. Note the Error Generating Field Path (pointer) in the rejection to identify the exact consignment and value (e.g., Consignment[transportDocumentNumber=pc12233]).
2. Search prior submissions for the same Declarant and transportDocumentNumber.
3. Confirm correct transport doc number from shipment paperwork.
4. If it was a data entry error, replace with the correct unique number and resubmit.
5. If the prior filing must be corrected instead, follow amendment/cancellation process rather than creating a duplicate.

90

Explanation:
 
 The MRN referenced in the message cannot be found (it may be mistyped, belong to another system, or not yet created).
 

Reason:
 
 Unknown MRN (Master Reference Number).
 

Step-by-step solution:
 

1. Verify the MRN format and digits against the paperwork.
2. Confirm which authority issued the MRN and that it exists in the target system.
3. If the MRN should exist, provide the MRN and related message IDs to ICS2/iCustoms support for lookup.

91

Explanation:
 
 The MRN in the submission already exists for the same filing context, causing a uniqueness conflict.
 

Reason:
 
 Duplicate MRN.
 

Step-by-step solution:
 

1. Search system for the prior MRN usage.
2. If new submission was intended as an amendment, use amendment flow referencing that MRN rather than creating a new filing.
3. If MRN duplication is unexpected, escalate with prior submission details to support.

92

Explanation:
 
 Messages (lifecycle events) were sent in the wrong order (for example an amendment was sent before the original message was acknowledged). ICS2 expects a defined message sequence.
 

Reason:

 Message out of sequence.
 

Step-by-step solution:
 

1. Check message timestamps and response notifications to confirm sequence.
2. Re-send the correct preceding lifecycle message if missing (e.g., send initial ENS before amendment).
3. If sequence cannot be reconstructed, contact support with full message log. 
   
    

94

Explanation:
 
 The LRN supplied for a house/master level is already used for another filing and violates uniqueness constraints.
 

Reason:
 
 Duplicate LRN (Local Reference Number).
 

Step-by-step solution:
 

1. Confirm the LRN value and its prior use.
2. If LRN was re-used accidentally, assign a new unique LRN and resubmit.
3. If LRN collision is due to system error, provide examples to support for correction.
   
    

100

Explanation:
 
 The submission contains missing mandatory fields, stop words, code list violations, formatting issues, or other data-quality problems that prevent acceptance. ICS2 enforces strict data quality (including stop-word lists).
 

Reason:
 
 Not satisfactory data quality (insufficient/invalid data).
 

Step-by-step solution:
 

1. Review the IE3N01/IE3N99 error details to identify missing/invalid elements.
2. Check against the latest ICS2 data guides and stop-word lists.
3. Correct the fields (mandatory values, format, code lists) and revalidate locally.
4. Resubmit once all data-quality issues are fixed.
   
    

102

Explanation:
 
 The message contains characters not permitted by the ICS2 message encoding rules (for example control characters or unsupported Unicode).
 

Reason:
 
 Not allowed Unicode character.
 

Step-by-step solution:
 

1. Inspect the field indicated in the pointer for non-printable or special characters.
2. Remove or replace illegal characters (use basic ASCII where required or the approved character set).
3. Re-encode the message and re-submit.