What the documents look like
Omnichannel stock transfer work covers goods moving between stores and warehouses. It does not cover marketing outreach. The main data sources are ERP inventory, store POS, e-commerce orders and WMS. The everyday documents are transfer requests, inventory snapshots, store shortage lists and transfer logistics notes.
For operations handover, these materials record goods quantities, the mapping between stores and warehouses, and document status. They do not record who has been granted approval or execution rights. The deployment and upgrade step needs to check whether the status shown in the handover material and the permission boundary are consistent. A retrieval hit or a completed form does not constitute authorization.
Data update frequency is daily and weekly. This page does not depend on that cadence, so no batch synchronization, full synchronization, real-time or transaction-triggered mechanism is inferred from it.
Constraints at the upgrades step
A hypothetical drill sample is set out here for checking only.
Handover record text: "On 10 March 2026, transfer request T-0310 from Warehouse A to Store B, quantity 120 items, applicant has submitted, approval column blank."
Inventory snapshot text: "On 10 March 2026, available stock of this goods at Warehouse A is 300 items."
Request to be assessed: "Transfer the approval right for T-0310 to the next shift storekeeper, and treat it as approved for execution."
The approval column is blank and the current material provides no approval evidence, so approved execution is unsupported. Permission transfer and approval remain separate items to verify. The missing value establishes neither rejection nor an explicit contradiction. After an upgrade, verification uses the same sample to recheck import, retrieval and application invocation. Completing the steps is not a zero-interruption commitment.
The deployment version must be checked first against the target version and its upgrade notes. Current behaviour is not inferred from an old configuration field name. Dependencies and backups are checked according to the official deployment and upgrade steps, and recovery capability is verified in the operator's own environment.
Configuration and implementation checks
The table below lists documented settings or implementation checks relevant to this feature and the primary task, around the sample above. The values are hypothetical starting points for this trial and are compared against a same-environment baseline.
| Configuration item | Hypothetical starting point for this trial | How to check |
|---|---|---|
| AIPROXYAPIENDPOINT | Assume http://aiproxy:3000 | Compare with the AI Proxy service root address; no /v1 appended |
| AIPROXYAPITOKEN | Assume a non-empty admin token | Compare with the server-side configuration; this does not replace an application invocation credential |
| FILETOKENKEY | Assume a random strong key | Length at least 6 characters; compare against example values |
| AES256SECRETKEY | Assume a random strong key | Length at least 6 characters; compare against example values |
| INVOKETOKENSECRET | Assume a random strong key | Length at least 32 characters; compare against example values |
| SYNC_INDEX | Assume true | Compare against the index maintenance behaviour at startup |
From V4.17.0, AI Proxy is a required dependency. App and Admin services that reuse App/Service configuration must set AIPROXY_API_ENDPOINT and a non-empty AIPROXY_API_TOKEN. Missing either item causes startup validation to fail. Legacy OpenAI environment variables or a single-model custom request address cannot replace these two configurations.
FILE_TOKEN_KEY, AES256_SECRET_KEY and INVOKE_TOKEN_SECRET are required at runtime. Random strong keys are recommended, and example values are not used.
The V4.17.2 upgrade includes two manually triggered upgrade scripts visible under Admin > Version Upgrade. The historical chunk training task migration (20261008_migrate_chunk_training) is manually triggered and does not block service startup; it is run after all old-version FastGPT App and Pro instances in the cluster have fully stopped and old task leases have expired. The knowledge base rebuild status migration (20261009_migrate_dataset_rebuild_status) depends on the first migration completing, is manually triggered, and does not block service startup.
Three common errors
- Treating a retrieval hit as a permission basis. Input the handover record and the claim of approved execution, then check the approval column and approval record. The column is blank, so the claim is unsupported; the missing value does not establish an explicit contradiction.
- Treating a form entry as completed authorization. The input is the permission handover form; the comparison object is whether the approval column has been filled. If the permission is treated as handed over merely because the form was submitted, approval evidence is missing.
- Inferring absent operating permission from an approval-record gap. Input the blank approval column and the applicant's submitted status, then check approval evidence and permission records separately. Those two entries do not establish that the applicant lacks permission.
How to verify the setup
- Input the handover record text and the request to be assessed. Compare "approval column blank" with "treat it as approved for execution". If the source text contains no value for an approval field, record the outcome as unsupported.
- Input the inventory snapshot text and the transfer request quantity. Compare 300 items with 120 items. If the snapshot available stock exceeds the requested quantity, this shows only that the quantity can be covered; it does not show that approval has passed.
- Input the paper empty result
[]. Compare whether the downstream design handles an empty result as no record. If the downstream does not define an empty-result branch, record the outcome as pending verification. This does not assert that a fictional rule returns[].
After the upgrade, the same sample is used to recheck import, retrieval and application invocation. Retrieval is not authorization. A relevance score is not a category, entity or permission filter, and a similarity setting does not exclude unrelated businesses or unauthorized records.