Using Enrollment Related Processes

This chapter discusses how to:

• Create historical enrollment records.

• Manage wait lists.

• Process withdrawals and cancellations.

• Purge drop enrollment records.

Creating Historical Enrollment Records

This section discusses how to record historical enrollment records.

Pages Used to Create Historical Enrollment Records

Recording Historical Enrollment Records

Access the Historical Course Enrollment page.

Academic Institution	Select the academic institution for which you want to record historical enrollment data for the student.
Term	Select the term for which you want to record historical enrollment data for the student. The term that you select must be less than or equal to the last term for historical enrollment data for the specified academic career.
Enroll Seq (enrollment sequence)	Indicates the sequence in which a student enrolled in each course within a term. The system by default displays a chronological enrollment sequence number starting with 1, but you can override this default value for any row.
Subject Area	Select the subject area of the course for which you want to record historical enrollment data for the student.
Catalog Number	Enter the catalog number of the course for which you want to record historical enrollment data for the student. Because this is a stand-alone page, it has no connection to your current course catalog.
Units Taken	Enter the number of units that the student took for the course.
Units Passed	Enter the number of units that the student passed for the course.
Official Grade	Enter the official grade that the student received for the course.
Grade Points	Enter the grade points that the student received for the course.
Description	Enter the title of the course.
Transcript Text	Click to access the Historical Course Enrollment - Transcript Text page, where you can enter free-form transcript text. This information, along with the historical enrollment information, appears on the student's transcript.

Note. Courses entered on the Historical Course Enrollment page do not impact Academic Advisement’s analysis processes or academic statistics. To include historical courses in advisement processes and academic statistics, you must treat them as transfer courses. Create a fictional academic institution, use the transfer credit process to create pseudo incoming courses, and then map those courses to your academic institution’s course equivalencies.

See Also

Reviewing Examples of Course Equivalencies

Preparing for Data Conversion

Managing Wait Lists

This section provides an overview of wait list management and discusses how to:

• View a student’s wait list position.

• Move students from wait lists to enrollment.

• Purge students from wait lists.

Understanding Wait List Management

The wait list management functionality in Student Records enables you to set processing parameters that define the groups of students to move from wait lists to enrollment into classes within a specific enrollment period. This section provides information on the following topics:

• Waitlist position numbers.

• Automatic enroll from waitlist.

Waitlist Position Numbers

When a student enrolls or is waitlisted into a class the Enrollment process assigns him the next available student position number. For instance, the first student to enroll in a class would get a student position number of 10, the second 20, the third 30, and so on. Student position numbers identify the order in which students enroll into a class. In addition, student position numbers determine the position students hold on the waitlist: the student with the wait list position number of 1 is the student who has the lowest student position number and an enrollment status of waiting.

For example, suppose Mia is the 31st student to try to enroll into a class with an enrollment capacity of 30. She is put on the wait list (has an enrollment status of waiting) and the Enrollment process gives her a student position number of 310. Her waitlist position number is 1, because she is the only student in the class with an enrollment status of waiting. Then a second student, Mitch, puts himself on the waitlist. The system gives him a student position number of 320. Since Mia has a lower student position number than Mitch, the system gives Mitch a waitlist position number of 2. If there is one seat available when you run the Waitlist process, Mia, the student with the lowest waitlist position number, is enrolled (the Enrollment process changes her enrollment status from waiting to enrolled). Mitch then has the lowest position number with an enrollment status of waiting. Therefore, his waitlist position number changes to 1.

In multiple component classes, the Enrollment process assigns students the next available student position number for each component. For this reason, a single student will often have different waitlist position numbers for each component. For example, a student could have a student position number of 130 and a wait list position number of 1 for one component, and a student position number of 60 and a waitlist position number of 3 for the related component (depending on how many students were already enrolled and were on the waitlist for each component at the time the student received a student position number).

When the process runs on a class section, it creates an enrollment request. The enrollment request includes all related components of the class. For the enrollment engine to process an enrollment request successfully, all related components have to have a seat available for that request. If all related components have a seat available for that request, the enrollment engine enrolls the student into all of the related components. If at least one related component is full, the enrollment engine would produce an error for the request, and the student would not get enrolled into any of the related components.

