Review and confirm a delivery order

Reading the split view

The header reads Confirm delivery order fields with the container number beside it. Below it, the source PDF fills the left pane and the review rail fills a fixed column on the right. On a phone the two panes collapse into a toggle labeled Document and Fields; the screen opens on Fields, because that is where the work is.

Each row in the rail has the same shape: a label, the control you actually commit, and underneath it a muted evidence line reading Document: followed by what the parser pulled off the page. When nothing was found the line reads No document value found. Click that evidence line and the left pane highlights the matching text in the PDF, which is the fastest way to check a number without reading the whole page.

How the rail is grouped

Fields are grouped into Parties, Pickup, Moved By, Shipment, and Support Details, preceded by an unlabeled block holding the document date and issuer, and a Billing customer defaults section with Freight Customer and Accessorial Customer.

The required assignments

Text fields hold what the document said. Assignments are different: they bind the document to a real record in your workspace, and eight of them must resolve before Confirm will fire. Each one blocks with its own message.

Issuer

“Issuer must be selected or marked as not shown before confirming.”

Pickup terminal

“Pickup terminal must be selected before confirming.”

Vessel

“Vessel must be selected before confirming.”

Ocean carrier

“Ocean carrier must be selected before confirming.”

Container SSL

“Container SSL must be resolved before confirming.”

Local carrier

“Local carrier must be selected before confirming.”

Importer (BCO)

“Importer (BCO) must be selected or marked as not shown before confirming.”

Deliver To

“Deliver To must be selected before confirming.”

Broker and Freight forwarder are optional and never block a confirm. Deliver To location is conditionally required — see the next section.

Reading the state of a picker

1. Needs match. The parser read a name off the document but no canonical record is selected yet. The helper text says “Parsed from the document, but no canonical match is selected yet.” Focusing the field opens the picker for you.
2. An amber warning. Several active company records match the parsed name: “Multiple active company records match this parsed name. Resolve it to the canonical record.” Pick the canonical one rather than whichever sorts first.
3. Auto-filled or Manual. A resolved field shows where its value came from — a suggestion from the document, a value derived from the vessel, the container BIC or the B/L prefix, a workspace default, or your own search. Auto-filled is not the same as verified; check it against the evidence line.

Resolving Deliver To: company, then site

Deliver To is two decisions stacked in one row. First the company that owns the destination, then the specific site under that company. The row shows the company picker until a company is chosen; after that, the same row becomes the site picker. That is why the control seems to change what it is asking for mid-task — it did.

1. Pick the company. An unresolved Deliver To carries the label Needs owner. If the parsed name matched nothing, the helper reads “No existing Deliver To company matches this document yet. Create it or choose an existing org instead.” If several companies matched, you get “Multiple existing companies could match this Deliver To. Pick the right one before choosing a site.” and a Choose the matching Deliver To company list where each candidate has a Use action.
2. Then pick the site. Once a company is set, the site picker resolves against that company's saved locations. A clean match reads “Matched to saved site.” or “Matched to saved site (address normalized).” and needs nothing from you.
3. Resolve an unclear site. The picker labels itself Choose or create site and tells you which case you are in: “Similar saved site found. Choose it or create a new site.”, “Multiple saved sites could match. Choose one or create a new site.”, or “No matching site found. Create a new one.”

The warehouse case is the two-level one people trip on: a warehouse company can own many yards and docks, and the delivery address on the document identifies the site, not the company. Conterminal treats the company as the owner and the address as a saved site beneath it, so a second delivery order to the same warehouse at a different address is a new site under the same company — not a second company.

Creating a new company or site inline, and when a reason is required

You do not have to leave the screen to add a missing record. Creation is staged as intent and executed by the Confirm button, in the same commit as the order.

A new company

When nothing matches the parsed Deliver To, a New company on confirm panel appears: “Confirm can create a new Deliver To company from these delivery fields and add its first saved site in the same commit.” Choose the role — Warehouse or Importer (BCO) — and the panel previews the name and address it will use. The Deliver To field then reports “Confirm will create a new Deliver To company from the edited delivery fields.” and stops blocking. If you would rather attach an existing record, use Choose existing org instead.

