What the documents look like
General trade import declaration work centres on the import declaration form, commercial invoice, packing list, bill of lading and contract. The distinguishing focus, compared with export declaration, sits on customs dutiable value, freight and insurance charges, and tax payment. Source material arrives from the International Trade Single Window, the customs tariff schedule, the freight forwarder's arrival notice and foreign exchange payment documents. The update rhythm is per shipment. Importers, customs brokers and customs managers handle these records, which may exist in Chinese, English or several languages at once, so collection, retrieval and handover happen inside one workflow.
Three facts shape this page. First, dutiable value, freight and insurance charges drive the declaration, so any routing decision must keep those fields visible to the reviewer. Second, the documents are multilingual and per-shipment, so the workflow cannot assume one stable language or a batch cadence. Third, the cost of error is supplementary tax, delayed declaration, cargo detention or administrative penalty, which means routing steps must distinguish collected values from reviewed or approved values.
Constraints at the workflow routing step
The form input node belongs to the user interaction category. When it triggers, the conversation enters an interaction state, the workflow state is recorded, and execution continues after the user completes the interaction. The node collects the required form information the user submits and passes it to later nodes. The user selection node also belongs to user interaction. When it triggers, the conversation enters an interaction state and the workflow state is recorded; after the user makes a choice, the node evaluates that choice and runs the "yes" branch.
The documents describe the interaction state as behaviour of the interaction nodes. No global state-recording switch is documented. Collected information must be explicitly passed to later retrieval, judgement or interface nodes, and output must be compared item by item against input. Order writing, document backfill and external status synchronisation require a separate business interface or a later process. Retrieval and forms do not constitute authorised execution.
Hypothetical drill sample, clearly labelled as constructed for this page. A commercial invoice excerpt reads: "Invoice No. HYP-2024-001, Seller: HYP Export Co., Buyer: HYP Import Co., Amount: USD 50,000, Terms: FOB." An accompanying bill of lading excerpt reads: "B/L No. HYP-BL-001, Port of Loading: HYP Port, Port of Discharge: HYP Port." A draft sentence awaits judgement: "This invoice has been reviewed and approved by the customs manager and can be used directly for declaration form entry." The sample contains no review signature record, so the approval status in that draft sentence remains unverified.
Configuration and implementation checks
| Item | Type | Description |
|---|---|---|
| Form input node | Node | Enters interaction state on trigger, collects required information, passes it to later nodes after submission |
| User selection node | Node | Runs the "yes" branch after the user makes a choice; verify branch connections one by one |
| Interaction state check | Implementation check | State recording is interaction-node behaviour; no separate global state-recording switch is documented |
| Output handover check | Implementation check | Pass collected information explicitly to later retrieval, judgement or interface nodes and compare item by item |
| External action split | Implementation check | Order writing, document backfill and external status synchronisation require a separate business interface |
| Retrieval scope check | Implementation check | Required material must sit in a target retrieval scope the request may access, or in explicit manual input |
Three common errors
- Treating form submission as review approval. The sample invoice and bill of lading carry only parties, numbers, amount and trade term. No review signature record appears, so the draft sentence's "reviewed and approved" claim is unsupported.
- Treating the user selection "yes" branch as already executed. The user selection node runs the corresponding branch only after the user makes a choice. The sample holds no choice record, so branch execution status remains unverified.
- Treating retrieval results as authorisation. Retrieval and relevance scores do not perform permission or entity isolation. Whether the sample material may be accessed by the current request must be checked against the target retrieval scope, and a gap recorded when that evidence is absent.
How to verify the setup
- Enter the sample invoice text and the draft sentence. Compare the draft's "reviewed and approved" wording against whether a review signature record exists in the source text. If the source holds no such record, mark the claim unsupported rather than negated or conflicting.
- Enter the sample bill of lading text and the user selection node output. Compare whether the branch connection matches the documented "yes" branch. If output is empty, check whether the interaction state was recorded; do not claim an actual test was run.
- Enter an explicit paper-based empty result
[]and the downstream retrieval node. Compare whether the downstream design accepts an empty result. If no acceptance design exists, record it as pending; do not claim a constructed rule retrieval necessarily returns[].
This page addresses one scope: general trade import declaration, cross-border material and multilingual retrieval, workflow routing. Which materials, operations and requests sit at which authorisation state during operational handover cannot be resolved by treating retrieval or a form as authorised execution.