What the documents look like
Omnichannel stock transfer work moves goods between stores and warehouses. It does not handle marketing outreach. The daily materials are transfer requests, inventory snapshots, store shortage lists, and transfer logistics notes. These come from ERP inventory, store POS, e-commerce orders, and WMS. The material update rhythm given for this category is daily and weekly.
Product data and selection questions must answer three things: which items a transfer request covers, how much of each item is transferable in the current inventory snapshot, and whether a shortage list and a request point at the same item. Model connections and configuration decide whether these questions reliably reach the source text of those materials.
Constraints at the model connections step
FastGPT requires at least one language model and one index model before it can be used normally. Model ID is the value of the model field in the request body and is globally unique. Model name is for display only. A model channel is separated by provider protocol, and one model can be configured across several channels for load balancing. Channel priority ranges from 1 to 100, and a larger value is selected more readily. Model mapping sends the model requested by FastGPT to the actual upstream model; for example, a request for gpt-4o-test reaches the upstream as gpt-4o.
Model status probing covers only currently enabled system models. A failed probe retries at most 3 times, so one round makes at most 4 attempts; one success is enough to count as valid, and only 4 failed attempts produce an abnormal result. Normal means the test succeeded with a response latency of 30s or less. High latency means the test succeeded but took longer than 30s. Retrieval returns materials. It does not grant authorization, and a relevance score does not act as an entity or permission filter.
Hypothetical drill sample, marked as hypothetical: the source material reads "Transfer request TA-0417, requesting party: East China store group, item objects: SKU-8823 and SKU-8824, requested quantity 40 units each, request date 2026-04-17, status is pending review." The inventory snapshot passage reads "Snapshot date 2026-04-17, SKU-8823 transferable 25 units, SKU-8824 transferable 60 units." The draft sentence to be judged reads: "TA-0417 is approved, and the transferable quantity of SKU-8823 meets the request." This sentence touches two facts: approval and quantity.
Configuration and implementation checks
The table below is the configuration checklist for this hypothetical drill. The values are drill starting points and must be confirmed against source material or channel test results. They are not official default values.
| Configuration item | Hypothetical starting point for this drill | How to check |
|---|---|---|
| Language model enabled | One enabled language model | Confirm enablement on the system model page and compare with the capability the question needs |
| Index model enabled | One enabled index model | Confirm enablement; the index model governs text block retrieval |
| Model ID | A dedicated ID for SKU questions | Match the model field inside the channel; globally unique |
| Channel priority | 50 | Range 1 to 100; compare with other channels of the same model |
| Model probe interval | 30 minutes | Documentation supports integers from 5 to 60; compare with alerting needs |
| Alert webhook | One HTTPS address | Use the test button to push a simulated error and a simulated recovery |
Three common errors
- Treating pending review as approved. In the sample, TA-0417 has status pending review, while the draft sentence states "is approved." Both values sit on the same status field of the same request, and they differ.
- Treating transferable quantity as automatically meeting the request. SKU-8823 shows 25 transferable units against a request of 40 units, so the quantity field does not meet it; SKU-8824 shows 60 units and does meet it. The two items need separate judgments.
- Treating a successful channel test as business authorization. A channel test verifies model connectivity only. It does not change the approval status of a transfer request and does not write any inventory record.
How to verify the setup
- Input the sample source text and the draft sentence. Compare whether "pending review" and "is approved" point to the same status field of the same request. If the draft sentence keeps "is approved," it is judged contradictory to the source. If it is rewritten as "pending review, approval result not stated," it agrees with the source.
- Input the inventory snapshot passage and the draft sentence. Compare SKU-8823's 25 transferable units with the requested 40 units. If the draft sentence claims the request is met, it is judged contradictory to the quantity field. If it states separately that SKU-8823 does not meet it and SKU-8824 does, it agrees with the source.
- Input an empty retrieval result, written explicitly as a paper input of
[], and check whether the downstream question output states "no related material retrieved" and preserves the evidence gap. If the downstream output asserts on that basis that the request is approved or that stock is sufficient, it has gone beyond the retrieval scope. If it records only the gap, it matches the expected design.
These checks are paper comparisons. They have not been run against a live system, and no approval, refund, deployment, or other business action is claimed. A pending request is not an approval, an offered option is not execution, and an unsigned termination is not a completed termination. Form values collected during configuration are values only; business verification, approval, database writes, and external synchronization require their own downstream implementation that the supplied documents do not describe.