What the documents look like
Supermarket supplier settlement in this category usually runs as purchase-and-sale or consignment accounts, and a supplier does not necessarily operate an on-site counter. Order fulfilment and after-sales question handling therefore centre on four document types: the purchase contract, the delivery acceptance note, the rebate agreement, and the statement of account. These materials originate in different systems, including ERP purchasing, the supplier portal, POS sales, and the finance system, and they update weekly or monthly. When values are pulled across systems, field definitions and period boundaries frequently diverge.
The practical work concentrates on three points: reconciling accepted quantities, calculating rebate deduction rates, and handling return differences. Each of these needs both the single-transaction scope and the full-month scope kept separate, because a figure that is valid for one delivery line is not automatically valid for a monthly total.
Constraints at the HTTP integrations step
The HTTP module sends a request to the configured address, and its operation is close to tools such as Postman and ApiFox. Params carry path request parameters and are used more often with GET requests. Body carries the request body and is used more often with POST and PUT requests. Headers carry request headers for special information. All three data locations can reference variables through {{}}, and the URL can also reference variables. Variables come from global variables, system variables, and outputs of preceding nodes.
Return-value configuration describes how to parse the interface response. Values are extracted with JSON path syntax. When the output type is set to string, the value at the corresponding key is converted into a JSON string before output.
The HTTP node's system variables include appId, chatId, responseChatItemId, variables, cTime, and histories. In test mode, chatId and responseChatItemId do not exist. histories defaults to a maximum of 10 entries, and that length cannot be changed. These are inputs the node can reference. They are not fields that a supplier interface must return. Authentication, detail, and stream rules for the FastGPT chat API are checked separately under that API and are not carried over to an external settlement interface.
Accepted quantities, rebate deduction rates, and return differences are business reconciliation subjects. The HTTP module only sends and receives data according to the agreed contract. Retrieval and similarity scores do not carry permission or entity-isolation duties, and a retrieval result is not an authorization basis. Forms collect values. Business validation, approval, database writes, and external synchronization each require their own downstream implementation.
Hypothetical paper exercise. A supplier and a supermarket sign a purchase contract, number HT-2024-031, signed 2024-03-01, valid through 2025-02-28, providing for monthly reconciliation. A delivery acceptance note, number YS-2024-0407, records arrival on 2024-04-07 of 120 cases at a unit price of 30 yuan. A statement of account, number DZ-2024-04, records 100 cases for that arrival, amounting to 3000 yuan. A rebate agreement, number FL-2024-01, provides a 2-point rebate when monthly purchases reach 30000 yuan. One draft sentence is awaiting judgment: "The 120 cases arriving on 7 April have all been included in the April reconciliation." This sentence touches two different fields, one on the acceptance note and one on the statement, so quantity definitions must be compared before any judgment.
Configuration and implementation checks
| Configuration item | Hypothetical starting point and reason | Comparison method |
|---|---|---|
| Request address and method | Address and method are selected from the external interface document; the address can reference a variable already provided | Compare word by word against the address and method declared in the interface document |
| Params and Headers | Path parameters and request headers are checked separately; authentication credentials are injected through secure configuration | Compare against parameter name, type, and required status in the interface contract |
| Body | Used only under the corresponding request type; the JSON structure is checked against the contract | Compare against the request body structure given in the interface document |
| Variable references | Global variables, system variables, and preceding node outputs can be referenced | Check the actual source of each passed value against the expected source |
| Return-value parsing | Extraction follows JSON path; when output type is string, the value becomes a JSON string | Compare the key path against the actual response structure |
| Debug system variables | chatId and responseChatItemId do not exist in test mode | Check the run mode and variable source; check the external response separately against its own contract |
Three common errors
- Treating an empty chatId or responseChatItemId in test mode as a business fault. The input is a test-mode request, and the comparison is the documented statement that these do not exist in test mode. Check the node run mode and the available system variables first. The external response is checked separately against its own contract, and a missing system variable does not support an inference of business fault.
- Treating a retrieval result or similarity score as a permission or entity-isolation basis. The input is one retrieval return, and the comparison is the source of business authorization. The observable result is whether an authorization conclusion has an independent source elsewhere. Retrieval itself produces no authorization effect.
- Treating values collected by a form as already validated or already written. The input is form content submitted at an interactive node, and the comparison is the implementation of downstream validation, approval, writing, and synchronization. The observable result is whether those actions are performed by another stage.
How to verify the setup
- Take the delivery acceptance note YS-2024-0407 and the statement of account DZ-2024-04 from the hypothetical sample. Compare the two values for the same field, arrival quantity: 120 cases and 100 cases. The observable result is that the two disagree, so the draft sentence "have all been included" is not supported and must be marked as pending verification.
- Take the rebate agreement and the 3000-yuan statement record. Check the single-transaction amount and the full-month purchase amount separately. The monthly total is not provided, so whether the 30000-yuan threshold is reached cannot be determined. The 2-point condition and its calculation are checked separately, and the single-transaction amount cannot stand in for the full month.
- Check the system variables the HTTP node can reference in test mode. chatId and responseChatItemId do not exist as documented, and histories defaults to a maximum of 10 entries. Record the history actually carried and the mode in use. Do not require the external settlement interface to return these fields, and do not infer a business fault from them.