What the documents look like
Operating reports and exception reviews for fresh-fruit store procurement revolve around four document types: purchase orders, acceptance sheets, pesticide-residue test reports, and loss records. Compared with convenience-store fresh-food ordering, fruit procurement relies more on wholesale-market price movement and grade-based acceptance, and it lacks a headquarters standard-meal baseline that would give all stores one shared measurement convention. The main data sources are wholesale-market quotations, supplier quotes, store sales, and test reports, with updates at daily or per-batch frequency. Together these materials determine the quantity, amount, and loss figures that appear in a report, and they also determine which conclusions in an exception review have support and which remain open.
A purchase order records what was ordered. An acceptance sheet records what arrived and how much passed grade inspection. A pesticide-residue test report records a test outcome for a batch. A loss record records shrinkage. These four documents do not share one identifier scheme by default, so a review has to line them up on subject, period, and field before treating any two values as comparable. The update frequency of daily or per-batch matters here: a purchase order and its matching acceptance sheet can belong to the same day while the test report and loss record for the same batch arrive later, so a review that expects all four to be present at one moment may be reading a still-incomplete set.
Constraints at the tool calls step
The tool call node lets a model decide whether to invoke a system module or a plugin, based on the tool introduction and the tool parameters. For system modules the parameters are already fixed and need no extra configuration; for plugins the parameters are configurable. Two parameter values matter for the decision: the parameter introduction and whether the parameter is required. A tool with no parameters is judged from its introduction alone. A tool with parameters but no required parameter can still be called even when the context holds no suitable value, and the model may fabricate a parameter. A tool with a required parameter may not be called when no suitable value exists, and prompt wording can guide the user to supply it.
In advanced orchestration, a usable tool shows a diamond at its head, and connecting that diamond to the diamond at the bottom of the tool call module separates the tool input from ordinary input and lets the introduction be edited so the call timing is more precise. The documentation notes that debugging tool calls remains uncertain and recommends adding only a few tools at a time and tuning them before going further.
The tool call termination node ends the current call: once the workflow reaches it, no further tools are called and the AI is not asked to summarize the tool results. The custom tool variable node extends a tool's variable input, so a node that is not treated as a tool parameter, or that cannot be called as a tool, can still be reached by supplying a parameter description.
Hypothetical paper exercise. A store's fresh-produce supervisor submits an exception-review handover request with two quoted source lines: "The purchase order dated 12 March 2025 states: Red Fuji apples, 80 boxes, unit price to be confirmed." and "The acceptance sheet dated 12 March 2025 states: Red Fuji apples arrived, 80 boxes, 76 boxes passed acceptance, 4 boxes lost." The draft sentence to be judged is: "This loss has already been confirmed as borne by the supplier, so the loss record needs no further checking." The request is pending review and has received no signature or approval.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | How to check it |
|---|---|---|
| Tool introduction | State the purpose of the purchase order, acceptance sheet, and loss record, and the situations in which the tool should not be called | Compare against the source lines and check whether the introduction covers the input conditions |
| Tool parameters | Fill in the parameter introduction and the required flag for the plugin | Check whether the parameters in the actual request come from the source lines |
| Tool connections | Connect only the few tools this page needs | Check whether the connection points reach only the relevant modules |
| Tool call termination | Place the termination node after the exception-review output | Check whether any further tool call or AI summary follows that node |
| Custom tool variable | Add a parameter description for the loss-record node | Check whether the description matches the fields in the source material |
| Prompt-based completion | Guide the user to supply a missing required parameter through prompt wording | Check whether the completed parameter matches the source lines |
The starting point of few tools is chosen because this page handles only operating reports and exception reviews; each added tool widens the model's decision surface, and that count should be compared with the number of connection points.
Three common errors
- Treating a pending handover request as approved and writing a loss-bearing conclusion into the output. The check is to read the authorization-status field of that request and observe whether it still reads as pending review.
- Reading "76 boxes passed acceptance, 4 boxes lost" on the acceptance sheet as supplier-confirmed liability. The check is to compare whether the loss record contains a supplier-confirmation field and observe whether that field holds a value.
- Assuming the tool call termination node still asks the AI to summarize. The check is to read the connections after that node and observe whether any AI summary call remains.
How to verify the setup
- Input the two quoted source lines and the draft sentence above, then compare "already confirmed as borne by the supplier" in the draft against the supplier-confirmation field in the loss record. The condition is met only when that field holds an explicit confirmation value; otherwise record the claim as unsupported.
- Input the handover request and compare its authorization status against the value "approved." The condition is met only when the status field explicitly reads as approved; the current pending-review state is recorded as still to be verified.
- Input the connection configuration of the tool call termination node and compare whether any other tool call or AI summary call follows it. The condition is met only when neither is present; otherwise record the check as not passed.
Retrieval and forms collect and present values; they do not constitute authorization to execute. An empty result can be checked against a downstream design using the explicit paper input [], without asserting that a fictional rule search necessarily returns empty. Libraries built on different vector models cannot be associated together; verify the identifier and exclude non-matching entries, then record what was actually observed. A similarity score is not a category, entity, or permission filter, and retrieval is not authorization.