What this category's data looks like
This page focuses on laboratory hazardous chemical procurement and ledgers, and the materials include three types: hazardous chemical procurement applications, requisition registrations, and inventory ledgers. Procurement applications record the item name, specification, quantity, application date, and approval signature; requisition registrations record the requisitioner, requisition quantity, requisition date, and issuer signature; inventory ledgers record the balance quantity, batch, date, and custodian signature. The three types of materials are updated on a rolling basis by batch and date, and the field characteristics are the four categories of name, quantity, date, and signature. When entering the abnormal traceback and manual review function, the procurement application serves as the source basis, the requisition registration serves as the intermediate consumption voucher, and the inventory ledger serves as the balance verification underlying account; together, the three support the generation of the abnormal list and review conclusions.
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 abnormal list and review conclusions are parsed from the response by subsequent nodes, or handled by an external system according to the agreement to complete the rest. The HTTP node does not replace the external system in writing to the database or approving.
| Object | Check | Verification action |
|---|---|---|
| Hazardous chemical procurement application | The name, quantity, application date, and approval signature are consistent across the three materials | Retrieve the procurement application, requisition registration, and inventory ledger and compare them field by field, and check whether the signature and receipt are complete |
| Requisition registration | The requisition quantity, requisition date, and issuer signature can be traced to the corresponding procurement application | Link the requisition registration and procurement application by batch number, and check whether the quantity and date match |
| Inventory ledger | The balance quantity, batch, date, and custodian signature connect with the requisition registration | Check whether the ledger balance matches the consumption in the requisition registration, and check whether the version is synchronized |
| HTTP request configuration | The placeholder variables in the request URL, request headers, and request body can be resolved into actual values | View the fully rendered URL in the request preview, and check the sources and values of Authorization, variables, and responseData |
Three common errors
- Symptom: The name and quantity of the same record do not match between the procurement application and the requisition registration. Cause: The two materials are entered separately, field-level verification by batch number is not performed, and the source material and consumption voucher are disconnected.
- Symptom: The inventory ledger version is not synchronized, and the balance quantity is inconsistent with the consumption in the requisition registration. Cause: The ledger update is later than the requisition registration, or the external system write-back is not triggered as agreed.
- Symptom: The procurement application lacks an approval signature, and the requisition registration lacks the issuer receipt. Cause: The signature and receipt steps are not included in the abnormal list, and the responsible person cannot be traced during manual review.
How to verify the setup
Acceptance of this function: preview the rendered request, check the status code and returned fields, then compare the result against one sample to confirm that the abnormal identifier in responseData corresponds to the original record.
Business test: create one abnormal record, see whether it can be traced to the source material, and confirm that the three materials—procurement application, requisition registration, and inventory ledger—can be traced back field by field.
- In the variable panel, check the source of each placeholder, confirm that
variablescan be traced to global variables, system variables, or the output of preceding nodes, and pass inAuthorizationin the request headers according to the external system's requirements. - Use one sample request to compare the return, check that the request body fields are consistent with the external interface agreement, and record the number of array entries and the tokens of the referenced text, so as to avoid the external system receiving empty fields or request timeouts.