Document review

Confirm a delivery order with several containers

A forwarder sends one PDF covering four containers. Conterminal stages four delivery orders from it, but you only want to review the shared fields once. This is how the multi-container confirm screen works, what the per-container grid is telling you, and what to do when the batch is not offered.

9 minute read · Updated July 27, 2026

When one document covers several containers

When a delivery order arrives as an email attachment and names more than one container, Conterminal stages one delivery order per container from that single attachment. Each one gets its own row in Document Review and its own confirm screen. That is deliberate — the containers move separately, get billed separately, and end up on separate PODs.

What you do not want is to retype the same consignee, the same Deliver To, and the same billing customer four times. So when Conterminal can prove that the staged orders all came from the same reviewed document, the confirm screen offers a batch: you audit the shared fields once against the PDF, and one Confirm commits every selected container together. Everything else on the screen behaves exactly as described in Confirm a delivery order.

The batch is not always available. It is offered only when all of these are true at once:

The upload came in as an email attachment: The order has to be linked to an attachment assignment. An order created by hand, or one whose upload is not part of a staged attachment, always confirms on its own.
Two or more orders are still open: The batch counts only assignments still awaiting confirmation. If one container is left, you get the ordinary single-order screen with no grid.
The document review finished: The stored review for the attachment must have reached its ready state and must still parse. A review that is mid-enrichment, or one whose stored proposal no longer validates, falls back.
Every staged order is fully activated: Each open assignment needs both a target delivery order and its own upload record, and the review must carry at least as many included container rows as there are open orders.

The batch is all-or-nothing.

The screen says it plainly: “Review the shared fields against the PDF once. Confirm commits every selected container together; if any order fails, none are confirmed.” A container-number collision, an already-confirmed row, or a readiness gap on any single selected order aborts the whole submission. Nothing is half committed, but nothing is committed either.

When any of the conditions fails, you do not get blocked — you get an amber banner headed Multi-container document · N delivery orders confirm one at a time, and the screen degrades to ordinary one-at-a-time confirmation. The remaining containers stay in the review queue. That is the designed behavior, not an error.

Reading the per-container grid

Depending on how your workspace is configured you will see one of two layouts above the review fields. The full layout is a wide table headed N delivery orders on this document. The compact layout is a blue banner headed Multi-container audit · N delivery orders with a checkbox per container and a status chip reading Enrichment ready. Both drive the same selection and the same Confirm button; only the amount of detail differs.

The table columns are:

Column	What it shows
Container	The container number, or Order N if the staged order has none yet. It is a button — clicking it highlights that container in the document preview. The order you are currently on is marked (this order).
B/L, Booking, Seal · PO	Per-container identifiers taken from the review, not from the fields you are editing. An em dash means the review found nothing for that row.
Size/Type, Weight, Vessel/Voyage	Equipment and voyage detail for that container. Vessel and voyage render joined, as in MSC ARUSHI V.428W.
Terminal, LFD	Terminal name and last free day, but only where a discovered fact was recorded against that exact container number. These two columns are frequently empty on a document that has not been enriched yet.
Trucker	Matched when the review resolved a company in your network for that row, Needed when it did not.
Readiness	Ready, or one red chip per gap. This is the column that decides whether Confirm will go through.
Conflicts	A count. Click it to expand the conflict messages inline under the row, and click again to collapse them. Conflicts are advisory — they do not block Confirm.
Evidence	How many evidence entries the review recorded for that row. A zero is worth a closer look at the PDF.

Every value in the grid is read from the stored review snapshot. The grid performs no live lookups while you are on the screen, so a blank Terminal or LFD means the snapshot has nothing for that container — not that the terminal has no record.

Refreshing the facts

Refresh enrichment in the grid header re-queues a LongShorty lookup against the carrier for this document. LongShorty signs in to the ocean carrier or terminal system, and anything it finds is merged back into the review and lands through the page's normal refresh. It is not instant, and the grid will not repaint on its own the moment you click.

The button gives you no result. It reads Refreshing… while the request is in flight and then goes back to Refresh enrichment whether the job was queued or rejected — for example when no compatible carrier adapter can be resolved from the document. If the Terminal and LFD columns are still empty a few minutes later, assume the lookup did not run rather than that the carrier has nothing.

Rows that are already confirmed

Confirmed containers stay in the grid, dimmed, with Confirmed in place of their checkbox and an em dash in Readiness. They keep their Print POD link, and once more than one row is confirmed a Print PODs (N) link appears in the header for the whole set. Every row also carries an Open link to that order's own confirm screen.