Note. The Waitlist process runs on non enrollment components as well as on enrollment components. The process creates enrollment requests for students based on their positions on the waitlist in the section on which the process is running (which is not necessarily the enrollment component). Thus, the order in which the process runs on class sections is important, because the process might not enroll students in the order that they would expect, if they expect to be enrolled based on their waitlist position number in a section that was run after a related section.

You can run the Wait List process on a term, session, subject area, course, or class. The process runs on classes in sequential order based on the criteria on which you run the process, and on the key structure of the CLASS_TBL (course ID, course offering number, term, session code, and class section). For example, when you run the process on a term, the process first runs in order of course ID: 000001, 000002 and so on. If there are two courses with course ID 000001, it runs by course offering number: course 000001, course offering number 1, course 000001, course offering number 2, and so on. In the same way, the process would then go by session code (unless you selected session as one of your criteria on the Wait List Process page), and then by class number. So within a course, course offering number, and session, the process would run on class section 1, class section 2, and so on. Because the Wait List process runs by class section, it would run on a multiple component class that has two lectures (sections 1 and 2) and two labs (sections 1A and 1B), in the following order: section 1, 1A, 1B, 2.

As you can see, the order of your classes and sections in the schedule of classes determine the order in which students are moved from the waitlist into the class for multiple component classes. Suppose you had two multiple component classes that shared a component, such as two biology lectures that share a lab, which have the following class sections: 1 (lecture), 1A (lab), and 2 (lecture). When you run the waitlist process on this class, the process creates enrollment requests for waitlisted students for section 1 and for its related class, section 1A. If there are available seats in section 1 and 1A, the process would move students from the waitlist into both components. Then the process will run on section 1A (because section 1A is sequentially next based on the key structure of the CLASS_TBL). If there are still students on the waitlist in section 1A (because they are on the waitlist for section 2, which has not yet been run), the process creates enrollment requests for those students. Again, if their are available seats in section 1A and section 2, the enrollment engine would process the requests successfully. Finally, the process would run on section 2.

For example, Mia has a waitlist position number of 1 in section 2, and a waitlist position number of 5 in the related section 1A. Additionally, Mitch has a waitlist position number of 3 in section 1A. Since the Wait List process runs on section 1A first, Mia get's put into the class after Mitch. The Wait List process evaluates Mia based on her position on the waitlist in section 1A, even though section 2 is the enrollment component.

Automatic Enroll from Waitlist Feature

The Wait List feature is controlled by the Auto Enroll From Wait List and Wait List Capacity options (on the Enrollment Control page of the schedule of classes) and the Last Day For Wait List date (on the Session Table page for classes with traditional academic calendars and on the Dynamic Class Dates page for classes with dynamic academic calendars). In addition, students have a wait list unit limit defined by academic load for terms and sessions within their primary academic programs on the Enrollment page and Session page of the Academic Program Table component.

If you select the Auto Enroll From Wait List option for a class, you can use the wait list process to move qualified students from the class wait list to enrollment into that class as space becomes available. If you do not select this option, you can manually move students from the wait list to enrollment into a class by selecting Override Class Limit on the enrollment processing component. The manual process is best monitored by the instructor of the class.

As you manage your wait lists, you can use the Class Roster page to view students on the wait list for a particular class section. The system performs corequisite and prerequisite checking before placing a student on the waitlist. However, the system does not check for a scheduling time conflict before it places a student on a wait list. Scheduling time conflicts and all of the other enrollment edits are performed when the system attempts to move a student from the wait list to enrollment in a class. You can view an individual student’s position and status on the wait list for a class through the Wait List Position link. This link appears only for applicable enrollment requests on the enrollment request processing pages.

Enabling the Wait List Process

To enable the wait list process:

1. Set the last date for wait list for sessions on the Session Table page of the Term/Session Table component.

2. Define the maximum wait list units for terms within academic programs on the Enrollment page of the Academic Program Table component.

