Understanding Class Enrollment Processing

The class enrollment processing tools in Student Records provides maximum flexibility when dealing with enrollment transactions and other enrollment-related activities. Five components and one self-service application, all of which post enrollment records to the same table (STDNT_ENRL), are available for you to process enrollment transactions.

You can process enrollment requests on a student-by-student basis through the Quick Enroll and Enrollment Request components. You can process enrollment requests for blocks of students and classes through the Block Enrollment component. Through the Mass Enrollment component, you can post a range of enrollment requests. Enrollment requests from all of these components go through the powerful enrollment engine during the posting process. The enrollment engine verifies that for every class requested, the student meets all rules for requisites, deadlines, permissions, and so on. Optionally, the enrollment engine also warns of potential repeats.

The Enrollment component, in contrast, bypasses the enrollment engine and all of its checkpoints, posting enrollment transactions directly to a student's enrollment record as soon as you save the data in the component. The Enrollment component is intended for use by only a select few power users at your academic institution and should not be made available to a wide user population.

If your academic institution has licensed PeopleSoft Campus Self Service, your students can also submit enrollment requests over the internet during their scheduled enrollment appointment times. These requests function the same as all other enrollment requests in your Student Administration system, writing data directly to your application tables.

When a user submits an enrollment request for an open entry/exit (OEE) class, the enrollment engine evaluates the student's primary academic program to verify that the academic program permits OEE enrollment. If the academic program does not permit OEE enrollment, the system returns an error message notifying the user that enrollment is not allowed in the chosen class. If the academic program does permit OEE enrollment, the enrollment engine then performs all of the existing edits as usual (such as class limits and requisite checks).

If the request successfully passes these edits, the enrollment process uses the OEE dynamic date rule assigned to the class to calculate a class end date and all the other dynamic calendar dates for the student. If no OEE dynamic date rule has been defined for the class, the enrollment process uses the rule established for the course offering. If no rule exists for the course offering, the request fails and the process returns an error message.

If the request is successful, you can view the dates calculated by the process using the academic calendar link on the Study List or by accessing the Student OEE Enroll Data page.

To submit an enrollment transaction for a student, the student must have a personal data record, have been activated in an academic program within the academic career to which the classes belong, and have been activated in the necessary term for that same academic career.

When processing enrollment requests with an enrollment action of drop through the Quick Enroll, Enrollment Request, and Block Enroll components or self-service enrollment, the enrollment engine must determine the drop deadlines, reasons, grading bases, and grades with which to update the impacted student enrollment records (STDNT_ENRL).

The enrollment engine determines drop deadlines, grading bases, and grades differently depending on the class enrollment type (traditional, dynamic date, OEE).

When requesting to drop a traditional class enrollment, the enrollment engine:

• Determines the deadlines according to the values set on the Academic Calendar 2 page.

• Determines if a drop or withdrawal grade has been defined for the grading basis (based on the student's grading basis in the class) on the Grading Scheme Table page.

  If there is no grade set on that page, the enrollment engine uses the grading schemes and grades set on the Session Calendar 2 page.

  See Defining Grading Schemes.

When requesting to drop a dynamic date class enrollment, the enrollment engine:

• Determines the deadlines according to the values that the Dynamic Class Dates process calculates and displays on the Dynamic Class Data page.

  If you have not calculated the academic calendar dates for the class, the enrollment engine determines the deadlines according to the values set on the Academic Calendar 2 page.

• Determines if a drop or withdrawal grade has been defined for the grading basis (based on the student's grading basis in the class) on the Grading Scheme Table page.

  • If there is no grade set on that page and you have calculated the academic calender dates for this class, the enrollment engine uses the grading schemes and grades set on the Dynamic Date page of the Academic Program Table component.

    If there is no grading scheme and grade set on that page, the enrollment engine uses the grading scheme and grades set on the Session Calendar 2 page.

  • If there is no grade set on the Grading Scheme Table page and you have not calculated the academic calender dates for this class, the enrollment engine uses the grading scheme and grades set on the Session Calendar 2 page.

When requesting to drop an OEE class enrollment, the enrollment engine:

• Determines the deadline according to the values it calculates upon enrollment and displays on the Student Enroll OEE page.

  If the deadlines have not been calculated, the request fails.

• Determines the grading scheme and grade, if applicable, according to the value set on the Grading Scheme Table page.

  If there is no grade set on that page, the enrollment engine uses the grading schemes and grades set on the Dynamic Date page of the Academic Program Table component. If there is no grading scheme and grade set on that page, the request fails.

Regardless of the class enrollment type, the enrollment engine determines the reason according to the enrollment action reason that you enter on the enrollment processing page. If you do not enter a value on the enrollment processing page, then, for drop transactions during the drop retain record period only, the enrollment engine uses the reason set on the Session Calendar 2 page. Otherwise, the engine assigns no reason.

If your institution wants to retain student enrollment records during the drop delete period, you can add an enrollment action reason to the drop and it will be retained subject to the time period associated with the enrollment action reason.

Whenever you post an enrollment transaction that adds, drops, or updates a student enrollment record (STDNT_ENRL), the system populates the appropriate, enrolled, dropped, or updated row with date and time stamps based on the system date. These values are not viewable on any application pages. Student Financials uses these date and time stamps to correctly calculate adjustments in situations where your academic institution charges by term and adjusts by session. Classes are associated with sessions. The date and time stamp fields are as follows: