What the documents look like
Wholesale market stall trading is more fragmented than regional dealer replenishment, and its daily rhythm is built around on-site price negotiation and shipping arrangements. Four document types recur in operating reports and exception reviews: purchase slips, handwritten sales slips, stall lease contracts and payment receipts. These materials update daily or per order, and the document date and counterparty should be retained on entry. That update frequency does not show that batch summaries are absent; whether a summary exists requires checking the actual records.
Tool calling lets a model decide from context semantics whether to invoke a given tool. In a stall setting this mechanism is used to link scattered document information, payment records and shipping notes into a review flow. The tool description, the tool parameters and whether each parameter is required jointly determine whether the model issues a call. When a suitable required parameter is missing, the model may not call the tool, and prompt wording can guide the user to supply it.
Constraints at the tool calls step
A tool can be a system module, such as AI dialogue, knowledge base search or an HTTP module, or it can be a plugin. For system modules the tool parameters are already fixed and need no extra configuration; for plugins the tool parameters are a configurable item. In advanced orchestration, dragging the connection point of the tool call node makes a diamond appear at the head of available tools, which can be connected to the diamond at the bottom of the tool call module. A connected tool automatically separates tool input from ordinary input, and its description can be edited so that the call timing becomes more precise. The official guidance notes that debugging tool calls remains uncertain, so adding many tools at once is not advisable; a small set should be tuned first before further attempts.
The tool call termination node can be attached after a tool. When the workflow reaches it, the current tool call ends forcibly, no other tools are called, and the AI no longer answers based on the tool call result. Custom variables extend tool variable input: nodes that are not treated as tool parameters, or that cannot be called as tools, can be given a custom variable with a corresponding parameter description, so that the tool call invokes that node and the workflow after it. Operating reports and exception reviews cover the four material types named above, and tool calls need to cover reading, field extraction and cross-checking for them. Retrieval itself does not constitute authorization, and a form collecting values does not equal completed business verification or approval.
Hypothetical paper exercise sample. A stall holds a handwritten sales slip whose text reads: "Received today from buyer Wang the sum of three thousand yuan, corresponding to the two boxes dispatched on 12 March; the balance remains unpaid." A stall lease contract reads: "Lease term from 1 January 2024 to 31 December 2024; monthly rent paid through June." A draft sentence awaiting assessment reads: "Wang has settled all payments in full." The check compares the handwritten sales slip text with the draft sentence: the original states the balance remains unpaid, the draft states all payments settled in full, and the same counterparty, same period and same payment field carry mutually exclusive values, so the draft sentence is not supported by the original. The lease contract states only the term and that rent is paid through June, with no renewal or termination clause, so any judgment about renewal status stays pending verification.
Configuration and implementation checks
| Configuration item | Assumed starting point for this page | Reason and comparison method |
|---|---|---|
| Tool description | State that it reads purchase slips, handwritten sales slips, stall lease contracts and payment receipts and extracts fields | The description should state input conditions and situations where calling is inappropriate; compare whether the model still issues a document-reading call when no document input exists |
| Tool parameters | Set document type and date range parameters for each document class | System module parameters are fixed while plugin parameters are configurable; check whether parameter values in the actual request match the input |
| Required parameter | Treat document type as a required parameter | With a suitable required parameter missing the model may not call; after interactive completion, check the actual request |
| Tool connection | Connect only the document-reading and field-extraction tools | Tune with a small set first; compare whether call timing becomes more precise after adding tools |
| Tool call termination | Attach the termination node after field extraction | The termination node ends the call and does not invoke AI summarization; compare whether output still contains AI summarization before and after |
| Custom variable | Define a custom variable description for the shipping note number | Extends tool variable input; compare whether that node is called because of the variable description |
Three common errors
- Writing a generic tool description that omits situations where calling is inappropriate. Input: a buyer inquiry containing no document. Compare whether the tool description states input conditions, and observe whether the model still issues a document-reading call when no document input exists.
- Treating a parameter description as a guarantee of execution. Input: one handwritten sales slip with the document type filled in the parameters. Compare the parameter values in the actual request against the document text, and observe whether a parameter is fabricated or omitted by the model.
- Treating a retrieval result as authorized execution. Input: a request to look up a purchase slip. Compare the retrieved records against the operating permission, and observe whether a database write or external synchronization is executed merely because a record was retrieved. Retrieval does not handle permission or entity isolation; business verification, approval and external synchronization require separately connected system implementation.
How to verify the setup
- Input the handwritten sales slip text from the hypothetical sample and the draft sentence "Wang has settled all payments in full." Compare the payment field value in the original, which states the balance remains unpaid, against the draft sentence. When the same counterparty, same period and same field carry mutually exclusive values, the draft sentence is judged unsupported by the original. The expected result is that this mutually exclusive value is identified; no claim is made that this was actually tested.
- Input the stall lease contract text. Compare the term and the rent-paid scope stated in the original against a judgment request about renewal status. When the original states no renewal or termination clause, renewal status stays pending verification. The expected result is that the evidence gap is recorded, without fabricating authorization or effective clauses.
- Input a buyer inquiry containing no document. Compare whether the tool description states situations where calling is inappropriate, and observe whether the model issues a document-reading call. The expected result is that the model does not issue a call; if a call is issued, check whether the tool description needs the inappropriate-call situations added. An empty result can be carried into downstream design checks using explicit paper input; no claim is made that a fictional rule retrieval necessarily returns an empty result.
This page addresses only wholesale stall trading / operating reports and exception reviews / tool calls and plugins. At operational handover, which materials, operations and requests sit at which authorization state cannot be treated as authorized execution on the basis of retrieval or a form.