What the documents look like
Procurement and supplier records in wholesale stall trading sit on four document families: purchase notes, handwritten sales slips, stall lease contracts and payment receipts. Stall-level trading is fragmented, and on-site price negotiation plus shipping arrangements consume much of the working day. The documented consequences of getting this wrong are unpaid balances, wrong or short deliveries, and market disputes. Data sources named in the brief are wholesale market prices, stall inventory, WeChat payments and logistics shipping notes, with updates occurring daily and per order.
For the procurement task, these inputs usually arrive as manually written documents and as values returned by external interfaces. Formats vary and fields are frequently absent. The procurement task itself requires matching the item, quantity and supplier information on a purchase note against the amount and date on a payment receipt, and checking whether supplier records are complete. Scheduled workflows at this step trigger a data read or a request at a defined point in time and gather scattered document information into a record that can be checked. The trigger alone does not establish a connection to a business system; external data must be read through a configured interface.
Constraints at the scheduled workflows step
Trigger responsibility must be stated: whether the application's scheduling capability fires the task or an external scheduler does so must be checked against the actual version's available entry point. HTTP requests must be checked against the external interface documentation for method, headers, body and variable inputs. De-duplication, idempotency and business writes require explicit design in the interface or in a downstream flow, and cannot be claimed as automatic. Execution records must be checked for trigger time, actual input, returned result and business status; the existence of a task does not substitute for successful execution.
Hypothetical paper exercise. A stall holds a handwritten sales slip whose text reads: "12 March 2025, sold to buyer Liu, rebar HRB400 diameter 20 mm, quantity 12 tonnes, unit price at that day's market price, payment outstanding, settlement agreed before 20 March." A payment receipt reads: "18 March 2025, received from Liu the sum of RMB 42,000, corresponding to the 12 March sales slip." A draft sentence under review reads: "The system's scheduled task will automatically initiate balance collection from Liu on 20 March and will synchronously update the outstanding-debt status in the supplier records." This draft involves two business actions, automatic collection and automatic status update. The materials do not state any authorization or effective clause for either, so the evidence gap remains.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | How to check and compare |
|---|---|---|
| Trigger entry | Use the application's scheduling capability | Check the available entry point against the actual version, and distinguish it from an external scheduler |
| HTTP request method | POST | Confirm method, headers and body against the external interface documentation |
| Request body variable | Reference the purchase note number output by the preceding node | Check variable source and parsed result against the {{key}} syntax |
| Return value extraction | Configure key as data.user.name | Check the extracted value against JSON path syntax, with output type set to string |
| Execution record fields | Record trigger time, actual input and returned result | Compare item by item with business status to confirm consistency |
| Repeated trigger handling | Design explicitly in the interface or a downstream flow | Check de-duplication and idempotency design; do not assume they are automatic |
The POST method is chosen here because the external interface documentation labels record creation as POST. The key data.user.name is chosen because that path appears in the documented extraction examples. These starting points belong to this hypothetical exercise and are not official default values.
Three common errors
- Treating the existence of a scheduled task as successful execution. The input is one scheduled task in the task list; the comparison object is the trigger time and returned result in the execution records; the observable result is a task that exists with no corresponding execution record or with an empty return. Successful execution cannot be concluded in that case.
- Treating retrieval or a form as authorized execution. The input is one draft sentence under review; the comparison object is the authorization or effective clause in the source materials; the observable result is that the materials state no authorization clause. The automatic collection and automatic status update in the draft then remain unsupported.
- Writing an HTTP return-value extraction key as a path that does not exist. The input is the documented interface response example; the comparison object is the configured
keyagainst the actual fields in the response; the observable result is that the configured key has no corresponding value in the response. The extraction returns empty and the field name must be checked.
How to verify the setup
- Verification one: take the handwritten sales slip text and the payment receipt text from the hypothetical exercise as input. Compare the parties, dates, amounts and correspondence between the two documents. The observable result is that the two documents agree on the parties and on the correspondence, while the settlement status of the balance is not stated. The evidence gap remains at that point.
- Verification two: take the draft sentence "The system's scheduled task will automatically initiate balance collection from Liu on 20 March and will synchronously update the outstanding-debt status in the supplier records" as input. Compare the automatic actions in the draft against the authorization clauses in the source materials. The observable result is that the materials state no clause authorizing automatic collection or automatic status update, so the draft is unsupported.
- Verification three: take the configured return-value extraction key
data.user.nameand the documented interface response example as input. Compare that key against the actual field path in the response. The observable result is that the path has a corresponding value in the example and the extracted value matches the example. If the configured key has no corresponding field in the response, the extraction returns empty and the field name must be checked before reconfiguring.