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 September 3, 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, the same optional Care Of, 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, review each container's own details, and then commit every selected container together. Each selected container receives the shared per-stop Care Of details on its generated POD. 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. Save each selected container, then Confirm commits the batch 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

The guided layout is a wide table headed N delivery orders on this document. The active row is highlighted and its container number is marked Reviewing now. Clicking another container switches the header, the editable container fields, and the document highlight to that container. A reviewed container reads Saved; a container left out of this batch reads Not selected.

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 makes that row active, loads its editable fields, and highlights that container in the document preview. The URL's source order is still 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. A selected container must be ready before Save containercan mark it reviewed.
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. The bottom action bar follows the exact queued work item until it finishes. If you reload while it is running, Conterminal resumes that refresh instead of starting a duplicate. The stored grid snapshot itself still updates through the page's normal refresh.

The button reads Refreshing… while the exact work item is queued or running. A rejected or failed lookup now reports its reason in the tracking status instead of silently returning to idle. When the work succeeds, the materialized candidates open inReview tracking results; the grid can remain on its original snapshot until the next normal page refresh.

The grid refresh and the full form's manual routing lookup share the same per-field result review. If vessel, carrier, terminal, voyage, equipment, B/L, or ETA is still blank, select the pickup terminal when the document did not resolve it, then use Find from tracking in the Moved By section. The bottom bar reports progress while you continue reviewing and opens an explicit per-field result review; no returned value is silently applied.

Rows that are already confirmed

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

After the last selected container is confirmed, the completed POD screen becomes the handoff. Its Print N PODs action opens one merged PDF containing every confirmed container from the same source document.

Reviewing and saving each selected container

Every open row starts selected. Review the selected containers one at a time. Clear a checkbox only when that container should stay in Needs Review for a later confirmation.

Audit the shared fields once. Parties, Deliver To, billing customers, document date, issuer, vessel, and voyage carry forward across the selected containers. Check them against the PDF as you normally would.
Open a container. Click its number in the grid. The form now shows that container's B/L, seal, PO, pickup number, size and type, cargo description, pieces, and weights. Correct those values without changing the other containers.
Save the container. Press Save container. The row changes to Saved and the form advances to the next selected container that has not been reviewed. If you later edit a saved container, save it again before confirming.
Confirm the saved batch. After every selected container is saved, the action changes to Confirm N orders. Press it once to commit the exact saved container details atomically. Deselected containers stay in Needs Review.

Partial confirmation is supported. Already-confirmed rows are not resubmitted, and any open rows you deselect remain active for a later pass. The server still verifies that the exact saved selection is current before it commits anything.

The ordered delivery route is shared. Add companies and sites once in Full Review; every selected container receives the same pickup, ordered delivery stops, stop contacts, requested windows, instructions, per-stop Goods and Pieces, and return. Editing that route marks previously saved container drafts unsaved, so save each selected container again before confirming. After confirmation, each container still keeps its own receipt and stop-scoped POD cargo for each delivery leg.

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 and save every selected container.

The active container and the source order

The row marked (this order) has a checkbox that is permanently selected because the URL belongs to that source order. It is not necessarily the row you are actively editing: click any other selected container to make that one Reviewing now. The header and container-specific fields follow the active row.

Shared-field edits carry forward to every selected container draft. Container-specific edits stay only on the active container. If a request somehow excludes the source order, the server refuses it; open one of the included orders and run the batch from that order's screen instead.

Which values are shared and which are per row

Shared across the batch: Delivery and importer parties, the Deliver To selection and its location, ordered additional delivery stops with their Goods and Pieces, structured company assignments, freight and accessorial billing customers, document date, issuer, vessel, ocean carrier, ETA, voyage, and other document-level values.
Taken per container: Container number, bill of lading, house bill, customer reference, reference or PO, pickup number, seal, size and type, cargo description, package count, gross weight in pounds and kilograms, 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. If the final order's canonical tracking timeline is still being assembled, its detail page briefly shows Preparing tracking and opens automatically when ready. 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. A selected Local Carrier satisfies this row: choose the correct carrier on the form, then save the container. Add a network company only when the intended carrier is not available to select.
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 Matched when either enrichment found the trucking company or the form has a resolved Local Carrier. Without either one, Readiness only lists Trucker match when the review marked it as a blocking gap. A row can still 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 saved containers no longer match the assignments the server still counts as open — usually because another user confirmed or changed one after your screen loaded. Nothing was committed. Reload the review, check the remaining selected containers, save them again, and retry.

“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. A completed carrier review appears above the fields; if routing details are still blank, Find from tracking uses the bottom bar and opens an explicit per-field review. No lookup result is silently applied.

“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 and watch the bottom status. A failure names the reason; a successful lookup opens Review tracking results even when the stored grid snapshot remains blank. If the provider returns no usable fields, confirm without them — terminal and last free day continue to fill in through normal tracking after the orders exist.