What this category's data looks like
Laboratory hazardous chemical procurement and ledgers involve three types of materials: procurement applications, usage registrations, and inventory ledgers. Procurement applications contain product name, specification, quantity, application date, and approval signature; usage registrations contain the person using the item, usage date, purpose, and receipt; inventory ledgers contain the balance quantity, storage location, and inventory count date. The materials come from procurement systems, warehousing records, and manual reporting, and the update cadence changes with each procurement, usage, and inventory count. The field characteristics are that four types of information—name, quantity, date, and signature—are scattered across multiple materials. When entering this function, procurement applications and usage registrations serve as sources of request body fields, while the inventory ledger serves as the basis for comparison with fields returned by the external system; in the version ledger and change records, the three respectively play the roles of source data, flow records, and result verification.
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 version ledger and change records are parsed from the response by subsequent nodes, or handled by the external system according to the agreement and then completed. The HTTP module sends requests to the target address, and variables can be used as placeholders in three places: path parameters, request body, and request headers. The variables come from global variables, system variables, or outputs from preceding nodes.
| Object | Check | Verification action |
|---|---|---|
| Procurement application | Name, quantity, date, and signature are consistent between the application and the ledger | Take one procurement application and compare the application date, approval signature, and inventory ledger receipt date |
| Usage registration | The person using the item, usage date, quantity, and receipt correspond between the registration and the ledger | Take one usage registration and check the usage quantity against the ledger outbound quantity and the receipt signature |
| Inventory ledger | The current version is unique, old versions are traceable, and references are synchronized | Change one quantity and see whether the version number and materials referencing that quantity are updated synchronously |
| HTTP request | The placeholder variables in the request address, request headers, and request body can be resolved into actual values | In the request preview, view the fully rendered address and check the sources of Authorization and variables |
Three common errors
- Symptom: The quantity and date of the same procurement record do not match between the application and the ledger. Cause: The two materials are maintained separately and are not updated synchronously under the same version number.
- Symptom: An old version of a usage registration is still referenced, and the current version is not unique. Cause: After a change, the version ledger was not updated, and references were not replaced synchronously.
- Symptom: A usage registration lacks the signature of the person using the item or the receipt. Cause: The usage process is not closed-loop, and the registration material has not been completed according to the field requirements.
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 one sample to confirm that the fields in responseData are consistent with the agreement.
Business test: change one piece of content and see whether the version number and references are updated synchronously.
- In the variables panel, check the source of each placeholder and confirm that it comes from a global variable, system variable, or output from a preceding node.
- Take one sample request and compare the returned fields, checking that the request body fields are consistent with the external interface agreement.