Reading a transhipper or custodian file

Open it. CSN filing → SCMTR JSON upload, drop it on, and every field is named and explained from ICEGATE's own guide.

Neither message is yours to file. They reach you anyway, and almost always for one of three reasons: a CFS has emailed you their file and asked what it says; a transhipper has quoted a refusal at you that turns out to be about your CSN; or you are being asked to confirm that what the yard reported matches what you declared.

Which of the two am I holding?

The file name says so, in its second segment.

If the name has been changed in transit, the same two values are inside the file at headerField.messageID — and you do not need to look, because the platform reads it for you.

What each reporting event means

The third segment of the name is the event, and it is the single most useful thing on the file: it says what happened, not just which party is speaking.

The transhipper's three — one movement, reported at each end:

One transhipper is responsible for the whole movement and executes the bond, whatever the modes of transport involved.

The custodian's five, plus one they receive:

Which of it actually concerns me?

Most of it does not. Three things usually do.

The cargo identification number. A CUCHE01 stuffing report and a TRCHE01 ASR both reference an mcinPcin — the MCIN or PCIN that came from a customs filing. When that is your PCIN, the movement is against your cargo, and an error on their message about that field is a question about your CSN.

The containers. The container number is containerID on a transhipper's file and equipmentID on a custodian's — the two guides name the same thing differently — alongside equipmentSize and equipmentSealNumber. Check them against the boxes on your own filing. A container number that does not match is worth raising before it becomes an amendment. The same container is named differently on each document, which matters when you are reading their file against your filing side by side:

On a transhipper's file	On a custodian's file	On your CSN
containerID	equipmentID	eqmtId
equipmentSize	equipmentSize	eqmtSize
equipmentSealNumber	equipmentSealNumber	sealNmbr
mcinPcin (their reference to your cargo)	mcinPcin	the PCIN or MCIN your acknowledgement granted

So a question like "what is containerID" is a question about their file; the field it should agree with on yours is eqmtId, on the master consignment and on each house bill.

The reporting party. reportingPartyCode is the custodian or transhipper code, and authorizedPersonPAN the person filing for them. These are the same codes your own filing carries in its transhipper fields — see Transhippers, CFSs and bond numbers.

They quoted an error code at me from one of these

Paste it into the assistant, or open their acknowledgement here — the codes are explained.

Inland messages are answered with alphanumeric codes (TMB03, CDB05, LCB08), not the numbered codes a CSN gets, and the letters name the block that failed: HF header, LC location and party, DC declaration, CD cargo details, CC cargo container, IT itinerary, SD supporting documents. TM and CI are the transport means and the control checks — an inference, since no published guide expands them.

Two of them are really about you, even though the refused message is somebody else's:

CDB04 and CDB05 — the other party being refused because the MCIN or PCIN your CSN earned is missing, or does not resolve, on their message. Your filing, or its amendment, is what to check. CDB06 is the same thing on a transhipper's ASR or DP (Invalid PCIN / Invalid CIN No) — but on a custodian's stuffing report (SF) it means Shipping Bill is not ready for Stuffing, which is an export-side matter between the custodian and the exporter's broker, not your CSN.LCB05 – LCB09 — bond problems. That is the transhipper's bond, never yours. LCB08 Insufficient Bond Balance in particular is a conversation to have with them.

The full list is in Which error list does my code come from?.

I kept the file. Where is it now, and who can see it?

Under Files you kept on the checker's own page — the link of that name just under SCMTR JSON upload on the CSN filing page — not on the Shipping line filing page, which lists SAMs and SDMs only. Everyone in your organisation sees it and can open it; the person who kept it, or an organisation admin, can delete it, and deleting asks first. An organisation can keep up to 200 of them, separately from its saved manifests. Nothing about a kept file is sent anywhere: it is a copy held so you can come back to it.

Can I file one of these, or fix one?

No, and the platform deliberately offers no way to. A TRCHE01 goes to customs under the transhipper's registration and their bond; a CUCHE01 under the custodian's. Neither is filed on a forwarder's ICEGATE credential, and a corrected copy of somebody else's message is not a thing customs will accept from you. What you can do is read it, check it against your own filing, and tell them precisely what is wrong — which is what this screen is for.

Some fields showed as "not described in either guide"

That is deliberate, and it is worth telling somebody about.

Every label on this screen comes from ICEGATE's published Transhipper and CIM Custodian guides. When a file carries a key neither guide describes, it is shown with its raw name rather than dropped, and counted at the top. It means one of two things: ICEGATE has revised a guide since this platform read it, or the file is not quite what its message ID says. Both are worth knowing, and hiding the field would make the screen look authoritative in exactly the case where it is not.

How far to trust what this screen says

The field descriptions are ICEGATE's own, from the two published guides, and are as good as those guides. What is not corroborated is anything about how these messages behave in practice: this platform has never sent or received either one, and holds no real sample of either. So the labels are reliable, the reporting-event meanings are reliable, and nothing here should be read as evidence about what customs will accept.

For every field of both messages, block by block, see Every field a transhipper or custodian files.

Related

Every field a transhipper or custodian files — the full tablesWho else files against your cargo — why these reach you at allWhich error list does my code come from? — the alphanumeric codesTranshippers, CFSs and bond numbers — the fields on your filing that name themWhere the cargo goes after the gateway portSCMTR JSON upload — the door all of this comes through