What this category's data looks like
This page focuses on kindergarten operation behavior and quality self-assessment; the materials include self-assessment reports, issue lists, and rectification plans. Self-assessment reports are produced by semester or academic year, and their fields include kindergarten name, indicator item, self-assessment conclusion, date, and signature; the issue list records, item by item, the issue description, related indicators, discovery method, responsible person, and rectification deadline; the rectification plan follows from the issue list and records measures, completion time, and receipt. When these three types of materials enter the exception tracing and manual review function, the self-assessment report serves as the source basis, the issue list serves as the exception clue, and the rectification plan serves as the disposal evidence. The fields, dates, and signatures of the three must be cross-compared to form an exception list and review conclusion.
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 exception list and review conclusion are completed by subsequent nodes parsing the response, or by an external system handling it as agreed. The HTTP node does not replace an external system in writing to the database or approving.
| Object | Check | Verification action |
|---|---|---|
| Self-assessment report | The indicator items and conclusions in the report must correspond one by one with the issue list, and the date and signature must be complete | Take one self-assessment conclusion, check the indicator name, quantity, date, and signature, then compare it with the issue list |
| Issue list | The issue description, related indicators, and the measures and deadlines in the rectification plan must be consistent | Use one issue record to trace back to the original text of the self-assessment report, and check whether the name, quantity, and date match |
| Rectification plan | The measures, completion time, and receipt must be synchronized with the version of the issue list | Check the version number and receipt signature, and inspect whether the signature or receipt is missing |
| HTTP request | The placeholder variables in the request URL, request headers, and request body can be parsed into actual values | View the fully rendered URL in the request preview, check the sources of Authorization and variables, and compare the responseData fields |
Three common errors
- Symptom: The name and quantity of the same issue do not match between the self-assessment report and the issue list. Cause: The two materials were entered separately, and no field-level comparison was performed.
- Symptom: The rectification plan has been updated, but the issue list still references the old version. Cause: The versions are not synchronized, and there is no unified version identifier.
- Symptom: The review conclusion lacks a signature or receipt. Cause: The manual review step does not enforce a trace, and signatures and receipts are not included in verification.
How to verify the setup
This function's acceptance: 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 external interface agreement.
Business test: create one exception record, see whether it can be traced back to the source material, and check the name, quantity, date, and signature.
- In the variables panel, check the source of each placeholder and confirm whether it comes from a global variable, system variable, or the output of a preceding node.
- Use one sample request to compare the response, check the request header names and value sources, and troubleshoot 401 and empty fields.