Deselecting containers and confirming a subset

Every open row starts selected. Clear a checkbox to leave that container out of this confirm.

Audit the shared fields once. Parties, Deliver To, billing customers, and the document-level fields you edit on the right apply to every selected container. Check them against the PDF as you normally would.
Check the per-container rows. The identifiers in the grid — container number, B/L, booking, seal, PO, size and type, weights, cargo description — are taken per row from the review, so they can legitimately differ from what is in the form in front of you.
Deselect what you are not ready to commit. Deselected rows go grey and struck through in the compact layout. The Confirm button relabels itself as you go: Confirm 4 orders when everything is selected, Confirm 3 of 4 orders when it is not.
Confirm. The compact layout spells out what happens next: “Confirming 3 of 4 orders — deselected orders stay in Needs Review, and you land on the next one after this confirm.”

Deselect at most one order.

Partial confirms have a sharp edge. Once a document has some confirmed containers and two or more still open, pressing Confirm on the batch screen submits the already-confirmed rows along with the open ones and the server rejects the whole thing with “The selected delivery orders no longer match the staged batch. Refresh the review and confirm again.” Refreshing does not clear it. If you need to hold something back, hold back exactly one container: after the confirm only one order is left open, the batch grid stops appearing, and that order confirms normally on its own screen.

A single confirm accepts at most 25 orders. Past that the submission fails validation before it is sent, and the action bar reports a generic field problem rather than telling you about the cap. Deselect down to 25 or fewer, keeping the one-order rule above in mind.

Why you cannot deselect the one you are viewing

The row marked (this order) has a checkbox that is permanently disabled. That is not an oversight. The confirm screen you are on belongs to that specific order, and the shared fields you just edited are that order's review — they are what the whole batch inherits. Committing the batch while excluding its own source row would commit your edits to every container except the one you actually reviewed.

If a request somehow reaches the server with the current order deselected, it is refused with “Keep this delivery order selected, or open one of the selected orders and confirm the batch from there.” That second half is the real answer: to confirm a set that does not include this container, use the Open link on one of the rows you do want, and run the batch from that order's screen instead.

Which values are shared and which are per row

Shared across the batch: Everything you edit in the review form: delivery and importer parties, the Deliver To selection and its location, the structured company assignments, the freight and accessorial billing customers, and the document-level values the review did not override.
Taken per container: Container number, bill of lading, house bill, broker and customer reference, reference or PO (falling back to the booking number), pickup number, seal, size and type, cargo description, package count, gross weight, and release status.

Each row is also checked on its own before anything commits. Its upload must still be open for confirmation, and its container number must match the order it is being written to. That is why a batch can fail on a container you never looked at.

Continuing to the next order

After a batch commits, Conterminal decides where to put you based on what is left:

If orders from this document are still open, you land on the confirm screen of the next one, in the order the containers were staged. You do not go back to the queue and hunt for it.
If nothing is left open, you land on the POD stage for the order you were on, which is the same place a single-order confirm takes you.

Deselected containers are not cancelled and not archived. They stay in Needs Review with their staged order intact, and you can come back to them at any time. Confirmed ones move to the recently confirmed view and their PODs become printable from the grid.

Every confirmed order in the batch gets the same post-confirm treatment as a single confirm — the reviewed values are written back to the order, party candidates are reconciled, and the detail pages are refreshed. The batch changes how many orders commit at once, not what confirming means.

Creating a sibling order when the grid is unavailable

There is a second multi-container path that has nothing to do with the batch grid. You open an order to confirm it and the screen blocks with an orange banner:

This PDF is for TCNU5632910, but this order is FFAU3667535. Attach it to the matching order instead.

That means the container number now in the review does not match the order the upload is attached to. Confirm stays disabled while the banner is up. When the upload demonstrably contains both container numbers, the banner carries a button labelled Create/open matching sibling order for TCNU5632910.

Finish your edits first. The parties, the structured assignments, the size and type, and the Deliver To kind you have set are carried over to the sibling order, with the container number swapped to the requested one. Anything you have not filled in is not carried.
Press the button. It shows Opening sibling order... while it works. Conterminal claims the staged slot for that container, creating the order if it does not exist and reusing it if it does.
Land on the sibling. You are redirected to the confirm screen for the matching container, with your carried values already applied. Confirm it there.

This recovery is only available for forwarded multi-container delivery-order attachments. On any other upload the action returns “Sibling recovery is only available for forwarded multi-container DO attachments.” and you are left with the block. In that case the fix is upstream: attach the document to the correct order, or re-send it so it can be staged properly.

