What the documents look like
Near-expiry markdown handling follows the shelf-life of stock rather than the weighing of individual orders. The working materials are the near-expiry list, the markdown approval, the damage report, and the promotional price tag. Data arrives from POS stock age, store inspections, ERP inventory, and quality inspection records, with updates typically at day or shift level. In order fulfilment and after-sales answering, these four materials must be linked to external systems: once a store confirms that a batch has entered near-expiry status, the markdown approval result must reach the promotional price tag, and an after-sales question must check whether the damage report and the markdown approval sit in the same authorization state. The authorization status, effective scope, and subject identity carried by these materials determine whether an HTTP request can carry the correct object identifier.
A hypothetical drill sample is used throughout this page. A store shift inspection record dated 10 March 2026 states: "Batch A yogurt, 12 units, shelf life to 14 March, 12 units remaining on shelf, inspector recommends 30% markdown." A markdown approval form of the same date states: "Batch A, 30% markdown, approval status: approved, approver: store manager Li, effective scope: 10 March to 13 March." The draft handover request reads: "Please synchronize the 30% markdown for Batch A to the external promotion system, and reply to the customer question about whether this batch can be returned or exchanged." The authorization boundary of this request is that the markdown approval is approved; the damage report and the return-and-exchange rule do not appear in the materials.
Constraints at the HTTP integrations step
The HTTP module sends a request to the corresponding address. Params, Headers, and Body can each reference global variables, system variables, or prior node outputs through {{}}, and the URL also supports variable references. System variables include appId, chatId, responseChatItemId, variables, cTime, and histories. Of these, chatId and responseChatItemId do not exist in test mode, so an empty value during debugging does not by itself indicate a business fault. Return values are extracted through JSON path; when the output type is string, the value of the corresponding key is converted into a JSON string. When calling the chat interface at chat/completions, passing body.appId in the request body is recommended, and Authorization: Bearer <apiKey>-<appId> is also supported; if a 404 appears on BaseUrl, adding v1 and retrying is permitted. The model, temperature, and similar fields passed in are invalid, because these are decided by the orchestration. The interactive value returned by an interaction node contains only type and params; internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs, and nodeResponseId are not returned.
For the drill sample, the request address is selected from the external promotion system's interface documentation, the method is chosen according to that interface contract, and the Body must carry the batch identifier, the markdown ratio, and the effective start and end. The batch identifier is taken from the prior node output, and the markdown ratio and dates are compared field by field against the approval form text. The approval form states only the 30% markdown and the effective scope from 10 March to 13 March. The damage report and the return-and-exchange rule are not present in the materials, so any after-sales reply about return or exchange lacks a stated basis.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this drill | Reason for the choice and comparison method |
|---|---|---|
| Request address | The markdown synchronization address provided by the external promotion system | Selected from the external interface documentation; compared with the effective scope stated on the approval form |
| Request method | POST | Selected from the external interface contract; compared with the method declared in the interface documentation |
| Headers authentication | Authorization referencing a configured variable | Credentials injected through secure configuration; compared with the authentication method required by the interface documentation |
| Body structure | Contains batch identifier, markdown ratio, effective start and end | Compared field by field against the approval form text; a missing field is recorded as a gap |
| Variable reference | References the batch identifier from a prior node output | The actual passed value is checked against the batch identifier in the inspection record |
| Return value extraction | Extracts the synchronization result field by JSON path | Compared against the external interface response structure; no success value is presumed |
Three common errors
- Treating the "approved" status on the markdown approval form as authorization for the damage report and the return-and-exchange rule. The approval form states only the 30% markdown and its effective scope; the damage report and the return-and-exchange rule do not appear in the materials, so the after-sales reply lacks a stated basis.
- Treating the absence of chatId and responseChatItemId in test mode as a business fault. An empty debugging value is unrelated to business authorization status and cannot be used to conclude that synchronization failed.
- Treating the interactive display configuration as internal runtime state. Fields such as entryNodeIds and memoryEdges are not returned, so node execution paths or a completed approval cannot be inferred from them.
How to verify the setup
- Input the inspection record and the approval form text from the drill sample, and compare the batch identifier, markdown ratio, and effective start and end in the draft handover request against the approval form fields. If the three match and the approval status is approved, the markdown synchronization part of the request has a material basis; the damage report and return-and-exchange fields are missing from the materials and are recorded as unsupported.
- Input the draft handover request from the drill sample, and compare the sentence "reply to the customer question about whether this batch can be returned or exchanged" against whether the materials state a return-and-exchange rule. If no rule is stated, that part of the reply lacks a basis, and the evidence gap must be recorded; authorization for return or exchange must not be inferred.
- Input the approval form text from the drill sample, and compare the effective scope "10 March to 13 March" against the request date. If the request date falls inside the effective scope, the markdown synchronization has a time-dimension condition; if it falls outside, a new approval record must be checked, and the original approval must not be reused.