3. Define the maximum wait list units for sessions within academic programs on the Session page of the Academic Program Table component.

4. Select the Auto Enroll From Wait List check box for classes on the Enrollment Control page of the schedule of classes.

See Also

Viewing Class Rosters

Pages Used to Manage Wait Lists

Viewing a Student’s Wait List Position

If your institution has licensed PeopleSoft Enterprise Campus Self Service, your students can also view their statuses and positions directly over the web. Wait list position numbers appear on the class schedule.

See Also

Viewing a Class Schedule

Moving Students From Wait Lists to Enrollment

Access the Wait List Process page.

Run the Wait List COBOL/SQL process (SRPCWAIT) as needed.

The process generates a new enrollment request for the student and displays one of the following enrollment status reasons on the new request: RCAP (reserve slots full), FULL (section is full), CREQ (corequisite enrollment), ALIM (appointment limit exceeded), TLIM (term limit exceeded), SLIM (session limit exceeded), TIME (time conflict exists), RCMP (related component), TIMR (time conflict resolved), or EWAT (enrolled from wait list). You can view these enrollment requests through the Block Enroll component.

If a class has reserve capacity rules and space opens in a reserve capacity group, the process evaluates whether students on the wait list meet these reserve capacity rules. If no students meet the rules, then the process moves no one from the class wait list to enrollment into the class. If a class has multiple reserve capacity groups and space opens in more than one group and a student matches the criteria of more than one reserve capacity group, the system enrolls the student into the first reserve capacity group it finds where the student meets the reserve capacity rules.

Purging Students From Wait Lists

Access the Wait List Purge page.

Sequence Number	The system displays a default sequence number. It is for internal processing purposes only.
Academic Institution	Select the academic institution for which you want to purge students from wait lists.
Term	Select the term for which you want to purge students from wait lists.
Academic Career	If you want to purge students from wait lists for classes within a specific academic career, select a value for this field. Note. This field and the remaining fields on this page are optional. They provide the means of searching for wait lists by various parameters.
Session	If you want to purge students from wait lists for classes within a specific session, select a value for this field.
Subject Area	If you want to purge students from wait lists for a specific class subject area, select a value for this field.
Class Nbr (class number)	If you want to purge students from wait lists for a specific class, select a value for this field.
Campus	If you want to purge students from wait lists for classes at a specific campus, select a value for this field.
From Date	If you want to purge from wait lists the students in waiting status with an class start date greater than or equal to a certain date, enter the date in this field.
To Date	If you want to purge from wait lists the students in waiting status with a class start date less than or equal to a certain date, enter the date in this field. The system displays, by default, the value in the From Date field.
Last Date for Wait List	Enter a value in this field to have the process search for active wait lists in which the class last date for wait list value is less than or equal to the value that you specify here. Define last date for wait list values on the Session Table page for classes with traditional academic calendars.

Processing Withdrawals and Cancellations

This section provides an overview of withdrawal and cancellation processing, lists common elements, and discusses how to:

• Post withdrawals and cancellations for terms.

• Post withdrawals and cancellations for sessions.

• Resubmit failed withdrawal and cancellation requests.

• View withdrawal and cancellation request status.

See Also

Calculating Tuition and Fees

Understanding Withdrawal and Cancellation Processing

In Student Records, you can enter and post withdrawals or cancellations for a term or session on a student-by-student basis through the Student Records Term Withdrawal COBOL/SQL process (SRPCWDPR). When you withdrawal or cancel a student from a term, the process performs a series of session withdrawals or cancellations to complete the term withdrawal or cancellation. A student cannot be cancelled from a session, and therefore a term, in which grades have been posted. The system prevents this with an error message and does so because enrollments for cancelled terms and sessions are always excluded from the transcript. Withdrawals can be processed when grades are present, however the classes with grades will be excluded from the process. A warning message appears when you select the Withdrawal code for a session or term where grades are present.

Important! If you have not calculated the landmark calendar dates for the affected class enrollments, the Student Records Term Withdrawal process fails the entire withdrawal or cancellation request.

For term and session cancellations, the Student Records Term Withdrawal COBOL/SQL process retrieves the applicable cancel deadline and reason as follows.