What “not ready” means on a row

The Readiness column and the server use the same evaluation, so a red chip in the grid is a reliable prediction of a rejection. If a selected row is not ready, the confirm is refused with a message naming the container, for example: “TCNU5632910 is not ready to confirm: missing Trucker match. Deselect it or resolve the gaps first.” A row with no container number is named Order 2 instead.

Container number: The review produced no container number for that row at all. Nothing can be written back against it. Deselect the row and work out from the PDF what the container should be.
Trucker match: The review could not resolve the trucking company named on the document to a company in your network. Add or match the company, then reload the confirm screen.
Tracking identity: The row has nothing usable to track the container with — no container or booking identity the carrier sources can be asked about.
Required field: A required value the review flagged that is not one of the three above. The chip is deliberately generic; the underlying field path is internal.

The Trucker column and the Readiness column are not the same signal. Trucker reads Needed whenever no company is matched on that row, but Readiness only lists Trucker match when the review marked it as a blocking gap. A row can legitimately show Trucker Needed and Readiness Ready; that row will confirm.

The compact layout does not have a Readiness column. Instead it summarises the whole document under the checkboxes, in operator language rather than field paths — for example “2 conflicts to audit · 3 orders need a trucker match · 1 order missing a tracking identity”. It does not tell you which rows, so you have to deselect and retry, or open the individual orders.

Troubleshooting

“The selected delivery orders no longer match the staged batch. Refresh the review and confirm again.”

The submitted selection contains an order the server no longer counts as open. In practice this almost always means the document already has confirmed containers while two or more are still open — the confirmed rows are submitted along with the open ones and the whole batch is refused. Reloading does not clear it. Avoid it by never leaving more than one container deselected; if you are already in this state, contact support with the container numbers rather than retrying.

“Multi-container document · N delivery orders confirm one at a time”

The batch was not offered and the screen has degraded on purpose. The banner tells you which case you are in: “The agent review is still enriching. Wait for batch confirmation to become available, or confirm this delivery order now — the remaining containers stay in the review queue.” means wait or proceed singly; “The agent review for this document could not be used.” means the stored review no longer validates; “The staged delivery orders no longer line up with the agent review.” means the staged orders and the review have drifted apart. In all three, confirming one at a time is safe and nothing is lost.

No grid and no banner at all

Only one order from this document is still open, or the upload was never part of a staged email attachment. This is the ordinary single-order confirm screen — nothing is wrong.

“Confirm this agent-reviewed batch first, then promote individual container assets from their shipment details.”

You are a Platform Admin and you set Stable Fact Workflow to Promote to Platform on a multi-container confirm. Promotion is not available during a batch: the field itself reports “Container asset promotion is not available during a multi-container confirmation.” Set it back to Shell Only, confirm the batch, then promote each container from its own shipment detail page.

“Keep this delivery order selected, or open one of the selected orders and confirm the batch from there.”

The submission excluded the order whose screen you are on. The checkbox for that row is disabled precisely to prevent this. Use the Open link on a row you do want to keep, and run the batch from that order's screen.

“CONTAINER is not ready to confirm: missing … . Deselect it or resolve the gaps first.”

A selected row has a readiness gap. Nothing was committed. Either fix the gap — usually a trucker match — or clear that row's checkbox and confirm the rest.

“This DO upload is already confirmed.”

One of the rows in your selection was confirmed by someone else, or in an earlier pass, between the page loading and your Confirm. Reload the confirm screen so the grid reflects reality, then confirm again.

“This PDF is for X, but this order is Y. Attach it to the matching order instead.”

The reviewed container number does not match the order. Confirm is disabled. If the upload contains both containers you will get a Create/open matching sibling order button — use it. If you do not, the document is attached to the wrong order and needs to be re-staged.

“This upload does not prove a matching sibling container in the same PDF.”

Sibling recovery refused because the requested container is not among the container numbers found in this upload's own stored payloads. It will not create an order on the strength of a number you typed into the field.

“The deterministic sibling assignment is reserved for X, not Y.”

The staged slot for that position already belongs to a different container. The message ends “This requires a data repair before automatic recovery can continue.” — that is accurate, it is not something you can clear from the screen. Send support the document, both container numbers, and the order you were on.

The grid is empty in Terminal and LFD for every row

The review has identity data but no enrichment yet. Try Refresh enrichment once. If the columns are still empty several minutes later, the carrier lookup is not running for this document; confirm without it — terminal and last free day continue to fill in through normal tracking after the orders exist.