Drop For Non-Payment Processing
Introduction
Per VCCCD Board Policy 5030, fees are due upon registration. In particular, non-exempt students are required to pay enrollment and tuition fees for classes upon registration or establish a payment plan upon which to pay on a schedule. When the student fails to pay the enrollment and tuition fees fully or set up a payment plan via CashNet at the time of registration, an automated nightly drop for non-payment process will then determine which of the student’s registrations are due, notify the student of the unpaid class registrations, and drop the student from these classes at the end of a pre-defined grace period as set by the Chancellor.
As there are legal consequences from not attempting to collect enrollment fees (Ed. Code 73600(d)), the VCCCD drop for non-payment process is an effective, legal, and sensible method to ensure collection of fees. Dropping students from unpaid classes after a reasonable grace period, ensures seats in classes are freed up for other students waiting to add and increasing class enrollments. Because students often rely on the district to drop them from unpaid classes, the drop for non-payment process also prevents students from incurring a debt which would be forwarded to the state to collect.
Methodology
Student Selection Criteria
The drop for non-payment process only considers outstanding enrollment and tuition related fees in a specified term. Other fee categories are not examined. Though the process can be run for any term, it will not process students in terms that have either ended or are NOT assessing fees. The process will also exempt students meeting the following conditions:
- Has an active CN (CashNet payment plan), BR (CCPG revoke), or PD (manual intervention) hold
- Is enrolled as a high school dual enrollment student (student type Y)
- Is receiving financial aid
- Is flagged as a veteran in the past year (veteran status 1,5,C,D,E,I,J,K,L,M,N,O,P,Q,R,S,T,U,W)
Unpaid Course Registration Determination
An algorithm is used to determine which courses are considered as unpaid. This algorithm first summarizes the outstanding balances by student and enrollment fee transaction college for the designated term. Enrollment fee transactions with the detail code ENR% and UDC%, or are in the TUI fee category are the only fee transactions considered.
Only course registrations that have not been assigned a grade and that match the term and college where the debt was incurred are evaluated. Course registrations are evaluated against the debt owed in descending order by the registration date and billable hours. In other words, the algorithm will flag the student’s most recent, higher unit, registration for drop first and then traverse through the student’s registrations until the debt would be less than or equal to an agreed upon threshhold. Once the outstanding balance drops to the threshhold or below, no other course registrations for that college are considered.
Threshhold Amount
When a threshhold amount greater than zero is used, the registrations to be considered for drop will only be flagged if the total balance due is greater than the threshhold amount. Once enough registrations are flagged for drop to lower the balance to less than or equal to the threshhold, no further registrations will be considered. The student will only be notified of the flagged registrations. However, all registrations will still appear on the drop for non-payment report to administrative personnel.
To set a threshhold amount, notify IT to update the threshhold limit on the GTVSDAX configuration record (group code SYSDRNP, internal code THRESHHOLD) to the amount in whole dollars. At this time, the threshhold is set to zero.
Grace Period
Prior to dropping a student from a class, the student is given a grace period in which to pay beginning from the day they are first notified of the course registration past due status. The duration of the grace period depends on the start date of the class and the type of registration. In some instances the grace period is limited by the start of the class. For example, if the student registers prior to the start of the class and the standard grace period overlaps the start date of the class, the amount of grace days given is then limited to either the standard grace period or the start of the class plus the “Class Start” grace period whichever expires first.
Current settings for grace periods are:
Registration Status | Standard (Prior to start of class) | Class Start (On or after start of class) |
|---|---|---|
RE, RW (regular) | 7 days | 1 day |
RL (waitlist)* | 7 days | 7 days |
RI (reinstatement)* | 7 days | 7 days |
* Waitlist and reinstatement registrations only have one grace period option at this time.
First Notification Date
Prior to this release, the grace period "clock" began with the registration date of the course. However, this led to students being dropped from classes when their exemption status changed after the grace period had ended. To avoid this, the start of the grace period clock is now set to the date the student is first notified of their course drop status.
For example, a student that was offered financial aid and exempted from the drop for non-payment process at the time of registration and, subsequently, had the aid offer withdrawn after the grace period had expired would have had their unpaid courses dropped the day following their loss of exemption status under the previous methodology. As of this release, the start of the grace period now begins with the first notice the student receives regarding the drop status for each unpaid class. To do this, the first date the student is notified of a pending drop for an unpaid class will be recorded and remain fixed until the class is dropped or the student is no longer on the drop for non-payment list. A new unpaid registration for a prior dropped class will have it's first notification date reset.
Grace Period Calculation
Depending on when the student is first notified of a pending drop for non-payment of a class, the grace period is then computed using the settings specified above. The following diagram illustrates the grace periods calculated for a regular course registration using a hypothetical course start date of 9/11.
In this example, students registering for classes prior to 9/5 (notified on 9/5 or earlier) would receive 7 full grace days. Students notified on 9/6 thru 9/10 would receive progressively fewer grace days as the grace period is limited to the Class Start grace period after the start of the class. Notification on 9/6, for example, would result in the student being dropped on 9/13 (6 grace days). Registrations on the day prior to the start of the class and beyond would only get the Class Start grace period.
Calculated Drop (Cut-Off) Date vs. Anticipated Drop Date
Internally, the process will compute two drop dates: a calculated drop date and an anticipated drop date. The calculated drop date is really an aging of the notification date. Using the grace period rules mentioned above, the system will compute the notification date cut-off. The calculation is based on the current date relative to the start of the term and the registration type. If the course still has an outstanding balance and the notification date is older than or equal to the calculated drop cut-off date and the run mode is set for Update then the student is dropped from the course.
The anticipated drop date is the actual date the course will be dropped if left unpaid. This date is also computed using the rules above and is based on the first notification date, the start date and the grace period calculation. This date is reported both to the student when the student is notified of the pending drop or drop action and on the SYSDRNP Drop Students for Non-Payment report. This date is also recorded in the drop for non-payment archive view, VC_DB_STUDENT_TERM_DROP_NONPAY, for use by campuses for research and outreach.
Effective Date Override
In cases where fees assessment was staggered, it may be desired to delay the actual drop date for a period of time after fee assessment is turned on. For example, when Fall fee assessment is turned on. The process does allow an administrative user to set an effective date override using the GTVSDAX setting (DRNPEFFDT) for a specified term. If this setting is enabled, the process will not drop the student from any past due courses until the effective date has been reached. The drop indicator will remain pending until the effective date is reached or disabled.
Notification
Depending on the run mode, students will be notified of any pending drops or drop actions via email messages and portal alerts. (*Note: A separate process also notifies faculty when the process drops students from classes that have already started.)
There are three run modes:
- No Msg - No drops and no notifications; generates audit report only
- Audit - Audit only. No drops; all unpaid classes reported as "pending" to the student; generates audit report.
- Update - Updates students registrations and account balances after dropping classes with unpaid balances as specified above, notifies students of courses dropped or pending drop and generates audit report.
No Msg Mode: Run in the N - No Msg mode, an audit report of students with unpaid registrations is produced but students are not notified of any unpaid balances or pending drops. This mode is typically used when there are planned system outages preventing students from logging in to resolve the unpaid balance or for testing purposes. No balance and course information is recorded in the drop for non-payment archive tables.
Audit Mode: This mode produces an audit report of students with unpaid registrations and notifies the students of all unpaid registrations as determined by the criteria above using the Pending Drop For Non-Payment template (DRNPEMW) and indicating the fees due date (1 day prior to the anticipated drop date) for each class in the notification. If the drop for non-payment process effective date is delayed using the GTVSDAX setting (DRNPEFFDT), the anticipated drop date is set to the effective date. All balance and course information is recorded in the drop for non-payment archive tables.
Update Mode: This mode will produce an audit report of students with unpaid registrations, notifies the students of all unpaid registrations indicating the action to be taken, and drops any courses flagged for dropping. If the course is pending drop, the student will be notified using the Pending Drop For Non-Payment template (DRNPEMW) with the fees due date (1 day prior to the anticipated drop date) for each class in the notification. If the course is slated for drop, the student will be notified using the Drop For Non-Payment template (DRNPEML) with the message "CLASS WAS DROPPED" followed by the date of the drop. If the drop for non-payment process effective date is delayed using the GTVSDAX setting (DRNPEFFDT), no drops will be performed and the process will treat this the same as in AUDIT mode. The anticipated drop date is set to the effective date. All balance and course information is recorded in the drop for non-payment archive tables.
Notification Decision Logic
Notification Templates
Pending Drop For Non-Payment (DRNPEMW)
Drop For Non-Payment (DRNPEML)
Drop For Non-Payment Portal Announcement
Reporting
SYSDRNP - Drop Students For Non-Payment Audit Report
The drop for non-payment process will produce an audit report that is distributed to District Accounting and IT, Registrars and Bursars. The audit report lists students by primary college and ID. Student name and outstanding balance for each college the student is enrolled in that has an unpaid enrollment/tuition fee balance is listed first. All course registrations for that college are listed below the balance line in descending registration date and billable hour order exactly as the main algorithm applies the outstanding balance to these courses. The course registration line will list the registration college, CRN, registration status and date, CRN start date, first notification date, anticipated/actual drop date, drop status indicator, billable hours, enrollment fee, remaining outstanding enrollment fee balance, tuition fee amount, and remaining outstanding tuition fee balance. UDC fees would be included under the enrollment fee calculations.
Sample report: sysdrnp_7425697.lis
VC_DB_STUDENT_TERM_DROP_NONPAY View
A view is available to extract data from the drop for non-payment process archive tables. This view combines all of the elements of the audit report into a single row. The view is updated each time the drop for non-payment process is run in either audit or update mode.
| COLUMN_NAME | DATA_TYPE | KEY | COMMENTS |
|---|---|---|---|
| ACTIVITY_DATE | DATE | Activity date. | |
| BILLABLE_HOURS | NUMBER(7,3) | Section billable hours. | |
| CRN | VARCHAR2(5 CHAR) | Yes | Section CRN. |
| DATA_ORIGIN | VARCHAR2(30 CHAR) | Data origin of this record. | |
| DROP_DATE | DATE | Date section will be or was dropped. | |
| DROP_IND | VARCHAR2(1 CHAR) | Drop status indicator. Y-Drop, P-Drop pending, L-Waitlist reg drop pending, N-Not due. | |
| DROP_REGISTRATION_CODE | VARCHAR2(2 CHAR) | Registration drop code. | |
| ENROLL_FEE | NUMBER(12,2) | Section enrollment fee. | |
| ENROLL_FEE_BAL | NUMBER(12,2) | Remaining enrollment fee balance after applying section enrollment fees to the original outstanding balance. | |
| ENROLL_FEE_BEGIN_BAL | NUMBER(12,2) | Outstanding enrollment fee balance for the student and college. | |
| FIRST_NOTICE_DATE | DATE | Date student was notified of drop for non-payment for this section. | |
| ID | VARCHAR2(9 CHAR) | Banner student identifier. | |
| LAST_AR_TRANS_DATE | DATE | Date of most recent student accounts receivable transaction. | |
| LAST_NAME | VARCHAR2(60 CHAR) | Student last name. | |
| PIDM | NUMBER(9) | Yes | Key internal identifier of the student. |
| PRIMARY_COLLEGE_CODE | VARCHAR2(1 CHAR) | Primary college the student is enrolled in. | |
| REGISTRATION_CODE | VARCHAR2(2 CHAR) | Registration status code. | |
| REGISTRATION_DATE | DATE | Registration status date (date added). | |
| RESIDENCY_CODE | VARCHAR2(1 CHAR) | Residency status code. Note: this is a hold over from prior process. Residency is only used to note if tuition fees should be there. | |
| RUN_DATE | DATE | Yes | Date/timestamp when the drop for non-payment process was run. |
| RUN_MODE | VARCHAR2(1 CHAR) | Run mode of the drop for non-payment process that generated this record. | |
| SECTION_COLLEGE_CODE | VARCHAR2(1 CHAR) | Yes | College code for the registered CRN. |
| SECTION_START_DATE | DATE | Section start date found in SSASECT part of term. | |
| TERM_CODE | VARCHAR2(6 CHAR) | Yes | Key term code for the drop process. |
| TUITION_FEE | NUMBER(12,2) | Section tuition fee. | |
| TUITION_FEE_BAL | NUMBER(12,2) | Remaining tuition fee balance after applying section tuition fees to the original outstanding balance. | |
| TUITION_FEE_BEGIN_BAL | NUMBER(12,2) | Outstanding tuition fee balance for the student and college. | |
| USER_ID | VARCHAR2(30 CHAR) | User ID that ran the drop for non-payment process. |
Automation
The drop for non-payment process is run nightly using three SYSDRNP jobs (NJ_810, NJ_811, and NJ_812) representing each of the current academic year terms (Fall, Spring, Summer) beginning with the oldest term. NJ_810 always runs first, followed by NJ_811 and NJ_812. When a registration period opens for a term, the SYSRER4 nightly job rolls the term parms in the SYSDRNP nightly jobs to keep the term order consistent. Any term that is currently being run will retain its job parameter settings when moved to a new NJ_8xx number.
Any SYSDRNP nightly job created for a new term will default to running in Audit mode. As IT staff need to turn the nightly job on for update mode manually, Accounting and Registrars need to coordinate with IT staff to begin dropping students.
Manual Mode Adjustment
-- View SYSDRNP settings
select * from gjbpdft
where gjbpdft_job = 'SYSDRNP'
and gjbpdft_user_id = 'SAISUSR'
ORDER BY 6,2;
-- Set gjbpdft_value to N(Audit w/o msg), A(Audit w/ msg) or U(Update w/ msg) and set the gjbpdft_jprm_code to the appropriate job
update gjbpdft
set gjbpdft_value = 'U'
where gjbpdft_job = 'SYSDRNP'
and gjbpdft_user_id = 'SAISUSR'
and gjbpdft_jprm_code = 'NJ_810'
and gjbpdft_number = '06'
-- Don't forget to commit
commit;
Suggested Test Plan
The following test plan is recommended for administrative users to check that the drop for non-payment process is working correctly. The test will assume that the drop for non-payment process is running nightly in a test environment in UPDATE mode with the standard grace day settings.
| Case | Test | Expected Result | Note |
|---|---|---|---|
1 | Student paid all enrollment/tuition fees but has outstanding balance | Not appear in DRNP report | Add a miscellaneous fee to a student that is registered |
| 2 | Student is on payment plan | Not appear in DRNP report | Register test student in a class and add a CN hold |
| 3 | Student has CCPG revoke (BR) hold | Not appear in DRNP report | Register test student in a class and add a BR hold |
| 4 | Student has manual intervention (PD) hold | Not appear in DRNP report | Register test student in a class and add a PD hold |
| 5 | HSDE student | Not appear in DRNP report | Register test student with student type Y |
| 6 | Financial aid student | Not appear in DRNP report | Register student with FA award |
| 7 | Veteran student | Not appear in DRNP report | Register student with on of the following veteran status codes veteran status (1,5,C,D,E,I,J,K,L,M,N,O,P,Q,R,S,T,U,W) |
8 | First notice of past due is min of 7 days prior to start of class | Notice date set to current date, drop date equal to notice date plus 7 days, drop ind is P-Pending, pending drop email created | Register a regular student at least 7 days prior to the start of class, check drop report and gwiemal showing date due as day prior to drop date |
| 9 | Second notice of past due | Notice date is still set to first notice date, drop date still same, drop ind is P-Pending, pending drop email created | Use test data from prior case and wait a day to review report and gwiemal or find a student that is two days past due |
| 10 | Student past due date | Notice date is still set to first notice date, drop date still same, drop ind is Y-Dropped, drop email created | Search for a student that is seven days past the first notice date |
| 11 | First notice 5 days or less from start of class | Drop date is equal to start date plus 1, drop ind is P | Register student within 5 days of start of class |
| 12 | Unpaid registration as of start of class | Drop date is one day from notice date | Register student on start of class |
| 13 | RL (waitlist reg) add within 5 days or less from start of class | Drop date is 7 days from notice date | Remove student from a full class that is within 5 days of start date and run waitlist process to create RL reg (IT assistance needed) |
| 14 | RI (Re-instatement reg) as of start of class | Drop date is 7 days from notice date | Re-instate student (RI rsts code) into class on or after start date |
| 15 | Effective date override and past 7 days due | Drop date is set to effective date, drop ind is P | Set GTVSDAX DRNPEFFDT setting to date greater than 7 days out (IT assistance needed) |
| 16 | Student enrolled in a BDP course | UDC fees for BDP courses are counted together with ENR fees. | Register test student in a BDP class |