What the documents look like
Omnichannel replenishment moves goods between stores and warehouses, so operating reviews and exception reviews rest on transfer requests, inventory snapshots, store shortage lists and transfer logistics notes. ERP inventory, store POS, e-commerce orders and WMS supply the underlying values. The three slowest steps are locating transferable stock, approving the transfer route, and updating arrival and putaway, which means any field misalignment passed through an interface can surface as overselling, a store stockout, or a book-to-physical mismatch. Daily and weekly update rhythms require the reporting basis to stay aligned with document status.
For this page the relevant material is a transfer request and the status it carries, because status is the field that decides whether a review may treat a movement as approved, executed or still pending.
Constraints at the HTTP integrations step
The HTTP module sends a request to a target address. Params, Headers and Body can each reference variables with {{}}, and the URL can also reference variables. Variables come from global variables, system variables and preceding node outputs. Body takes effect only under the relevant request type; a referenced string needs quotation marks, while numbers and booleans do not. Return values are extracted through JSON path or JS object access rules, and when the output type is set to string the corresponding value is converted into a json string.
Among system variables, chatId and responseChatItemId do not exist in test mode, so an empty value during debugging is not a business fault. The chat endpoint authenticates with an APIKey, and passing body.appId in the request body is recommended; appId priority runs body.appId, then <apiKey>-<appId>, then the appId associated with the apikey. Passed model and temperature fields have no effect because the orchestration decides them. detail=true returns intermediate values, and in non-stream mode the result is held in responseData. Proxying a team member identity through authProxy requires the team owner to enable it when creating or editing the key, and the proxied identity still needs permission on the target app and conversation. An interactive node returns only type and params; internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs and nodeResponseId are not returned.
A hypothetical paper exercise sample is used below for checking only. The material text reads: "Request T-2024-0312, requesting party East China warehouse, receiving party Nanjing Xinjiekou store, item spring knitwear size M, requested quantity 120 pieces, request date 12 March 2024, status pending review." A draft sentence to be judged reads: "This transfer request has been approved, inventory has been deducted from the East China warehouse and synchronized to the Nanjing Xinjiekou store." The material states pending review; approval, deduction and synchronization do not appear in the material and remain unsupported.
Configuration and implementation checks
The table below lists documented settings or implementation checks tied to this page's documents and main task.
| Configuration item | Hypothetical starting point for this exercise | Check note |
|---|---|---|
| Request address and method | Chosen against the external interface document; the address may reference variables | Confirm the address matches the transfer document service contract |
| Headers authentication | Authorization uses Bearer with a credential injected through secure configuration | Do not place the credential in a public sample |
| Body structure | References request number, item and quantity fields | Confirm the JSON structure against the external interface contract |
| Variable references | References global variables or preceding node outputs | Check each value actually passed in |
| Return value extraction | Extracts the status field by JSON path | A string output type converts the value into a json string |
| Debug identity fields | chatId and responseChatItemId do not exist in test mode | Do not treat an empty debug value as a business fault |
The hypothetical starting point is the pending review status because that status appears literally in the material and allows a field-by-field comparison with the draft sentence.
Three common errors
- Treating pending review as approved. The input material states "status pending review" while the draft sentence states "has been approved". Comparing the status field, pending review and approved are mutually exclusive values of the same field, so the draft sentence contradicts the material.
- Treating requested quantity as deducted quantity. The input material states "requested quantity 120 pieces" while the draft sentence states "inventory has been deducted from the East China warehouse". Comparing the quantity field against the action description, the material records no deduction action, so the draft sentence is unsupported.
- Treating form collection as authorized execution. The input draft sentence states "synchronized to the Nanjing Xinjiekou store" while the material contains no synchronization record. Comparing subject, object and action, synchronization is a business action requiring a separate downstream implementation, and the material records none, so this is an evidence gap.
How to verify the setup
- Input the hypothetical material text and the draft sentence, then compare the status field: the material reads pending review and the draft reads approved, the two are mutually exclusive, so the draft sentence is judged to contradict the material. The expected observation is that the status field conflict is identified.
- Input the material phrase "requested quantity 120 pieces" and the draft phrase "inventory has been deducted", then compare quantity against action: the material carries only a requested quantity and no deduction record, so the draft phrase is judged unsupported. The expected observation is that the evidence gap is flagged.
- Input the material text and the draft phrase "synchronized to the Nanjing Xinjiekou store", then compare subject, object and action: the material carries no synchronization record and synchronization requires a downstream system implementation, so the result is judged an evidence gap. The expected observation is that the item is recorded as pending verification without any claim that it was executed.
All three checks use the hypothetical sample as input and compare the same subject, the same period and the same field. Where support is absent, the gap is preserved and no authorization or effective clause is supplied.