What the documents look like
Dealer rebate calculation happens after sales, and its centre of gravity is policy interpretation and financial treatment rather than stock movement. The working materials are the rebate policy, the volume achievement table, the reconciliation statement and the red-letter invoice. They arrive from ERP sales records, dealer remittances, the contract ledger and the finance system, and they are refreshed monthly or quarterly. For the comparison task on this page, the two decisive inputs are the reconciliation statement and the volume achievement table, because the rebate amount is checked against the achievement figures while returns and invoice offsetting are handled separately downstream.
These materials enter the workflow as documents and tables. The tool call node decides, from context, whether a given tool should run, and the tool description tells the model what the tool is for. That description is the main lever for keeping the comparison step on task: it should state which documents the tool accepts and which situations should not trigger a call. The reconciliation statement carries the dealer's claimed position; the volume achievement table carries the sales figures that the claim is checked against. A red-letter invoice is a separate financial document and is not produced by the comparison itself.
Constraints at the tool calls step
Tool descriptions explain purpose, and tool parameters divide into parameters already fixed for system modules and configurable parameters for plugins. Each parameter carries a description and a whether-required flag. When a required parameter has no suitable value in context, the model may decline to call the tool, and the prompt can guide the user to supply the missing value. In advanced orchestration, an available tool must be connected to the tool call module before it can be invoked, and the documentation recommends tuning a small number of tools before adding more.
The tool call termination node ends the current call. Once execution reaches it, no further tools are called and the AI does not summarise the tool results. Custom tool variables extend the inputs so that nodes not treated as tool parameters can still be invoked through the tool call path. Retrieval or a form collecting a value does not constitute authorised execution; business verification, approval, database writes and external synchronisation need their own downstream implementation. A pending request is not an approval, and an offered option is not an execution.
Hypothetical paper exercise sample: the source material reads, "Party A shall submit the rebate reconciliation statement to Party B within fifteen days after the end of each quarter; the rebate policy is governed by Annex 2 of the 2024 dealership agreement." The proposed handover request reads, "Please check the rebate amount against the reconciliation statement and the volume achievement table, and generate a red-letter invoice application." The request does not state the approval authority or the invoice offsetting rule, so both remain items to be verified. No approval, invoice or payment action has occurred.
Configuration and implementation checks
| Configuration item | Starting point for this hypothetical exercise | Comparison method and reason |
|---|---|---|
| Tool description | State the input conditions and the situations in which the tool should not be called | Compare against the sample source text and confirm the description covers the reconciliation statement and the volume achievement table |
| Tool parameters | Check each plugin parameter individually | Inspect the parameter description and the whether-required flag; when a required parameter is absent, do not assume the call succeeded |
| Tool connection | Connect the reconciliation statement reading tool first | Compare against the guidance to tune a small number of tools, and observe whether the expected call is triggered |
| Tool call termination | Place it after the rebate comparison tool | Check whether the AI summary is no longer invoked after termination |
| Custom tool variable | Fill in a parameter description for the volume achievement table node | Check whether that node is invoked through the tool call path |
These starting points are settings for this hypothetical exercise and are not official default values.
Three common errors
- Writing a generic tool description that omits the input conditions and the situations in which the tool should not be called. The check inputs the sample source text, compares whether the description covers the reconciliation statement and the volume achievement table, and observes whether the model is still guided to call the tool when a required parameter is missing.
- Treating a retrieval result or a collected form value as authorised execution. The check inputs the proposed handover request, compares whether the request states the approval authority and the invoice offsetting rule, and observes whether a red-letter invoice application action appears downstream without authorisation.
- Expecting the AI to summarise tool results after the tool call termination node. The check inputs the rebate comparison result, compares the position of the termination node, and observes whether no further tools and no AI summary are invoked.
How to verify the setup
- Input the sample source text and the proposed handover request, then compare whether the tool description states the input conditions and the situations in which the tool should not be called. The condition is satisfied when the model declines to call the tool because a required parameter is missing and prompts for the missing value.
- Input the proposed handover request, then compare whether the request states the approval authority and the invoice offsetting rule. The condition is satisfied when no red-letter invoice application action appears downstream and the item is recorded as pending verification.
- Input the rebate comparison result, then compare the position of the tool call termination node. The condition is satisfied when no further tools and no AI summary are invoked after termination. Retrieval checks require observing the actual return, and no guarantee is made that the first item matches or that all relevant items are recalled. An empty result can be checked against the downstream design using a paper input of an empty list; a fabricated rule is not claimed to return an empty result.