What this category's data looks like
For materials in the laboratory hazardous chemical procurement and ledger category, the core includes three types: hazardous chemical procurement applications, usage registrations, and inventory ledgers. Procurement applications come from the research group or laboratory supervisor, and include the item name, specification, quantity, application date, and signature; usage registrations come from the user, and include the usage date, purpose, quantity, and receipt; inventory ledgers come from the custodian, and include the balance quantity, storage location, and update date. The three types of materials update at different rhythms: procurement applications are submitted as needed, usage registrations are recorded per instance, and inventory ledgers are summarized weekly or monthly. When entering the question-answering intake and missing-item follow-up function, procurement applications serve as the basis for demand, usage registrations serve as consumption evidence, and inventory ledgers serve as the balance baseline. Field characteristics are concentrated in four categories: name, quantity, date, and signature. The same record often shows inconsistencies across the three materials in name spelling, quantity basis, and date order, with versions not synchronized or missing signature receipts.
Configuration and implementation checks
This step is executed by the HTTP node in the workflow, which outputs the response body, status code, and returned fields. The "accepted records and items to be completed" are parsed by subsequent nodes from the response, or handled by an external system according to the agreement before proceeding. The HTTP module sends requests to the target address, and variables can be used as placeholders in all three places: path parameters, request body, and request headers. Variables come from global variables, system variables, or outputs from preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Hazardous chemical procurement application | Whether fields, dates, and signatures are complete: if any of item name, specification, quantity, application date, or applicant signature is missing, follow-up is required | Check whether the request body fields are consistent with the external interface agreement, and compare the return using a sample request |
| Usage registration | Whether fields, dates, and signatures are complete: if any of usage date, purpose, quantity, or user receipt is missing, follow-up is required | Check the request header names and value sources, and confirm that Authorization is passed in according to the external system's requirements |
| Inventory ledger | Whether fields, dates, and signatures are complete: if any of balance quantity, storage location, update date, or custodian signature is missing, follow-up is required | Check the source of each placeholder in the variables panel, and confirm that variables and responseData can be traced to specific origins |
| Request address and path parameters | Placeholder variables can be resolved into actual values, and the address and path parameters are consistent with the external interface agreement | View the fully rendered address in the request preview, and confirm that the path parameters have been replaced with actual values |
Three common errors
- Symptom: The name and quantity of the same record do not match between the procurement application and the inventory ledger. Cause: The two materials are maintained separately, are not checked against a unified item name and measurement basis, and versions are not synchronized.
- Symptom: The usage registration date is earlier than the procurement application date, or the balance quantity does not match the usage quantity. Cause: The materials update at different rhythms, usage records are not written back to the ledger, and dates and quantities are not cross-compared.
- Symptom: The external system receives empty fields or the request returns 401. Cause: The request header authentication information is not passed in according to the external system's requirements, or the request body fields are inconsistent with the interface agreement.
How to verify the setup
Acceptance for this function: preview the rendered request, check the status code and returned fields, then compare the result against a sample; confirm that the three identifiers Authorization, variables, and responseData can all be traced to their sources.
Business test: submit a question missing key information and see whether it asks for follow-up before answering; confirm that the missing item is identified and followed up on, that the answer has material evidence, and then forward it to the handler.
- Check the source of each placeholder in the variables panel, and confirm that global variables, system variables, or outputs from preceding nodes can be resolved into actual values.
- Compare the return using a sample request, check that the request body fields are consistent with the external interface agreement, and record the number of array items and the referenced text tokens.