• If the impacted student enrollment record (STDNT_ENRL) is a traditional class enrollment, the process retrieves the cancel deadline and reason according to the values set on the Session Calendar 1 page.

• If the impacted student enrollment record is a dynamic date class enrollment, the process retrieves the cancel deadline calculated by the Dynamic Class Dates process and displayed on the Dynamic Class Data page and the cancel reason according to the value set on the Dynamic Date page of the Academic Program Table component.

  If the process fails to find a row in the Dynamic Class Dates table for the class, it will attempt to retrieve this information from the session academic calendar table. This will also occur if the Dynamic date cancellation reason has not been populated. In either case, the process searches for a row in the session calendar table and uses the field and deadline from that table if it exists.

• If the impacted student enrollment record is an open entry/exit class enrollment, the process retrieves the cancel deadline calculated upon enrollment and displayed on the Student Enroll OEE page and the cancel reason according to the value set on the Dynamic Date page of the Academic Program Table component.

If this deadline has passed, the process displays a warning message. You then have the option to cancel or continue with the request. If you continue, the process does the following.

• Generates and processes enrollment requests for each impacted student enrollment record.

• Retains the affected student enrollment records as drops with enrollment action reasons equal to the applicable cancel reason.

• Updates the withdrawal code on the affected student session records (STDNT_SESSION) to a value of cancelled.

• Updates the withdrawal code on the affected student career term record (STDNT_CAR_TERM) to a value of cancelled for term cancellations only.

For term and session withdrawals, the Student Records Term Withdrawal process determines the deadline by comparing the last date of attendance entered on the Term Withdrawal or Session Withdrawal page to the withdrawal deadlines that you set on the Session Calendar 1 page or to the withdrawal deadlines that the Dynamic Class Dates process calculates and displays on the Dynamic Class Data page or Student Enroll OEE page. The Student Records Term Withdrawal process then generates and processes the enrollment requests for each impacted student enrollment record (STDNT_ENRL), retaining the impacted records with student enrollment status of dropped. The process further updates the records depending on the enrollment type (traditional, dynamic date, or open entry/exit) and the withdrawal type (without penalty, with penalty, or with greater penalty).

For withdrawals from traditional class enrollments, the process updates the impacted student enrollment records as follows.

• If the last date of attendance is less than or equal to the withdraw-without-penalty deadline on the Session Calendar 1 page, the process updates the last enrollment action reason to the withdraw-without-penalty reason set on the Session Calendar 1 page.

• If the last date of attendance is less than or equal to the withdraw-with-penalty deadline, the process determines the student’s grading basis for the class, then assigns to the impacted student enrollment record the penalty grade value that is set on the Grading Scheme Table page for that grading basis.

  If the penalty grade is not defined, the process assigns the penalty grade according to the grading basis and grade set on the Session Calendar 1 page. Depending on how the grade is set up, the process can reduce in progress units, which can potentially affect the student's academic load and financial aid load.

• If the last date of attendance is less than or equal to the withdraw-with-greater-penalty deadline, the process functionality parallels that of the withdraw-with-penalty functionality.

For withdrawals from dynamic date and open entry/exit class enrollments, the process updates the impacted student enrollment records as follows.

• If the last date of attendance is less than or equal to the withdraw-without-penalty deadline on the Dynamic Class Data page or Student Enroll OEE page, the process updates the last enrollment action reason to the corresponding reason value set on the Dynamic Date page of the Academic Program Table component for the student’s primary academic program.

• If the last date of attendance is less than or equal to the withdraw-with-penalty deadline on the Dynamic Class Data page or Student Enroll OEE page, the process determines the class grading basis, then assigns to the impacted student enrollment record the penalty grade value that is set on the Grading Scheme Table page for that grading basis.

  If the penalty grade is not defined, the processes assigns the penalty grade according to the grading basis and grade set on the Dynamic Date page of the Academic Program Table component for the student’s primary academic program. Depending on how the grade is set up, the process can reduce in progress units, which can potentially affect the student's academic load and financial aid load.

