What the documents look like
Supermarket supplier entry settlement centers on purchase-and-sale or consignment payables. A supplier does not necessarily operate a staffed counter on site. The material needed for comparison sits in separate systems: ERP purchasing, the supplier portal, POS sales, and finance. Four document types carry the relevant fields. The purchase contract sets the settlement basis. The delivery acceptance note records received quantities. The rebate agreement sets the deduction rate. The statement of account summarizes activity for a period. When field definitions differ across these documents, a tool call has to place contract clauses, acceptance records, and the settlement request in one context for comparison. Updates arrive weekly or monthly, and comparison work starts per settlement cycle.
Constraints at the tool calls step
A tool call node relies on the tool description and the parameter descriptions for the model to decide whether to call the tool. Plugin parameters are configurable; system module parameters are fixed. When a required parameter has no suitable value in context, the model may not call the tool, and prompt wording can guide the user to supply the value. A tool call termination node attached after a tool ends that tool call, calls no further tools, and does not call the AI to summarize the tool result. A custom variable can add an input description for a node that is not treated as a tool parameter or cannot be called as a tool, so the tool call can invoke that node and the workflow after it. Retrieval results supply semantically related material only. They do not perform authorization checks and do not separate records belonging to different entities or different suppliers.
Hypothetical paper exercise sample. The purchase contract text supplied for comparison reads: "Party A is a supermarket chain in East China; Party B is a food supplier; settlement cycle is monthly with payment 30 days after month end; rebate is deducted at 2% of accepted amount; the contract is valid through 31 December 2025." The delivery acceptance note reads: "March 2025 accepted amount 100,000 yuan; acceptance date 18 March 2025." The statement of account reads: "March 2025 accounts payable 98,000 yuan; rebate deduction 2,000 yuan." The draft sentence to be judged reads: "The March 2025 rebate deduction of 2,000 yuan matches the 2% contract basis and can be submitted for settlement." This draft sentence involves a party, a period, and a field, and each must be checked item by item.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | How to check |
|---|---|---|
| Tool description | State the purpose of comparing contract, acceptance note, and statement | Check whether the description includes input conditions and cases where the tool should not be called |
| Required parameter | Set the settlement period as a required parameter | Observe whether the model requests the missing period when it is absent |
| Plugin parameter | Source field for the rebate rate | Check the parameter description against the value in the actual request |
| Tool connection | Connect only comparison-related tools | Tune a small set of tools before adding more |
| Tool call termination | Attach after the comparison tool | Observe whether the call ends and no AI summary is triggered |
| Custom variable | Add a parameter description for the statement node | Check whether the node is invoked accordingly |
The starting point is chosen only for this paper exercise. The reason is that limiting the required parameter to the settlement period reduces calls made without parameters. The comparison object is the call request when no required parameter is set.
Three common errors
- A tool description written as general text, without input conditions or cases where the tool should not be called, leads the model to issue a call when the settlement period is missing. The check input is the tool description text; the comparison is whether it contains the period condition and exclusion cases; the observable result is whether a fabricated period appears in the call request.
- A statement of account returned by retrieval is treated as an authorized settlement basis. The check input is the statement text returned by retrieval; the comparison is whether it contains an approval or authorization field; the observable result is whether the draft sentence goes directly to submission.
- An AI summary output is still expected after tool call termination. The check input is the connection position of the termination node; the comparison is whether a summary node exists downstream; the observable result is whether summary text appears after termination.
How to verify the setup
- Verification one: input the contract text, acceptance note text, statement text, and draft sentence from the hypothetical sample. Compare the 2,000 yuan rebate deduction in the draft sentence against the 2% contract basis and the 100,000 yuan accepted amount. Observe whether the result is 2,000 yuan and whether the period is March 2025 throughout. The condition is met when all three share the same party, the same period, and the same field, with consistent values. This sample is a paper exercise and was not executed.
- Verification two: input a request containing only the acceptance note text and missing the contract text. Compare whether the tool requests the missing contract clause. Observe whether a request to supply the missing required parameter appears. The condition is met when the model does not directly give a rebate conclusion. The missing contract text is an evidence gap and is recorded as pending verification.
- Verification three: input an empty reference [] with no material at all. Compare whether downstream nodes treat it as an empty result. Observe whether an unsupported settlement conclusion is produced. The condition is met when downstream does not generate a settlement submission. The empty result is used only to check downstream design and does not mean a search for invented rules necessarily returns empty.
These verifications describe expected design. They do not constitute a completed test, a deployment, or an approval.