What this category's data looks like
This page addresses the scenario of primary and secondary school student status establishment and changes, involving three types of materials: student status records, transfer applications, and suspension/resumption materials. Student status records are organized by the school's student status administrator at the time of new student enrollment or at the beginning of the semester, with fields including name, ID number, date of birth, guardian, class, and student status number; transfer applications are submitted by the handler of the transferring-out or transferring-in school, with fields including student name, original school, target school, transfer date, and signatures of both parties; suspension/resumption materials are submitted by parents or guardians and verified by the homeroom teacher and school doctor, with fields including suspension start and end dates, resumption date, diagnosis certificate, and receipt. The material update rhythm changes with student status establishment at the beginning of the semester, transfers during the semester, and suspension/resumption approvals, and the name, quantity, date, and signature of the same record in different materials are prone to discrepancies. After the three types of materials enter the workflow, they each assume the roles of source evidence, basis for changes, and approval trail, providing input for subsequent verification and discrepancy location.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branching), outputting branch directions and interaction state records. The "discrepancy list" is then completed by subsequent nodes continuing execution according to the branch. When this node is triggered, the conversation enters an interaction state and records the workflow state; after the selection is completed, execution continues along the branch corresponding to the selected option.
| Object | Check | Verification action |
|---|---|---|
| Student status record | Name, ID number, date of birth, class, and student status number are consistent between the record and the ledger, and signatures are complete | Check the options and branch connections one by one in the node, trigger once to view the node status in the run record, and reference variables in subsequent nodes for a trial run |
| Transfer application | Student name, original school, target school, transfer date, and signatures of both parties are consistent in the two materials | Check the name, date, and signature of the transfer application and student status record, write discrepant fields into the discrepancy list, and hand them to the reviewer for confirmation |
| Suspension/resumption materials | Suspension start and end dates, resumption date, diagnosis certificate, and receipt are consistent in the two materials | Check the dates, quantities, and receipts of the suspension/resumption materials and the ledger, write discrepant fields into the discrepancy list, and write back |
| User selection node | Each option corresponds to one branch, the interaction state is recorded, and the selection result variable has been passed to subsequent nodes | Check the options and branch connections one by one in the node, trigger once to view the node status in the run record, reference variables in subsequent nodes, and run a trial once |
Three common errors
- Symptom: The name, quantity, and date of the same record do not match between the student status record and the transfer application. Cause: The two materials were entered by different handlers at different times, lacking a unified verification and discrepancy location step.
- Symptom: The versions of the transfer application and suspension/resumption materials are not synchronized, and the old version is still in circulation. Cause: After the materials were updated, re-verification was not triggered, and the workflow still continued execution along the old branch.
- Symptom: The suspension/resumption materials lack signatures or receipts, and the approval trail is incomplete. Cause: The submission step did not validate the signature and receipt fields, and the reviewer did not confirm before write-back.
How to verify the setup
This feature acceptance: run trials option by option, check the branch direction and interaction state in the run record, confirm that each option corresponds to one branch, that the selection result variable has been passed to subsequent nodes, and reference variables in subsequent nodes, checking nodeId and the run record.
Business test: use one real record to find fields inconsistent with the ledger, write them into the discrepancy list, and hand them to the reviewer for confirmation and write-back.
- Check the options and branch connections one by one in the node, trigger once to view the node status in the run record, and confirm that the interaction state is recorded.
- Reference the selection result variable in subsequent nodes and run a trial once, check whether the discrepancy list fields are consistent with the ledger, and hand them to the reviewer for confirmation and write-back.