FA.MENU 23-14
This process, stored in FA.REP as member SET.VERIF, is used when staff in the Financial Aid Office need to mark one or more student records, which originally were not marked by the Central Processing System (CPS), for financial aid verification. Alternatively, when the staff need to mark a record as waived from verification, this process is also used. The ID(s) to be processed for either of the operations are written to a saved list, which is specified as one of the input parameters in the run. The user also specifies whether the record(s) should be marked as being selected for verification (code "S") or are being waived (code "W"). Once this process is run, the records will be further processed via the XVER form in Colleague, where ultimately, records to be verified will have a verification status of "1" set, and waived records will have a verification status of "8".
Updates to this process have included a change to omit any student records currently having verification status of "7" (completed) from being marked. This change was added during May 2017. During October 2018, another change was made to omit any student records currently having verification status of "8" (waived). During November 2020, after encountering issues with records marked which had already been processed for verification, coding was added to omit students with verification status "1" or "2". Note that when processing students to be waived, the coding will still only check for verification statuses of "7" and "8".
FA.MENU 23-16
This process, stored in FA.REP as member VERIFICATION.COMPLETE.17, is used to produce a listing of students who have completed verification, for use by the Financial Aid Office staff. The process can be used for academic years 2017-18 and following. A previous version, named VERIFICATION.COMPLETE (still available as menu item 23-2), has been used in processing for academic years 2016-17 and prior. One of the main differences with the current, newer version is that multiple verification track codes can be specified by the operator, when separated by spaces only. This became necessary in academic year 2017-18, when three different tracks began to be used in verification (one each for types V1, V4, and V5).
XVER Form in Colleague
The Colleague form, XVER, was reviewed during October 2018, and it was found that the logic in the process is valid, and still needs to be performed. Actually, it would probably be more efficient to do this processing in a paragraph run from FA.MENU, but the current process does do the job. The basic functions of the program are listed below. An update was made to the process at this time, which will prevent records previously coded with verification status "7" or "8" from being changed by XVER.
1) Update CS records marked to be waived (status 8) via FA.MENU 23-14.
2) Update CS records marked for verification per CU request (status 1) via FA.MENU 23-14.
3) Check for previously processed records for recently Accepted, etc. that now need to be put on verification tracks.
4) Select records from above steps that match program type being processed (UG or GS).
5) Update CS records identified in the new UG or GS ISIR file (status 2).
6) Combine all records (saved lists) created through this point in the process.
7) Omit records as necessary, based on application status, withdrawal, or active hiatus.
8) Split records out into saved lists based on V1, V4, and V5 coding (this prepares for track assignment later).
9) Create output listings for each V1, V4, V5 list created.
10) When a GS V1 list has been created, the CS records are updated to be waived (status 8).
11) An output listing is created for records not in the new ISIR file that are retained during the run.
12) The V1, V4, and V5 saved lists generated from this processing are used as input to CRA, to assign verification tracks to students.