What this category's data looks like
Materials for modern apprenticeship and order class management include school-enterprise cooperation agreements, order class training plans, and mentor apprenticeship records. Together, the three constrain the position, cycle, and assessment of the same group of apprentices. The school-enterprise cooperation agreement determines the cooperating entities and term, the order class training plan specifies the courses and rotation arrangements, and the mentor apprenticeship records register the apprenticeship date, mentor name, and apprentice signature one by one. Materials are updated by semester or batch, and the fields mainly consist of apprentice name, order class name, mentor name, date, quantity, signature, and receipt. When entering the exception tracing and manual review function, the cooperation agreement and training plan serve as the comparison baseline, and the apprenticeship records serve as the original records being traced. When the names, quantities, or dates among the three are inconsistent, or the versions are not synchronized, or signatures or receipts are missing, an exception list is formed and handed to the reviewer for signature confirmation, then handed to the person in charge for handling.
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 parsed from the response by subsequent nodes, or handled and completed by the external system according to the agreement. The request URL, path parameters, request headers, and request body can all reference global variables, system variables, or outputs from preceding nodes through variables. Authentication information is placed in the request headers according to the external system's requirements, for example Authorization.
| Object | Check | Verification action |
|---|---|---|
| School-enterprise cooperation agreement | The cooperating entities, term, and order class name in the agreement must correspond item by item with the training plan and apprenticeship records, and dates and signatures must not be missing | Search for the agreement by apprentice name and order class name, and verify the signing date, validity period, and signatures and receipts of both parties |
| Order class training plan | The courses, rotation batches, and number of apprentices in the plan must be consistent with the agreement and the actual batches in the apprenticeship records | Extract the batches and headcount from the plan, compare them one by one with the apprenticeship records, and mark entries whose quantity or date does not match |
| Mentor apprenticeship records | Each record should have the mentor name, apprenticeship date, apprentice signature, and receipt, and the name spelling should remain in the same version as the agreement and plan | Using one exception record as the entry point, trace back to the agreement clauses and plan batches it references, and inspect the scanned copies of the original materials |
| HTTP request return | The responseData field in the response body should contain the exception identifier and the pointer to the original record, and the status code should be a successful return | In the request preview, verify the rendered URL and request body, and confirm that responseData can locate the source material |
Three common errors
- Symptom: The same apprentice's name spelling or headcount does not match between the agreement and the apprenticeship records. Cause: The two materials were entered separately and were not checked against unified fields and versions.
- Symptom: The training plan has been updated, but the apprenticeship records still reference the old batch date. Cause: The versions were not synchronized, and an outdated baseline was used during exception tracing.
- Symptom: The apprenticeship records lack the apprentice signature or receipt, so the review cannot be closed. Cause: The signature items were not checked when the materials were archived, and the reviewer cannot sign for confirmation.
How to verify the setup
Acceptance of this function: preview the rendered request, check the status code and returned fields, confirm that the response body contains responseData and the exception identifier, and then compare the result against one sample.
Business test: create one exception record, see whether the source material can be traced, and verify the reviewer's signature and the destination of the person in charge's handling.
- In the variables panel, check the source of each placeholder and confirm that the
variablesin the path parameters, request headers, and request body can all be resolved into actual values - Check the request header names and value sources, and confirm that authentication information is passed in according to the external system's requirements, avoiding a 401 return or empty fields