A new site

Under a selected company, a New site on confirm panel offers Create new site, Choose saved site, and Change Deliver To company, with a preview of the parsed delivery address. Its message depends on what the resolver found: “No saved site matches this delivery. Confirm can add it as a new site under the selected Deliver To company.”, “A similar saved site already exists. Create a new site only if this delivery is distinct.”, or “Multiple saved sites could match. Pick one above or confirm this as a new site if none are correct.”

The other role pickers create records inline too. The Importer (BCO) picker, for example, carries a Create new importer (BCO) action that uses whatever you typed as the name.

Confirming

The primary button reads Confirm DO normally, and Confirm & Continue when you came in from the review queue. On a multi-container document it counts what it will commit — Confirm 4 orders, or Confirm 2 of 4 orders if you deselected rows. A batch confirm is all-or-nothing: if any order in the selection fails, none are confirmed.

1. Watch the action bar. While fields are outstanding it summarizes them as, for example, “3 fields need attention.”
2. Press Confirm. If anything is unresolved the screen does not submit; it shows a red banner reading “Fix 3 fields before confirming.” listing up to five issues. Each listed issue is a button that scrolls to and focuses the field.
3. Fix and press Confirm again. The server re-validates independently, so a value that drifted since the page loaded is caught here rather than committed.

Where you land afterwards depends on what is left to do: the proof of delivery stage if it is available, then the confirmation email stage, then the next delivery order from the same document, then the next item in your review queue, and finally the order's detail page.

The POD stage

The proof-of-delivery stage replaces the PDF pane with the POD document itself, while the right rail switches to a read-only Confirmed DO summary — document date, issuer, container, BOL, broker reference, ETA — plus the delivery address and the route legs. The confirmed values stay in view while you print and reply.

1. Check the sheet. The desktop preview shows a letter page with two identical copies of the POD stacked on it — one for the driver, one for the file.
2. Select Print POD. Conterminal opens a new tab that reads “Opening POD PDF...” and then loads the generated PDF.
3. Select Finish to leave, or Email Update to move to the email stage. Both are also in the Actions menu, along with Open source document and Open operations detail.

The confirmation-email stage: draft, send, or skip

This stage only exists when the document arrived as an email attachment — there has to be a thread to reply to. If there is no draft, the email stage is unavailable and asking for it sends you back to POD.

The compose is a reply-all against the reconstructed thread: From, To and Cc as removable recipient chips, Subject, and a rich text Message. Typing pauses briefly and the draft saves itself; you will see Saving draft… in the toolbar while it does. Recipients are validated as you add them — anything that is not an email address is dropped rather than rejected loudly.

1. Review the recipients. If the thread reconstruction was uncertain the stage says “Review recipients before sending.” Sending with an empty To list is refused with “Add at least one recipient before sending.”
2. Send or skip. Send is the primary button; Skip sits beside it and is also available as Skip email in the Actions menu. Both close out the stage and move you along.
3. Check the history. The right rail lists Emails for this document with each message's kind, status, timestamp, and recipients, or “Nothing has been emailed for this document yet.” Sent and failed messages each carry a Resend button.

An already-sent email opens read-only with a green summary — “This confirmation email was already sent.”, or “The received confirmation was already sent.” when it was the automatic acknowledgment — and the buttons change to Back to POD and Continue to Next DO or Finish. A failed send exposes a Delivery diagnostics disclosure with the provider response.

Archiving instead of confirming

Some uploads should not be confirmed at all — a duplicate, a scan of the wrong document, a PDF that turned out to be unrelated. Open the Actions menu and choose Archive document. The item shows Archiving... while it runs, then returns you to the next item in the queue, or to the order's detail page if you were not in queue mode.

Archiving is only offered while the upload is still pending review. Attempting it later is refused in plain terms: “Confirmed DO uploads cannot be archived from this review screen.”, “This DO upload has already been superseded.”, or “This document has already been archived.”

Troubleshooting