• If the last date of attendance is less than or equal to the withdraw-with-greater-penalty deadline on the Dynamic Class Data page or Student Enroll OEE page, the process functionality parallels that of the withdraw-with-penalty functionality.

  Note. The system will use the session calendar (if it exists) when it fails to find a Dynamic Class Dates table row or the appropriate Academic Program table dynamic dates field when processing withdrawals from non-OEE dynamically dates classes.

Regardless of the enrollment and withdrawal types, the Student Records Term Withdrawal process also does the following for term and session withdrawals.

• Updates the withdraw code on the affected student session (STDNT_SESSION) records to a value of withdrew.

• Updates the withdraw code on the affected student career term (STDNT_CAR_TERM) records to a value of withdrew for term withdrawals only.

  Note. The process does not update the student career term record for session withdrawals so that the student can still enroll in other sessions within the term.

Common Elements Used to Process Withdrawals and Cancellations

Pages Used to Process Withdrawals and Cancellations

Posting Withdrawals and Cancellations for Terms

Access the Term Withdrawal page.

Important! Posting a student's term cancellation request refunds 100% of their fees. Posting a student's term withdrawal request refunds her or his fees according to the adjustment calendar associated with the student's tuition group.

See Also

Viewing Withdrawal and Cancellation Request Status

Maintaining Student Career Term Records

Recalculating Tuition and Fees after Enrollment Cancellation

Setting Up Adjustment Calendars

Posting Withdrawals and Cancellations for Sessions

Access the Session Withdrawal page.

Session	Select the session for which you want to process the student’s withdrawal or cancellation request.
Units Taken for Progress	The system displays the student’s in-progress units for the specified session.

See Also

Posting Withdrawals and Cancellations for Terms

Maintaining Student Career Term Records

Resubmitting Failed Withdrawal and Cancellation Requests

Access the Term Withdrawal / Cancellation page.

When the Term Cancellation process is run in the Student Financials application, that process generates a cancellation request. To process the cancellation request, enter the request number on this page and run the Student Records Term Withdrawal process (SRPCWDPR).

Run the Term Withdrawal COBOL/SQL process (SRPCWDPR) as needed.

Viewing Withdrawal and Cancellation Request Status

Access the Term Withdrawal Run Status page.

See Also

Working with Enrollment Request Messages

Purging Drop Enrollment Records

Class drops are kept in the student's academic record if a student drops from a course while the drop retain record date is defined on the academic calendar for the session in which the student was enrolled. At some point, your institution might decide to purge the system of these retained drop enrollment records. The drop purge process affords you this functionality. Run the purge process on past terms only when information about a student's drop enrollment record is no longer pertinent.

This section discusses how to delete drop enrollment records from your system.

Page Used to Delete Drop Enrollment Records

Deleting Drop Enrollment Records

Access the Drop Purge Process page.

Academic Institution	Select the academic institution for which you want to purge drop enrollment records.
Term	Select the term for which you want to purge drop enrollment records.
Sequence Number	The system displays a default sequence number. It is for internal processing purposes only. Note. This field and the remaining fields on this page are optional. They provide the means of purging drop enrollment records by various parameters.
Academic Career	If you want to purge drop enrollment records within a specific academic career, select a value.
Session	If you want to purge drop enrollment records within a specific session, select a value.
From Date	If you want to purge student enrollment records with a class start date (as defined on the CLASS_TBL) greater than or equal to a specific date, enter the date.
To Date	If you want to purge student enrollment records with a class start date (as defined on the CLASS_TBL) less than or equal to a specific date, enter the date.
Subject Area	If you want to purge drop enrollment records for a specific class subject area, select a value.
Class Nbr (class number)	If you want to purge drop enrollment records for a specific class, select a value.
Campus	If you want to purge drop enrollment records at a specific campus, select a value.
Enrollment Status Reason	If you want to purge only the drop enrollment records that have a specific enrollment status reason attached to them, select the enrollment status reason. For example, you can purge drops that have an enrollment status reason of Drop Wait and that meet your other criteria. Enrollment status reasons appear in the Status/Reason field on pages within enrollment components.