getting started with colleague studentclientsearch.ellucian.com/documentexport/home...getting...

Colleague StudentGetting Started with Colleague Student

Release 18April 2, 2015

Without limitation: Ellucian®, Banner®, Colleague®, and Luminis® are trademarks of the Ellucian group of companies that are registered in the U.S. and certain other countries; and Ellucian Advance™, Ellucian Course Signals™, Ellucian Degree Works™, Ellucian PowerCampus™, Ellucian Recruiter™, Ellucian SmartCall™, are also trademarks of the Ellucian group of companies. Other names may be trademarks of their respective owners.

© 2012-2015 Ellucian.

Contains confidential and proprietary information of Ellucian and its subsidiaries. Use of these materials is limited to Ellucian licensees, and is subject to the terms and conditions of one or more written license agreements between Ellucian and the licensee in question.

In preparing and providing this publication, Ellucian is not rendering legal, accounting, or other similar professional services. Ellucian makes no claims that an institution's use of this publication or the software for which it is provided will guarantee compliance with applicable federal or state laws, rules, or regulations. Each organization should seek legal, accounting, and other similar professional services from competent providers of the organization's own choosing.

Ellucian4375 Fair Lakes CourtFairfax, VA 22033United States of America

Revision History

Publication Date Summary

April 2, 2015 Updated manual with information about setting up requisite waivers and the SOC fields on the Noncourses (NONC) form.

Ge

Table of Contents

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

What Does This Manual Cover? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Where Can I Find More Information? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Overview of Colleague Student. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Colleague Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Understanding Colleague Student Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Academic Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Accounts Receivable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Campus Organizations Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Cash Receipts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Curriculum Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Degree Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Financial Aid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Faculty Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Recruitment/Admissions Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Residence Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Understanding Student Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Understanding Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Codes in Colleague Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Sharing of Codes Between Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Codes from Colleague Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Comprehensive List of Colleague Student Codes . . . . . . . . . . . . . . . . . . . . . . . . . 69

Different Types of Codes: General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3tting Started with Colleague Student | Contents

Ge

About Special Processing Codes (Validation Codes Only) . . . . . . . . . . . . . . . . . . . 70

Notes About the Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Defining Colleague Student Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Academic Committee Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Academic Program Honor Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Academic Program Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Academic Requirement Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Academic Standing Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Academic Standing Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Action Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Admit Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Advisor Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Applicant Remark Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Applicant Remark Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Application Fee Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Application Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Application Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Components of an Application Status Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Processing Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Column Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Application Status Processing Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

What Happens When an Prospect’s Application Status Is Changed to Applied . . . 145Other Functions of Some Processing Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Application Status Column Titles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146


Ge

Application Status Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Application Test Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

AR Add/Drop/Withdraw Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

AR Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

AR Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Understanding AR Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

General Ledger Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Deferred Revenue Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

General Ledger Distribution Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Defining GL Distribution Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Tax Codes and Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Components of an AR Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Default Charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Default Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Application Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Other Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

AR Fee Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

AR Miscellaneous Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

AR Tax Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Components of an AR Tax Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Tax Rate Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

AR Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Understanding AR Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

AR Waiver Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Attendance Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Award Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Award Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162


Ge

Award Disbursement Code Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Award Packaging Category Codes (AWDPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Award Periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Awards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Award Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Billing Frequency Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Billing Method Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Billing Period Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Billing Override Reasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Billing Rounding Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Calculation Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Campus Organization Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Campus Organization Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Campus Organization Groupings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Campus Organization Member Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Campus Organization Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Career Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

CB/Institutional Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

CCD Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Citizenship Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Class Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

COD Document Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

COD Document Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171


Ge

COD Error Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

COD Export Message Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

COD Import Message Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

College Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

College Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

College Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Common School IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Contact Measures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Counselor Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Course Disability Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Course Equate Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Course Level Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Course or Credit Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Course Purposes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Course Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Course Tax Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Course Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

CPS Transaction Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Credit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

CSS Marital Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

CSS Parent in College . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

CSS Student Tax Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

CSS Student Visa Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179


Ge

Days of the Week . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Default Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Deferred Revenue Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Degrees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Department of ED Import Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Dependency Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Deposit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Understanding Deposit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Components of a Deposit Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Auto Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Deposit Allocation Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Procedure for Defining Deposit Allocation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Direct Loan Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Direct Loan Type All . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Discount Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Due Date Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

ED TG Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Educational Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Electronic Loan Enrollment Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Electronic Loan Grade Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Electronic Loan Type Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Electronic Loan Processing Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Electronic Loan Relationship Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189


Ge

Enrollment Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

EOPS CARE Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

EOPS Eligibility Factor Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

EOPS Term End Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Evaluation Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Expense Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

FA Academic Calendar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

FA Accepted Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

FA Active Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

FA Application Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

FA Award Letters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

FA Award Letter Print Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

FA Batch Award Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

FA Birthdate Variance Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

FA Budget Default Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

FA Budget History Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

FA Budget History Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

FA Budget Unit Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

FA Citizenship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Financial Aid Demographics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Financial Aid Application Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

FA COD Grade Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

FA COD MPN Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197


Ge

FA COD Platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

FA COD Temp Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

FA Code Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

FA CommonLine Co-sign Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

FA CommonLine Display Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

FA CommonLine Hold/Release Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

FA CommonLine Import Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

FA CommonLine Import Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

FA CommonLine Record Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

FA CommonLine Release Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

FA CommonLine Rent/Own Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

FA CommonLine Sort Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Beginning with the 1994/95 Financial Aid Application . . . . . . . . . . . . . . . . . . . . . . . . . 202

FA Core Import Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

FA CR Decision Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

FA CR Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

FA Custodial Parent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

FA Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

FA Default/Overpayment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

FA Degree/Certification Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Beginning with 1999/00 Financial Aid Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

FA Direct Loan MPN Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

FA Disbursement Roster Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206


Ge

FA Direct Loan Credit Decisions Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

FA Document Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

FA Document Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

FA DOEI Report Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

FA Drug Convictions Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

FA Electronic Loan Citizenship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

FA Electronic Loan Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

FA Electronic Loan Comparison Parameter Codes. . . . . . . . . . . . . . . . . . . . . . . . . 209

FA Electronic Loan Retrieve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

FA Electronic Loan Transmit Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

FA Entrance/Exit/Both Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

FA Federal Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

FA File Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

FA File Suite Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

FA File Suite Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

FA FM State and Other Tax Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

FA Fund Distribution Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

FA Gift/Self Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

FA IFB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

FA IM State and Other Tax Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

FA Income Protection Allowance Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

FA Loan Application Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

FA Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215


Ge

FA Low Tuition Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

FA Manifest Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

FA Marital Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

FA Media Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

FA Message Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

FA NAS Sort By Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

FA Need Analysis Assumption Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

FA Need/Cost Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

FA Negative Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

FA Offices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

FA Packaging Desirability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

FA Packaging Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

FA Parent Marital Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

FA Pell or DL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

FA Production Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

FA Promissory Note Print . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

FA Promissory Note Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

FA Reconciliation Report Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

FA Reject Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

FA Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

FA Serial Loan Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

FA Signed By Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

FA SOP Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224


Ge

FA Stafford Loan Class Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

FA State Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

FA State Grade Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

FA Student Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

FA Tape Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

FA Tax Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

FA Tax Return Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

FA Tax Return Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

FA Transmittal Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

FA Unconverted Records Delete Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

FA Verification Status Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

FA Yes/Blank Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

FA Year in College Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Faculty Contract Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Faculty Position Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Faculty Remark Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Faculty Remark Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Faculty Special Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

FAFSA Housing Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Federal Cohorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Floor Preference Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Funding Accounting Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Funding Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233


Ge

GAIN Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Grades Participation Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Guarantor Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Hiatus Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Hiatus Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Honors Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Housing Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Housing Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Influences to Apply Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Institution Cohorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Instructional Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Invoice Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Lenders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Local Government Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Matriculation Other Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Matriculation Provide Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

MCAT Writing Sample Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Majors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Meal Classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Meal Plan Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Meal Plan Assignment Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Meal Rate Periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Meal Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239


Ge

Military Benefit Eligibility Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Military Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Military Veteran Remark Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Military Veteran Remark Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Minorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Minors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Miscellaneous Admissions Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Multiple Reporting Request Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Name/Titles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Non-AR Receipt Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Understanding Non-AR Receipt Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Noncourse Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Noncourse Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Noncourse Grade Usage Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Noncourse Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Note Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Other Restriction Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Packaging Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Parents In College . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Pell Attended Campuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Pell Enrollment Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Pell Entitlement Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248


Ge

Pell Payment Methodology Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Pell Reconciliation Verification Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Person Tax Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Petition Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Profile Parent Marital Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Program Designations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Program Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Prospect Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Receipt Reversal Reasons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Recommendation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Using Recommendation Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Recruitment Purposes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Refund Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Refund Portion Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Registration Audit Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Registration Billing Rate Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Registration Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Registration Process Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Registration Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Registration Refund Days to Exclude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Registration Refund Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Registration Term Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259


Ge

Relation Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Repeat Grade Use Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Replacement Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Requisite Waiver Reasons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Residency Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Restrict Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Restriction Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Return of Funds Institutional Charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Return of Funds Title IV Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Reversal Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Room Assignment Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Room Rate Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Room Wings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Roommate Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Rounding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Rule Process Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Rule Table Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Rural Indicator Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

SAP Appeal Action Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

SAP Report Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

SAP Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

SAP Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268


Ge

Schedule Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Secondary School Subjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Section Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Self Description Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Session Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Session Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

SOC Service Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

SOC Branches of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

SOC Credit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

SOC Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Sort Graduate Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Special Services Needed Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Specializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Sponsorship Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Staff Room Assignment Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

State Report Period Name Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

State Report Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Student Academic Credit Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Student Academic Credit Status Reasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Student Load Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Student Miscellaneous Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Student Noncourse Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277


Ge

Student Program Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Student Remark Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Student Remark Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Student Special Service Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Student Term Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Student Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Subjects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Suite Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Tax Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Tax Return Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Teaching Arrangements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Term Note Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Topic Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Total Contribution Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Transcript Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Transcript Groupings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Transfer Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Trust Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Tuition Discounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Tuition Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

VA Certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

VA Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

VATEA Economic Status Source Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286


Ge

VATEA Economic Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Verification Field Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Verification Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

Veteran Benefit Eligibility Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

Veteran Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Visa Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Waitlist Ratings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Waitlist Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Waive or Charge Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Withdraw Reasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Yearly Cycle Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Defining Validation Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Understanding Validation Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Special Processing Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Components of a Validation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Procedure for Defining a Validation Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Codes Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Admit Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Application Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

AR Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

AR Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

AR Tax Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301


Ge

AR Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

Deposit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Non-AR Receipt Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Recommendation Type Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Validation Code Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

Understanding the Rules Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Understanding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

How Colleague Evaluates Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Rule Evaluation Results Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Working with Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

How to Build Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

The Run-Time CDD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312Office Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313Primary View File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313Subroutine Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

How to Validate Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

How to Assign Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Procedure for Building Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Procedure for Validating Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

A Rules Processor Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Rules Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Rule Construction—English Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Rule Construction Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322


Ge

Defining Academic Records Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Understanding Academic Records Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Graduation Honors Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

When Colleague Evaluates the Graduate Honors Rules . . . . . . . . . . . . . . . . . . . . . . . 325

How to Define Academic Level Graduate Honors Rules . . . . . . . . . . . . . . . . . . . . . . . 326

Procedure for Defining Academic Level Graduate Honors Rules . . . . . . . . . . . . . . . . 327

How to Define Academic Program Graduate Honors Rules. . . . . . . . . . . . . . . . . . . . . 329

Procedure for Defining Academic Program Graduate Honors Rules . . . . . . . . . . . . . . 330

Academic Standing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

When Colleague Evaluates the Academic Standing Rules . . . . . . . . . . . . . . . . . . . . . 331

How to Define Academic Standing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Case Study: Defining Academic Level Standing Rules . . . . . . . . . . . . . . . . . . . . . . 332Case Study: Defining Academic Level Term Standing Rules . . . . . . . . . . . . . . . . . 333

Procedure for Defining Academic Standing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Academic Term Registration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

When Colleague Evaluates the Academic Term Registration Rules . . . . . . . . . . . . . . 336

How to Define Academic Term Registration Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

Case Study: Defining Academic Term Registration Rules . . . . . . . . . . . . . . . . . . . . . . 337

Procedure for Defining Academic Term Registration Rules . . . . . . . . . . . . . . . . . . . . . 338

Class Level Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

When Colleague Evaluates the Class Level Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

How to Define Class Level Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Procedure for Defining Class Level Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

Enrollment Status Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

When Colleague Evaluates Enrollment Status Rules. . . . . . . . . . . . . . . . . . . . . . . . . . 342

How to Define Enrollment Status Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Procedure for Defining Enrollment Status Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Grade Point Averages Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

When Colleague Evaluates Grade Point Averages Rules . . . . . . . . . . . . . . . . . . . . . . 344


Ge

How to Define Grade Point Averages Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Procedure for Defining Grade Point Averages Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Print Restriction Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

When Colleague Evaluates Print Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

How to Define Print Restriction Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

Case Study: Defining Print Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Procedure for Defining Print Restriction Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

Student Load Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

When Colleague Evaluates Student Load Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

How to Define Student Load Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

Procedure for Defining Student Load Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

Student Term Status Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

When Colleague Evaluates Student Term Status Rules. . . . . . . . . . . . . . . . . . . . . . . . 353

How to Define Student Term Status Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

Procedure for Defining Student Term Status Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

Defining Academic Records Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 356

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Understanding Academic Records Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Noteworthy Fields on the ACPR Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Generate Random IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Academic Level Standing Default Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Transcript/Grade Print Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Petition Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Withdrawal Approval Required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358Comparison Grade Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Procedure for Defining Academic Records Parameters. . . . . . . . . . . . . . . . . . . . . . . . 358

Setting Up Active Military and Veteran Student Information . . . . . . . . . 360

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Tracking Active Military Student Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Entering Information for Active Military Students . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362


Ge

Noteworthy Fields on the MILS Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Primary Military Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Primary Military Status Start/End Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Selective Serv Reg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Cur SOC Elig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363SOC Elig Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Visiting Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Visiting From . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Military Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364GEO Ed Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Overall Comm Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Military Benefit Elig Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Military Benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Start Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365End Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Comm Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365SOC Serv Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Acad Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366MOS/Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Pay Grade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Cmpl Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Updt Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Posted Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

Entering Military Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

Noteworthy Fields on the PEMS Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Military Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368End Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Primary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

Entering Remarks for Active Military or Veteran Students . . . . . . . . . . . . . . . . . . . . . . 368

Noteworthy Fields on the MVSR Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369[Remark Entry] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369Author. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370Text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Procedure for Entering Active Military Student Information . . . . . . . . . . . . . . . . . . . . . 370

Tracking Veteran Student Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Entering Veteran Students Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Noteworthy Fields on the VETS Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372


Ge

Primary Military Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372Start Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372End Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372VA File Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372Visiting Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Visiting From . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Citizenship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Overall Comm Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Active Military Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Veteran Benefit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Start Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374End Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374Delimiting Dt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374Veteran Benefit Elig Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374Comm Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374VA Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374Exp Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Comm Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Acad Lvl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Reg Cred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Net Cert Amt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Entering Military Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Entering Remarks for Veteran Students . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Recording a Student’s VA Certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Noteworthy Fields on the VTRM Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Stu Term Stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377[Stu Term Stat] Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Selected Stu Pgm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377[Stu Pgm] Start Dt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Pgm Stat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Ant Cmpl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Loc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Deg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Last Eval Date/Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Section Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Stat Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Billing Amt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378VA Pgm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Pgm Cert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Repeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Reg Cred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Stu Cert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Cert Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Total Section-based Charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Net Certified Amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379


Ge

Net Certified Amount Dt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380Comm Cd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380When you enter a communication code, and then save the information on this form, this code will be assigned to this student. . . . . . . . . . . . . . . . . . . . . . . . . . 380

Procedure for Tracking Veteran Students Information . . . . . . . . . . . . . . . . . . . . . . . . . 380

Notifying VA Students About Expiring VA Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Noteworthy Fields on the VAFE Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381Processing Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381Document to Send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382Months Prior to Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382Benefits Expiration date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Procedure for Notifying VA Students About Expiring VA Forms . . . . . . . . . . . . . . . . . . 382

Tracking Servicemembers Opportunity Colleges (SOC) Agreement Information 382

The SOC Agreement Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Edit SOC Agreement Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

Generating a SOC Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

Requirements, Subrequirements, and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Specifications Requiring Specific Courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

Specifications Requiring General Courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

Options for Mapping Subrequirements and Groups to SOC Student Agreements389

Mapping a Subrequirement to a Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

When Not All Groups in a Subrequirements are Required . . . . . . . . . . . . . . . . . . . 390

Mapping a Group to a Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390

Displaying the Subrequirement Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Subrequirement and Group Print Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Exception Print Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Awarded Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

SOC DNS Course Category Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Setting Up Military and Veteran Student Parameters . . . . . . . . . . . . . . . . . . . . . . . 393

Setting Up Defaults for Military and Veteran Student Forms . . . . . . . . . . . . . . . . . . . . 393

Noteworthy Fields on the MVSP Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Overall Military . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394


Ge

Overall Veteran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Military Student Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Veteran Student Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394VA Forms Received . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395VA Net Certified Amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395Default Credits Per Course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395Display Groups Individually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395Show Subrequirement Header with Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . 396Show Print Text for Completed Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396VA Program Evaluation Include Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Setting Up Military Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Noteworthy Fields on the MINS Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397GEO Ed Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

Using the Enrollment Activity Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

Enrollment Activity Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

Enrollment Activity Export to Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Defining Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Understanding Grades and Grade Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Grade Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Grade Scheme Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

Repeat Grade Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

Grades in Grade Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

Grade Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Automatic Grade Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

Pass/NoPass, Withdraw, and Audit Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406Incomplete Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Inclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Repeat Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

Procedure for Defining Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408


Ge

Defining Academic Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

Understanding Academic Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

Components of an Academic Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Class Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

Absences Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416

Defining Academic Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Understanding Academic Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Academic Term Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

Academic Terms Within a Reporting Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

Start/End Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

Reporting Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

Calculated/Actual Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

Further Defining an Academic Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

Academic Term Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420

Term Process Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Registration Process Period Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421Residence Life Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422Billing Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422Drop Grades Required Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423Example of Term Process Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Term Registration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Term Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Census Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Term Location Dates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Procedure for Defining Academic Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426


Ge

Defining Transcript Groupings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

Understanding Transcript Groupings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

Components of a Transcript Grouping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

Print Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

Sort Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429Sort Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430Break Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430Printer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

GPA Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

GPA Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431GPA Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431GPA Break Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Procedure for Defining Transcript Groupings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Academic Records Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

Academic Level Graduation Honors Rules — English Statements . . . . . . . . . . . . 435

Academic Program Graduation Honors Rules — English Statements . . . . . . . . . 436

Academic Level Standing Rules — English Statements. . . . . . . . . . . . . . . . . . . . . 437

Academic Level Term Standing Rules — English Statements . . . . . . . . . . . . . . . . 438

Academic Program Standing Rules — English Statements . . . . . . . . . . . . . . . . . . 439

Academic Term Registration Rules — English Statements . . . . . . . . . . . . . . . . . . 440

Class Level Rules — English Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Enrollment Status Rules — English Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

GPA Rules — English Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443


Ge

Transcript Print Restriction Rules — English Statements . . . . . . . . . . . . . . . . . . . 444

Grade Print Restriction Rules — English Statements. . . . . . . . . . . . . . . . . . . . . . . 445

Student Load Rules — English Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Student Term Status Rules — English Statements . . . . . . . . . . . . . . . . . . . . . . . . . 447

Academic Records Default Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

Grades Schemes and Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

Absences Table Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

Setting Up Billing Defaults and Parameters . . . . . . . . . . . . . . . . . . . . . . 453

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

General Billing Defaults and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

Components of Billing Defaults And Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

Posting Charges to AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456Section Cancellations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459Section Cancel Cutoff Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459Immediate Billing Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459Location-Specific Immediate Billing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Relationship between Default Billing Parameters and Location-Specific Billing Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461

Deferred Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464

Deferred Revenue Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464Deferred Revenue General Ledger Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465

Default AR Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465

AR Type Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465Default AR Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465Using the Default and Rules-based AR Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466Tips for Writing AR Type Assignment Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Registration Billing Defaults and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Registration Billing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Discount Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

Periodic Registration Billing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

How Colleague Calculates Periodic Registration Charges . . . . . . . . . . . . . . . . . . . 468Setting Up Colleague for Periodic Registration Billing . . . . . . . . . . . . . . . . . . . . . . 470


Ge

Room Billing and Meal Plan Billing Defaults and Parameters . . . . . . . . . . . . . . . . 474

Default Refund Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

Rules-based Refund Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476Default Refund Formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476Using the Default and Rules-based Refund Formulas . . . . . . . . . . . . . . . . . . . . . . 476Writing Refund Formula Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Procedure for Setting Up Billing Defaults and Parameters . . . . . . . . . . . . . . . . . . 477

Defining Registration Refunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

Understanding Refund Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

Components of a Refund Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

Count Section Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480Days Excluded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481Days Before Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481Days Used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482Percent Used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482Refund Portion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Tips for Defining Refund Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

How Many Unique Refund Formulas Should I Define?. . . . . . . . . . . . . . . . . . . . . . 483What If We Don’t Refund a Charge?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483How Do I Define a Prorated Refund Formula? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Understanding Registration Refunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484

Understanding Registration Refund Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

Components of a Registration Refund Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

Default Refund Formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487Course Rate Rule & Refund Formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487Term Rate Rule & Refund Formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

Understanding Room Charge and Meal Plan Charge Refunds . . . . . . . . . . . . . . . 488

How Colleague Calculates Days Used for Room and Meal Plan Refunds. . . . . . . . . . 489

Using Rules with Room & Meal Plan Refund Formulas . . . . . . . . . . . . . . . . . . . . . . . . 489

Procedures for Defining Refunds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

Procedure for Defining Registration Refund Policies & Formulas . . . . . . . . . . . . . . . . 490

Procedure for Defining Room Charge Refund Formulas . . . . . . . . . . . . . . . . . . . . . . . 491


Ge

Procedure for Defining Meal Plan Charge Refund Formulas . . . . . . . . . . . . . . . . . . . . 492

Setting Up Registration Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

Tips for Setting Up Registration Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494

Defining Student Billing Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495

Components of Student Billing Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

Effective Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498Field Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

Tips for Defining Student Billing Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

Determining the Appropriate Billing Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500When to Use Student Type as a Billing Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

Understanding a Course Section’s Billing Information . . . . . . . . . . . . . . . . . . . . . 501

Components of Course Section Billing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

Defining Table-Based Tuition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

Course Section Billing Information for Table-Based Tuition Billing . . . . . . . . . . . . . . . . 504

Important Components of Course Section Billing Information for Table-based Billing505

Understanding Tuition Rate Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

Components of a Tuition Rate Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

The Tuition Charges Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

Tips for Defining Tuition Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

Defining Tuition Charges Based on Schedule Types . . . . . . . . . . . . . . . . . . . . . . . 511Naming Tuition Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511Using Rules with Tuition Charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

Defining Section-Based Tuition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

Course Section Billing Information for Section-Based Tuition Billing . . . . . . . . . . . . . . 513

Important Components of Section-based Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . 513Deciding Whether to Define Billing Information at the Course or the Course Section Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

Defining a Registration Rate Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

Components of a Registration Rate Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

Tips for Defining Registration Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Do I Need Different Billing Tables and Policies? . . . . . . . . . . . . . . . . . . . . . . . . . . . 517


Ge

Naming Registration Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

Defining Registration Term Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

Components of a Registration Term Rate Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

Course/Course Credit-Based Charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519Rules-Based Charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

Defining Add/Drop/Withdrawal Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Types of Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Flat Charge Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520Add, Drop, and Withdraw Specific Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Components of an AR Add/Drop/Withdrawal Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . 521

Tips for Defining AR Add/Drop/Withdrawal Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

The Number of Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521Naming Add/Drop/Withdrawal Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522

Defining Tuition Waiver Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522

Components of a Waiver Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522

Waive or Charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523Tuition Waiver AR Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524Max Number of Courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524Max Number of Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524Max Tuition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525Other Charges Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526

Comparing Waivers and Tuition Discounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527

Defining Tuition Discounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

Components of a Tuition Discount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

Tuition Discount Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529Tuition Discount Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530

How Colleague Calculates and Applies Tuition Discounts . . . . . . . . . . . . . . . . . . . . . . 531

Difference Between Tuition Discounts and Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

Procedure for Setting Up Registration Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

Defining Room Rates and Meal Plan Rates . . . . . . . . . . . . . . . . . . . . . . . 533

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533


Ge

Defining Room Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533

Understanding Room Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

Components of a Room Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537

Procedure for Defining Room Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538

Defining Meal Plan Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539

Components of a Meal Plan Rate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539

Procedure for Defining Meal Plan Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

Setting Up Financial Aid Transmittal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

Understanding Financial Aid Transmittal Parameters . . . . . . . . . . . . . . . . . . . . . . 542

Posting Based on Financial Aid Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

Posting Based on Accounts Receivable Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

Unposted Financial Aid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

Defining Administrative Fee Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

Understanding Administrative Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

Components of Administrative Fee Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546

Using Rules for Administrative Fee Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548

Components of Application Fee Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548

Application Fees Based on Academic Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

Application Fees Based on Academic Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

How Colleague Evaluates Application Fee Defaults . . . . . . . . . . . . . . . . . . . . . . . . 551

Procedure for Defining Administrative Fee Defaults . . . . . . . . . . . . . . . . . . . . . . . 555

Defining Invoice Due Date Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . 556


Ge

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

Understanding Invoice Due Date Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

Components of Invoice Due Date Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

Calculating the Invoice Due Date Based on the Billing Period Start Date . . . . . . . . . . 557

Calculating the Invoice Due Date Based on Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . 558

Procedure for Defining Invoice Due Date Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 560Components of an Invoice Due Date Formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

Calculating the Invoice Due Date Based on a Custom Subroutine . . . . . . . . . . . . . . . 563

Procedure for Defining Invoice Due Date Parameters . . . . . . . . . . . . . . . . . . . . . . 564

Setting Up Miscellaneous Invoice Defaults . . . . . . . . . . . . . . . . . . . . . . . 565

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

Understanding Miscellaneous Invoice Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

Components of Miscellaneous Invoice Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

Update AR Immediately . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566Defer Revenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

Procedure for Setting Up Miscellaneous Billing Parameters . . . . . . . . . . . . . . . . . 566

Defining Payment Allocation Parameters . . . . . . . . . . . . . . . . . . . . . . . . 567

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

Understanding Payment Allocation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

Understanding Invoice Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568

Understanding Non-Term Payment Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569

Types of Non-Term Payment Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570

Term and Non-Term Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570Non-Term Allocation Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571Restricted Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572


Ge

Non-Term Payment Allocation and Cash Receipt Payments . . . . . . . . . . . . . . . . . . . . 573

Non-Term Payment Allocation and Web Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

Non-Term Payment Allocation and Zero Dollar Payments . . . . . . . . . . . . . . . . . . . . . 575

Non-Term Payment Allocation and Refund Voucher Payments . . . . . . . . . . . . . . . . . . 575

Understanding Non-Term Financial Aid Allocation . . . . . . . . . . . . . . . . . . . . . . . . 576

Procedure for Setting Up Payment Allocation Parameters . . . . . . . . . . . . . . . . . . 576

Prioritize Invoices by Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577Apply Non-Term Payments to Term Invoices . . . . . . . . . . . . . . . . . . . . . . . . . . . 577Apply Fin Aid to Non-term Invoices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578

Defining Refund Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579

Understanding the Refund Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

LIFO Refund Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581

LIFO Refund Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582

FA/LIFO Refund Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583

FA/LIFO Refund Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583

CC/LIFO Refund Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584

CC/LIFO Refund Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584

FA/CC Refund Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585

FA/CC Refund Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586

CC/FA Refund Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587

CC/FA Refund Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587

Understanding Days to Refund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588

Credit Card Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588

Financial Aid Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589

Understanding Refund Override Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590

Procedure for Setting Up Refund Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590

Refund Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591Days to Refund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591Refund Override Security Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592


Ge

Assigning GL Posting Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593

Registration Invoices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593

Room Assignment Invoices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593

Meal Plan Invoices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594

Miscellaneous Invoices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594

Sponsored Account Invoices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594

Refund Vouchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594

AR Cash Receipts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

Non-AR Cash Receipts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

Cash Deposits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

Cash Receipt Reversals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

Financial Aid Transmittals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

Understanding GL Posting Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596

Using Summary GL Posting Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596

Using Default Detail GL Posting Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597

Assigning Detail GL Posting Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598

Overriding Detail GL Posting Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

Procedure for Defining GL Posting Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 601

Accounts Receivable Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603

Refund Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605

Registration Refund Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606

Registration Charges & Refund Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607

Course & Course Section Registration Refund Policies . . . . . . . . . . . . . . . . . . . . 608

Registration Billing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

Room Billing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611


Ge

Meal Plan Billing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

Registration Rate Billing Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

Tuition Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614

Registration Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615

Registration Term Rate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616

AR Add/Drop/Withdraw Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617

Tuition Waiver Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618

Tuition Discounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

Financial Aid Transmittal Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620

Room Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621

Room Rate Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622

Meal Plan Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623

Administrative Fee Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624

Academic Program Application Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625

Academic Level Application Fees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626

Invoice Due Date Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627

Invoice Due Date Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628

Miscellaneous Invoice Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629

Setting Up the Campus Organizations Module . . . . . . . . . . . . . . . . . . . . 631

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631

Campus Organization Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631

Setting Up Cash Receipts Defaults and Parameters. . . . . . . . . . . . . . . . 635


Ge

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635

Understanding Cash Receipts Module Parameters . . . . . . . . . . . . . . . . . . . . . . . . 636

Controlling When Cash Receipts are Posted to Accounts Receivable. . . . . . . . . . . . . 636

Defining Electronic Check Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637

Payment Method Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637

Procedure for Defining Payment Method Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 638

Understanding Cashier Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

Processing Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639

Processing Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640

Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640

E-Commerce Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641

Enabling E-Commerce for an Individual Cashier . . . . . . . . . . . . . . . . . . . . . . . . . . 641Enabling E-Commerce for a Group of Cashiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 642

The Selection Criteria Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

Check Payer Present . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

Understanding Nonsufficient Funds Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 643

NSF Charges and Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644Change Returned AR Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645Non-AR Receipt AR Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645

Procedure for Defining an NSF Charge Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645

Procedure for Setting Up Cash Receipts Defaults and Parameters . . . . . . . . . . . 646

Cash Receipts Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

Cash Receipt Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648

Cashier Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

Nonsufficient Funds Defaults and Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650

Defining Course Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652


Ge

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652

Defining Credits, Contact Hours and Instructional Load . . . . . . . . . . . . . . . . . . . . 652

The Default Delimiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653

Default Synonym Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654

Defining Course Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654

Allow Course Waitlist Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655Waitlist Rating Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655Required Course Subroutine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655Enroll Number of Days Default. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655Multiple Sections Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656

Defining Synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658

Understanding Synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658

How Colleague Handles Synonyms and Specifications . . . . . . . . . . . . . . . . . . . . . . . . 658

Procedure for Defining Synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659

Defining Academic Evaluation Sort Types. . . . . . . . . . . . . . . . . . . . . . . . 660

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660

Understanding Evaluation Sort Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660

Procedure for Defining Academic Sort Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662

Defining Academic Evaluation Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . 663

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

Understanding Academic Evaluation Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663

Overriding Academic Evaluation Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664

Storing Evaluations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664

Defining Evaluation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665

Handling Extra Courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665

Selecting Courses Based on Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665

Defining Merge Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665


Ge

Including Courses Based on Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667

Defining a Cutoff Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667

Defining the Preferred E-Mail Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667

Defining Format Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668

Report Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668

Related Courses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668

Ignored Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669

Procedure for Defining Academic Evaluation Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 669

Restricting Additional Valid Requirement Types. . . . . . . . . . . . . . . . . . . 670

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670

Understanding Additional Valid Requirement Types . . . . . . . . . . . . . . . . . . . . . . . 670

Procedure for Defining Additional Valid Requirement Types . . . . . . . . . . . . . . . . . . . . 671

Defining Custom Paragraphs for the Evaluation Report . . . . . . . . . . . . 672

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672

Understanding the Evaluation Report Paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . 672

Defining the Custom Paragraph Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673

Writing Your Paragraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673

Procedure for Defining Custom Paragraphs for the Evaluation Report . . . . . . . . . . . . 673

Degree Audit Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674

Academic Evaluation Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674

Academic Evaluation Sort Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675

Additional Valid Requirement Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676

Synonyms and Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

Financial Aid File Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680


Ge

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680

Understanding FA File Suite Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680

File Suite Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680

Maintaining File Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

Noteworthy Fields on the FFSP Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686

Suite Year. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686Suite Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686Files to Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686

Procedure for Maintaining File Suites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686

Financial Aid System Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

Forms Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

Maintaining FA System Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

Noteworthy Fields on the FASP Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689

Allow New Person Add. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689Create Prospects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690

Procedure for Setting Up FA System Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690

Financial Aid Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

Understanding FA Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

Overview of the Setup Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

Forms Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

Creating an Initial Award Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

Procedure for Creating the Initial Award Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694

Maintaining FA Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695

Noteworthy Fields on the FADD Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695

Current Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695Current Award Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695Obsolete Fields on the FADD From . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696


Ge

Setting Up FA Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696

FA Office and Location Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

Understanding FA Offices and Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

Institutional Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698

Forms Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Setting Up FA Offices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Maintaining Institutional Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Noteworthy Fields on the FIDF Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700

FA Office ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700Health Prof Prog Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701Verif Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701Teacher Certification Program Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701

Allowing Higher Loan Limits for Health Professions Students . . . . . . . . . . . . . . . . . . . 701

Procedure for Setting Higher Loan Limits for Health Professions Students . . . . . . 702

Maintaining FA Office Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702

Noteworthy Fields on the FAOP Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

Office Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

Procedure for Setting Up Your Main FA Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

Procedure for Setting Up Additional FA Offices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704

Setting Up FA Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705

Noteworthy Field on the FLCD Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706

FA Office. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706

Creating Location Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706

Noteworthy Fields on the LCRL Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707

Default Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707Rule / Virtual Field Name / Location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708Location Subroutine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

Procedure for Creating FA Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

Setting Up the Faculty Information Module . . . . . . . . . . . . . . . . . . . . . . . 711


Ge

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711

Setting Up Codes for the Faculty Information Module . . . . . . . . . . . . . . . . . . . . . . 711

Setting Up Rules for the Faculty Information Module. . . . . . . . . . . . . . . . . . . . . . . 714

Defining Faculty Information Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

Understanding Advisor Assignment Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

When Colleague Evaluates the Advisor Assignment Rules . . . . . . . . . . . . . . . . . . . . . 715

How to Define Advisor Assignment Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716

Example: Advisor Assignment Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716

Procedure for Defining Advisor Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718

Defining Faculty Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

Understanding Faculty Information Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

Workload Calculation Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

Contract Position Subroutine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721

Defining Admissions Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

Understanding Admissions Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

Admissions Representative/AARS Assignment Rules . . . . . . . . . . . . . . . . . . . . . . 726

When Colleague Evaluates the Admissions Representative Assignment Rules . . . . . 726

Assigning Representatives to Applicants and to Applications . . . . . . . . . . . . . . . . . 726

How to Define Admissions Representative Assignment Rules. . . . . . . . . . . . . . . . . . . 727

Example Admissions Representative Assignment Rules . . . . . . . . . . . . . . . . . . . . 727

Procedure for Defining Admissions Representative/AARS Rules . . . . . . . . . . . . . . . . 728


Ge

Admissions Tracking Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729

When Colleague Evaluates the Admissions Tracking Rules . . . . . . . . . . . . . . . . . . . . 730

How to Define Admissions Tracking Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730

Procedure for Defining Admissions Tracking Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 732

Application Rating Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733

When Colleague Evaluates the Application Rating Rules . . . . . . . . . . . . . . . . . . . . . . 734

How to Define Application Rating Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734

Procedure for Defining Application Rating Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

Academic Program Admit Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736

When Colleague Evaluates the Academic Program Admit Rules . . . . . . . . . . . . . . . . 736

How to Define Academic Program Admit Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737

Procedure for Defining Academic Program Admit Rules . . . . . . . . . . . . . . . . . . . . . . . 738

External Course Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739

When Colleague Evaluates the External Course Rules . . . . . . . . . . . . . . . . . . . . . . . . 739

How to Define External Course Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740

Sort Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740

Procedure for Defining External Course Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741

External Transcript GPA Selection Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742

When Colleague Evaluates the External Transcript GPA Selection Rules. . . . . . . . . . 743

How to Define External Transcript GPA Selection Rules . . . . . . . . . . . . . . . . . . . . . . . 743

Procedure for Defining External Transcript GPA Selection Rules . . . . . . . . . . . . . . . . 744

Prospect Rating Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746

When Colleague Evaluates the Prospect Rating Rules . . . . . . . . . . . . . . . . . . . . . . . . 746

How to Define Prospect Rating Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746

Procedure for Defining Prospect Rating Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747

Student Creation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748

Setting Up Admissions Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749

Understanding Admissions Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749


Ge

Admissions Processing Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750

Snapshot Prospect Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750Auto Create Transfer Equivalencies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751Auto Update Application Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751Use Short Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751

Applicant/Prospect Data Entry Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751

Student Record Creation Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752

Student Creation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753

Procedure for Defining Student Creation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756

Create Student Record Immediately . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757Copy Admit Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757

How the Students Record Creation Parameters Work Together . . . . . . . . . . . . . . . 759Copy Special Services Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761Application Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761Default Move-to-Student Communication Code. . . . . . . . . . . . . . . . . . . . . . . . . 761Student Program Activation from Student Records . . . . . . . . . . . . . . . . . . . . . . 761Move-to-Stu Application Select Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762

Common Application Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762

Procedure for Defining Admissions Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . 765

Defining Tests and Other Noncourse Items. . . . . . . . . . . . . . . . . . . . . . . 766

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

Understanding Noncourses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

Components of a Noncourse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

Noncourse Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768

SOC Credit Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769

Minimum, Maximum, and Desired Score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769

Grades and Grade Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769

Grade/Score to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769

Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770

Example Noncourse Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770

Standard Admissions Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770Tests with Specific Course Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771Tests with General Academic Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772Military Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773

Procedure for Defining Noncourses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773


Ge

Defining Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774

Understanding Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774

Understanding Standard Course Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 775

Components of a Standard Course Equivalency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775

Transfer Course Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776Equivalent Course Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777Start Date and End Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777Grade Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777Minimum Grade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777Default Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778Transfer Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778Equiv Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778

Example Standard Course Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778How Colleague Calculates Transfer Course Credits . . . . . . . . . . . . . . . . . . . . . . . . 779

Understanding Noncourse Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780

Components of a Noncourse Equivalency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780

Noncourse Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781Minimum and Maximum Scores and Grades. . . . . . . . . . . . . . . . . . . . . . . . . 781

Considerations for Defining Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782

Transfer Course Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782

Advanced Placement Courses and Advanced Placement Test? . . . . . . . . . . . . . . . . . 783

Advanced Placement Courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783Advanced Placement Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783

When to Define a Standard Equivalency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783

Defining Equivalencies During Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784Defining Equivalencies When Entering a Transcript . . . . . . . . . . . . . . . . . . . . . . . . 784Note About Default Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785

Procedures for Defining Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786

Procedure for Defining Transfer Course Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . 786

Procedures for Defining Noncourse Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 786

Procedure for Defining a New Noncourse Item with an Equivalency . . . . . . . . . . . 786Procedure for Defining a Noncourse Equivalency for an Existing Noncourse Item 787

Recruitment/Admissions Management Worksheets . . . . . . . . . . . . . . . . 789

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789


Ge

Admissions Default Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790

Noncourse Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791

Noncourse Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792

Course Equivalencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794

Defining Registration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798

Understanding Registration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798

Student Eligibility Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799

When Colleague Evaluates the Student Eligibility Rules . . . . . . . . . . . . . . . . . . . . . . . 799

How to Define Student Eligibility Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799

How to Define Student Eligibility Rules to Require Confirmation of Emergency Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799

Procedure for Defining Student Eligibility Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800

Course Eligibility Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801

When Colleague Evaluates the Course Eligibility Rules . . . . . . . . . . . . . . . . . . . . . . . 801

How to Define Course Eligibility Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802

Procedure for Defining Course Eligibility Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802

Completion Eligibility Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803

When Colleague Evaluates the Completion Eligibility Rules . . . . . . . . . . . . . . . . . . . . 803

How to Define Completion Eligibility Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803

Procedure for Defining Completion Eligibility Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 803

Defining Registration Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805

Understanding Registration Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805


Ge

Components of a Registration Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806

LookUp Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808

Section Lookup Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808Apply Section LookUp Restrictions as Section Display Restrictions . . . . . . . . . 808Section Display Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809Student LookUp Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809Restrict LookUp by Staff Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809

Registration Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809

Print Setup for Registration Statements & Schedules . . . . . . . . . . . . . . . . . . . . . . . 810Print Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812Statement Print Subroutine, Printer, and Form Image . . . . . . . . . . . . . . . . . . . . 812Summary Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812Calculate Remaining FA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813Deduct Remaining FA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813Show Section Synonym . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813Show Waitlisted Courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813Name/Address Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813Produce Remittance Slip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813Show Balance Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814Show Other Charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814Show Future Charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814Print Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814Schedule Print Subroutine, Printer, and Form Image. . . . . . . . . . . . . . . . . . . . . 814

Print Setup for Account Information Displayed on WebAdvisor Forms . . . . . . . . . . 814Print Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815Calculate Remaining FA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815Deduct Remaining FA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816Show Balance Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816Show Other Charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817Show Future Charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817

Data Entry Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818Section Percentage Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819Pay Now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819Allow Pass/Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819Allow Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820Registration Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820Waitlist Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821

Eligibility Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821

Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822

Procedure for Defining Registration Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825

Assigning Registration Controls to Registration Users . . . . . . . . . . . . . 826

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826


Ge

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826

Understanding Registration User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826

Components of a Registration User Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827

Registration Functions Permitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828

Registration Control Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828

Registration Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829

Print Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832

Staff Group Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833

Override Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833

Case Study: Setting Up Registration Control Codes and User Groups . . . . . . . . 834

Procedure for Assigning Registration Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 835

Defining Registration Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836

Understanding Registration Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836

General Registration Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837

Audit Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837

Log Registration Overrides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838

Concurrent Requisite Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838

Default Academic Programs and Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838

Registration Session Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839

Transaction Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839

Default Registration Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839

Procedure for Defining Registration Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840

Defining Waitlist Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841


Ge

Understanding Waitlisting Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841

Allow Course Waitlist Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842Waitlist Rating Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843Required Course Subroutine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843Enroll Number of Days Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843Multiple Sections Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843E-Mail Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843Space Available Paragraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843Student Enrolled Paragraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844Space Available Comm Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844Space Available Comm Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844Student Enrolled Comm Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844Student Enrolled Comm Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844Defining a Custom Paragraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845Merge File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845Financial Aid Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846Paragraph Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846

Procedure for Defining Waitlist Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847

Initializing or Updating Waitlist Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 848

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848

Understanding Initializing or Updating Waitlist Fields . . . . . . . . . . . . . . . . . . . . . . 849

Waitlist Mult Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850Waitlist Enroll No Days . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850Saved List Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851Update Courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851Academic Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851Schools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851Divisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851Departments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851

Procedure for Initializing Waitlist Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851

Registration Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852


Ge

Student Eligibility Rules — English Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 853

Course Eligibility Rules — English Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 854

Completion Eligibility Rules — English Statements . . . . . . . . . . . . . . . . . . . . . . . . 855

Defining Residence Life Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858

Understanding Residence Life Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858

Defining File Types for Housing Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859Defining Notification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859Defining Mailing and Address Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859

Procedure for Defining Residence Life Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860

Setting Up a Meal Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861

In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861

Understanding Meal Plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861

Defining Restrictions for a Meal Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862Recording Rate Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862

Procedure for Setting Up a Meal Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862


Introduction

55Getting Started with Colleague Student | Introduction

Introduction

What Does This Manual Cover?

This manual provides instruction for setting up the modules within Colleague Student. The instructions provided in this manual do not take into consideration your institution’s policies that may influence how you set up your parameters, codes, and defaults. Wherever possible, we indicate how your policies may have a specific impact on a particular area of the system setup and remind you to consider those policies before proceeding.

Where Can I Find More Information?

For information about using the different modules within Colleague Student, refer to the following publications:

Table 1: Locating Related Information about Colleague Student Modules

Module Publication

Academic Records Using Academic Records

Accounts Receivable Using Accounts Receivable/Cash Receipts

Campus Organizations Using Campus Organizations

Cash Receipts Using Accounts Receivable/Cash Receipts

Curriculum Management Using Curriculum Management

Degree Audit Using Degree Audit

Financial Aid Using Financial Aid

Faculty Information Using Faculty Information

Recruitment/Admissions Management

Using Recruitment/Admissions Management

Registration Using Registration

Residence Life Using Residence Life

Overview

Ge

Overview of Colleague Student

In This Chapter

After a short description of Colleague Student, this chapter introduces you to the modules within Colleague Student and how they interact with other parts of Colleague. The information in this chapter is presented alphabetically by module name, beginning on 59.

Colleague Student

Colleague Student provides an automated administrative solution for all aspects of student services provided by your institution. Its Instructional Management, Enrollment Management, and Campus Life components encompass the wide variety of information and service requirements necessary to support your strategic enrollment management program. The ability to generate and track faculty and curriculum information, effectively target and recruit prospective students during the admissions process, process financial aid applications using electronic data exchange with federal information sources, provide automated registration, perform degree auditing online, process accounts receivable and cash receipts, and maintain campus organizations and residence life records online all add up to a comprehensive system for student management. The integration of Colleague Student with the other parts of Colleague, as well as the ability for students and faculty to access parts of Colleague Student via the World Wide Web, provides increased productivity for your administrative staff, improved retention rates for your institution, increased marketing and strategic planning capabilities, and improved service for students.

• The Instructional Management component tracks and maintains all aspects of faculty information and curriculum management, aiding with the development of your institution's academic infrastructure. Your institution can more efficiently develop academic programs, handle customized course scheduling and catalogs, formulate and enforce academic policy, and manage faculty responsibilities.

• The Enrollment Management component provides the information and tools necessary for your institution to achieve and maintain its optimum recruitment, retention, and graduation rates. Your institution can effectively target and increase the yield of prospective students, quickly process applications, manage all aspects of financial aid processing, increase the productivity and efficiency of the registration process, support accounts receivable and cash receipts processing, monitor academic progress, and track and maintain academic records.

• The Campus Life component maintains and tracks information on campus organizations and residence life to help your institution manage on-campus housing and better understand student participation and development in non-classroom settings.

58tting Started with Colleague Student | Overview of Colleague Student

Ge

Understanding Colleague Student Modules

Colleague Student is comprised of the following modules:

• Academic Records

• Accounts Receivable

• Campus Organizations

• Cash Receipts

• Curriculum Management

• Financial Aid

• Recruitment/Admissions Management

• Registration

• Residence Life

This section provides a general description of each of these modules along with a diagram illustrating how the module interacts with other modules in both Colleague Student and the rest of Colleague.

Academic Records

As part of the Enrollment Management component of Colleague Student, the Academic Records module tracks and maintains all information accumulated about individual students throughout their academic career at your institution.

The Academic Records module builds on the information acquired during the admissions cycle to create each student's administrative and academic record. All information can be updated individually or in batch mode to reflect changes in residency status, degree codes, major declarations, areas of concentration, advisor assignments, or academic progress. In addition, the module provides a history of the student's academic standing at your institution at specified points in time, such as at the end of a session or a term. This module generates enrollment verification reports on demand for use by outside organizations such as the Veterans Administration, insurance companies, lending institutions, or the NCAA, providing an online history of where verifications were sent. Following registration, the module produces a roster for each section that can be printed or viewed online, as well as a list of open, closed, and wait-listed sections. This module also assigns students to advisors based on a variety of user-defined criteria, including credits earned, academic status, program, major, educational objective, department, and campus/site. This module calculates GPA by term, credit type, and overall; calculates credit hours to determine the student's class; and calculates class rank. This module allows students to access selected data online, while your institution retains the ability to purge or archive selected student data (such as course rosters and transcripts) to tape or disk when no longer needed.


Ge

Accounts Receivable

As part of the Enrollment Management component in Colleague Student, the Accounts Receivable module can handle all aspects of your institution's accounts receivable process, including automatic invoicing, subsidiary ledgers, payment plans, sponsor billing, aging of receivables, financial aid credits, and automatic updates to the general ledger upon payment receipt. This module is tightly integrated with other modules in Colleague Student, as well as modules in the Financial System that track accounting information and cash transactions.

The Accounts Receivable module allows your institution to create unlimited subsidiary ledgers for different types of receivables, such as student, employee, and miscellaneous fees; establish deferred payment plans and print payment coupons; calculate and apply finance and service charges, interest, exemptions, or discounts; age receivables using detailed and aged trial balances; process invoices for selected groups or individuals online or in batch mode; track funds awarded to students by third-parties; and inquire about account balances online. In addition, the system supports automatic add/drop billing with tuition and fee forfeiture based on criteria defined by your institution, taking into account multiple course start dates. It also processes refund checks through an interface with the Accounts Payable module.

Your business office can specify to withhold registration privileges for any student with an accounts receivable balance. Once the student makes the appropriate payment of tuition, fees, or other miscellaneous charges, the accounts receivable balance is automatically updated online so the registration hold can be immediately released. Your business office is also able to automatically charge a service charge for any checks returned for non-sufficient funds, as well as generate a detailed deposit slip that splits payments into various funds. The system also enables your business office to define whether all accounts, selected accounts, or only overdue accounts will receive printed statements at regular intervals. This feature is provided for student accounts receivables as well as for non-student accounts receivables, such as for outside groups renting on-campus meeting rooms on a recurring basis.

Campus Organizations Module

As part of the Campus Life component of Colleague Student, the Campus Organizations module provides your institution with a single source of information on campus organizations and their members.

The Campus Organizations module is used to enter and maintain information about organizations, clubs, fraternities, sororities, student or faculty committees, and other campus social groups. This module includes the capability to record the organizational structure of each group, including names of officers and advisors. It also tracks the purpose of each group and any restrictions placed on the group or its members.

Cash Receipts

As part of the Enrollment Management component of Colleague Student, the Cash Receipts module provides the tools necessary to process and record all payments to your


Ge

institution, including payments from accounts receivable invoices, continuing education enrollments, and donations.

The Cash Receipts module provides online entry of all cash receipts, a complete audit trail for all transactions, a bad check file, bank deposit reports, and daily cash analysis reports with totals by cashier, location, and payment type. In addition, the system can simultaneously accept payments of many types, including cash, check, and credit card, and apply a single payment to multiple accounts. In the case of accounts receivable payments, the account detail is automatically updated online upon receipt of payment.

Curriculum Management

As part of the Instructional Management component of Colleague Student, the Curriculum Management module makes the job of scheduling courses, classrooms, and faculty more efficient and productive.

The Curriculum Management module enables your institution to support a variety of term-based and non-term-based schedules, as well as adult and continuing education courses. This module allows you to easily schedule courses and sections, producing customized course catalogs and schedules. For each course, the module allows you to define the name of the course, the course identifier, the subject and course description, the department/school offering the course, the type of the course, credits or continuing education units, course level, contact hours, workload units, required faculty qualifications, cross-listed courses/sections, billing parameters, requisites, restrictions, capacities, location, grading policies, repeat policy, supplies needed, and equipment requirements. New courses can be created online, with the ability to capture required state and local approval codes and agencies. Using this module, your institution can also develop criteria for moving students from waiting lists to the appropriate section as space becomes available.

Degree Audit

As part of the Enrollment Management component of Colleague Student, the Degree Audit module improves your institution's advisory services to students, ensures students stay on track in their efforts toward graduation, and facilitates review of alternate degree programs. This module works closely with the Registration and Academic Records modules to use up-to-date course registration and completion data to determine progress toward degree requirements.

The Degree Audit module uses transfer transcript information, non-course evaluations, and completed course information to determine progress toward degree requirements. It also provides up-to-date information on a student's academic progress in his or her general course of study and specialized individual programs, including credits completed and grades earned, graduation requirements, cumulative GPA and major GPA, completed courses, courses in progress, repeated courses, outstanding courses, non-course requirements, and exceptions granted by academic departments. This module includes a built-in warning mechanism to alert students enrolled in a specific program when the degree requirements for that program are updated or changed. The Degree Audit module can also track a student's progress toward completion of multiple academic programs and update a student's academic records automatically following a change in academic


Ge

program. This module automatically audits the records of all degree candidates, generates a list of candidates who have met all requirements as well as those who have not met all requirements, and updates permanent records when degree requirements have been met. Based on this information, the module can generate a potential graduate list, sorting it alphabetically, by department, by descending grade point, and by types of honors achieved.

Financial Aid

As part of the Enrollment Management component of Colleague Student, the Financial Aid module helps your institution manage all aspects of financial aid processing, including initial filing of financial aid applications, preparing reports to meet federal requirements, tracking continued student eligibility for aid, and automatically posting financial aid awards to accounts receivable when appropriate. This module works hand-in-hand with the other modules in Colleague Student to ensure that financial aid is appropriately administered and distributed.

The Financial Aid module uses the Core's Communications Management module to track and maintain contact with applicants in an effort to ensure they complete all aspects of the financial aid application and submit all documents required for packaging and disbursement. When financial aid applications are complete, your institution can perform awarding on an individual basis, or by using automatic packaging or batch processing. Your institution can use this module to develop financial aid budgets on the basis of student characteristics, including federal, institutional, and Pell budgets. In addition, the dollar amount limit for federal work-study funds made available as part of the financial aid package are automatically linked with the Payroll module. As the student is paid, the work-study balance is debited in the student's financial aid file. The Financial Aid module also enables your financial aid officers to perform online inquiries of student accounts receivables and student registration data to ensure that each student is taking enough courses to retain his or her financial aid eligibility.

Faculty Information

As part of Colleague Student's Instructional Management component, the Faculty Information module provides your institution with a central source for the entry and maintenance of all information related to faculty members, including qualifications, schedules, advising responsibilities, and course assignments.

The Faculty Information module accesses the demographic information maintained on each faculty member in the Core System's Core Demographics module to ensure the most up-to-date information is always available. Each faculty member's office information is maintained by the system, including campus address, Internet address, fax number, phone numbers, and office hours by term. The system tracks the entry and maintenance of all faculty academic credentials, including additional information on degrees and theses. It also maintains information on the academic level, departments, subjects, course levels, and courses each faculty member is certified to teach (for both credit and continuing education courses), as well as qualifications to serve on dissertation committees. This module also tracks position information for each faculty member, including the position title and the date the position was assumed, as well as the


Ge

department, division, and school the faculty member works for and the percentage of time the faculty member devotes to various departments.


As part of the Enrollment Management component of Colleague Student, the Recruitment/Admissions Management module supports your institution's strategic enrollment management program through the targeted recruitment of students, a focus on increasing the yield of prospects, the efficient management of the admissions process, and the evaluation of your institution's progress against its established goals. This module provides tools to develop and implement assertive and well-focused efforts for recruiting students, and follow-up mechanisms for contact during the admissions process.

Using queries and reports, the Recruitment/Admissions Management module gives your institution the capability to perform analysis on information about prospective students to understand their areas of interest in terms of specific programs or majors; where they first heard about your institution; the secondary school they attended; their test scores and subscores, including the ACT, SAT, Advanced Placement tests, LSAT, and MCAT; and their current status in the application process. During the application process, applicant records can be updated individually or in batch mode. This module includes the ability to input the Common Application and import transcripts using the SPEEDE format. This module also summarizes all contacts with individual prospects from recruitment through matriculation, without any duplicate data entry. Through the integration of the Recruitment/Admissions Management module with Colleague's other modules, your admissions officers are able to view financial aid information and status about each applicant online, as well as any outstanding admission-related fees. This module includes a rules-based processor to automate admissions decisions and generate waiting lists based on user-defined criteria, such as SAT scores, GPA, requisites, or recommendations. A simplified admissions process is also included in the module for admitting students to continuing education or community college programs.

Registration

As part of the Enrollment Management component of Colleague Student, the Registration module makes the job of registering your institution's students more efficient and productive through the use of automation and integration with other modules.

The Registration module enables your institution to register all types of students using multiple formats, including data entry by staff, optical scanning, student entry, or PC registration. This module allows your registrar to create and maintain unlimited user-defined terms for student registration, as well as create registration priority rules for classes of students. It also allows pre-registration, registration, and drop/add processing of students, generating appropriate warnings if the student's selected course of instruction violates applicable parameters. Students are able to register for all types and levels of courses at a single session, including continuing education, undergraduate, graduate, correspondence courses, courses on multiple campuses, courses covering multiple terms, and variable credit courses. Departments are able to designate a specific number of seats in each course for students meeting certain criteria, such as academic level, class, or major. This module gives your institution the ability to set waitlist maximums for each course, define priorities for moving students from the waiting list to enrolled status, and


Ge

purge waitlists at the end of each term. Based on registration information, the module can generate class rosters, as well as a variety of summary reports based on such factors as the students' academic level and major. Course enrollment data is maintained online to provide for easy access to course names and numbers, CIP numbers, maximum and current enrollment data, and open and closed sections. This module also provides generation of diskettes/tapes reflecting current student status for use by the National Student Clearinghouse.

Residence Life

As part of the Campus Life component of Colleague Student, the Residence Life module allows your institution to process room and board assignments and ensure students are appropriately charged for room, board, and other miscellaneous fees related to residence life.

The Residence Life module produces housing occupancy and vacancy reports, room change reports, and housing assignments. This module also generates online meal plan assignments and room and board agreement letters. Using the information in the Core System's Facilities Profile module, the maintenance of residence hall information at the hall and room level ensures the appropriate room and board billing rates are automatically posted to the student's accounts receivable account for invoice purposes. This module also allows for your Residence Life office to post miscellaneous charges to each student's accounts receivable account for items such as lost keys or dormitory damage.


Colleague Student Codes

Ge

Understanding Student Codes

In This Chapter

This chapter introduces the concepts surrounding the use of codes in Colleague Student, focusing on a basic understanding of their function.

The chapter is divided into the following sections:

• Understanding codes (brief discussion of purpose and function of codes).

• Comprehensive list of Colleague Student codes (a table indicating the module or modules in which each code is used).

Understanding Codes

A code is a character or group of characters (alphabetic, numeric, or combined alpha and numeric) used to represent a piece, or pieces, of related information. Codes provide a shortcut method for handling data by letting you group together many pieces of information under one code; in this way, a one- or two-character abbreviation can be used to represent a much larger body of information.

The information in codes can be as simple as the name of a building on your campus, or complex enough to indicate relationships between several items of information. For example, you use an AR code to provide detailed information to Colleague about how revenue associated with charges and credits is distributed to an accounts receivable account.

Codes are also extremely helpful in standardizing data entry, providing advantages by:

• Establishing standard values for certain data elements, ensuring uniformity of data.

• Limiting the valid responses a user has for data entry.

• Increasing data entry efficiency and speed.

• Simplifying data entry by storing several related pieces of information in a single code that can be added to a record in one step.

• Providing consistent values, and descriptions of those values, on forms and in reports, thereby ensuring more accurate and meaningful reporting.

67tting Started with Colleague Student | Understanding Student Codes

Ge

Codes in Colleague Student

Codes are used extensively throughout Colleague Student to ensure that information about your applicants, students, faculty, courses and sections, registration, room and board arrangements, and other important information is consistent across your entire system.

Sharing of Codes Between Modules

Because of the integrated functionality of Colleague Student, many types of information are shared between the various modules. The codes provide information useful at numerous points in system processing.

In many cases a single code is used by several Colleague Student modules. For example, instructional method codes

• Are defined and used as part of course and section offering information in the Curriculum Management (CU) module.

• Play a part in faculty section assignment in the Faculty Information (FI) module.

• Are displayed with course section information in the Registration (RG) and Academic Records (AC) modules.

• Are used as one of the selection criteria in Texas state reporting.

When you define the codes for your area of work, be sure to become familiar with codes that are used in your subject area of Colleague Student but that are “owned” by other modules. You should know whom to contact at your institution to ensure that the necessary values are added to the codes that you will need to use but are not maintained in your subject area of Colleague Student.

Codes from Colleague Core

In addition to student-related information, Colleague Student also makes extensive use of many types of information maintained and used primarily in the Core application. Some of the major types of Core information include:

• Departments and divisions

• Schools

• Buildings and rooms

• Locations

• Ethnicities

• Races

• Counties, states, and countries

• Handicaps and special health needs


Ge

• Veteran statuses

• Information for completing biographical information, such as name, address, citizenship, prefixes and suffixes of names, or educational background

• Correspondence and communications information

All this information is stored in Colleague Core, using codes. These Core codes include codes related to the functions of Core modules such as Person Demographics, Organization Information, Facilities Profile, Scheduling, Activities and Events, and Communications Management. Core forms are frequently accessed from Colleague Student forms or from menus within Colleague Student.

Because of this interdependency, you should become familiar with codes that are not directly used or updated in Colleague Student. When defining your institution’s codes, you should also know whom to contact to ensure that the values necessary to your office’s uses of the codes are added to the codes owned by the Core application.

Comprehensive List of Colleague Student Codes

Table provides an alphabetical list of all codes within Colleague Student application. Mnemonics representing the names of Colleague Student modules and Colleague applications are arranged across the top, and the codes are listed in alphabetical order along the left side of the table.

This table provides the following information about each code:

• The actual name by which Colleague recognizes the code (for example, RESIDENCY.STATUSES).

• The mnemonic of the form used to maintain the code (appears beneath each code name).

• If the code is user-maintainable, the module that “owns” the code.

• Other modules and applications where the code is used.

Every code that is user-maintainable is “owned” by one module — even though the code may be used by several different modules, the module most closely related to the code’s subject matter is classified as the owner of the code.

The table includes all codes used in any module of Colleague Student, including those pre-defined by Ellucian (and not user-maintainable). It also lists all Core codes used on forms in Colleague Student, including codes appearing on Core forms that can be accessed as detail forms from Colleague Student forms or from menus within Colleague Student. For example, the entire Communications Management module can be accessed from the Recruitment/Admissions Management module main menu; thus all codes used in Communications Management are listed in this table as accessible from the Recruitment/Admissions Management module.

For each code, the symbols in the module columns indicate the following:


Ge

• A D indicates the primary module or application where you can maintain the code; that is, the module that “owns” the code based on the code’s subject matter and functions within Colleague Student.

• A U indicates any modules or applications that use the code but are not primarily responsible for the code’s subject matter.

• A P indicates the modules or applications that use an Ellucian pre-defined code (these codes can be modified only with the assistance of an Ellucian representative).

For more detailed information and explanations of the codes in this table,

• See “Defining Colleague Student Codes” on page 137 of this manual.

• See the online help for any code defined on an individual form.

• See the Purpose field on the Validation Codes (VAL) form for validation codes.

Different Types of Codes: General Guidelines

Listed on the line following each code in Table 3 is a mnemonic indicating where that code is defined. The mnemonics are of two different kinds: some codes have the mnemonic VAL, followed by either “ST” or “Core;” others have four-letter mnemonics (such as “SCTY” for SCHED.TYPES).

Note the following differences in the methods of defining these two different types of codes.

• Codes maintained on the VAL form. Codes set up on the Validation Codes (VAL) form are called validation codes. Validation codes are stored as part of either Colleague Student or the Core application — never both. The two groups of codes (ST and Core) are defined on two different VAL forms:

• Codes whose mnemonic in the table is “VAL/ST” are stored in the st.VALCODES file, and can be accessed on the VAL form from anywhere in the ST application

• Codes whose mnemonic in the table is “VAL/Core” are stored in the CORE.VALCODES file, and can be accessed on the VAL form only when you exit the ST application and enter the CORE application from the DBMS prompt

• Codes maintained on their own form (with mnemonic other than VAL). Codes set up on their own forms are called code files. During daily processing, you use LookUp to access the values for these files. Each of these files is defined on a unique form and is most frequently listed on the setup menu for the module that owns it.

About Special Processing Codes (Validation Codes Only)

If you choose to modify the delivered codes, and a code you are modifying has special processing, you must make sure that all of the special processing codes delivered with your software are represented in the codes you define. If you do not, any given Colleague process that may be looking for a specific special processing code will not perform properly.


Ge

For example, if special processing codes “1” through “8” are delivered, be sure you have defined a code corresponding to each of the eight special processing codes. The special processing codes are hard-coded in the programs to drive specific processing. In some cases, these statuses are actually assigned by Colleague based on the special processing code.

See “Defining Validation Codes” on page 292 for more information on special processing.

Notes About the Table

The column headings in Table 3 list Colleague Student modules and other Colleague applications where codes are used. The following legend explains the abbreviations used in the table.

Note: Table 3 provides summary information only. For greater detail on any of these codes, see “Defining Colleague Student Codes” on page 137 or online help.

Table 2: Column Headings Legend

Column Headings Legend

AC Academic Records module

AM Recruitment/Admissions Management module

AR Accounts Receivable module

CO Campus Organizations module

CR Cash Receipts module

CU Curriculum Management module

DA Degree Audit module

FA Financial Aid module

FI Faculty Information module

RG Registration module

RL Residence Life module

ST General Colleague Student functions

CORE Core Application

CF Colleague Financial System

HR Colleague Human Resources System

FR Fund Raising System


72

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A(

AC(

A(

U

A(

U

A(

A(

A(

A(

D

A(

U D

A(

D

Table 3: Colleague Student Codes

D Code is defined in this module U Code is used in this module P Code is pre-defined

ode NameMnemonic For Defining)

Colleague Student Modules

AC AM AR CO CR CU DA FA FI RG

CAD.COMMITTEE.TYPESVAL/ST)

D

CAD.PROGRAM.HONOR.ODES

VAL/ST)

U D U

CAD.PROGRAM.TYPESVAL/ST)

D U

CAD.REUMT.TYPESVAL/ST)

U U D

CAD.STANDING.TYPESVAL/ST)

P

CAD.STANDINGSVAL/ST)

D U U

CAD.STATUSESVAL/ST)

CADEMIC.CALENDARSVAL/Core)

U U U U U

CCESS.STATUSESVAL/Core)

U

CCREDITATION.TYPEVAL/Core)

U U U U U

73

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

A(

P

A(

A(

P P

A(

A(

U D

A(

P

A(

U D

A(

A(

A(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

CKNOWLEDGE.METHODSVAL/Core)

P

CTION.CATEGORIESVAL/ST)

P

CTIVE.STATUSESVAL/Core)

P

DD.DROP.AMT.TYPESVAL/ST)

P P

DDRESS.CHANGE.SOURCESVAL/Core)

U U U

DDRESS.HIERARCHY.TYPESVAL/Core)

P

DDRESS.ROUTE.CODESVAL/Core)

U U U U U

DM.MISC1VAL/ST)

D

DM.MISC2VAL/ST)

D

DM.MISC3VAL/ST)

D

Table 3: Colleague Student Codes (continued)





74

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

A(

A(

A(

P P

A(

A(

U D

A(

U D

A(

A(

D

A(

A(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

DM.MISC4VAL/ST)

D

DM.MISC5VAL/ST)

D

DMIN.TYPESVAL/Core)

DMIT.STATUSESADST)

U D U U U

DREL.STATUSESVAL/Core)

U U U U

DREL.TYPESVAL/Core)

U U U U U

DVISOR.TYPESVAL/ST)

D U U

LIEN.STATUSESVAL/Core)

U U

M.REMARK.CODESVAL/ST)

D

M.REMARK.TYPESVAL/ST)

D






75

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

A(

U

A(

U D

A(

A(

A(

A(

A(

A(

A(

A(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

P.TAXESARTX)

D U

P.TYPESAPTF)

U

PPL.EXTL.TRAN.INDICSVAL/ST)

D

PPL.FEE.STATUSESVAL/ST)

P P

PPL.INFLUENCESVAL/ST)

D

PPL.PRIORITIESVAL/ST)

D

PPL.STATUS.COLUMNSVAL/ST)

D

PPL.STATUS.CONTROLSVAL/ST)

P P

PPL.TEST.SOURCESVAL/ST)

D

PPLICATION.STATUSESAPSM)

D U U U






76

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

A(

A(

A(

A(

A(

A(

A(

A(

U

A(

A(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

R.ADD.DROP.POLICIESADWP)

D

R.ALLOC.NONTERM.PMTSVAL/ST)

P

R.AMT.CALC.TYPESVAL/ST)

P P P

R.BALANCE.BY.CODE.LEVELSVAL/ST)

D

R.BALANCE.BY.TYPE.LEVELSVAL/ST)

D

R.CASH.RCPT.DESCSVAL/ST)

P

R.CATEGORIESACTF)

D U U

R.CODESARCF)

U U D U U U U

R.DEPOSIT.TYPESDPTY)

U D U U

R.DUE.DATE.FORMULASIDDF)

D






77

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

A(

A(

A(

A(

A(

A(

A(

A(

A(

A(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

R.EXCEPTION.REPORTSVAL/ST)

D

R.FEE.DEFAULTSARFD)

D

R.MISC1VAL/ST)

D

R.MISC2VAL/ST)

D

R.MISC3VAL/ST)

D

R.MISC4VAL/ST)

D

R.MISC5VAL/ST)

D

R.PENDING.FAVAL/ST)

P

R.PLAN.MODIFY.METHODSVAL/ST)

P

R.STATEMENT.CONTROLSVAL/ST)

P






78

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

A(

A(

A(

U

A(

A(

U U D

A(

U U D

A(

A(

A(

A(

A

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

R.SUMMARY.LEVELVAL/ST)

P

R.TRIAL.BALANCE.LEVELSVAL/ST)

P

R.TYPESARTF)

D U U U

R.WAIVER.POLICIESWAVP)

D

SSET.CATEGORIESACCD)

U

SSET.TYPESATCD)

U

SSIGN.CODESVAL/ST)

P

TTENDANCE.TYPESVAL/ST)

P

WARD.ACTIONSACT)

U D

WARD.CATEGORIESACD)

U D

WARD.DISB.CODE.TYPE P






79

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

A(

A(

A(

A(

B(

D U

B(

B(

B(

BR(

U

B(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

WARD.PERIODSAWPD)

U D

WARD.TYPESVAL/ST)

P

WARDS AWD/ST)

D

WDPC APCD)

D

ANK.CODESBKCM)

U

ATCH.STATUSESVAL/ST)

P P

ILLING.FREQUENCIESVAL/ST)

P

ILLING.METHODSVAL/ST)

P P P

ILLING.OVERRIDE.EASONS

VAL/ST)

D

ILLING.PERIOD.TYPESVAL/ST)

P P P






80

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

B(

B(

U U D

B(

P

B(

U D

B(

U D

B(

U D

B(

U D

C(

P

C(

P

C(

P

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ILLING.ROUNDING.CODESVAL/ST)

P

LDG.OWNERSHIP.STATUSESVAL/Core)

OX.BUILD.CODESVAL/ST)

UILDING.CONDITIONSVAL/Core)

UILDING.SECTORSVAL/Core)

UILDING.TYPESVAL/Core)

UILDINGSBLDG)

U U U U

A320.CENSUS.TYPESVAL/ST)

A320.DAY.TYPESVAL/ST)

A320.REPORTING.PERIODSVAL/ST)






81

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

C(

C(

U

C(

D

CC(

C(

C(

CS(

C(

CS(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ALC.INDICATOR VAL/ST)

P

ALENDAR.DAY.TYPESVAL/Core)

AMPUS.CALENDARCMPC)

U

AMPUS.ORG.HARACTERISTICS

VAL/ST)

D

AMPUS.ORG.FUNCTIONS VAL/ST)

D

AMPUS.ORG.GROUPINGSVAL/ST)

D

AMPUS.ORG.MEMBER.TATUSES

VAL/ST)

D U

AREER.GOALSVAL/ST)

D

ASH.RCPT.POST.UMMARIZATIONS

VAL/ST)

P






82

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

C(

C(

C(

P

C(

U D

C(

C(

D

C(

D

C(

D

C(

C(

U U D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ASH.RCPT.REV.DESCSVAL/ST)

P

B.INST.CODESVAL/ST)

P

C.ACTIONSVAL/Core)

P

C.CODESCMC)

U U U U U U

CDSCERT)

U U D U

ERT.REUMTSVAL/Core)

ERT.STATUSESVAL/Core)

ERT.TYPESVAL/Core)

I.ELIGIBLE.1040VAL/ST)

P

IPCIPD)

U U






83

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

C(

C(

C(

U

C(

D

C(

C(

C(

C(

C(

C(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ITIZENSHIP.STATUSVAL/ST)

P

L.RECORD.TYPESVAL/ST)

P

LASSESCLAS)

D U U

LASSROOMSRMSM)

U

LUSTER.ACTIONSVAL/ST)

P P

OD.DOC.STATUSESVAL/ST)

P

OD.DOC.TYPESVAL/ST)

P

OD.ERROR.TYPESVAL/ST)

P

OD.IN.MESSAGESVAL/ST)

P

OD.OUT.MESSAGESVAL/ST)

P






84

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

C(

C(

C(

C(

D

C

C(

U D

C(

U

C(

D

C(

U D

C(

P

C(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

OLLEGE.STATUSVAL/ST)

P

OLLEGE.TYPESVAL/ST)

P

OLLEGE.YEARVAL/ST)

P

OMMENCEMENT.SITESVAL/Core)

U U

OMMON.SCHOOL.IDS D

ONSTRUCTION.TYPESVAL/Core)

ONTACT.MEASURESVAL/ST)

D U

ONTACT.RESULTSVAL/Core)

U

ONTACT.ROLESVAL/Core)

U U U U U U

ONTROL.RECORD.STATUSESVAL/Core)

P P

ORP.STATUSESVAL/Core)

U U U U U






85

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

C(

D

C(

U U D

C(

P

C(

C(

D

C(

U D

C(

U

C(

U

C(

C(

U

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ORP.TYPESORTY)

U U U U U

ORR.STATUSESVAL/Core)

U U U

ORRESPONDENCE.TYPESVAL/Core)

P

OUNSELOR.TYPESVAL/ST)

D U U

OUNTIESCNTY)

U U U U

OUNTRIESCTRY)

U U U U

OURSE.DISABILITY.STATUSESVAL/ST)

D

OURSE.LEVELS VAL/ST)

U U D U U U

OURSE.OR.CRED.CODESVAL/ST)

P P

OURSE.PURPOSESVAL/ST)

U D






86

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

C(

U

C(

C(

C(

U

CP(

C(

C(

C(

U

C(

C(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

OURSE.STATUSESVAL/ST)

U U D U U

OURSE.STUDY.CODES.94 VAL/ST)

P

OURSE.TAX.STATUSESVAL/ST)

D U U

OURSE.TYPESVAL/ST)

D U

PS.TRANSACTION.REFERENCES

VAL/ST)

P

RED.CEU.PRINTVAL/ST)

P

RED.TYPE.TYPESVAL/ST)

P P P

RED.TYPESCTYP)

U U D U U U U

RED.USE.CODESVAL/ST)

P

SS.MARITAL.STATUSESVAL/ST)

P






87

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

C(

C(

C(

C(

D(

D(

D(

D(

D(

D(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

SS.PAR.IN.COLLEGEVAL/ST)

P

SS.STUD.TAX.TYPEVAL/ST)

P

SS.VISA.CLASSVAL/ST)

P

URRENT.HISTVAL/ST)

P

A.EVAL.INCLUDE.CODESVAL/ST)

P

A.EVAL.STATUSESVAL/ST)

P P

A.EXTRA.CODESVAL/ST)

P

A.KEYWORDSVAL/ST)

P

A.MERGE.METHODSVAL/ST)

P

A.RELATED.COURSES.CODESVAL/ST)

P






88

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

D(

D(

U U

D(

D(

D(

D(

D(

D(

D

D(

D(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.REPORT.FORMATSVAL/ST)

P

AYS.OF.WEEKVAL/ST)

D U

EFAULT.ACTIONSVAL/ST)

P

EFER.REVENUE.CODESVAL/ST)

P P

EG.CERT.CODES.94VAL/ST)

P


P


P

EGREE.TYPESVAL/Core)

U U

EGREESDEGR)

U U D U U

ENOMINATIONSDENO)

U U






89

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

D(

D(

D(

D(

U U D U

D(

D(

U D

D(

D(

U D

D(

U D

D(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

EPENDENCY.STATUSESVAL/ST)

P

EPOSIT.DESCSVAL/ST)

P

EPOSIT.POST.SUMMARIZATIONSVAL/ST)

P

EPTSDEPT)

U U U U U

ESTINATIONSVAL/ST)

P

IRECTORY.CODESVAL/Core)

U U U

IRECTORY.COFILEVAL/ST)

P

ISABILITY DISD)

U U

ISABILITY.TYPESVAL/Core)

U U

ISCOUNT.TYPESVAL/ST)

P P P






90

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

D(

D(

D(

U D U

D(

D(

D(

D(

D(

D(

D(

P

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ISCOUNTSDISC)

U U D U

ISTRIB.SUMM.CHOICESVAL/ST)

P

IVISIONSDIV)

U U U U U U

L.ENRL.STATUS.95VAL/ST)

P

L.ENRL.STATUS.99VAL/ST)

P

L.LOAN.TYPE.ALLVAL/ST)

P

L.LOAN.TYPEVAL/ST)

P

L.READY.TO.SENDVAL/ST)

P P

L.YR.IN.COLL.00VAL/ST)

OC.PRINT.FREUUENCIESVAL/Core)

P






91

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

D(

P

D(

E(

E(

E(

E(

D U

E(

E(

E(

E(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

OCUMENT.HISTORY.TYPESVAL/Core)

P

OEI.LEVELSVAL/ST)

P

ARLY.ALERT.SORTVAL/ST)

P

D.TG.NUMBERVAL/ST)

P

DUCATION.GOALSVAL/ST)

U D U U

EO.RPT.RANKSVAL/Core)

U

L.ENROLLMENT.STATUSESVAL/ST)

P

L.GRADE.LEVELSVAL/ST)

P

L.LOAN.TYPESVAL/ST)

P

L.PROCESSING.TYPESVAL/ST)

P






92

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

E(

E(

D

E(

D

E(

U D

E(

U D

E(

D

E(

E(

E(

E(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

L.RELATIONSHIP.CODESVAL/ST)

P

MAIL.SUBJECTSVAL/Core)

U

MPLOYABLE.BY.CODESVAL/Core)

MPLOYMT.REASONSVAL/Core)

U U U U

MPLOYMT.STATUSESVAL/Core)

U U U U

MPLOYMT.TYPESVAL/Core)

U U U

NR.STATUSVAL/ST)

P

NROLL.STATUSESENRS)

D U U

OPS.CARE.STATUSESVAL/ST)

D

OPS.ELIGIBILITY.FACTORSVAL/ST)

D






93

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

E(

E(

U D

E(

D

E(

D

E(

E(

E(

U D

E(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

OPS.TERM.END.STATUSESVAL/ST)

D

QUIPMENTEQPM)

U

THNIC.FED.GROUPSVAL/Core)

U U U

THNICSETH)

U U U

TS.TEST.TYPESVAL/ST)

P

VALUATIONSVAL/ST)

D

VENT.TYPESVAL/Core)

U

XPENSE.CODESEXPN)

D

A.ACADEMIC.CALENDARST/VAL)

P

A.ACCEPTED.RESPONSEST/VAL)

P






94

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.ACTIVE.FLAGSST/VAL)

P

A.APPL.FORMS.CODESST/VAL)

P

A.ASFAAS)

D

A.AWARD.LTRSFALD)

D

A.AWD.LTR.PRT.CODESST/VAL)

P

A.BATCH.AWD.TYPESVAL/ST)

P

A.BDATE.VAR.OPTIONSVAL/ST)

P

A.BGT.ADJ.CODESVAL/ST)

D

A.BGT.DFLT.OPTIONSVAL/ST)

P

A.BGT.HIST.STATUSESVAL/ST)

P






95

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.BGT.HIST.TYPESVAL/ST)

P

A.BGT.UNIT.TYPESVAL/ST)

P

A.CITIZENSHIP.95VAL/ST)

P

A.CITIZENSHIP.99VAL/ST)

P

A.CITIZENSHIPVAL/ST)

P

A.CL.COS.INDVAL/ST)

P

A.CL.DISP.OPTIONVAL/ST)

P

A.CL.HOLD.RELVAL/ST)

P

A.CL.IMPORT.OPTIONSVAL/ST)

P

A.CL.IMPORT.TYPESVAL/ST)

P






96

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.CL.RELEASEVAL/ST)

P

A.CL.RENT.INDVAL/ST)

P

A.CL.SORT.VALUESVAL/ST)

P

A.COD.GRADE.LEVELSVAL/ST)

P

A.COD.MPN.STATUSESVAL/ST)

P

A.COD.PLATFORMSVAL/ST)

P

A.COD.TEMP.FLAGVAL/ST)

P

A.CODE.OPTIONSVAL/ST)

P

A.COMPARE.TYPESVAL/ST)

P

A.COMPAREELCP)

D






97

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.CORE.IMPORT. OPTIONSVAL/ST)

P

A.CUSTODIAL.PARENTVAL/ST)

P

A.DECISIONSVAL/ST)

D

A.DEF.OVERPAY.CODESVAL/ST)

P

A.DISB.ROSTER.TYPESVAL/ST)

P

A.DL.CRED.DECSVAL/ST)

P

A.DOC.STATUSVAL/ST)

P

A.DOC.TYPEVAL/ST)

P

A.DOEI.REPORT.OPTSVAL/ST)

P

A.DRUG.CONVICTIONS.01VAL/ST)

P






98

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.DRUG.CONVICTIONSVAL/ST)

P

A.EL.CITIZENSHIPSVAL/ST)

P

A.EL.LOAN.FIELDSVAL/ST)

P

A.FEDERAL.TERMSVAL/ST)

P

A.FS.ACTIONSVAL/ST)

P

A.FS.STATUSESVAL/ST)

P

A.FUND.DIST.METHODSVAL/ST)

P

A.GIFT.SELFVAL/ST)

P

A.IFBVAL/ST)

P

A.IPAIPAL)

D






99

Getting S

tarted w

ith Co

lleague Studen

t|

Understanding

Student C

odes

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.LA.ACYR.FIELDSVAL/ST)

P

A.LOCATIONSFLCD)

D

A.LOW.TUITION.CODE.VAL/ST)

P

A.LOW.TUITION.CODE.2002VAL/ST)

P

A.MANIFEST.OPTIONSVAL/ST)

P

A.MARITAL.STATUSESVAL/ST)

P

A.MEDIA.TYPESVAL/ST)

P

A.MESSAGE.CLASS.CODESVAL/ST)

P

A.MPN.STATUSVAL/ST)

P

A.MRR.REUUEST.CODEVAL/ST)

P






10

0G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

F(

F(

P

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.NAS.SORT.BYVAL/ST)

P

A.NEED.COSTVAL/ST)

P

A.NEED.STATES.1992VAL/ST)

P


P


P


P

A.NFFANF)

D

A.NXB.VAL/ST)

P

A.OFFICESFAOP)

D

A.PARENT.MARITAL.00VAL/ST)

P






10

1G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.PARENT.MARITAL.99VAL/ST)

P

A.PAYMENT.DESCSVAL/ST)

P

A.PELL.OR.DLVAL/ST)

P

A.PKG.DESIRABILITYVAL/ST)

D

A.PKG.REPORTSVAL/ST)

P

A.PN.DELIVERY.CODESVAL/ST)

P

A.PRODUCTION.TYPESVAL/ST)

P

A.PROM.NOTE.PRINTVAL/ST)

P

A.PROM.NOTE.STATUSVAL/ST)

P

A.REC.FED.AID.91VAL/ST)

P






10

2G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.REC.FED.AID.92VAL/ST)

P

A.REJECT.MSGFARM)

D

A.RESPONSE. CODESVAL/ST)

P

A.SERIAL.LOAN.CODESVAL/ST)

P

A.SIGNED.BYVAL/ST)

P

A.SOP.FLAGSVAL/ST)

D

A.STAF.CLASSVAL/ST)

P

A.STATE.CRSE.STUDY.93VAL/ST)

P

A.STATE.DEG.CERT.93VAL/ST)

P

A.STATE.ENRL.STAT.04VAL/ST)

P






10

3G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.STATE.ENRL.STAT.93VAL/ST)

P

A.STATE.GRADE.LEVEL.99VAL/ST)

P

A.STATE.GRADE.LEVELVAL/ST)

P

A.STATE.HOUSING.STAT.93VAL/ST)

P

A.STATE.YR.IN.COLLEGE.93VAL/ST)

P

A.STU.COMM.CODESVAL/ST)

D

A.STUD.MARITAL.00VAL/ST)

P


P


P

A.STX.IMSSTA)

D






10

4G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

F(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.STXSOTA)

D

A.SUITESFFSP)

A.TAPEPARX)

A.TAX.FIGURESVAL/ST)

P

A.TAX.RETURN.STATUS.01VAL/ST)

P

A.TAX.RETURN.STATUS.99VAL/ST)

P

A.TAX.RETURN.TYPE.04VAL/ST)

P

A.TAX.RETURN.TYPE.99VAL/ST)

P

A.TRANSMITTAL.MODESVAL/ST)

P P

A.UR.DELETE.ACTIONSVAL/ST)

P






10

5G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

FC(

F(

F(

F(

F(

F(

F(

F(

F(

F(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.VERIF.STATUS.CHANGE.ODES

VAL/ST)

P

A.YBVAL/ST)

P

A.YR.IN.COLLEGEVAL/ST)

P

ACULTY.CONTRACT.TYPESVAL/ST)

D

ACULTY.POSITIONSVAL/ST)

D

ACULTY.REMARK.CODESVAL/ST)

D

ACULTY.REMARK.TYPESVAL/ST)

D

ACULTY.SPECIAL.STATUSESVAL/ST)

D

AFSA.HOUSING.CODES.95VAL/ST)

U

AFSA.HOUSING.CODES.99VAL/ST)

U






10

6G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

F(

F(

F(

D

F(

D

F(

D

F(

F(

F(

F(

F(

U

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

C.PGI.CODESVAL/ST)

P

ED.COHORTSVAL/ST)

D U

LOOR.PREFERENCESVAL/ST)

OREIGN.FUND.SOURCESVAL/Core)

U U

ORMATTED.NAME.TYPESVAL/Core)

U U U U U

P.AWARDING.STATUSVAL/ST)

P

P.STATUSFPD)

U D

SP.EL.RETRIEVEVAL/ST)

P

SP.EL.TRANSMIT.METHODSVAL/ST)

P

UNDING.ACCTG.METHODSVAL/ST)

D






10

7G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

F(

G(

G(

G(

D

G(

H(

U D

H(

H(

H(

H(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

UNDING.SOURCESVAL/ST)

D

AIN.STATUSESVAL/ST)

D

RADES.PARTICIPATIONVAL/ST)

D

RADUATION.TYPESVAL/Core)

U U U U U

UARANTOR GUAR)

D

EALTH.CONDITIONSVAL/Core)

U U

IATUS.CODESHIAT)

D U U

IATUS.STATUSESVAL/ST)

D

ONORSHONR)

D U U

OUSING.CODESVAL/ST)

P






10

8G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

H(

IM(

U D

IM(

U D

IN(

D U

IN(

D

IN(

D

IN(

U D

IN(

IN(

U

IN(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

OUSING.STATUSESVAL/ST)

U U D

MIGRATION.STATUSESVAL/Core)

U U

MUNIZATIONSVAL/Core)

U U U

DUSTRY.CLASSESVAL/Core)

U U U U U

ST.FUNDING.SOURCESVAL/Core)

U U U U U

ST.TYPESVAL/Core)

U U U U U

STITUTION.CODESVAL/Core)

STITUTION.COHORTSVAL/ST)

D U

STR.METHODSISTM)

U D U U

TERESTSINTR)

U U U U U






10

9G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

INC(

INS(

IN(

IN(

L(

D

L(

D

L(

L(

U

L(

D

L(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

VOICE.BATCH.SORT.ODES

VAL/ST)

P

VOICE.POST.UMMARIZATIONS

VAL/ST)

P

VOICE.SOURCESVAL/ST)

P

VOICE.TYPESVAL/ST)

D

ANGUAGESVAL/Core)

U U

CH.PROCESSING.STATUSVAL/ST)

P

ENDERSLID)

D

OCAL.GOVT.CODESLGCD)

D U

OCATION.REGIONSLCRG)

U U

OCATION.TYPESVAL/Core)

U






11

0G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

L(

U U D U

L(

P

L(

P

M(

U D

M(

P P

M(

U

M(

D

M(

M(

M(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

OCATIONSLOCN)

U U U U U U U U U U

TR.BACH.ACTIONSVAL/Core)

P

TR.BACH.STATUSESVAL/Core)

P

AIL.RULESVAL/Core)

U U U U U U

AIL.TYPESVAL/Core)

P P P P

AJORSMAJR)

U U D U U

ARITAL.STATUSESVAL/Core)

U U U

ATRIC.OTHER.STATUSESVAL/ST)

D

ATRIC.PROVIDE.STATUSESVAL/ST)

D

ATRIC.SERVICE.STATUSESVAL/ST)

P






11

1G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

M(

M(

M(

D

M(

D

M(

M(

D

M(

P

M(

D

M(

M(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ATRIC.STATUSESVAL/ST)

P

CAT.WR.CODESVAL/ST)

D

EAL.ASSIGN.STATUSESVAL/ST)

EAL.CLASSVAL/ST)

EAL.INV.DESCSVAL/ST)

P

EAL.PLAN.FREUUENCYVAL/ST)

EAL.RATE.PERIODSVAL/ST)

P

EAL.TYPEVAL/ST)

ID.FINAL.VERIFIEDVAL/ST)

P

ID.OR.FINALVAL/ST)

P






11

2G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

M(

M(

M(

D

M(

D

M(

M(

M(

M(

M(

D

M(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

IL.BEN.ELIGIBILITY.CODESVAL/ST)

U

IL.BENEFITSVAL/ST)

U

IL.PAY.GRADESVAL/CORE)

U

IL.STATUSESVAL/CORE)

U

IL.VET.REMARK.CODESVAL/ST)

U

IL.VET.REMARK.TYPESVAL/ST)

U

INORITIESVAL/ST)

P

INORSMINR)

U U D U U

ISC.CODESVAL/Core)

U

ISC.INV.DESCSVAL/ST)

P






11

3G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

N(

P

N(

N(

N(

N(

N(

N(

N(

N(

N(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

AME.HIERARCHY.TYPESVAL/Core)

P

AME.TITLESVAL/ST)

P

ON.AR.CASH.RCPT.DESCSVAL/ST)

P

ON.COURSE.CATEGORIESVAL/ST)

U D

ON.COURSE.FACTORSVAL/ST)

U D

ON.COURSE.GRADE.USESVAL/ST)

P

ON.COURSE.TYPESVAL/ST)

U D

OTE.CODESNOTC)

D U

SC.PGM.LEN.MEASURESVAL/ST)

P

SC.PHONE.TYPESVAL/ST)

P






11

4G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

N(

N(

O(

D

O(

D

O(

O(

D

O(

D

O(

D

O(

D

O(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

SC.VET.STATUSESVAL/ST)

P

SLC.STATESVAL/ST)

P

CCUPATIONSOCC)

U U

FFICE.CODESVAL/Core)

U U U U

RG.TYPESCOTY)

D U

THER.ACAD.LEVELSOCAD)

U

THER.CCDS.TITLE.CODESVAL/Core)

THER.CCDSOCCD)

U U U U U

THER.DEGREESODEG)

U U U U U

THER.DIVISIONSODIV)

U






11

5G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

O(

D

O(

D

O(

D

O(

D

O(

O(

D

O(

D

P(

P(

P(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

THER.HONORSOHON)

U U U U U

THER.LOCATIONSOLOC)

U

THER.MAJORSOMAJ)

U

THER.MINORSOMIN)

U

THER.RESTRICT.CODESORES)

D U

THER.SPECIALIZATIONSOSPC)

U U U U U

VERALL.EMP.STATUSVAL/Core)

U

ACKAGE.GROUPSVAL/ST)

D

ARENTS.IN.COLLEGEVAL/ST)

P

ASS.AUDIT.CODESVAL/ST)

P P






11

6G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

PS(

P(

P(

P(

P(

P(

P(

D

P(

D

P(

D

P(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

AYMENT.ALLOCATION.OURCES

VAL/ST)

P P

AYMENT.SOURCESVAL/ST)

P

ELL.ACAD.CALVAL/ST)

P

ELL.ENT.OPTIONSVAL/ST)

P

ELL.PAY.METHODVAL/ST)

P

ELLRECON.VERIF.STAT.2001VAL/ST)

P

ER.ETHNICS VAL/Core)

U U U

ER.RACESVAL/Core)

U U U

ERSON.EMAIL.TYPESVAL/Core)

U U U U U

ERSON.MILITARY.BRANCHESVAL/CORE)

U






11

7G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

P(

U D

P(

P

P(

P(

U D

P(

P(

U D U

P(

D

P(

D

P(

P

P(

U D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ERSON.ORIGIN.CODESVAL/Core)

U U U U U

ERSON.REL.TYPESVAL/Core)

P P P

ERSON.TAX.STATUSESVAL/ST)

D

ERSONAL.STATUSESVAL/Core)

U U U U

ETITION.STATUSESPTST)

U U D

HONE.TYPESVAL/Core)

U U U U U U

ORTS.OF.ENTRYSVAL/Core)

U U

OSITIONSVAL/Core)

U U U U

OSTAL.SORT.TYPESVAL/Core)

P P P P P P

REFIXESVAL/Core)

U U U U U






11

8G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

P(

U D

P(

P(

P(

P(

R(

R(

R(

R(

R(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

RIVACY.CODESVAL/Core)

U U U U U

ROFILE.PAR.MARITAL.STATUSESVAL/ST)

P

ROGRAM.DESIGNATIONSVAL/ST)

U

ROGRAM.STATUSESVAL/ST)

U U D U

ROSPECT.STATUSESVAL/ST)

U D U

ANDOM.ID.ASSIGN.CODESVAL/ST)

P

CPT.NON.AR.GL.DISTRNARD)

D

CPT.REVERSAL.REASONSVAL/ST)

D

CPT.REVERSAL.TYPESVAL/ST)

P

ECIPIENTRECP)

D






11

9G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

R(

R(

R(

U

R(

R(

D

R(

R(

R(

R(

R(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ECOMMENDATION.TYPESRECT)

D

ECRUIT.PURPOSESVAL/ST)

D

EFUND.FORMULASREFF)

D U U

EFUND.PORTIONSVAL/ST)

P

EFUND.REASONSVAL/CORE)

U

EFUND.VOU.DESCSVAL/ST)

P

EG.AUDIT.SELECTIONVAL/ST)

P P

EG.BILLING.RATESRGBR)

D U U

EG.CONTROLSRGCT)

D

EG.INV.DESCSVAL/ST)

P






12

0G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

R(

R(

R(

R(

R(

R(

U

R(

R(

R(

R(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

EG.METHODSVAL/ST)

P P P

EG.RATE.FIELDSRRBF)

D

EG.RATE.TABLESRGRT)

D U U

EG.REFUND.COUNT.EXCL.DAYSVAL/ST)

P

EG.REFUND.POLICIESRGRP)

D

EG.RETAKE.POLICIESRPOL)

D U

EG.TERM.RATE.TABLESRTRT)

D

EG.TIME.PERIODSVAL/ST)

P P

ELATION.CODESVAL/ST)

P

ELATION.STATUSESVAL/Core)

U






12

1G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

R(

D

R(

D

R(

R(

R(

R(

R(

U

R(

R(

U

R(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

EMINDER.PURPOSESVAL/Core)

U

EMINDER.STATUSVAL/Core)

U

EPEAT.GRADE.USESVAL/ST)

P P

EPLACEMENT.CODESVAL/ST)

D U U

EPORT.TYPESVAL/ST)

P

EQUISITE.WAIVER.REASONSVAL/ST)

D

ESIDENCY.STATUSESRSST)

U D U U

ESTRICT.CONNECTORSVAL/ST)

P

ESTRICTIONSREST)

D U

ESTRS.ACTION.CODESVAL/ST)

P






12

2G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

R(

D

R(

R(

R(

R(

D

R(

D

R(

U D

R(

U D

R(

R(

U D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

EUNION.CLASSESRCLS)

U U U

EUUEST.LOG.TYPESVAL/ST)

P

OF.INST.CHARGESDRAC)

D

OLESROLE)

U D U

OOM.ASSIGN.STAFF.CODESVAL/ST)

OOM.ASSIGN.STATUSESVAL/ST)

U

OOM.CATEGORIESVAL/Core)

U

OOM.CHARACTERISTICSVAL/Core)

U

OOM.INV.DESCSVAL/ST)

P

OOM.RATE.CLASSESVAL/Core)

U U






12

3G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

R(

P

R(

U D

R(

U D

R(

U D

R(

D

R(

U D

R(

U D

R(

U D

R(

U D

R(

U D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

OOM.RATE.PERIODSVAL/ST)

P

OOM.TYPESRTYP)

U

OOM.USAGESRMUD)

U U

OOM.WINGSVAL/Core)

U

OOMMATE.CHARACTERISTICSVAL/ST)

OOMS.MISC1VAL/Core)

U

OOMS.MISC2VAL/Core)

U

OOMS.MISC3VAL/Core)

U

OOMS.MISC4VAL/Core)

U

OOMS.MISC5VAL/Core)

U






12

4G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

R(

U D

R(

U D

R(

U D

R(

U D

R(

R(

R(

R(

S(

S(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

OOMS.MISC6VAL/Core)

U

OOMS.MISC7VAL/Core)

U

OOMS.MISC8VAL/Core)

U

OOMSRMSM)

U U U

OUNDING.RULESVAL/ST)

P

T.TYPEVAL/ST)

P

ULE.PROCESS.FLAGSVAL/ST)

P

URAL.INDICATORSVAL/ST)

P

AP.APPEALS.CODESSPAC)

D

AP.RPT.OPTIONSVAL/ST)

P






12

5G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

S(

S(

S(

D

S(

S(

S(

U D

S(

S(

S(

S(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

AP.STATUSESVAL/ST)

D

AP.TYPESPTD)

D

CHED.REPEATSVAL/Core)

U U

CHED.TYPESSCTY)

U U D U

CHEDULE.SORT.ORDERSVAL/ST)

P P

CHOOLSSCHL)

U U U U U

EC.SCHED.BLOCK.FORMATVAL/ST)

P

EC.SCHED.SORT.CODESVAL/ST)

P

ECONDARY.SCHOOL.SUBJECTSVAL/ST)

D

ECTION.COPY.CODESVAL/ST)

P






12

6G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

S(

S(

S(

S(

S(

S(

P

S(

D

S(

D

S(

D

S(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

ECTION.STATUSESVAL/ST)

U D U

ELF.DESCRIPTIONSVAL/ST)

D

ESSION.CYCLESSECY)

D U

ESSION.TYPESVAL/ST)

D

ESSIONSSESS)

U D U

EVIS.ACTIONSVAL/ST)

EVIS.EDUC.LEVELSVAL/ST)

EVIS.EXPENSE.TYPESVAL/ST)

EVIS.FORM.PURPOSESVAL/Core)

EVIS.PART.TIME.REASONSVAL/ST)






12

7G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

S(

P

S(

S(

S(

S(

S(

S(

S(

P

S(

U D

S(

U D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

EVIS.TRANS.STATUSESVAL/Core)

OC.BRANCHES.OF.SERVICEVAL/ST)

U

OC.CREDIT.TYPESVAL/ST)

D

OC.NETWORKSVAL/ST)

D

OC.SERVICE.PROGRAMS VAL/ST)

U

OC.SERVICE.PROGRAMSVA:/ST)

U

ORT.GRADSVAL/ST)

D

ORT.SEUUENCEVAL/ST)

P P

OURCESVAL/Core)

U U U U U

PECIAL.NEEDSVAL/Core)

U U






12

8G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

SC(

S(

S(

S(

S(

D

S(

S(

D

S(

D

S(

D

S(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

PECIAL.SERVICES.NEED.ODES

VAL/ST)

D

PECIALIZATIONS SPEC)

U U D U U

PONS.BILL.DESCSVAL/ST)

P

PONSOR.STATEMENT.LEVELSVAL/ST)

P P

PONSORSHIP.CONTRACT.TYPESVAL/ST)

PONSORSHIP.STATUSESVAL/ST)

D U

TAFF.REMINDER.TYPESVAL/Core)

U

TAFF.STATUSESVAL/Core)

U

TAFF.TYPESVAL/Core)

U

TATE.REPORT.PERIOD.NAMESVAL/ST)






12

9G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

S(

D

S(

D

S(

S(

S(

S(

S(

S(

S(

S(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

TATE.REPORTSVAL/ST)

TATESSTPR)

U U U U U

TU.MISC1VAL/ST)

D

TU.MISC10VAL/ST)

D

TU.MISC2VAL/ST)

D

TU.MISC3VAL/ST)

D

TU.MISC4VAL/ST)

D

TU.MISC5VAL/ST)

D

TU.MISC6VAL/ST)

D

TU.MISC7VAL/ST)

D






13

0G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

S(

S(

SB(

S(

SR(

S(

S(

U

SS(

S(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

TU.MISC8VAL/ST)

D

TU.MISC9VAL/ST)

D

TUDENT.ACAD.CRED.MARK.REAKS

VAL/ST)

P

TUDENT.ACAD.CRED.MARKSVAL/ST)

P P P

TUDENT.ACAD.CRED.STATUS.EASONS

VAL/ST)

D U U U

TUDENT.ACAD.CRED.STATUSESVAL/ST)

D U U U U U

TUDENT.LOADSVAL/ST)

D U U U U

TUDENT.NON.COURSE.TATUSES

VAL/ST)

U D U

TUDENT.PROGRAM.STATUSESVAL/ST)

D U U U U






13

1G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

S(

S(

SS(

S(

U

S(

S(

U

S(

D

S(

P

S(

U D

S(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

TUDENT.REMARK.CODESVAL/ST)

D U

TUDENT.REMARK.TYPESVAL/ST)

D U

TUDENT.SPECIAL.ERVICES

VAL/ST)

D U U

TUDENT.TERM.STATUSESVAL/ST)

D U

TUDENT.TYPESSTTC)

D U U U U

UBJECTSSUBJ)

U U D U U

UBROUTINE.ARGUMENTSVAL/Core)

U

UBROUTINE.TYPESVAL/Core)

P

UFFIXESVAL/Core)

U U U U

UITE.FLAGSVAL/ST)

P






13

2G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

S(

P

T(

D U

T(

T(

T(

T(

U D

T(

T(

D

T(

T(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

UMMARY.OR.DETAILVAL/Core)

P P

AX.CATEGORIESVAL/Core)

U

AX.RETURN.TYPEVAL/ST)

P

EACHING.ARRANGEMENTSVAL/ST)

D U

ERM.NOTE.TYPESVAL/ST)

D

IME.ZONESVAL/Core)

U U U U

IV.CATEGORIESTLCM)

U

K.CODESTRC)

U U U

OPIC.CODESTOPC)

D

RANSACTION.TYPESVAL/ST)

P






13

3G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

T(

T(

T(

T(

D

T(

D

T(

P

T(

U

T(

T(

V(

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

RANSCRIPT.CATEGORIESVAL/ST)

D

RANSCRIPT.GROUPINGSTRGR)

D U U U

RANSCRIPT.SORT.ORDERSVAL/ST)

P

RANSCRIPT.STATUSVAL/Core)

U U U U

RANSCRIPT.TYPEVAL/Core)

U U U U U

RANSFER.METHODSVAL/Core)

P

RANSFER.STATUSESVAL/ST)

D

RUST.CODEVAL/ST)

P

UITION.RATE.TABLESTRTB)

D U

A.CERTIFICATIONVAL/ST)

U






13

4G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

V(

VS(

V(

V(

V(

V(

V(

D

V(

V(

D

V(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

A.FORMSVAL/ST)

D

ATEA.ECONOMIC.STATUS.OURCES

VAL/ST)

D

ATEA.ECONOMIC.STATUSESVAL/ST)

D

ERIFICATION.CODESVAL/ST)

P

ET.BEN.ELIGIBILITY.CODESVAL/ST)

D

ETERAN.BENEFITSVAL/ST)

D

ETERAN.TYPESVAL/Core)

U U U

ISA.CLASSIFICATIONVAL/ST)

P

ISA.ISSUING.POSTSVISP)

U

ISITOR.POSITIONSEVPO)

U






13

5G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

V(

D

V(

P P

W(

W(

W(

W(

P

Y(

Z(

D

by Ellucian.

C(

Other Applications

RL ST CORE CF HR FR

OCATIONSVOCD)

U U

OU.STATUSESVAL/Core)

P P

AIT.LIST.STATUSESVAL/ST)

D

AIVE.OR.CHARGE.CODESVAL/ST)

P

ITHDRAW.REASONSWTHR)

D U U

P.DOCUMENT.TYPESVAL/Core)

P

EARLY.CYCLESYRCY)

D U

IP.SORT.SEQUENCEVAL/ST)

P






13

6G

etting Sta

rted with C

olleague S

tudent

|U

nderstanding S

tudent Code

s

Ge

Defining Colleague Student Codes

In This Chapter

This chapter provides information for defining the codes in Colleague Student. The information in this chapter is provided in alphabetical order by code name.

Academic Committee Types

Academic committee types identify different types of academic committees. These types can be used to determine whether a faculty member is eligible for a particular academic committee.

Academic committee types are maintained on the Validation Codes (VAL) form. These codes are stored in the ACAD.COMMITTEE.TYPES record of the ST.VALCODES file.

Academic Program Honor Codes

Academic program honor codes identify the types of honors associated with an academic program. This code is used with Canadian statistical reporting. These codes use special processing to identify that an academic program has honors available, but the student must choose whether or not to take the honors version. If the academic program has honor codes associated with it that have a special processing code of “1,” those honors are not automatically assigned to that student when the academic program is assigned. Those honors codes must be manually assigned when the student selects the academic program. If an academic program has honor codes associated with it that do not have special processing assigned, those honors are automatically assigned to that student when the academic program is assigned.

Academic program honor codes are maintained on the Validation Codes (VAL) form. These codes are stored in the ACAD.PROGRAM.HONOR.CODES record of the ST.VALCODES file.

137tting Started with Colleague Student | Defining Colleague Student Codes

Ge

Academic Program Types

Academic program types identify different categories of academic programs. These program types can be used to categorize academic programs in ways other than those provided by the Classification of Instructional Program (CIP) codes. These codes can also be used for Canadian statistical reporting to categorize academic programs so that the student population can be split and reported accordingly.

Academic program types are maintained on the Validation Codes (VAL) form. These codes are stored in the ACAD.PROGRAM.TYPES record of the ST.VALCODES file.

Academic Requirement Types

Academic requirement types codes are used to categorize academic requirements, such as by major, minor or specialization.

Each code has a special processing code that defines the order in which Colleague evaluates the requirement. For example, if the code “MAJ” has a processing code of 1 and the code “MIN” has a processing code of 2, then Colleague evaluates requirements with the MAJ requirement type before those with the MIN requirement type. This prioritization has implications if the requirements contain prior-usage restrictions. For example, if requirement “A” is defined as “cannot share courses with requirement “B,” and if “A” is a MAJ type and “B” a MIN type, then “A” will get evaluated first and will get first crack at the courses. If Colleague encounters a type that is not on the validation code table, or that does not have a processing code, then it assumes the lowest possible priority.

If an academic program has two or more requirements with the same priority, Colleague evaluates them in the order that they are listed in the academic program (as displayed on the Academic Program Requirement [APRS] form).

Academic requirement type codes are maintained on the Validation Codes (VAL) form. These codes are stored in the ACAD.REQMT.TYPES record of the ST.VALCODES file.

Academic Standing Codes

Academic standing codes identify a student’s academic standing at your university, such as academic probation, good standing, and dean’s list. Each code must be associated with an academic standing rule that Colleague uses to assign these academic standing codes to students. See “Academic Standing Rules” on page 331 for more information about defining your academic standing rules.

Use the Validation Codes (VAL) form to define academic standing codes. They are stored in the ACAD.STANDINGS record of the ST.VALCODES file.


Ge

Academic Standing Types

Academic standing type codes identify the different types of academic standing which can be calculated. The three types of academic standing are:

• academic level

• academic program

• term academic level

There are special processing codes associated with each type code that specify on which form or field the code will display. Table 4 shows the special processing codes and on which forms the corresponding code will display.

Academic standing type codes are delivered with Colleague. You can modify these codes, however, you must maintain the association between the special processing codes and what the standing calculation is based on. If you do not, the student standings may not display on the forms you expect.

Use the Validation Codes (VAL) form to define academic standing type codes. They are stored in the ACAD.STANDING.TYPES record of the ST.VALCODES file.

Action Categories

Action category codes are used to group together award action codes which have similar action statuses. You can define multiple award actions codes (for example, [E]stimated and [F]ile Incomplete) and associate them to a single action category (for example [P]ending). Colleague processes awards based on the action category to which the award action codes is associated, not the award action code. See “Award Actions” on page 161 for information about award action codes.

Table 4: Special Processing Codes for Academic Standing Type Codes

Special Processing Code

Standing Calculated Based on … Displays On …

1 Academic Level Student Acad Level (STAL) form

Student Academic Standings (SACS) form

2 Academic Program Student Acad Program (SACP) form


3 Academic Level and Registration Term

Student Term Detail (STRD) form



Ge

Action category codes are:

Action category codes are stored in the ACTION.CATEGORIES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Admit Status Codes

Admit statuses are used to define the original designation you assign to individuals when they begin the admissions process at your institution. Examples of admit status codes are:

• first time freshman

• transfer admissions

• honors admissions

• conditional admissions

You enter this code for each application an individual submits. For example, when an individual transfers to your institution as an undergraduate, the admit status associated with his undergraduate application indicates that he is a transfer student. If he later applies to an graduate program, enter a different admit status, such as returning student, for his graduate application.

When an applicant matriculates, if you set the Copy Admit Status flag on the Admissions Parameters (ADPA) form to “Y,” Colleague moves the admit status to his STUDENT.ACAD.LEVELS record. For each academic level, Colleague does not override this status once it creates a STUDENT.ACAD.LEVELS record. See “Copy Admit Status” on page 757 for examples of how Ellucian University use the admit status codes.

You can use the admit status code for your institutional and other reporting needs as you follow the progress of specific types of students.

Admit status codes are defined on the Admit Statuses (ADST) form. These codes are stored in the ADMIT.STATUSES file.

Table 5: Action Category Codes

Action Category Code Description

A Accepted

E Estimated

P Pending

D Denied

R Rejected


Ge

Advisor Types

Advisor type codes identify different types of advisors, such as major, minor or portfolio advisors, and are associated with a student’s advisement record. They can be used as a selection criteria in standard reports. The special processing associated with these codes can be any number and are used to sort the types in relative order of importance. If all your advisor types are equally important, and Colleague should only use dates when sorting a student’s advisors, you can leave the special processing field blank. You can give multiple types of advisors the same importance and thus the same special processing value.

If you only assign one advisor type to a student, you can decide not to use these codes at all. If there is no advisor type, Colleague sorts by the assignment date.

Use the Validation Codes (VAL) form to define advisor type codes. They are stored in the ADVISOR.TYPES record of the ST.VALCODES file.

Applicant Remark Codes

Applicant remark codes indicate the source or office of applicant remarks. Examples of remark codes include:

• FA for family

• FF for friend of family

• AM for admissions office

• CO for counselor

Use the Validation Codes (VAL) form to define and maintain your institution’s applicant remark codes. These codes are stored in the AM.REMARK.CODES record of the ST.VALCODES file.

Applicant Remark Types

Applicant remark type codes indicate the types of remarks that may be kept for an applicant. You can use these remark types to group similar remarks for reporting purposes. Examples of admissions remark type codes include:

• BU for business information

• PE for personal information

• TU for tutoring center

• AD for academic advising center


Ge

Use the Validation Codes (VAL) form to define and maintain applicant remark types. These codes are stored in the AM.REMARK.TYPES record of the ST.VALCODES file.

Application Fee Statuses

Application fee status codes indicate the status of an individual’s application fee. Colleague derives this status based on information from the individual’s accounts receivable files as follows:

Application fee status codes are stored in the APPL.FEE.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

See the Using Recruitment/Admissions Management manual for more information about how application fee statuses are used.

Application Priorities

Application priorities indicate how the applicant views the priority of a given application. For example, if an individual has applied to different programs, one of the programs may be her top priority and the other is more of a backup. Use application priority codes to categorize these priorities. You can use these codes for reporting or rules definition.

Use the Validation Codes (VAL) form to define and maintain application priority codes. These codes are stored in the APPL.PRIORITIES record of the ST.VALCODES file.

Table 6: Application Fee Statuses

Status How Derived

N – Not Paid If the application fee has been charged but no payment has been received, then the status is “N.”

W – Waived If the applicant’s record reflects an invoice for an application fee, but the amount charged was zero, then the status is “W.”

P – Paid If the applicant’s record reflects an invoice for an application fee, and the amount received is greater than or equal to the amount charged, then the status is “P.”

R – Partially Paid If the applicant’s record reflects an invoice for an application fee, and the amount received is less than the amount charged, then the status is “R.”


Ge

Application Statuses

Application statuses identify the stages of the admissions process. At any given point in time during applications processing, each application has an application status assigned to it.

Use the Application Statuses (APSM) form to define application status codes. These codes are stored in the APPLICATION.STATUSES file.

Figure 1: Example Application Status Codes

Components of an Application Status Code

Description

Provide a brief description of each application status code.

Processing Code

You can associate your application statuses with pre-defined processing codes that track the progress of the application through the admissions process. See the following section for details.

Column Number

You can obtain a count of applications, grouping those applications by application status, with the application status summary report. You indicate where you want Colleague to


Ge

include the count associated with each application status by entering the column number of the report when you define the application status codes. There are 11 columns in the application summary report and you can group together as many different status codes in one column as necessary. For example, if you have six different status codes that indicate a different level of applied status, you might want to group these codes together in one column of the report; therefore you would assign each of these status codes the same column number. Use the application status column titles to define the heading that Colleague will put on each column of the report.

See “Application Status Column Titles” on page 146 for information about defining column titles. See Using Recruitment/Admissions Management for information about how to use the column number and column titles to create a customized application status summary report.

Application Status Processing Codes

You can associate each of your application status codes with one of the following processing codes:

• AP – applied

• CO – complete

• AC – accepted

• RE – rejected

• WL – waitlisted

• WI – withdrawn

• MS – moved to students1

These processing codes let you define multiple status codes that are all the same type. For example, you might have the following different types of admitted applications: early decision, regular decision, probationary admission, and conditional admission. If you want Colleague to treat these status codes the same, you would assign the processing code “accepted” to each of these status codes.

The processing codes are used to link your application statuses with specific processing that Colleague must perform in order to record the stages of the admissions process and facilitate processing of the application all the way through to registration of the student.

1.The “Moved to Students” processing code differs from the other codes listed here. You cannot manually assign a status with a special processing code of “MS” code to an application; Colleague assigns this code automatically at the point in time when a STUDENTS record is created from an application.


Ge

What Happens When an Prospect’s Application Status Is Changed to Applied

An application is considered applied if

• its status is “applied” (special processing code of “AP”) or

• its status is a status that logically follows “applied” in the application process (special processing codes of “CO” [Complete], “AC” [Accepted], “WL” [Waitlisted], “RE” [Rejected], or “MS” [Moved to STUDENTS])

Once an application has been given an applied status—a status with any of the above processing codes—Colleague performs several processes on the application.

Prospect data is snapshotted. If you have set the Snapshot Prospect Data parameter on the Admissions Parameters (ADPA) form to “Yes,” you have indicated you want Colleague to snapshot data from a prospect record at the point where the prospect becomes an official applicant. The processing code on the application status tells Colleague when to do this. The first time you enter on a prospect’s record an application status with a processing code of either “applied,” “complete,” “accepted,” “rejected,” “waitlisted,” or “moved to students,” Colleague takes a snapshot of that individual’s record for recording their prospect information.

These processing codes are designed in this way so that even if you skip steps in the normal applications process (for example, change an application from a status of “Incomplete File” directly to “Moved to Student”), Colleague will have taken a snapshot of the prospect record at the point in time when the application changed from non-applicant to applicant—regardless of the exact stage the application was in. Thus if any of the processing codes listed above are associated with the status you enter on an application when you change it from non-applicant to applicant, Colleague will take a snapshot of the record.

See “Admissions Processing Parameters” on page 750 for more information on the Snapshot Prospect Data parameter.

Application fees are assigned. When an application is first assigned a status with one of the six processing codes listed above (either “applied,” “complete,” “accepted,” “rejected,” “waitlisted,” or “moved to students”), indicating that the status is now applied, Colleague defaults the appropriate application fees into the applicant’s record.

Application date becomes required. As soon as an application receives a status with one of these special processing codes, the application date becomes required, and will remain required for the entire life of the application.

Other Functions of Some Processing Codes

In addition to the special functions of the ‘applied’ processing codes, some of the codes also have other functions. They are listed below:

• Accepted. When you use an application status with an “accepted” processing code, Colleague updates the Admit From State field and the Admit From County field on the Admit From (ADFR) form with the applicant’s home state and county. (Colleague updates this information only if you have updated it on the ADFR form.)


Ge

• Applied. Whenever you assign one of the statuses to an application that means the individual has become an applicant, Colleague considers the application as “applied.” You can use database queries to find out, at any point in time, whether an individual has become an applicant, by querying on the APP.APPLIED field of the APPLICANTS file to distinguish between prospects and applicants (the value in the APP.APPLIED field would be “Yes”).

• Moved to STUDENTS. When an applicant becomes a student, and a STUDENTS record is created, Colleague updates the application status with the status code associated with the “MS” processing code. Since an individual may have more than one active application on file, Colleague updates to “MS” status only the application that was used to determine the individual's eligibility to become a student. (Student eligibility is determined by the student creation rules you have defined on the Admissions Parameters [ADPA] form.) The status of any other applications on file for the individual is not changed.

• Waitlisted. When you assign an application status with a “waitlisted” processing code, Colleague recognizes this application on the admissions waitlist (used in the Admissions Waitlist (AWLM) process.

Application Status Column Titles

Application status column titles define the titles that Colleague will place on each of the 11 columns of the application status summary report. You define which status codes Colleague reports in each column by assigning a specific column number to each application status code. You define the title of each column using these codes. Use the Special Processing fields on the Validation Codes (VAL) form to record each column heading.


Ge

Figure 2: Example Application Status Column Titles

Use the Validation Codes (VAL) form to define these report column titles. These codes are stored in the APPL.STATUS.COLUMNS record of the ST.VALCODES file.

Application Status Controls

Application status controls drive applicant processing based on your application statuses. These codes let you define your own statuses while allowing Colleague to do special processing based on the status values.

Application status controls codes are stored in the APPL.STATUS.CONTROLS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Application Test Sources

Application test sources denote the source of test results. One code must have a special processing code of “S” assigned to it to denote self-reporting. Colleague uses this special processing code to put the code associated with an “S” (for self-reported) on any test scores entered through the Common Application form. For example, you could define a test source code of “SR” and give that code the special processing code “S.” When you enter test scores from the Common Application, Colleague will automatically give those test scores the “SR” source code.


Ge

Use the Validation Codes (VAL) form to define application test sources codes. These codes are stored in the APPL.TEST.SOURCES record of the ST.VALCODES file.

AR Add/Drop/Withdraw Policies

AR add/drop/withdrawal policy codes define charges you assess a student who adds or drops a course through the registration processes or withdraws from one or more classes or from your institution.

AR add/drop/withdrawal codes are maintained on the AR Add/Drop/Withdraw Policies (ADWP) form. These codes are stored in the AR.ADD.DROP.POLICIES file.

See “Defining Add/Drop/Withdrawal Policies” on page 520 for details on defining these codes.

AR Categories

AR categories are codes that group together similar AR codes for financial aid distribution and for reporting purposes. Examples of AR categories are:

• STF – student fees

• STT – student tuition

• ACADS – academic scholarship

• ATHLS – athletic scholarship

AR categories are defined on the AR Categories (ACTF) form. These codes are stored in the AR.CATEGORIES file.


Ge

AR Codes

Before You Begin

Before you can define AR codes, you should define the following:

If you expect to define rules for determining general ledger distribution and for assigning tax codes, you should understand how to define rules. See “Understanding the Rules Processor” on page 309 for information about the rules processor. See “General Ledger Distribution Rules” on page 151 for more information about using rules with AR codes.

Understanding AR Codes

Use AR codes to indicate how Colleague distributes revenue associated with charges and credits to an accounts receivable account. Examples of AR codes include:

• those that identify charges, such as tuition, fees, housing, and meal plans

• those that identify credits, such as discount or write-off

General Ledger Distribution

Colleague can distribute the charge associated with an AR code to any number of general ledger (GL) accounts for current revenue and to different GL accounts for deferred revenue. If you define a default charge or credit amount you can identify the amount of the distribution by a percentage or by a dollar amount.

Note: If your institution uses Colleague HR and you are defining an AR code for a benefit or a group of benefits that are eligible for arrears processing, then enter only the general ledger number of the liability account for the associated benefit or group of benefits. This is the account that Colleague HR will credit with any arrears amounts or any prepaid vendor amounts for this benefit or the benefits belonging to this group.

Table 7: Information Needed Before You Can Define AR Codes

Item Reference

AR categories1

1.Optional.

148

GL account numbers see the documentation for the General Ledger module

Office codes1 Using Demographics

Tax codes1 157


Ge

Figure 3 illustrates a distribution to a single GL account. In this example, Colleague will distribute 100 percent of the charge to the selected GL account.

Figure 3: An AR Code with a Single GL Distribution and a Default Charge

You can distribute the amount of the charge or credit to more than one GL account by either a percentage of the total charge or by a set amount. If you distribute the charge or credit based on a set amount, the total of all the amounts must equal the default charge or credit (which you must identify if you want to distribute by amount). If you distribute the charge based on a percentage, the total of all the percentages must equal 100 percent.

Note: If you enter the distribution by using specific amounts, Colleague will calculate the corresponding percentages and the total must equal 100 percent.

Note: The GL distribution percent must equal 100, even when you leave the Default Charge and Default Credit fields blank.

Deferred Revenue Accounts

For each general ledger distribution account you associate with an AR code, you can also associate a deferred revenue account. Colleague uses the deferred revenue accounts whenever the billing period for a charge falls outside of the current fiscal year. When a charge falls outside of the billing period, Colleague posts all or part of charge to the appropriate deferred revenue accounts. The parameters for registration, room, meal plans, and miscellaneous charges instruct colleague when to defer the revenue associated with each type of billing. See “Deferred Billing” on page 464 for general information about deferred billing.


Ge

Note: If you do not enter a deferred revenue code for each general ledger code, then Colleague will not defer the revenue associated with this AR code when the charges span multiple fiscal years.

General Ledger Distribution Rules

Colleague uses the default GL distribution you define for an AR code to distribute charges or credits each time you use the AR code. If, however, you want Colleague to distribute the revenue associated with one AR code distributed differently based on certain identifiable circumstances, then define this distribution with general ledger distribution rules.

Enter each distribution rule in the GL Distr Rules field on the AR Codes (ARCF) form. When you add a new rule, Colleague displays the Rules Definition (RLDE) form. After you define the rule, Colleague displays the AR Code Rule GL Distribution (ARGL) form. Use the ARGL form to define the GL distribution for Colleague to use when the rule is true. As with the default general ledger distribution, you can define multiple current and deferred revenue GL accounts and base the distribution on a percentage or an amount.

Note: If you enter the distribution by using specific amounts, Colleague will calculate the corresponding percentages and the total must equal 100 percent.

Note: The GL distribution percent must equal 100, even when you leave the Default Charge and Default Credit fields blank.

For example, Colleague distributes the revenue from Ellucian University’s (EU) meal plan charges to different GL accounts based on the location of the meal plan. To minimize the number of AR codes, the business office chose to create one AR code for all meal plans and to use the general ledger distribution rules to identify how to distribute the charges. The office defined one AR code—MEALS—that it associated with each meal plan. This AR code is associated with several rules that determine how to distribute the charges based on the location of the meal plan (Figure 4).


Ge

Figure 4: Example of GL Distribution Rules for AR Codes

Colleague evaluates the general ledger distribution rules when you use the AR code to generate a charge. Thus, Colleague evaluates the rules illustrated in Figure 4 each time the business off ice generates an invoice for a meal plan.

Defining GL Distribution Rules

Complete the following steps to define the general ledger distribution rules for each AR code.

1. Map out your rules in English-like statements.

Use the worksheet “Rule Construction—English Statements” on page 320.

2. Identify the data elements you need to construct the rules.


Ge

Note: The data elements you use must be from the AR.INOICE.ITEMS file. See “Understanding the Rules Processor” on page 309 for more information about primary views.

Work with your system administrator to identify these data elements.

3. Map out your rules using the Rule Processor syntax.

Use the worksheet “Rule Construction Translation” on page 322.

4. Go to the AR Codes (ARCF) form.

5. Access the AR code you want to enter general ledger distribution rules for.

6. Go to the GL Distr Rules field.

If you have not defined the AR code, do so before completing this procedure.

7. Enter the name of the distribution rule.

The Rules Definition (RLDE) form is displayed.

If the AR Code rule GL Distribution (ARGL) form, and not the RLDE form, is displayed, continue with Step 10.

8. Enter the rule.

Use the information from the worksheet “Rule Construction Translation” on page 322.

Refer to “Understanding the Rules Processor” on page 309 for information about the Rules Definition form.

9. Save the rule.

The AR Code rule GL Distribution (ARGL) form is displayed.

10. Define the distribution that Colleague will use when the associated rule is true.

The total distribution must equal 100 percent.

11. Save the distribution information.

The ARCF form is redisplayed.

12. Repeat this procedure beginning with Step 7 for each general ledger distribution rule associated with this AR code.

13. Save the AR code.

Tax Codes and Rules

If an AR code is associated with one or more tax codes, then you will define rules that indicate when Colleague applies each tax code. When an AR code is used, Colleague evaluates all of the tax rules defined for that code and, for each rule that is true, applies the corresponding tax code. For example, you may have three types of sales tax—state, county, and locality—that apply to all meal plan charges. However, some people or groups


Ge

of people may be exempt from one or more of these taxes. Use tax code rules to identify the conditions under which each tax code applies.

Complete the following procedure to define tax code rules for an AR code.




Note: The data elements you use must be from the AR.INOICE.ITEMS file. See “Understanding the Rules Processor” on page 309 for more information about primary views.




4. Go to the AR Codes (ARCF) form.

5. Access the AR code you want to enter general ledger distribution rules for.

6. Go to the Tax Rules/Codes field.

If you have not defined the AR code, do so before completing this procedure.

7. Enter the name of the tax code rule.


If the cursor moves to the Tax Code field, continue with Step 10.

8. Enter the rule.



9. Save the rule.

The ARCF form is redisplayed with the cursor in the Tax Codes group.

10. Enter the tax code Colleague will assign with the associated rule is true.

The cursor moves to the next line of the Tax Rules/Codes group.

11. Repeat this procedure beginning with Step 8 for each general ledger distribution rule associated with this AR code.

12. Save the AR code.

If a tax code is always applied to a charge, then you can set a rule that will always be true and associate that rule with one or more tax codes. Figure 5 illustrates a rule that will always be true.


Ge

Figure 5: Example of a Rule That Is Always True

Components of an AR Code

Use the AR Codes (ARCF) form to define AR codes. AR codes are stored in the AR.CODES file.

Figure 6: Example of an AR Code

The following fields from the ARCF form are explained in this section:

• Default Charge

• Default Credit

• Priority

• GL Account No

• Deferred Revenue GL Account No

• GL Distr Rules

• Appl Fee

Refer to the online help for information about the other fields on the ARCF form.


Ge

Default Charge

Use the Default Charge field to identify the total charge associated with the AR code. When you use an AR code with a default charge, you can override the amount charged to an individual. If you define a default charge for an AR code, you cannot also define a default credit.

Default Credit

Use the Default Credit field to identify the total credit associated with the AR code. When you use an AR code with a default credit, you can override the amount credited to an individual. If you define a default credit for an AR code you cannot also define a default charge.

Priority

Use the priority field to indicate the order in which Colleague distributes the funds associated with this AR code to financial aid destination 7 awards and in payment allocation. Priorities are ranked on a scale of 1 to 999 (which is the default). See Using Accounts Receivable/Cash Receipts for more information about financial aid payments payment allocation.

Application Fees

Use the Application Fees field to identify AR codes that represent admissions application fees. The admissions office will only have access to these AR codes if you enter Y in this field.

Other Items

See “General Ledger Distribution” on page 149 for information about the GL Account No and Deferred Revenue GL Account No fields.

See “General Ledger Distribution Rules” on page 151 for information about the GL Distr Rules field.

See “Tax Codes and Rules” on page 153 for information about the Tax Rules/Codes field.

AR Fee Defaults

Colleague automatically processes application fees, enrollment verification fees, and transcript request fees. You define the default AR codes and AR types that Colleague uses to process these fees. These codes are stored in the AR.FEE.DEFAULTS file.


Ge

See “Defining Administrative Fee Defaults” on page 545 for details on defining these defaults.

AR Miscellaneous Codes

AR miscellaneous codes let you define up to five codes that you can use for any purpose. Once you have defined these codes you assign them to any individual or organization that has an accounts receivable account. Although Colleague does not directly use these fields, you can use this information for reporting or query purposes or to group individuals for batch miscellaneous billing.

The AR miscellaneous codes are defined on the Validation Codes (VAL) form and are stored in the ST.VALCODES file as AR.MISC1 through AR.MISC5.

Use the AR Accountholders (ARAC) form to assign a miscellaneous code to an individual.

AR Tax Codes

AR tax codes describe the percentage of tax added to charges generated through the module —including registration, room, meal plan, and miscellaneous charges. You associate tax codes with specific AR codes so that each time the AR code is used, the appropriate taxes are calculated.

Note: To apply one or more tax codes to any charge, you must first assign the tax code to the appropriate AR codes. See “Tax Codes and Rules” on page 153 for complete information about associating a tax code with an AR code.

Components of an AR Tax Code

Use the AR Tax Codes (ARTX) form to define each tax code. AR tax codes are stored in the AP.TAXES file.


Ge

Figure 7: Example of an AR Tax Code

This section explains the fields in the Tax Rate group. Refer to online help for information about the other fields on the AR Tax Codes (ARTX) form.

Tax Rate Group

Use the fields in the Tax Rate group to record the current tax rate for each tax code and the compounding sequence that Colleague will use to calculate this tax. Each time a tax rate changes, enter a new rate with a new effective date and, if necessary, a different compounding sequence number. Colleague uses the rate and sequence associated with the most current effective date.

Use the Compound Seq field to indicate the order in which Colleague will apply this tax relative to other taxes and the base amount. If a tax is computed as a percent of the base amount, enter 1 in the Compound Seq field. Any value greater than “1” is charged on the base amount plus any of the taxes with a lower compounding sequences. For example, you might have a state tax and a local tax that are both applied as a percent of the charge. You should define both of these taxes with a compounding sequence of “1.” If you also have a value-added tax that is computed as a percent of the charge plus the state and local tax, use a compounding sequence of “2” for the value-added tax. When you apply all three taxes to a charge, Colleague applies the state and local taxes to the charge and applies the value-added tax to the sum of the charge plus the state tax plus the local tax.

Tax Rate Group


Ge

AR Types

Before You Begin

Before you can define AR type codes, you should define the following:

Understanding AR Types

In many manual systems, receivable accounts are maintained on ledger cards organized in trays, with each tray representing a different type of receivable. An AR type is analogous to these ledger trays. Examples of AR types are student receivables, employee receivables, bad debt, and miscellaneous receivables. You might also use AR types to represent receivables for different locations, such as a student receivable for the main campus and a student receivable for the east campus.

Each AR type you define should describe a complete and unique set of receivables with a unique general ledger control account. You can limit the offices that use a particular AR type by assigning office codes to the AR type. AR types are stored in the AR.TYPES file.

Use the AR Types (ARTF) form to define your AR types.

Table 8: Information Needed Before You Can Define AR Codes

Item Reference

GL account numbers see the documentation for the General Ledger module

Office codes1

1.Optional.

Using Demographics


Ge

Figure 8: Example of an AR Type

AR Waiver Policies

AR waiver policies describe how registration charges are reduced for a selected group of students. For example, if you provide a reduction in the cost of attending classes to employees, then you might set up a registration rate table for employees that uses a standard tuition rate table, term rate table, and an employee waiver policy. Colleague calculates an employee’s tuition and registration charges and then reduces those charges based on the waiver policy.

AR waiver policies codes are maintained on the AR Waiver Policies (WAVP) form. These codes are stored in the AR.WAIVER.POLICIES file.

See “Defining Tuition Waiver Policies” on page 522 for complete information about defining waiver policies.

Attendance Types

Attendance type codes identify the type of student attendance in a course section.

There are special processing codes associated with each attendance type code. Colleague checks the special processing codes associated with the attendance type


Ge

codes to see which type of attendance to count as absent. Table 9 shows the special processing codes, how the codes will be used, and on which form they display.

Use the Validation Codes (VAL) form to define attendance type codes. They are stored in the ATTENDANCE.TYPES record of the ST.VALCODES file.

Award Actions

Award action codes are used to indicate the action status of an award. You can define multiple award actions codes (for example, [E]stimated and [F]ile Incomplete) and associate them to a single action category (for example [P]ending). Colleague processes awards based on the action category to which the award action codes is associated, not the award action code. See “Action Categories” on page 139 for information about action category codes.

Examples of award action codes include:

Table 9: Special Processing Codes for Attendance Type Codes

Special Processing Code Will Be Used … Will Display On The …

0 as a default. Will not be stored on the student’s record.

Section Attendance Tracking (SATK) form.

1 to tally days the student is absent.

Section Attendance by Student (SATS) form.

2 to tally days the student is excused.


3 to tally days the student is late. Will not be used in the total absence counts.


Table 10: Award Action Codes

Award Action Code Description Category

A Accepted (A)ccepted

D Denied (D)enied

E Estimated (E)stimated

F File Incomplete (E)stimated

L Late Applicant (P)ending

N Note to be signed (P)ending


Ge

Award action codes are defined on the Award Action Definition (ACT) form. These codes are stored in the AWARD.ACTIONS file.

Award Categories

Award category codes are used to group together award codes which have similar attributes for use in compiling the Financial Aid Transcript and reports. Section D of the Financial Aid Transcript lists, by award category, sources of assistance, current amounts, and cumulative amounts for a student.

Examples of award category codes include:

Award category codes are defined on the Award Category Definition (ACD) form. These codes are stored in the AWARD.CATEGORIES file.

P Pending (P)ending

R Rejected (R)ejected

S Suggested (P)ending

V Verification Needed (E)stimated

X Cancelled (D)enied

Table 11: Examples of Award Category Codes

Award Category Code Description

BYRD Robert C. Byrd Scholarship Program

CL Consolidated Loan

GSL Federal Stafford Loan

NDSL Federal Perkins/National Direct Student Loan

PELL Federal Pell Grant

PLUS PLUS Loan

SEOG Federal Supplemental Educational Opportunity Grant

SSIG State Student Incentive Grant

USTF Unsubsidized Federal Stafford Loan

Table 10: Award Action Codes (continued)

Award Action Code Description Category


Ge

Award Disbursement Code Type

Award disbursement code types are tied to each award disbursement code, which is stored in the FLPC.ACYR file.

• P — Pell

• C — CommonLine

• B — Both (Pell/Dl)

• L — Direct Loan

• A — All

Award type codes are stored in the AWARD.DISB.CODE.TYPE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Award Packaging Category Codes (AWDPC)

Award packaging category codes are used to group award codes in packaging categories for processing by the Automatic Packaging (PKCR) form. Award packaging categories are defined on the Packaging Category Detail (APCD) form. For each category you define, you can define the following parameters:

• Designate the category as gift aid or self-help aid.

• Assign a packaging priority to the category (assign packaging priorities to awards within the category on the Award Packaging [APAC] form).

• Specify how award amounts are to be rounded during automatic packaging processing.

• Specify whether or not existing award packages can be increased by the PKCR form.

• Specify whether this packaging category uses campus-based or institutional need and cost figures in automatic packaging.

The characteristics you define for the packaging category apply to all awards within the category unless you override the characteristic for an individual award on the APAC form. That is, the category values are used in automatic packaging processing as defaults for each award within the category unless you override them for the specific award using the APAC form.

Examples of award packaging category codes include:

Table 12: Examples of Award Packaging Category Codes

Award Packaging Category Code Description

FEDGR Federal Grant Category


Ge

Award packaging category codes are defined on the Packaging Category Detail (APCD) form. These codes are stored in the AWDPC file.

Award Periods

Award period codes are used to indicate a time period for which financial aid is awarded. Examples of award period codes include:

Award period codes are defined on the Award Period Definition (AWPD) form. These codes are stored in the AWARD.PERIODS file.

Awards

Award codes are used to indicate a financial aid award. Award codes can be associated with an award category for use in compiling an award history or a packaging category for use in automatic packaging. See “Award Categories” on page 162 for information about award category codes.

GRANT Institutional Grant

LOANS Federal Stafford Loans

PELL Pell Packaging Category

SCHOL Inst. Honors Scholarships

STATE State Grant Category

WORK Work-Study Options

Table 13: Example Award Period Codes

Award Period Code Description Start Date End Date

97/FA Fall 1997 09/01/97 12/20/97

97/WI Winter 1997 12/21/97 01/19/98

98/SP Spring 1998 01/20/98 05/20/98

98/SU Summer 1998 06/01/98 08/20/98

Table 12: Examples of Award Packaging Category Codes (continued)

Award Packaging Category Code Description


Ge

Examples of award codes include:

Award codes are defined on the Award Definition (AWD) form. These codes are stored in the AWARDS file.

Award Types

Award type codes are used to indicate the type of financial aid award. Award type codes can be used for reporting purposes. Award type codes are:

Award type codes are stored in the AWARD.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Billing Frequency Codes

Billing frequency codes control the billing cycles for payment plans, recurring receivables, and for periodic registration billing. Valid billing frequency codes are:

Table 14: Examples of Award Codes

Award Code Description

AVD Arthur Vining Davis Scholarship

BOG Basic Opportunity Grant

CON Consolidated Loan

L01 Federal Stafford Loan

PELL Federal Pell Grant

E02 Ellucian University Scholarship

W04 Federal College Work Study

Table 15: Award Type Codes

Award Type Code Description

F Federal

I Institutional

S State

O Other


Ge

• W – weekly

• M – monthly

• Y – yearly

When defining a payment plan, you will indicate the frequency of the plan (using a billing frequency code) and the number of payments. Together, this information determines the length of the payment plan. For example, if the frequency is “M” and the number of payments is 15, then the payment plan is for 15 months.

When defining recurring receivables, you will indicate either a frequency for generating the receivable (using the billing frequency code) or the number of days between billing cycles. For example, if the frequency is “M,” then the recurring receivable is generated each month (by contrast, if you could indicate that a recurring receivable is generated every 28 days).

When defining periodic registration billing, you indicate the type of billing period Colleague uses to calculate all registration charges associated with periodic billing. For example, you use a monthly base billing period, all tuition and other charges you define for periodically billed course sections are monthly charges.

Billing frequency codes are stored in the BILLING.FREQUENCIES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Billing Method Codes

Billing method codes indicate how Colleague should calculate tuition charges for a specific course. The valid options for this code are described below:

Billing method codes are maintained on the Validation Codes (VAL) form. These codes are stored in the BILLING.METHODS record of the ST.VALCODES file. You should only modify this code with the assistance of an Ellucian representative.

Table 16: Billing Method Codes

Code Description

T Indicates that Colleague should use tuition rate table to calculate the tuition for this course or course section.

S Indicates that Colleague should use the billing information associated with the course section to calculate the tuition charge for this course section.


Ge

Billing Period Types

Billing period type codes group together course sections for the purposes of computing charges for a specific billing period. Valid billing period type codes are:

• T – term

• R – reporting term

Billing period type codes are stored in the BILLING.PERIOD.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Billing Override Reasons

Billing override reason codes identify the reasons a computed billing amount is overridden. You must enter an override reason code any time you change a billing amount from the calculated amount. You can use this code as an audit check, but Colleague does not directly use it for processing.

Examples of billing override reason codes include:

• F – financial hardship

• B – business office approval

• O – other authorized override

Billing override reason codes are maintained on the Validation Codes (VAL) form. These codes are stored as BILLING.OVERRIDE.REASONS in the ST.VALCODES file.

See Using Accounts Receivable/Cash Receipts for information about using billing override reasons.

Billing Rounding Codes

Billing rounding codes identify how Colleague rounds a partial registration billing period. Valid options are:

• U – round up

• D – round down

• N – round to the nearest

Colleague uses the billing rounding codes, along with the rounding units, to round partial periods.


Ge

Billing rounding codes are stored in the BILLING.ROUNDING.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Calculation Indicators

Calculation indicator codes are used to indicate which family contribution results are used to calculate a student’s need for Pell grant, federal, or institutional awarding.

Calculation indicator codes are:

Calculation indicator codes are stored in the CALC.INDICATOR record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Campus Organization Characteristics

Campus organization characteristics codes indicate the characteristics, or make-up, of the organization (for example, men only or research organization). This code is notational only; no processing is based on this code.

Use the Validation Codes (VAL) form to record campus organization characteristic codes. These codes are stored in the CAMPUS.ORG.CHARACTERISTICS record of the ST.VALCODES file.

Campus Organization Functions

Campus function codes represent the types of functions/events an organization may sponsor (for example, weekly meetings or seminars). These codes are notational only and do not affect processing code.

Table 17: Calculation Indicator Codes

Calculation Indicator Code Description

P Pell Grant Awarding

F Federal Awarding

I Institutional Awarding


Ge

Use the Validation Codes (VAL) form to record campus organization function codes. Campus function codes are stored in the CAMPUS.ORG.FUNCTIONS record of the ST.VALCODES file.

Campus Organization Groupings

Campus organization grouping codes identify related campus organizations such as different chapters of a single organization at separate locations and/or with separate memberships.

Campus organization grouping codes are maintained on the Validation Codes (VAL) form. These codes are stored in the CAMPUS.ORG.GROUPINGS of the ST.VALCODES file.

Campus Organization Member Statuses

Member status codes indicate the membership statuses of individuals within an organization (for example, Good, Active, or Inactive). This code is notational only and does not affect processing.

Campus organization member status codes are maintained on the Validation Codes (VAL) form. These codes are stored in the CAMPUS.ORG.MEMBER.STATUSES of the ST.VALCODES file.

Campus Organization Types

Campus organization type codes represent the various types of organizations at your institution (for example, athletic, academic, or committee). The organization type may affect other processing at your institution. For example, you may find it beneficial to identify athletic organizations which may be affected by National Collegiate Athletic Association (NCAA) reporting or athletic-based financial aid.

Use the Campus Org Types (COTY) form to define campus organization type codes. You can access the COTY form from the menu. Campus organization type codes are stored in the ORG.TYPES file.

Career Goals

Career goal codes identify what type of career an applicant is interested in after finishing a selected course of study at your institution. Examples of career goals include computer


Ge

programmer, doctor, secretary, landscape designer, or philosopher. You can use career goals to track an individual’s intended vocation.

Use the Validation Codes (VAL) form to define career goal codes. These codes are stored in the CAREER.GOALS record of the ST.VALCODES file.

CB/Institutional Codes

Campus-based/institutional codes are used to indicate whether, for the purposes of automatic packaging, an award uses campus-based or institutional need and cost figures. Use the Packaging CB/Inst Rules (PCRL) form to define a rule table or subroutine that indicates the campus-based/institutional code result.

Campus-based/institution codes are:

Campus-based/institution codes are stored in the CB.INST.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

CCD Codes

CCD codes define your institution’s credentials, certificates, or diplomas. Use the CCDS (CERT) form to define CCD codes. These codes are stored in the CCDS file.

Citizenship Status

Citizenship status codes indicate whether a student is a U.S. citizen, an eligible non-citizen, or neither.

Citizenship status codes are stored in the CITIZENSHIP.STATUS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 18: CB/Institutional Codes

CB/Institutional Code Description

CB Campus Based

INST Institutional


Ge

Class Levels

Class level codes identify the class levels at your institution, such as freshman, sophomore, junior and senior. As you set up academic levels you must define which class levels will be associated with a particular level. You must associate rules to each class level code so Colleague will properly assign these codes to students. See “Class Level Rules” on page 339 for more information about defining your class level rules.

Use the Class Level Codes (CLAS) form to define class codes. They are stored in the CLASSES file.

COD Document Statuses

COD document status codes indicate the status (Accepted/Rejected/Duplicate) of an XML document from Common Origination and Disbursement (COD) system processing. Document status codes are delivered in the response block of imported COD documents.

COD status codes are stored in the COD.DOC.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

COD Document Types

COD document type codes indicate the document type assigned by the Department of Education’s Common Origination and Disbursement (COD) system. Document type codes are delivered in the response block of imported COD records. The following codes are defined:

• BN Booking Notification

• CO Credit Decision Override

• ND Negative Disbursement

• PS Payment to Servicing

• PN Promissory Note

• RC Receipt

• RS Response

• SG System Generated Response

• WB Web Initiated Response


Ge

COD document type codes are stored in the COD.DOC.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

COD Error Types

COD error types codes indicate for Common Origination and Disbursement (COD) processing the various COD errors that are loaded in the COD errors file from XML imports using the Department of ED Import (DOEI) form. COD error types codes are delivered in the response block of the imported COD record. The following codes are defined:

• DC Document

• RS Reporting School

• AC Attended Campus

• ST Student

• PA Pell Award

• PD Pell Disbursement

• LA PLUS Award

• LD PLUS Disbursement

• SA Subsidized Award

• D Subsidized Disbursement

• UA Unsubsidized Award

• UD Unsubsidized Disbursement

COD error types codes are stored in the COD.ERROR.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

COD Export Message Class

COD export message class codes indicate the outbound message class used by the Export COD XML Records (CODE) form to communicate with the Department of Education’s Common Origination and Disbursement (COD) system. The export message class is specified in the Export Message Class field on the COD Parameter Definition (CODP) form.

Two codes are delivered.


Ge

• COMRECIN Live Inbound to Dept

• CRTESTIN Test Inbound to Dept

The live export message class code, COMRECIN1, is delivered as the default, and should not be changed except in consultation with an Ellucian representative. If you must perform testing with the Department of Education, enter the proper message class for testing.

Warning! Ellucian strongly recommends that you do not test directly with the Department of Education (ED). You risk mixing data between your live and test accounts. See Support Solution 2354 for additional information.

COD export message class codes are stored in the COD.OUT.MESSAGE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

COD Import Message Class

COD import message class codes indicate the inbound message class used by Colleague’s COD Interface to communicate with the Department of Education (ED) Common Origination and Disbursement (COD) system. The import message class is specified in the Import Message Class field on the COD Parameter Definition (CODP) form. Two import message class codes are available:

• COMRECOP Live Outbound from Dept

• CRTESTOP Test Outbound from Dept

The entry live message class COMRECOP2 is delivered as the default and should not be changed except in consultation with an Ellucian representative. If you must perform testing with the Department of Education, you would need to enter the proper message class for testing.

Warning! Ellucian strongly recommends that you do not test directly with the Department of Education (ED). You risk mixing data between your live and test accounts. See Support Solution 2354 for additional information.

COD import message class codes are stored in the COD.IN.MESSAGE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

1.The “IN” portion of this code for the outbound class reflects the view of the document from the Department of ED (ED). Although the document is outbound for Colleague, it is inbound for ED.

2.The “OP” portion of this code for the inbound message class reflects the view of the document from the Department of ED (ED). Although the document is inbound for Colleague, it is outbound for ED.


Ge

College Status

College status codes indicate on the PROFILE Family info/Signatures (PFI1) form whether or not the family member will attend college this year.

College status codes are stored in the COLLEGE.STATUS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

College Types

College types codes indicate on the PROFILE Family info/Signatures (PFI1) form whether an institution is two or four year, public or private, or graduate or professional.

College types codes are stored in the COLLEGE.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

College Year

College year codes indicate on the FAFSA the student’s year in college.

College year codes are stored in the COLLEGE.YEAR record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Common School IDs

Common School IDs codes indicate the various routing IDs assigned to your institution by the Department of Education (ED) for Common Origination and Disbursement (COD) processing. The routing IDs include the institution’s Source Entity ID (the default code entered in the Source Entity ID field on the COD Parameter Definition (COPD) form), and the various routing IDs specified on the COD Institutional Defaults (CSID) form and, for multi-campus institutions, the FA Office COD Parameters (CSOF) form and FA Locations Definition (FLCD) form. Each of the routing IDs must be specified in the COMMON.SCHOOL.IDS validation code table before it can be entered on a default or parameter form. See Using the COD Interface for additional information on setting up your institution’s COD routing IDs.

Use the Validation Codes (VAL) form to define the various routing IDs assigned to your institution. These codes are stored in the COMMON.SCHOOL.IDS record of the ST.VALCODES file.


Ge

Contact Measures

Contact measure codes identify how contact hours are measured. For example, if a course has two contact hours per week, you would enter “2” in the Contact Hrs field and a code for weekly in the Contact Measure field on the Course Offering Info (COFF) form.

This code table is used to validate the following fields:

Note: To indicate which of your codes corresponds to a weekly measure, enter 1 in the first Special Processing field on the Validation Codes (VAL) form. This special processing is used in Affordable Care Act reporting, by the ACA Measurement Extract (ACME) process, to correctly determine the faculty member’s calculated contact hours with regard to course section assignments.

Use the Validation Codes (VAL) form to define contact measure codes. These codes are stored in the CONTACT.MEASURES record of the ST.VALCODES file.

Counselor Types

Counselor type codes categorize counselors who are assigned to students, such as personal, financial, and job placement counselors.

Use the Validation Codes (VAL) form to define counselor type codes. These codes are stored in the COUNSELOR.TYPES record of the ST.VALCODES file.

Course Disability Statuses

Course disability statuses identify whether a course is approved for funding based on its service to students with disabilities. These codes use a special processing value of “1” if they count as a disability service contact for fields SD02 and SD04.

Table 19: Fields Validated by the CONTACT.MEASURES Code Table

Field Form

Contact Measure Course Offering Info (COFF)

Measure Faculty Membership Detail (FCMD)

Measure Faculty Organization Asgmt (FAOA)

Contact Measure Section Offering Info (SOFF)


Ge

Use the Validation Codes (VAL) form to define course disability statuses. These codes are stored in the COURSE.DISABILTY.STATUSES record of the ST.VALCODES file.

Course Equate Codes

Course equate codes identify a group of courses that are equal to each other and may be substituted for each other in academic programs. For example, your institution may offer a math course and a computer science course that essentially cover the same material and, therefore, may be substituted for each other. You create an equate code and link each course to the equate code to establish the link between the two courses.

Course equate codes are maintained on the Course Equate Codes (EQCD) form. These codes are stored in the COURSE.EQUATE.CODES file.

Course Level Codes

Course level codes let you associate each course with a particular level without having that level indicate a standard part of the course title or name. Examples of course levels are 100, 200, 300, RE (remedial), and SR (senior).

Use the Validation Codes (VAL) form to maintain course level codes. These codes are stored in the COURSE.LEVELS record of the ST.VALCODES file.

Course or Credit Codes

Course or credit codes identify whether registration billing for a specific charge is based on the number of course sections (“S”) or the total number of billing credits (“C”).

Course or credit codes are stored in the COURSE.OR.CRED.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Course Purposes

Course purposes are used to further categorize courses by general purpose. These codes are used to support California Community College MIS reports.

Use the Validation Codes (VAL) form to maintain course purposes. These codes are stored in the COURSE.PURPOSES record of the ST.VALCODES file.


Ge

Course Statuses

Course statuses represent the different statuses of courses offered at your institution. Use the Validation Codes (VAL) form to define course status codes. Course status codes are stored in the COURSE.STATUSES record of the ST.VALCODES file.

Course Tax Statuses

Course tax status codes identify any specific tax status that you want to keep track of for defining the tax status of a course. “Exempt” is an example of a course tax status.

Course tax status codes are maintained on the Validation Codes (VAL) form. These codes are stored in the COURSE.TAX.STATUSES record of the ST.VALCODES file.

Course Types

Course types describe other categorizations for courses, such as remedial, apprentice, or honors.

Course type codes are maintained on the Validation Codes (VAL) form. These codes are stored in the COURSE.TYPES record of the ST.VALCODES file.

CPS Transaction Statuses

CPS transaction statuses identify priorities for printing an Institutional Student Information Record (ISIR). The following codes are defined:

• AC—prints current active CPS transactions

• HI—prints the highest numbered transaction

• AL—prints all available CPS transactions

CPS transaction statuses codes are stored in the CPS.TRANSACTION.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

Credit Types

Credit type codes identify different types of credits that a student may receive at your or another institution, such as institutional, continuing education or life experience. You must also group the credit types into categories as either transfer, institutional, continuing education, exchange, none or other.

For each credit type code you must decide whether to include that type of credit in the following calculations:

• attempted credit totals

• completed credit totals

• GPA credit totals

You will make similar decisions concerning these calculations when you set up grades and grade schemes. If you decide to set any of these flags to “Yes” or “No” here at the credit type definition, it will override the values set in the grade setup. If you leave these blank here, Colleague will use the grade values.

Use the Credit Type Codes (CTYP) form to define your credit type codes. These codes are stored in the CRED.TYPES file.

CSS Marital Statuses

CSS (College Scholarship Service) marital statuses codes indicate parent marital status on the PROFILE application.

CSS marital statuses codes are stored in the CSS.MARITAL.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

CSS Parent in College

CSS (College Scholarship Service) parent-in-college codes indicate on the PROFILE application whether the parent is attending college.

CSS parent in codes are stored in the CSS.PAR.IN.COLLEGE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

CSS Student Tax Type

CSS (College Scholarship Service) student tax type codes indicate the student’s filing status on the PROFILE application.

CSS student tax type codes are stored in the CSS.STUD.TAX.TYPE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

CSS Student Visa Class

CSS (College Scholarship Service) visa class codes indicate visa classification on the PROFILE application.

CSS visa class codes are stored in the CSS.VISA.CLASS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Days of the Week

Days of the week codes validate the days of the week from Monday to Sunday. These codes are used in the modules that process room and course section scheduling.

The special processing codes relate to check marks on the Section Offering Info (SOFF) form. The special processing codes assignment is as follows:

Use the Validation Codes (VAL) form to record days of the week codes. These codes are stored in the DAYS.OF.WEEK record of the ST.VALCODES file.

Table 20: Days of the Week Special Processing Codes

Day Special Processing Code

Monday 1

Tuesday 2

Wednesday 3

Thursday 4

Friday 5

Saturday 6

Sunday 7


Ge

Default Actions

Default action codes indicate the allowable action categories for default action codes. Each award must have an associated default award action code. The default award action codes is assigned to the award when the award is awarded to a student. See “Action Categories” on page 139 for information about action category codes. See “Award Actions” on page 161 for information about award action codes.

Default action codes are:

Default action codes are stored in the DEFAULT.ACTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Deferred Revenue Codes

Deferred revenue codes identify how you want Colleague to recognize revenue when the billing period of a charge spans fiscal years. The valid deferred revenue codes are “S,” for start date, “E,” for end date, and “P,” for part in each year.

Deferred revenue codes are stored as DEFER.REVENUE.CODES in the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Degrees

Degrees define the academic degrees offered by your or another institution.

Examples of degree codes are:

• MBA – Masters in Business Administration

• BA – Bachelor of Arts

Use the Degree Codes (DEGR) form to define degree codes. These codes are stored in the DEGREES file.

Table 21: Default Action Codes

Default Action Code Description

A Accepted

E Estimated

P Pending


Ge

Department of ED Import Levels

Department of ED import levels codes are used in the Process Steps field on the Department of Ed Import (DOEI) form to specify whether you are processing in a Unix environment (with an entry of 1-All steps) or on a Windows platform (with an entry of 7-Full Windows Processing). In addition, for troubleshooting purposes, you can indicate a subset of the steps performed to import Common Origination and Disbursement (COD) documents.

Department of Ed import levels codes are stored in the DOEI.LEVELS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Dependency Statuses

Dependency status codes indicate whether a financial aid applicant is independent or dependent. Dependency status codes are:

Dependency status codes are stored in the DEPENDENCY.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Deposit Types

Before You Begin

Before you can define deposit types you should define the following:

Table 22: Dependency Status Codes

Dependency Status Code Description

D Dependent

I Independent

Table 23: Information Needed to Define Deposit Types

Item Needed Reference

GL number for posting the monies held for deposit by this deposit type code.

The documentation for the General Ledger module


Ge

Understanding Deposit Types

Use deposit type codes to define the different kinds of deposits you receive at your institution. You can limit the use of deposited funds for specific purposes through deposit allocation rules. Deposit allocation rules indicate how Colleague applies the money associated with a specific deposit type to an individual’s account. For example, you can define a deposit type for dorm room deposits that are only applied against a student’s account if that student incurs specific charges, such as room damage charges. If you do not identify a specific usage rule and you set the auto allocation parameter to “yes,” Colleague applies the deposit against any charge in the individual’s account.

Components of a Deposit Type

Use the Deposit Types (DPTY) form to define deposit types. These codes are stored in the AR.DEPOSIT.TYPES file.

Figure 9: Example of a Deposit Type

The Auto Allocation and Allocation Rules fields are described below. Refer to online help for information about the other fields on the Deposit Types (DPTY) form.

Rules for describing the allocation of a deposit type

“Components of a Deposit Type” on page 182

Table 23: Information Needed to Define Deposit Types (continued)

Item Needed Reference


Ge

Auto Allocation

You can allocate money received as a deposit toward a student’s account or you may choose not to allocate the funds. Use the Auto Allocation parameter to indicate how you want Colleague to handle each deposit type.

If you do not want Colleague to automatically allocate the deposit against charges, then you would set the Auto Allocation parameter to “No.” When you receive a deposit defined without automatic allocation, the money is not applied against any charges that the student incurs. You can leave that deposit as unapplied funds or you can manually apply it to one or more charges. See Using Accounts Receivable/Cash Receipts for more information about manual deposit allocation.

If you want the money associated with a particular deposit allocated against charges, then you would set the Auto Allocation parameter to “Yes.” For these deposits, you can allocate the money:

• against any charge until the deposit is completely allocated

• against specific charges

If the type of deposit you are defining can be allocated against any charges incurred, then set the Auto Allocation parameter to “Yes,” and leave the Allocation Rules field blank. As explained in “Allocation Rules” below, if you identify one or more allocation rules, Colleague allocates the deposit as dictated by the rules.

Deposit Allocation Rules

Use allocation rules to indicate the type of charges that you want a certain deposit applied against.

For example, Ellucian University requires that each resident pay a room security deposit prior to the start of the occupancy. The housing office returns the deposit at the end of the occupancy period if the resident does not incur room damage charges. However, if the resident incurs a room damage charge, EU applies the security deposit Figure 10 illustrates how the business office defined this deposit type.


Ge

Figure 10: Example of a Deposit Type with Allocations Rules

Colleague evaluates the allocation rules associated with a deposit type when you run the deposit allocation process. This process lets you allocate one or more deposits to the appropriate charges for a group of individuals. For example, if you have a group of students who have incurred the room damages fee (charged as the DMGS AR code), when you run the deposit allocation process Colleague allocates the student’s room deposits against these charges.

When an allocation rule is true, Colleague applies as much of the deposit as it can against the charge specified in the rule. For example, at Ellucian University, the room security deposit is $75.00. If a student is assessed a $35.00 dorm damage fee, Colleague applies $35.00 of the $75.00 deposit against that fee. If, however, a student is assessed a $150.00 dorm damage fee, Colleague applies the total $75.00 deposit against that charge, leaving the student with a $75.00 unpaid charge.

Note: Colleague evaluates the allocation rules when you run the auto allocation process, not when you manually allocate a deposit against an individual’s charges.

Deposit allocation rules must use the AR.INVOICE.ITEMS file as the primary file view. See Using Accounts Receivable/Cash Receipts for complete details on the deposit allocation process.


Ge

Procedure for Defining Deposit Allocation Rules

Complete the following steps to define deposit allocation rules.




Note: The data elements you use must be from the AR.INVOICE.ITEMS file. See “Understanding the Rules Processor” on page 309 for more information about primary views.


3. Go to the Deposit Types (DPTY) form for the deposit type you want to define allocation rules for.

If you have not defined the deposit type, do so before completing this procedure.

4. Go to the Auto Allocation field.

5. Enter Y.

The cursor moves to the Allocation Rules field.

6. Enter the name of each allocation rule.


If the name of the rule displays and the cursor moves to the next blank line, continue with Step 9.

7. Define the rule.

8. Save the rule on the RLDE form.

The DPTY form is redisplayed.

9. Repeat this procedure for each allocation rule you want to define for this deposit type.

10. Save the deposit type record.

Destinations

Destination codes are used to indicate how financial aid funds are applied against a student's account. Destination codes are:

Table 24: Destination Codes

Destination Code Description

1 Accounts Receivable


Ge

Destination codes are stored in the DESTINATIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Direct Loan Types

Direct loan type codes indicate the type of direct loan. Direct loan type codes are:

Direct loan type codes are stored in the DL.LOAN.TYPE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Direct Loan Type All

Direct loan type all codes are used in the Award Type field on the Direct Loan Variance Report (DLVR) form to restrict the report to a specific award type. The values are:

2 Cash Payment

3 Limited CWS Payroll

4 External Fund

5 Other Institutional Job

6 Loan

7 Conditional Award

Table 25: Direct Loan Type Codes

Direct Loan Type Code Description

S Subsidized

U Unsubsidized

P PLUS

Table 26: Direct Loan Type All Codes


S Subsidized

Table 24: Destination Codes

Destination Code Description


Ge

Direct loan type codes are stored in the DL.LOAN.TYPE.ALl record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Direct Loan Year In College ‘00

Direct loan year in college ‘00 codes specify the student’s year in college on the direct loan application for academic year 2000 and later.

Direct loan year in college ‘00 codes are stored in the DL.YEAR.IN.COLL.00 record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Discount Types

Discount type codes identify where you can apply the discount. The options for this field are:

Discount type are stored as DISCOUNT.TYPES in the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Due Date Formulas

Invoice due date formulas describe how Colleague calculates the due date for a specific invoice, such as registration invoices and meal plan invoices. When you use invoice due

U Unsubsidized

P PLUS

A All

Table 27: Discount Types

Discount Types Of this type are associated with…

C A specific course section so that all student’s who take the course section will receive the discount

S A student so that the discount applies to all course sections for which the student registers

B A specific course section record for a student

Table 26: Direct Loan Type All Codes (continued)



Ge

date formulas, Colleague calculates the due date for the invoices based on specific time periods.

Invoice due date formulas are maintained on the Invoice Due Date Formula (IDDF) form. These codes are stored in the AR.DUE.DATE.FORMULAS file.

See “Defining Invoice Due Date Parameters” on page 556 for details on defining invoice due date formulas.

ED TG Number

ED TG number codes indicate your institution’s Live/Test TG number for COD processing.

ED TG numbers are stored in the ED.TG.NUMBERS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Educational Goals

Educational goals describe what an applicant expects to achieve by attending your institution. Educational goals may describe a specific degree (such as a Bachelor of Arts) or a certificate, degree, or diploma. You can use these codes to track an individual’s intended outcome based on his selection of studies. For example, one student may seek a goal of completion of a degree while another may simply want to increase her aptitude in a given skill.

Use the Validation Codes (VAL) form to define your educational goals. Educational goals are stored in the EDUCATION.GOALS record of the ST.VALCODES file.

Electronic Loan Enrollment Statuses

Electronic loan enrollment statuses identify a student’s enrollment for CommonLine processing.

Electronic loan enrollment status codes are stored in the EL.ENROLLMENT.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

Electronic Loan Grade Levels

Electronic loan grade levels identify a student’s grade level for CommonLine processing.

Electronic loan grade level codes are stored in the EL.GRADE.LEVELS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Electronic Loan Type Codes

Electronic loan type codes identify loan types for CommonLine processing.

Electronic loan type codes are stored in the EL.LOAN.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Electronic Loan Processing Types

Electronic loan processing type codes identify for CommonLine processing the action a recipient (guarantor or lender) should take to process the loan. Example codes include the following:

Use the Validation Codes (VAL) form to define electronic loan processing type codes. These codes are stored in the EL.PROCESSING.TYPES record of the ST.VALCODES file.

Electronic Loan Relationship Codes

Electronic loan relationship codes identify relationships for CommonLine processing.

Table 28: EL Processing Type Codes

EL Processing Type Description

CR Certification Request

GO Guarantee Only

GP Guarantee and Print

PG Print and Guarantee

PO Print Only


Ge

Electronic loan relationship codes are stored in the EL.RELATIONSHIP.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Enrollment Statuses

Enrollment status codes identify the enrollment status of a student. These are in addition to a student’s academic standing code. You must associate rules to each enrollment status code so Colleague will properly assign these codes to students. See “Enrollment Status Rules” on page 342 for more information about defining your enrollment status rules.

Use the Enrollment Status Codes (ENRS) form to define enrollment status codes. These codes are stored in the ENROLL.STATUSES file.

EOPS CARE Statuses

EOPS CARE statuses identify Cooperative Agencies Resources for Education (CARE) statuses as defined by the California Community Colleges MIS Reports.

Use the Validation Codes (VAL) form to define EOPS CARE statuses. These codes are stored in the EOPS.CARE.STATUSES record of the ST.VALCODES file.

EOPS Eligibility Factor Codes

EOPS eligibility factor codes identify eligibility factors as defined by the California Community Colleges MIS Reports.

Use the Validation Codes (VAL) form to define EOPS eligibility factor codes. These codes are stored in the EOPS.ELIGIBILITY.FACTORS record of the ST.VALCODES file.

EOPS Term End Statuses

EOPS term end statuses identify the end-of-term EOPS statuses as defined by the California Community Colleges MIS Reports.

Use the Validation Codes (VAL) form to define EOPS end-of-term statuses. These codes are stored in the EOPS.TERM.END.STATUSES record of the ST.VALCODES file.


Ge

Evaluation Codes

Evaluation codes describe the status of an evaluation needed for a medical school application.

Use the Validation Codes (VAL) form to define evaluation codes. These codes are stored in the EVALUATIONS record of the ST.VALCODES file.

Expense Codes

Expense codes define the types of expenditures associated with each course section established in the Curriculum Management module. Use these codes to record projected and actual course expenses for reporting purposes.

Use the Expense Codes (EXPN) form to define expense codes. Expense codes are stored in the EXPENSE.CODES file.

FA Academic Calendar

FA academic calendar codes indicates for RFMS processing the type of academic calendar your institution uses. You specify the academic calendar your institution uses on the Attendance Pattern Definition (ATPC) form.

FA academic calendar codes are stored in the FA.ACADEMIC.CALENDAR record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Accepted Response

FA accepted response codes enable you to enter a code to limit the selection of the COD Accepted Response Report (CARR) to accepted responses (with an entry of A-Accepted) or to corrected responses (with an entry of C-Corrected) in the Response Types field on the selection form for the report.

FA accepted response codes are stored in the FA.ACCEPTED.RESPONSE.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

FA Active Flags

Entry of an FA active flags code in the Act field on the Need Analysis Summary (NASU) form indicates that the application is to be used for awarding purposes. An entry in this field determines if the application is used for budgeting, automatic packaging, and Common Origination Disbursement (COD) processing. The following codes are defined:

• F Federal

• I Institutional

• B Both

FA active flags codes are stored in the FA.ACTIVE.FLAGS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Application Forms

FA application forms codes indicate the version of the application and promissory note used in financial aid processing. The following codes are defined:

• B - Appl/Prom for Fed Staff

• M - MPN for Fed Staff

• P - Appl/Prom for PLUS

• Q - Appl/Prom for PLUS

FA application forms codes are stored in the FA.APPL.FORMS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Award Letters

FA Award Letters codes are used to define custom award letters for your institution. To define a custom award letter, use the FA Award Letter Definition (FALD) form to specify an award letter ID and associate the award letter ID with an award letter print subroutine. You can also create custom award letters using the Award Letter Parameters (ALPA) form. The award letter print subroutine is called by the Award Letters (ALTR) form and tells Colleague the content and format of the award letter.

A default award letter print subroutine, S.PRINT.AWARD.LETTERS, is provided with Colleague. This subroutine can be modified to create multiple award letter versions, such as an award letter for undergraduate students and an award letter for graduate students.


Ge

Your system administrator can assist you in the creation of additional award letter print subroutines.

FA award letter codes are defined on the FA Award Letter Definition (FALD) form and are sorted in the FA.AWARD.LTRS file.

FA Award Letter Print Codes

FA award letter print codes specify in the Award Letters to Print field on the Award Letters (ALTR) form which letters to print (A-all letters, M-modified letters, N-not printed).

FA award letter print codes are stored in the FA.AWD.LTR.PRT.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify these codes with the assistance of an Ellucian representative.

FA Batch Award Types

FA batch award type codes are used to indicate whether, during batch awarding, awards are made for the entire award year or for a particular award period in the award year.

FA batch award type codes are:

FA batch award type codes are stored in the FA.BATCH.AWD.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Birthdate Variance Options

FA birthdate variance options codes are used to indicate whether, during batch awarding, awards are made for the entire award year or for a particular award period in the award year.

• 1-Verified Students: Display all students whose birthdates have been verified by the CPS.

Table 29: FA Batch Award Type Codes

FA Batch Award Type Code Description

A Annual

P Award Period


Ge

• 2- Non-verified Students: Display all students whose birthdates have not been verified by the CPS.

• 3-All Variances: Display all students with variances regardless of verification.

These codes are stored in the FA.BDATE.VAR.OPTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Budget Default Options

FA budget default options codes are used to indicate the default options for reassigning budget components (that is, rebuilding the budget) or recalculating budget expenses for a student after you update or finish from the Budget Calculation Parameters (BCP) form. FA budget default options are selected on the FA System Parameters (FASP) form.

FA budget default options codes are:

FA budget default options codes are stored in the FA.BGT.DFLT.OPTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Budget History Statuses

FA budget history status codes are used to indicate the status of a student budget component at the time of an adjustment to the budget, a budget component, or family contribution of the student.

FA budget history status codes are:

Table 30: FA Budget Default Option Codes

FA Budget Default Option Code Description

N Don't Rebuild or Recalc

C Recalc but don't Rebuild

R Rebuild and Recalc

Table 31: FA Budget History Status Codes

FA Budget History Statuses Description

A Automatically Assigned

M Manually Assigned


Ge

FA budget history status codes are stored in the FA.BGT.HIST.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Budget History Types

FA budget history type codes are used to indicate the type of adjustment to a student budget. FA budget history type codes are:

FA budget history type codes are stored in the FA.BGT.HIST.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Budget Unit Types

Budget unit type codes are used to indicate cost basis of an student budget component. The unit type is used to determine a value that is multiplied by the unit cost to determine the total cost of the component.

D Deleted

F Frozen

U Unfrozen

R Recalc

O Remove Overrides

C Changed

Table 32: FA Budget History Type Codes

FA Budget History Types Description

BE Budget Expense

BA Budget Adjustment (obsolete beginning with 2005/2006 processing year)

FC FC Adjustment (obsolete beginning with 2005/2006 processing year)

Table 31: FA Budget History Status Codes (continued)

FA Budget History Statuses Description


Ge

FA budget unit type codes are:

FA budget unit type codes are stored in the FA.BGT.UNIT.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Citizenship

FA citizenship codes are used to indicate the citizenship of the financial aid applicant.

Financial Aid Demographics

For the purposes of demographics, Colleague records the citizenship of a financial aid applicant in both the Colleague Student Financial Aid module and the Core Demographics module. See “Financial Aid Application Processing” on page 197 for information about codes used to indicate the citizenship of the financial aid applicant as reported on the financial aid application.

The following codes are used to indicate the citizenship of a financial aid applicant for the purposes of demographics:

FA citizenship codes, for demographics, are stored in the FA.CITIZENSHIP record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 33: FA Budget Unit Type Codes

FA Budget Unit Types Description

YR Per Year

TR Per Term

MO Per Month

CR Per Credit Hour

NF Number in Family

Table 34: FA Citizenship Codes for FA Demographics

FA Citizenship Code Description

1 U. S. Citizen

2 Eligible Non-Citizen

3 Non-Eligible Non-Citizen

4 Assumed U. S. Citizenship


Ge

Financial Aid Application Processing

For the purposes of financial aid application processing, Colleague records the citizenship of a financial aid applicant in the Colleague Student Financial Aid module only. See “Financial Aid Demographics” on page 196 for information about codes used to indicate the citizenship of the financial aid applicant for the purposes of demographics.

The following codes are used to indicate the citizenship of a financial aid applicant as reported on the financial aid application:

FA citizenship codes, for financial aid application processing, are stored in the FA.CITIZENSHIP.99 record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA COD Grade Levels

FA COD grade level codes indicate grade level for Common Origination Disbursement (COD) processing.

FA COD grade codes are stored in the FA.COD.GRADE.LEVELS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA COD MPN Status

FA COD MPN statuses codes indicate master promissory note (MPN) statuses for Common Origination Disbursement (COD) processing. Examples include the following:

• A Accepted

• R Rejected

• P Pending

Table 35: FA Citizenship Codes for FA Application Processing

FA Citizenship Code Description

1 U. S. Citizen

2 Eligible non-citizen

3 Neither 1 nor 2


Ge

FA MPN statuses codes are stored in the FA.COD.MPN.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA COD Platforms

FA COD platform codes are used to specify in the Platform field on the FA Transfer Parameters (TRPS) form the mainframe platform your institution uses for Common Origination Disbursement (COD) processing.

• UNIX-AIX - IBM AIX 4.2 or higher

• UNIX-HP - HP-UX 10.01 or higher

• UNIX-SUN - Sun Solaris 2.6 or higher

• DEC-TRU64 - DEC Tru64 4.0

• WINDOWS - NT Windows NT

These codes are stored in the FA.COD.PLATFORMS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA COD Temp Flag

FA COD temporary flag codes indicate if an address is temporary or permanent for Common Origination Disbursement (COD) processing.

FA COD temporary flag codes are stored in the FA.COD.TEMP.FLAG record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Code Options

FA code options codes indicate in the Report Option of the Export COD XML Records (CODE) form the level of detail to include on the output report. The following codes are defined:

• 1 - Sent records only. Reports only the student records actually sent to COD.

• 2 - Sent/Awaiting response. Reports the records sent to COD, and also the records not sent because they were included on a previous export but have not yet received a COD Response.


Ge

• 3 - All records shown. Reports all the student records that met the selection criteria.

FA code options codes are stored in the FA.CODE.OPTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CommonLine Co-sign Indicator

For CommonLine processing, these codes indicate an applicant or cosigner.

These codes are stored in the FA.CL.COS.IND record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CommonLine Display Options

These codes are used by the Hold/Release Batch (ELHR) form to determine the manner in which data is presented on the accompanying report. The following display option codes determine how the information will be displayed on the report.

Table 36: FA CommonLine Co-sign Indicator

FA CommonLine Co-sign Indicator Code Description

C Cosigner

D Self

Table 37: FA CommonLine Display Options

FA CommonLine Display Options Description

A Causes all awards to print on the report, regardless of whether a hold/release status change will take place on any of the award disbursements.

D Causes only those awards for which a disbursement change is required.

E Causes all awards to print, regardless of change, and shows and expanded view of each award being evaluated on the disbursement level.


Ge

These codes are stored in the FA.CL.DISP.OPTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CommonLine Hold/Release Indicator

These codes are used by the Hold/Release Rule (HRRL) form to assign a validation code for Hold/Release Status used by the Hold/Release Batch (ELHR) form to place a hold or release status on a specific disbursement or multiple disbursements associated to electronic loan awards whose disbursements fall within a given date range. The following codes are assigned based on the rules defined on the HRRL form.

These codes are stored in the FA.CL.HOLD.REL record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CommonLine Import Options

FA CommonLine copy option codes describe whether and how Colleague will overwrite Colleague loan data fields during the Import Electronic Loan Files (IELF) process. These codes direct copying from the EL.APP file to the LA.ACYR file.

FA CommonLine copy codes are stored in the FA.CL.IMPORT.OPTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CommonLine Import Type

These codes are used on the Electronic Loan Import (IELF) process to select Response Files and Disbursement Roster Files for import from CommonLine into Colleague. The

Table 38: FA CommonLine Hold/Release Indicator

FA CommonLine Hold/Release Indicator Description

H Hold

R Release


Ge

following codes are used to select CommonLine Response and Disbursement Roster files for import.

These codes are stored in the FA.CL.IMPORT.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CommonLine Record Types

FA CommonLine record type codes indicate the CommonLine record types used by the FA module. These codes are used in Electronic loan processing.

FA CommonLine record type codes are stored in the FA.CL.RECORD.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CommonLine Release Number

These codes are used in processing electronic loans to indicate the CommonLine release number. The following codes indicate the CommonLine release number.

These codes are stored in the FA.CL.RELEASE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 39: FA CommonLine Import Type Codes

FA CommonLine Import Type Description

R Response Files

DR Disbursement Roster Files

B Both Response and Disbursement Roster Files

Table 40: FA CommonLine Release Number Codes

FA CommonLine Release Number Description

3 CommonLine Release 3

4 CommonLine Release 4


Ge

FA CommonLine Rent/Own Indicator

These codes indicate whether the CommonLine co-signer rents or owns a home. The following codes indicate the co-signer’s rent/own status.

These codes are stored in the FA.CL.RENT.IND record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CommonLine Sort Values

FA CommonLine sort values codes indicate sort processing for CommonLine processing. These codes are stored in the FA.CL.SORT.VALUES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Beginning with the 1994/95 Financial Aid Application

Beginning with the 1994/95 financial aid application, examples of course study codes include:

Table 41: FA CommonLine Rent/Own Codes

FA CommonLine Rent/Own Indicator Description

O Own

R Rent

Table 42: Examples of Course Study Codes Beginning with the 1994/95 FA Application

Course Study Codes Description

01 Agriculture

02 Architecture

03 Bioscience

04 Business

05 Communications

06 Computer Science

07 Education


Ge

Beginning with the 1994/95 financial aid application, course study codes are stored in the COURSE.STUDY.CODES.94 record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Core Import Options

FA Core import option codes specify on the Core Import Options (CIMO) form the manner in which the ISIR Import (ISIM) form updates data stored in the Core module. You can specify the manner in which you want each of the following fields updated in Core:

• Name

• Birthdate

• Gender

• Driver’s License

• Email

• Address

• Phone

When you run the ISIR Import (ISIM) process, Colleague uses Social Security numbers to match incoming records to students who already exist in your Colleague database. If it finds a matching student, the process uses the codes specified in the appropriate field on the CIMO form to determine, on a field-by-field basis, how that information gets updated in the PERSON and associated Core files.

The following are the available options:

• 1 - Never Update CORE. The ISIM form does not update the specific demographic field in the PERSON file. If you determine that the ISIR data is correct and you're working with information from 2004 or earlier, you can use the Application Demographics (FAAD) form to update the CORE files as needed. If you determine that the ISIR data is correct and you're working with information from 2005 or later, you can use the FAFSA App Demographic Update (FADU) form to update the CORE files as needed.

• 2 - Update if CORE is null. If the Person file contains any information in this field, Colleague retains that information. However, if the field is null in the Core file, Colleague populates the field with data from the ISIR.

• 3 - Update if ISIR not null. If the ISIR contains any data in this field, Colleague updates the PERSON file with this information.

However, if this field is null on the ISIR, Colleague retains whatever information is in the PERSON file rather than nulling out the field in Core.

• 4 - Always Update CORE. The import process automatically overwrites the Core data with information from the ISIR. Note that if the ISIR value is null, it will delete any data that exists in the Core field.


Ge

If you determine that the previous Core data was correct, you must use the appropriate Core forms to update Core files manually, then run the Correction Application Export (CAPX) form to send the correction to the Department.

These codes are stored in the FA.CORE.IMPORT.OPTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CR Decision Statuses

FA CR decision statuses codes indicate the possible statuses from a Common Origination Disbursement (COD) processing response. Possible values include A- Accepted, D - Denied, and P - Pending.

These codes are stored in the FA.CR.DECISION.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA CR Override

FA CR override codes indicate credit checks statuses for PLUS loans that are a result of an override in Common Origination Disbursement (COD) processing. The following codes are defined:

• C New Credit Info Override

• E Endorser Credit Override

• D Endorser's Denial

• N Pending Credit Denial

These codes are stored in the FA.CR.OVERRIDE.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Custodial Parent

FA custodial parent codes indicate the custodial parent for financial aid INAS processing.

These codes are stored in the FA.CUSTODIAL.PARENT record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

FA Decisions

FA decision codes are used to indicate a decision by your institution regarding the eligibility or status of a financial aid applicant. Examples of FA decision codes include:

Use the Validation Codes (VAL) form to define FA decision codes. These codes are stored in the FA.DECISIONS record of the ST.VALCODES file.

FA Default/Overpayment

FA default/overpayment codes indicate default/overpayment status for Direct Loan Common Origination Disbursement (COD) processing. The following codes are defined:

• Y Yes

• N No

• Z Overridden by School

These codes are stored in the FA.DEF.OVERPAY.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Degree/Certification Codes

Degree/certification codes are used to indicate the highest degree or certification received by the financial aid applicant as reported on the financial aid application.

Table 43: Examples of FA Decision Codes

FA Decision Code Description

AC Accepted

RE Rejected

PN Pending

DN Denied


Ge

Beginning with 1999/00 Financial Aid Application

Beginning with the 1999/00 financial aid application, examples of degree/certification codes for the 1999/00 financial aid application include:

Degree/certification codes for the 1999/2000 and subsequent financial aid application are stored in the DEG.CERT.CODES.99 record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Direct Loan MPN Statuses

FA direct loan MPN status codes indicate the status of the master promissory note (MPN) for the student. MPN status codes are used in the MPN Status field and the Prom Nt Status field on the Direct Loan Application (DLAN) form.

These codes are stored in the FA.MPN.STATUSES record of the ST.VALCODES file for 2002/2003 and previous years, and in FA.MPN.STATUS beginning with processing year 2003/2004. These codes can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Disbursement Roster Types

FA disbursement roster type codes determine whether the Electronic App Disb Variance (ELDV) report produces a variance report or a comparison report.

Table 44: Examples of Degree/Certification Codes for the 1999/00 FA Application

Degree/Certification Code Description

1 1st Bachelor’s Degree

2 2nd Bachelor’s Degree

3 Assoc Degree (Occ or Tech)

4 Assoc Degree (Gen or Tran)

5 Cert/Diploma (Less 2 Yr)

6 Cert/Dipl (2 Yr or More)

7 Teaching Credential Pgm

8 Grad or Prof Degree

9 Other/Undecided


Ge

FA disbursement roster type codes are stored in the FA.DISB.ROSTER.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Direct Loan Credit Decisions Codes

FA direct loan credit decisions codes indicate on the Direct Loan Application (DLAN) form the credit decision obtained from the Loan Origination Center's (LOC) web site.

FA direct loan credit decision codes are stored in the FA.DL.CRED.DECS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Document Status

FA document status codes indicate the status of an XML document during Common Origination Disbursement (COD) processing. The following codes are defined:

• A - Accepted

• R - Rejected

• D - Duplicate

These codes are stored in the FA.DOC.STATUS.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Document Type

FA document type codes indicate the type of XML document response returned from the Common Origination Disbursement (COD) system. The following codes are defined:

• BN - Resp/Booking Notification

• CO - Resp/Credit Dec Override

• ND - Resp/Neg Disbursement

• |PS - -Resp/Pmt to Servicing

• PN - Resp/Prom Note

• RC - Receipt

• RS - Response


Ge

• SG - Resp/System Generated

• WB - Resp/Web Initiate

These codes are stored in the FA.DOC.TYPE.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA DOEI Report Options

FA DOEI options codes indicate the format for the report (summary or detail) associated with the Department of ED Import (DOEI) form for Common Origination Disbursement (COD) processing.

These codes are stored in the FA.DOEI.REPORT.OPTS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Drug Convictions Codes

FA drug conviction codes are used to validate questions about drug conviction on the FAFSA to determine applicant’s eligibility for federal financial aid.

For award years 2000/01 and previous years, FA drug conviction codes are stored in the FA.DRUG.CONVICTIONS record of the ST.VALCODES file. Beginning with award year 2001/02 FA drug conviction codes are stored in the FA.DRUG.CONVICTIONS.01 record of the ST.VALCODES file. These codes can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Electronic Loan Citizenship

FA electronic loan citizenship codes indicate citizenship for CommonLine processing.

FA electronic loan citizenship codes are stored in the FA.EL.CITIZENSHIPS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

FA Electronic Loan Fields

FA electronic loan fields codes are used on the Electronic Loan Compare Param (ELCP) form to define comparison parameters for use with the Electronic Loan Appl Variance (ELAV) report. The electronic loan field code entered on the ELCP form describes, by field position, the imported Response File data (EL.APP and EL.LOAN) to be compared. The electronic loan field codes are representations of the data element names in the files that store the application and loan data.

Use the Validation Codes (VAL) form to define FA electronic loan field codes. These codes are stored in the FA.EL.LOAN.FIELDS record of the ST.VALCODES file.

FA Electronic Loan Comparison Parameter Codes

FA electronic loan parameter comparison codes define a group of data elements to be compared during production of the Electronic Loan Appl Variance (ELAV) report. For example, you might run a variance report on borrower data and a comparison report on school certification data. You can use one comparison parameter to represent the borrower data and another to represent school certification data.

The comparison parameter ID must be more than one character and less than eleven characters. Use the Electronic Loan Appl Variance (ELAV) form to specify the comparison parameter to be used for a specific report. The following codes are examples of electronic loan comparison parameter codes.

Electronic loan comparison parameter codes are defined on the Electronic Loan Compare Param (ELCP) form and are stored in the FA.COMPARE file.

Table 45: FA Electronic Loan Comparison Parameter Codes

Electronic Loan Comparison Parameter Codes Description

ALL All comparison fields

DISBURSMNT Disbursement comparison fields

FREQUENT Frequently referenced fields

BORROWER Borrower fields

SCHLCERT School Certification fields


Ge

FA Electronic Loan Retrieve

FA electronic loan retrieve codes specify default electronic loan retrieval parameters on the Send/Receive Parameters (ELSR) form and override retrieval parameters on the Loan Application Export (LAPX) form.

FA electronic loan retrieve codes are stored in the FA.EL.RETRIEVE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Electronic Loan Transmit Method

FA electronic loan transmit method codes specify default electronic loan transmittal parameters on the Send/Receive Parameters (ELSR) form and override transmit parameters on the Import Electronic Loan Files (IELF) form.

FA electronic loan retrieve codes are stored in the FA.EL.TRANSMIT.METHODS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Entrance/Exit/Both Interview

FA entrance/exit/both interview codes enable you to specify on the Entrance/Exit Interview (DLEI) form which type of interview dates you want to import for Common Origination Disbursement (COD) processing. The following codes are defined:

• N - Entrance

• X - Exit

• B - Both

These are stored in the FA.NXB record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify these codes with the assistance of an Ellucian representative

FA Federal Terms

FA federal term codes are used to indicate the academic term(s), as defined by the federal government, associated with a particular award period.


Ge

FA federal term codes are:

FA federal term codes are stored in the FA.FEDERAL.TERMS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA File Suites

The FA.SUITES file stores one record per year identifying the status of the file suites for that year. File suites are created and deleted, and their statuses are displayed in the Suites Status group on the FA File Suite Processing (FFSP) form. The FA file suite is a set of files for holding financial aid date for a single academic year. Each file contains records relating to a particular type of financial aid data.

FA File Suite Actions

FA file suite action codes are used to indicate the action that you want to perform for a selected file suite.

FA file suite action codes are:

Table 46: FA Federal Term Codes

FA Federal Term Code Description

1 Summer (occurring at the beginning of the award year)

2 Fall

3 Winter

4 Spring

5 Summer (occurring at the end of the award year)

Table 47: FA File Suite Action Codes

FA File Suite Action Code Description

C Create

D Delete

U Update


Ge

FA file suite action codes are stored in the FA.FS.ACTION record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA File Suite Statuses

FA file suite status codes indicate the status of a processed file suite.

FA file suite status codes are:

FA file suite status codes are stored in the FA.FS.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA FM State and Other Tax Codes

FM state and other tax allowance codes identify the year-specific supplemental version of the Allowances for State and Other Taxes table (keyed year*SM). These values in these tables are used by the federal need analysis calculation. Examples of state tax and other allowance codes include the following:

FA State and Other Tax Allowance codes are stored in the FA.STX file and can be viewed using the State and Other Tax Allowances (SOTA) form.

Table 48: FA File Suite Status Codes

FA File Suite Status Code Description

C Created

D Deleted

Table 49: FA FM State and Other Codes

FA FM State and Other Code Description

2000*SM 2000 FM State and Other Tax Allowance Table

2001*SM 2001 IM State and Other Tax Allowance Table


Ge

FA Fund Distribution Methods

FA fund distribution method codes indicate on the Loan Disbursement (LDIS) form the manner in which funds are to be distributed or returned.

FA fund distribution method codes are stored in the FA.FUND.DIST.METHOD record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Gift/Self Codes

FA gift/self codes are used to indicate whether, during automatic packaging, an award will be used as gift aid or self-help. Colleague allows you to control, by student, the percent of cost or need that can be satisfied with gift aid. You can also indicate a maximum amount of gift aid that can be used to meet a student’s cost or need.

FA gift self codes are:

FA gift self codes are stored in the FA.GIFT.SELF record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA IFB

FA IFB codes indicate which calculation worksheet to print (Institutional/Federal/Both) for the College Board Batch Calc (CBBC) form.

These codes are stored in the FA.IFB record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 50: FA Gift/Self Codes

FA Gift/Self Code Description

G Gift

S Self

E Entitlement


Ge

FA IM State and Other Tax Codes

IM State and Other Tax Allowance codes identify the year-specific institutional version of the Allowances for State and Other Taxes table (keyed year*IM). These values in these tables are used by the institutional need analysis calculation. Examples of IM state tax and other allowance codes include the following:

FA IM State and Other Tax Allowance codes are stored in the FA.STX.IM file and can be viewed/maintained using the IM Stu State Tax Allowances (SSTA) form.

FA Income Protection Allowance Tables

Income protection allowance table codes store by year the income protection tables used in the federal and supplemental need analysis calculations.

The following codes are examples of electronic loan comparison parameter codes.

Note: The Federal Methodology Income Protection Allowance table can be viewed but not modified.

Income protection allowance table codes are defined on the Income Protection Allowance (IPAL) form and are stored in the FA.IPA file.

Table 51: FA IM State and Other Codes

FA IM State and Other Code Description

2000*IM 2000 IM State and Other Tax Allowance Table

2001*IM 2001 IM State and Other Tax Allowance Table

Table 52: FA Income Protection Need Analysis Codes

Income Protection Allowance Codes Description

2000*FM Federal Methodology

2000*SM Supplemental Methodology

2001*FM Federal Methodology

2001*SM Supplemental Methodology


Ge

FA Loan Application Fields

FA loan application fields codes are numeric codes that represent data elements in the yearly loan application file (the template for which is LA.ACYR). These loan application fields codes are used by FA forms that call the S.FA.CL.UPDATE.COLL subroutine to translate the field location number to a data element name.

FA loan application fields codes are stored in the FA.LA.ACYR.FIELDS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Locations

FA locations refer to location codes which have been associated with an FA office code. Location codes are used to indicate the various location of your institution. Use the Location Rule Table (LCRL) form to define a rule table or subroutine that assigns a location code, along with the associated FA office, to a student. Colleague tracks student awards against the appropriate office fund balance. See “FA Offices” on page 219 for information about FA office codes.

Examples of FA locations include:

FA locations defined on the FA Locations Definition (FLCD) form. FA office associations for locations are stored in the FA.LOCATIONS file. The FA.LOCATIONS file is a co-file of the LOCATIONS file, which is defined in the Core System.

Table 53: Examples of FA Locations

Location Code Description

FA Office Code Description

MAIN Ellucian University Main Campus FAMAIN EU Main Campus FA Office

PWC Ellucian - PWC Satellite Campus FAMAIN EU Main Campus FA Office

FFX Ellucian University - Fairfax FAFFX EU Fairfax Campus FA Office

SFC Ellucian University - San Francisco FASFC EU San Francisco FA Office


Ge

FA Low Tuition Codes

FA low tuition codes define on the Stu Pell Overrides and Orig (SPOO) form low tuition ranges for use with alternate Pell calculations.

FA low tuition codes are stored in the FA.LOW.TUITION.CODE record (for years 2001 and previous) or in the FA.LOW.TUITION.2002 (for years 2002 and subsequent) of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Manifest Options

FA manifest options codes indicate which manifest statuses to print for the DL Prom Note Manifest (DPMN) form. The following codes are defined:

• D - Date Specific-Manifested (requires entry in the Manifest Date field).

• N - Not Manifested

• I - Ignore Manifest Status

These codes are stored in the FA.MANIFEST.OPTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Marital Statuses

FA marital status codes are used to indicate the marital status of a financial aid applicant or an applicant’s parent(s) as reported on the financial aid application.

FA marital status codes are stored in the FA.STUD.MARITAL.99 record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Media Types

FA media types codes identify the method being used to submit data to a CommonLine Network service provider. You specify the appropriate code in the Media Type field on the Loan Appl Export (LAPX) form. The type of media used will depend on the requirements of the service provider. Each export file must indicate the method being used to submit data to the service provider.


Ge

FA media types codes are stored in the FA.MEDIA.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Message Class

FA message class codes enable you to import files by message class using the ISIR Import (ISIM) form for Common Origination and Disbursement (COD) processing. The following codes are defined:

• A -Electronic App (EAPS)

• C - Corr/Dup (CORR)

• E - Auto ISIR (SARA)

• F - Fed Data Reqst (FDRF)

• G - CPS Sys Gen (SYSG)

• I - Year-To-Date (YTD)

• K - State Non-Res (ESFN,YTDN)

• L - State Res (ESFR,YTDR)

These codes are stored in the FA.MESSAGE.CLASS.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA NAS Sort By Codes

FA NAS sort by codes indicate whether to sort student records by ID, SSN, or name.

FA NAS sort by codes are stored in the FA.NAS.SORT.BY record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

FA Need Analysis Assumption Tables

Need analysis assumption suppression tables are defined and modified on the FM Assumption Suppression (FAAS) form. The following codes are examples of assumption suppression table codes.

FA need analysis assumption suppression table codes are defined on the FM Assumption Suppression (FAAS) form. These codes are stored in the FA.AS file.

FA Need/Cost Codes

FA need/cost codes are used to indicate whether an award from a designated fund offsets a student's need or family contribution, when calculating unmet need, or cost of attendance, when calculating unmet cost. FA need/cost codes are:

FA need/cost codes are stored in the FA.NEED.COST record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Negative Fields

FA negative field codes identify the year-specific negative field tables that indicate which FAFSA fields can contain negative numeric information. The codes allow you to view or maintain the year specific tables of values for the Federal Methodology need calculation

Table 54: FA Assumption Suppression Codes

FA Assumption Suppression Table Code Description

2000*FM

2001*FM

Table 55: FA Need/Cost Codes

FA Need/Cost Code Description

N Need

C Cost

F FC


Ge

(keyed year*FM) or the Supplemental need calculation (keyed year*SM). Examples of FA negative field codes include the following:

FA negative fields codes are stored in the FA.NF file and can be maintained using the FA Negative Fields (FANF) form.

FA Offices

FA offices codes are used to indicate a financial aid office. FA offices codes can be associated with an location code. Use the Location Rule Table (LCRL) form to define a rule table or subroutine that assigns a location code, along with the associated FA office, to a student. Colleague tracks student awards against the appropriate office fund balance. See “FA Locations” on page 215 for information about FA locations.

Examples of FA office codes include:

FA office codes are defined on the FA Office Parameters (FAOP) form. These codes are stored in the FA.OFFICES file.

FA Packaging Desirability

FA packaging desirability codes are used to indicate your desire to have a student attend your institution. You can use the student packaging desirability code as part of an eligibility

Table 56: FA Negative Field Codes

FA Negative Field Code Description

2001*FM 2001 FM Negative Field Table

2001*SM 2001 SM Negative Field Table

Table 57: Examples of FA Office Codes

FA Office Code Description

FADUM EU Main Campus FA Office

FAFFX EU Fairfax Campus FA Office

FASFC EU San Francisco FA Office


Ge

restrictions for an award or packaging category of awards, or as part of a sort order. Examples of FA packaging desirability codes include:

FA packaging desirability codes are stored in the FA.PKG.DESIRABILITY record of the ST.VALCODES file and can be viewed and modified on the Validation Codes (VAL) form.

FA Packaging Reports

FA packaging report codes are used to indicate the level of detail of the report produced by the Automatic Packaging (PKCR) process. FA packaging report codes are:

FA packaging report codes are stored in the FA.PKG.REPORTS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 58: Examples of FA Packaging Desirability Codes

FA Packaging Desirability Code Description

H Highly Desired

M Moderately Desired

Table 59: FA Packaging Report Codes

FA Packaging Report Code Description Detailed Description

SP Student Packaging The Student Packaging Report provides summary information about the award packages, including the student's name, packaging group, and attendance pattern; information about existing awards and newly created awards; and the packaging comments for each award.

V Validation The Validation Report provides justification (the rules used) for how the package was generated, in addition to the information provided in the Student Packaging Report.

ERV Expanded Rule Validation

The Expanded Rule Validation Report provides the result of each rule evaluation for each rule used in automatic packaging processing, in addition to the information provided in the Validation Report.


Ge

FA Parent Marital Status

FA parent marital status codes indicate the parent’s marital status on the FAFSA.

Parent marital status codes are stored in the FA.PARENT.MARTIAL.99 record of the ST.VALCODES file. These codes can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Pell or DL

FA Pell or DL codes enable you to select Pell records, direct loan records, or both types of records for Common Origination Disbursement (COD) processing on the following forms:

• COD Accepted Response (CARR) Report

• COD Missing Response (CDMR) Report

The following codes are defined:

• P- Pell only

• D - DL only

• B - Both Pell and DL

These codes are stored in the FA.PELL.OR.DL record of the ST.VALCODES file. These codes can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Production Types

FA production types codes are used by the Loan Application Export (LAPX) form to determine if a file should be created during the export process.

FA production types are stored in the FA.PRODUCTION.TYPES record of the ST.VALCODES file. These codes can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Promissory Note Print

FA promissory note status codes indicate the print status of the promissory note for COD processing. The following codes are defined:


Ge

• S — COD Prints/Sends Borrower

• R — COD Prints/Sends School

• Z — COD Reprint

• O — School Prints/Sends

FA promissory note print codes are stored in the FA.PROM.NOTE.PRINT record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Promissory Note Status

FA prom note status codes indicate for COD processing whether the promissory note has been (S)igned or (P)rinted.

FA promissory note status codes are stored in the FA.PROM.NOTE.STATUS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Reconciliation Report Types

FA reconciliation report type codes enable you to indicate whether you want the Pell Reconciliation Report (PRER) form to report on only those students who have a variance between their Colleague and COD year-to-date amount or on all students regardless of whether they have a variance or not. The following codes are defined:

• V-Variance

• A-All

FA reconciliation report type codes are stored in the FA.RECON. REPORT.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Reject Message

FA reject message codes identify the year-specific Federal Methodology tables that indicate the reject messages used by the Department of Education’s central processor. The reject message codes allow you to view or maintain the year-specific tables of reject


Ge

messages for the Federal Methodology need calculation (keyed year*FM). Examples of FA reject message codes include the following:

FA reject message codes are stored in the FA.REJECT.MSG file and can be viewed using the FM - Reject Messages (FARM) form.

FA Response

FA response codes indicate the response returned from ED’s Central Processing System (CPS) following Common Origination Disbursement (COD) processing. These codes are displayed on the following forms:

• Pell COD Disbursement (PLDT)

• DL COD Response Info (DLRI)

• COD Document Information (CODD)

The following codes are defined:

• A Accepted

• R Rejected

• C Corrected

These codes are stored in the FA.RESPONSE.CODES record of the ST.VALCODES file. These codes can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Serial Loan Codes

FA serial loan codes indicate the manner in which your institution wants to use the master promissory note. Example codes include [N]ew to use a new promissory note and [S]erial to renew an existing master promissory note.

FA serial loan codes are stored in the FA.SERIAL.LOAN.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 60: FA Reject Message Codes

FA Reject Message Code Description

2000*FM 2000 FM Reject Message Table

2001*FM 2001 FM Reject Message Table


Ge

FA Signed By Codes

FA signed by codes indicate in the Signed Flag field on the Releases and Sigs FAFSA (RS##) form (where ## indicates the first half of the processing year) whose signature is on the application. Colleague populates the Signed By field based on the data in the signature fields as follows:

• “A” if only the Student Signature field contains a “Y.”

• “P” if only the One Parent Signature field contains “Y.”

• “B” if both the Student Signature field and the One Parent Signature field contain a “Y.”

The Signed Flag field is not exported as part of the initial electronic application.

Colleague populates the Signed Flag field in the EDE data set when you use the ISIR Import (ISIM) process to import ISIR data. An “A” indicates receipt of a student signature by the CPS. A “P” indicates receipt of only a parent signature by the CPS. A “B” indicates receipt of both the student and parent signature by the CPS.

Note: The CPS does not update the signature fields. Therefore, the signature requirement may be satisfied although the signature fields on this form contain “N” or are blank.

You can use the Signed Flag code to indicate the resolution of signature rejections. If the Signed Flag code in the COLL data set differs from the Signed Flag code in the EDE data set, Colleague will export the Signed Flag code in the COLL data set as a correction.

These codes are stored in the FA.SIGNED.BY record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA SOP Flags

FA standards of progress (SOP) flag codes are used to indicate whether a student has met the standards of progress for an academic program. Use the Standards of Progress View (SOPV) form to view the history of a student's standards of progress calculation results.

Note: The FA standard of progress (SOP) functionality has been replaced by satisfactory academic progress (SAP) in version 14 of Colleague. See “SAP Statuses” on page 268 for information about SAP status codes.

Standards of progress flags are:

Table 61: FA Standards of Progress Flag Codes

Standards of Progress Flag Code Description

PE Probation


Ge

FA standard of progress codes are stored in the FA.SOP.FLAGS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Stafford Loan Class Level

FA Stafford Loan class level codes are used to indicate the class level for the student’s most recent Stafford Loan as reported on the 1993/94 supplemental financial aid application. FA Stafford Loan class level codes are:

FA Stafford Loan class level codes are stored in the FA.STAF.CLASS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

UN Unsatisfactory

SA Satisfactory

Table 62: FA Stafford Loan Class Level Codes

Stafford Loan Class Level Code Description

1 Freshman

2 Sophomore

3 Junior

4 Senior

5 5th Yr or more Undergrad

6 1st Yr Grad or Prof

7 Continuing Grad or Prof

Table 61: FA Standards of Progress Flag Codes (continued)

Standards of Progress Flag Code Description


Ge

FA State Codes

FA state codes are used to indicate a state, such a the legal state of residence of a financial aid applicant, as reported on the financial aid application. Examples of FA state codes include:

FA state codes are stored in the FA.NEED.STATES.2001 record of the ST.VALCODES file. These codes can be viewed on the Validation Codes (VAL) form and should only be modified with the assistance of an Ellucian representative.

FA State Grade Level

FA grade level codes are used to indicate the highest grade level attained by the parent(s) of a financial aid applicant as reported on the financial aid application.

For the 1995/96 through 1998/99 financial aid applications, FA state grade level codes are stored in the FA.STATE.GRADE.LEVEL record of the ST.VALCODES file. Beginning with 1999/00 financial aid applications, these codes are stored in the FA.STATE.GRADE.LEVEL.99 record of the ST.VALCODES file. These codes can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Student Comments

FA student comments codes identify the comments fields that to be updated with a specific comment by the Student Comment Assignment (BASC) form. The BASC form updates comments for groups of students in batch mode. Examples of codes for specific comments fields include:

• FA - FA Comments

Table 63: Examples of FA State Codes

FA State Code Description

AL Alabama

AK Alaska

AS American Samoa

AZ Arizona

AR Arkansas

CA California


Ge

• NA - Need Analysis Comments

• AW - Awarding Comments

• VERIF - Verification Comments

• TRANS - Transcript Comments

• TRACK - Tracking Comments

• SAP - Satisfactory Academic Progress Comments

Student comments codes are maintained on the Validation Codes (VAL) form. These codes are stored in the FA.STU.COMM.CODES record of the ST.VALCODES file.

FA Tape Codes

FA tape codes identify parameter records for an import/export files. Parameter records identify the description, size, and default name of the record to be exported or imported.

Use the Import/Export Parameter Files (PARX) form to maintain FA tape parameters. FA tape parameter records are stored in the FA.TAPE file.

FA Tax Figures

Tax figure codes are used to indicate the source of income tax figures for the financial aid applicant and/or the parent(s) of the financial aid applicant as reported on the financial aid application.

Tax figure codes are stored in the FA.TAX.FIGURES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Tax Return Status

FA tax return status codes indicate whether or not a tax return has been filed in conjunction with FAFSA processing. FA tax return status codes are:

• 1 Already Completed

• 2 Will File, Not Completed

• 3 Not Going to File


Ge

FA tax return status codes are stored in the FA.TAX.RETURN.STATUS.01 record of the ST.VALCODES file. These records can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Tax Return Type

FA tax return type codes indicate which income tax return was filed in conjunction with FAFSA processing.

FA tax return type codes are stored in the following year-specific records of the ST.VALCODES file. For processing years1998/1999 through 2002/2003, in the FA.TAX.RETURN.TYPE.99 record, and for processing years 2003/2004 and subsequent years in the FA.TAX.RETURN.TYPE.04 record. These records and can be modified using the Validation Codes (VAL) form.

FA Transmittal Modes

FA transmittal mode codes are used to indicate the manner in which an FA.TRANSMITTALS record is created. FA transmittal mode codes are:

FA transmittal mode codes are stored in the FA.TRANSMITTAL.MODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 64: FA Transmittal Modes

FA Transmittal Mode Code Description

AR Online from AR

FA Online from FA

B Batch Transmittal


Ge

FA Unconverted Records Delete Action

On the Batch Process Unconverted Records (BPUR) form, these codes allow you select which unconverted records you want to process. The following codes are examples:

FA unconverted record delete action codes are stored in the FA.UR.DELETE.ACTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Verification Status Change

FA verification status change codes are used on the Select Verification Students (SVST) form to specify a change of verification status. On the SVST form, you specify in the Verif Status Change Code field the manner in which you want the verification status to change.

Valid verification change status codes include:

• 1 - Change Null to 1

• 2 - Change 2 to 8

• 3 - Change 1 to Null

• 4 - Change 8 to 2

For example, if you select a group of students with a verification status of 2 and choose Verif Status Change Code 2 (Change 2 to 8) the verification statuses for all the selected students are changed to 8.

Any records in your selection that do not match the Verif Status Change Code are not changed. For example, if you select a group of students with verification statuses of 1 and 2 and choose Verif Status Change Code 2 (Change 2 to 8), only the students with a verification status of 2 in your selection are changed to 8. Students with a verification status of 1 are not changed.

Table 65: Batch Process Unconverted Records Codes

Unconverted Records Delete Action Code Description

1 Don't Delete (Keep all converted records in the UNCONVERTED.RECORDS file)

2 Delete Converted Records (Delete those records that do convert from the UNCONVERTED.RECORDS file.)

3 Delete Low Tran/Conv Recs, (Delete all records from UNCONVERTED.RECORDS that convert or have a low transaction number)


Ge

These codes are stored in the FA.VERIF,STATUS.CHANGE.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Yes/Blank Codes

FA YB codes are used for ISIR fields that allow “Y” or “Blank” values, and do not allow “N” for “No.” The following forms contain fields that use the FA.YB validation code table.

• CPS Overrides/Comment Codes (CPSR)

• FAFSA App Demographic Update (FADU)

FA.YB codes are stored in the FA.YB record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

FA Year in College Codes

Year in college codes are used to indicate the highest year of college attended by the financial aid applicant.

Year in college codes are:

Year in college codes are stored in the FA.YR.IN.COLLEGE.01 record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 66: Year in College Codes

Year in College Code Description

0 1st, never attended

1 1st, attended before

2 2nd Yr/Sophomore

3 3rd Yr/Junior

4 4th Yr/Senior

5 5th Yr or Other Undergraduate

6 1st Yr, Grad/Prof

7 Continuing Grad/Prof


Ge

Faculty Contract Types

Faculty contract type codes identify the different types of faculty contracts offered at your institution.

Use the Validation Codes (VAL) form to define faculty contract types. These codes are stored in the FACULTY.CONTRACT.TYPES record of the ST.VALCODES file.

Faculty Position Codes

Faculty position codes identify faculty positions at your institution if you do not use the Colleague Personnel module. As delivered, these codes reflect the EEO6 reporting codes used by the federal government.

Use the Validation Codes (VAL) form to define or modify faculty position codes. Faculty position codes are stored in the FACULTY.POSITIONS record of the ST.VALCODES file.

Faculty Remark Codes

Faculty remarks codes identify the source of the remarks made on a faculty member’s record.

Use the Validation Codes (VAL) form to define faculty remarks codes. Faculty remarks codes are stored in the FACULTY.REMARK.CODES record of the ST.VALCODES file.

Faculty Remark Types

Faculty remark type codes identify the types of remarks entered on a faculty member’s record.

Use the Validation Codes (VAL) form to define faculty remark types. Faculty remark types are stored in the FACULTY.REMARK.TYPES record of the ST.VALCODES file.

Faculty Special Statuses

Faculty special statuses represent various special statuses you can assign to faculty members. These codes are useful for reporting, but they do not affect processing.


Ge

Use the Validation Codes (VAL) form to define faculty special statuses. Faculty special statuses are stored in the FACULTY.SPECIAL.STATUSES record of the ST.VALCODES file.

FAFSA Housing Codes

FA housing codes are used to indicate the type of housing, as reported on the FAFSA, in which a financial applicant expects to live while attending an institution.

Use the Validation Codes (VAL) form to define FAFSA housing codes. FAFSA housing codes are stored in the FAFSA.HOUSING.CODES.95 and FAFSA.HOUSING.CODES.99 record of the ST.VALCODES file.

Federal Cohorts

Federal cohort codes identify the list of standard federal cohort groups to which you can assign students. These codes are useful for reporting, but they do not affect processing.

Use the Validation Codes (VAL) form to define federal cohort codes. Federal cohort codes are stored in the FED.COHORTS record of the ST.VALCODES file.

Floor Preference Codes

Floor preference codes identify an individual’s floor preferences for housing assignment.

Use the Validation Codes (VAL) form to maintain floor preference codes. These codes are stored in the FLOOR.PREFERENCES record in the ST.VALCODES file.

Funding Accounting Methods

Funding accounting method codes identify methods used to determine course section enrollment for funding purposes. These codes are used by the California Community College MIS reports, but other institutions can also use these codes to describe funding accounting methods. These codes use a special processing of “1” to indicate whether attendance is tracked on the Non-Scheduled Mtg Attendance (NSMA) form for course sections flagged with this funding accounting method code.

Use the Validation Codes (VAL) form to maintain funding accounting method codes. These codes are stored in the FUNDING.ACCTG.METHODS record in the ST.VALCODES file.


Ge

Funding Sources

Funding sources identify the sources from which a course or section is eligible to receive funding.

Use the Validation Codes (VAL) form to maintain funding source codes. These codes are stored in the FUNDING.SOURCES record in the ST.VALCODES file.

GAIN Statuses

GAIN statuses indicate a student’s status in the California GAIN (General Assistance for Instruction) program. This status shows whether a student has a GAIN contract with the county for educational services and the type of contract. This status is used in California Community Colleges MIS reporting (field SB25).

Use the Validation Codes (VAL) form to define GAIN statuses. These codes are stored in the GAIN.STATUSES record of the ST.VALCODES file.

Grades Participation Codes

Grades participation codes identify when an applicant participated in specific areas of interest during secondary school. For example, if an applicant played football in his junior and senior year, you would associate 11th and 12th grade with this area of interest. You enter these grades when recording a Common Application.

Use the Validation Codes (VAL) form to define grades participation codes. These codes are stored in the GRADES.PARTICIPATION record of the ST.VALCODES file.

Guarantor Codes

Guarantor codes represent guarantor agencies your institution uses for FFELP loan applications. A Guarantor is required for all Common Line loans. Each guarantor record is associated with one or more lender records.

Use the Loan Guarantor (GUAR) form to define guarantor codes. Guarantor codes are stored in the GUARANTOR file.


Ge

Hiatus Codes

Hiatus codes define the types of hiatus or leave of absence a student may take from your institution, such as study abroad, or illness. These codes also describe a student who is withdrawing from your institution permanently, either because of personal choice or academic dismissal.

Use the Hiatus Codes (HIAT) form to define hiatus codes. They are stored in the HIATUS.CODES file.

See Using Academic Records for additional information about how hiatus codes are used.

Hiatus Statuses

Hiatus status codes identify the status of a student’s leave of absence from your institution. These codes are not used directly by the system, but you may use them in reporting and for queries.

Use the Validation Codes (VAL) form to define hiatus status codes. They are stored in the HIATUS.STATUSES record of the ST.VALCODES file.

Honors Codes

Honor codes identify honors a student can receive at your institution.

Use the Honors (HONR) form to define honor codes. They are stored in the HONORS file.

Housing Codes

Housing codes indicate on to indicate the type of housing, as reported on the PROFILE, in which a financial applicant expects to live while attending an institution.

Housing codes are stored in the HOUSING.CODES record of the st.valcodes file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.


Ge

Housing Statuses

Housing status codes indicate where a student’s housing is located, such as on campus or off campus.

Use the Validation Codes (VAL) form to define housing status codes. They are stored in the HOUSING.STATUSES record of the ST.VALCODES file.

Influences to Apply Codes

Influence to apply codes indicate what influenced an individual to apply to your institution. Examples include campus tour, high school night, counselor, alumni, or friend. You can use the codes to track reasons why an individual decided to apply to your institution and to assist in tracking trends for how applicants view your institution.

Use the Validation Codes (VAL) form to define influence to apply codes. These codes are stored in the APPL.INFLUENCES record of the ST.VALCODES file.

Institution Cohorts

Institution cohort codes group your student population so that you can easily track them. These are separate from the standard federal cohorts which your institution can use as well.

Examples of institution cohort codes are:

• ATHL – Athlete

• FRAT – Fraternity

• VET – Veteran

Use the Validation Codes (VAL) form to define institution cohort codes. These codes are stored in the INSTITUTION.COHORTS record of the ST.VALCODES file.

Instructional Methods

Instructional method codes identify the various methods of instruction (for example, lecture or lab) at your institution.

Use the Instructional Methods (ISTM) form to define instructional methods. These codes are stored in the INSTR.METHODS file.


Ge

Invoice Types

Invoice type codes let you classify miscellaneous and recurring invoices for the purpose of printing invoices. For example, you might have an invoice type that identifies all invoices generated for a specific event. You would then use this invoice type when you printed the invoices as a means of selecting only those associated with the specified event.

Invoice type codes are maintained on the Validation Codes (VAL) form. These codes are stored as INVOICE.TYPES in the ST.VALCODES file.

Lenders

Lender codes are records of lending institutions used for electronic loan processing. Lender records are associated with loan awards and with loan applications. In addition, each lender is associated with a specific guarantor.

Use the Lending Inst Definition (LID) form to maintain data about lenders. Lender data is stored in the LENDERS file.

Local Government Codes

Local government codes represent state or province classification codes assigned to courses.

Use the Local Government Codes (LGCD) form to define these codes. These codes are stored in the LOCAL.GOVT.CODES file.

Matriculation Other Statuses

Matriculation other statuses identify any other supportive assessment services that a student may have received as a part of the matriculation process.

Use the Validation Codes (VAL) form to maintain matriculation other statuses. These codes are stored in the MATRIC.OTHER.STATUSES record of the ST.VALCODES file.


Ge

Matriculation Provide Statuses

Matriculation provide statuses identify any counseling or advising services that a student may have been provided during a particular term.

Use the Validation Codes (VAL) form to maintain matriculation provide statuses. These codes are stored in the MATRIC.PROVIDE.STATUSES record of the ST.VALCODES file.

MCAT Writing Sample Codes

MCAT writing sample codes define the score that a medical applicant received on the writing sample submitted with the Medical College Admissions Test. The valid scores are “J” through “T” and “X” for could not be scored.

Use the Validation Codes (VAL) form to maintain the MCAT writing sample codes. These codes are stored in the MCAT.WR.CODES record of the ST.VALCODES file.

Majors

Major codes define the majors offered at your institution. After you create a requirement, you can identify it as a major using a major code you defined. For example, you may create a requirement that a student must complete 50 credits in math and identify the requirement as a math major.

Use the Majors (MAJR) form to define major codes. These codes are stored in the MAJORS file.

Meal Classifications

Meal classification codes identify the classes of meals offered at your institution (for example resident, commuter). You may classify a meal plan based on the individual using the meal plan. For example, you may set up separate meal plans for resident students and commuter students.

Use the Validation Codes (VAL) form to define meal classification codes. These codes are stored in the MEAL.CLASS record of the ST.VALCODES file.


Ge

Meal Plan Frequencies

Meal plan frequencies identify how often a meal plan may be used for example, day, week). Use this code with the number of times the plan can be used. For example, a meal plan frequency code of Day is combined with the number of meals to establish the how often the meal plan can be used (3 times per day).

Use the Validation Codes (VAL) form to define meal plan frequency codes. Meal plan frequency codes are stored in the MEAL.PLAN.FREQUENCY record of the ST.VALCODES file.

Meal Plan Assignment Statuses

Meal plan assignment status codes identify the status of a meal plan (for example, assigned, cancelled, or refunded). The meal plan assignment status affects billing and is used by Colleague to determine the refund formula and amount.

Use the Validation Codes (VAL) form to define meal plan assignment status codes. Meal plan assignment status codes are stored in the MEAL.ASSIGN.STATUSES record of the ST.VALCODES file.

Meal Rate Periods

Meal rate periods describe how you bill a particular meal plan. Valid meal rate periods are:

When you assign a meal plan to an individual, Colleague displays the rate period. If the plan is billed by the term, you can only enter 1 in the No of Rate Periods field on the Meal Plan Assignment (MPAS) form. For meal plans that are billed on a basis other than term, you enter the number of periods for which the meal plan applies. For example, if you assign a meal plan that is billed weekly and the assignment is for six weeks, enter 6 in the No of Rate Periods field on the MPAS form.

Table 67: Meal Rate Period Codes

Meal Rate Periods Description

B by the meal

D daily

W weekly

M monthly

Y yearly

T by the term


Ge

Meal rate periods are stored in the MEAL.RATE.PERIODS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Meal Types

Meal type codes identify the various types of meals offered by your institution such as lunch or dinner. You can use the meal type codes to restrict the types of meals available to a meal plan.

Use the Validation Codes (VAL) form to define meal type codes. Meal type codes are stored in the MEAL.TYPE record of the ST.VALCODES file.

Military Benefit Eligibility Codes

Military Benefit Eligibility codes describe the categories for active military benefits. The eligibility codes include the following:

• A (Active Military)

• R (Reserves)

• SA (Spouse of active military)

• SR (Spouse of reservist)

• DA (Active military dependent)

• DR (Dependent of reservist)

Use the Validation Codes (VAL) form to define military benefit eligibility codes. The codes are stored in the MIL.BEN.ELIGIBILITY.CODES record of the ST.VALCODES file.

Military Benefits

The Military Benefit codes describes the benefits available for active military students, their spouses, or dependents. The following are examples of military benefits:

• Tuition assistance

• Post -9/11 GI Bill

• Montgomery GI Bill

• Reserve Ed assistance


Ge

• Loan Repayment

Use the Validation Codes (VAL) form to define military benefit codes. The codes are stored in the MIL.BENEFITS record of the ST.VALCODES file.

Military Veteran Remark Codes

The Military Veteran Remark codes denote the source of remarks made. For example, this could include remarks recorded by a staff member.

Use the Validation Codes (VAL) form to define military benefit eligibility codes. The codes are stored in the MIL.VET.REMARK.CODES record of the ST.VALCODES file.

Military Veteran Remark Types

The Military Veteran Remark Types codes are the types of remarks that are attached to a students who is an active military servicemember or veteran, or a spouse or dependent of an active military servicemember or veteran.

These are codes to allow reporting by remark types.

Use the Validation Codes (VAL) form to define military veteran remark type codes. The codes are stored in the MIL.VET.REMARK.TYPES record of the ST.VALCODES file.

Minorities

Minorities codes describe individuals as either an ethnic, financial, or both an ethnic and financial minority. These codes are used on the Medical Application (MDAP) form.

Minorities codes are stored in the MINORITIES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Minors

Minors codes describe the minors offered at your institution. After you create a requirement, you can identify it as a minor using one of the minor codes you defined. For example, you could create a requirement that a student must complete 30 credits in Math and identify the requirement as a math minor.


Ge

Minors codes are defined on the Minors (MINR) form. These codes are stored in the MINORS file.

Miscellaneous Admissions Codes

Miscellaneous admissions codes let you define up to five codes that you can use for any purpose. Once you have defined these codes you can associate them with any application. Although Colleague does not directly use these fields, you can use this information for writing rules or for reporting or querying purposes.

Use the Validation Codes (VAL) form to define miscellaneous admissions codes. These codes are stored in the ST.VALCODES file as ADM.MISC1 through ADM.MISC5.

You assign these codes to an applicant on the Applicant Miscellaneous (AMSC) form.

Multiple Reporting Request Codes

Multiple reporting request codes are used to construct Multiple Reporting Request (MRRs) by the Pell Export (PLEX) form.

Multiple reporting request codes are stored in the FA.MRR.REQUEST.CODE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Name/Titles

Name/title codes indicate a person’s gender on the Application Demographics (FADD) form.

Name/titles codes are stored in the NAME/TITLES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

Non-AR Receipt Codes

Before You Begin

Before you can define your non-AR receipt codes, you should define the following:

Understanding Non-AR Receipt Codes

Use non-AR receipt codes to identify the receipt of money for any item not associated with

an AR account, such as grant money or daily receipts from the library or parking office.1

Each non-AR receipt code is associated with one or more general ledger account numbers. When receipts are distributed across more than one GL number, you must define either the percentage of the distribution (the total distribution must equal 100 percent) or the amount of each distribution (and the total of all amounts represents the total charge).

Use the Non-AR Receipt Code (NARD) form to define non-AR receipt codes.

Table 68: Information Needed Before You Can Define Non- AR Receipt Codes

Item Reference

GL account numbers See the documentation for the General Ledger module

Office codes1

1.Optional.

Using Demographics

1.You could record library and parking fines as accounts receivable items and then process the payments as standard payments against an account.


Ge

Figure 11: Example of a Non-AR Receipt Code

Noncourse Categories

Noncourse category codes identify the different types of noncourse work your institution recognizes. Examples of noncourse category codes include:

• AM – admissions test

• PL – placement test

• LF – life experience

When you define the categories you use for any test, you identify for Colleague—through the noncourse category code—whether the test is an admissions test, a placement test, or another type of test. You make this distinction by using the appropriate special processing codes for the noncourse category codes:

• A – admissions tests

• P – placement tests

• T – other tests

If a noncourse category code does not use one of the three special processing codes, Colleague identifies any noncourse associated with that category as something other than a test.

When you enter an individual’s noncourse work, Colleague displays either the Test Scores (TEST) form or the Noncourse Work (NCRS) form based on the special processing code.


Ge

Colleague also uses these special processing codes to appropriately categorize tests on the Test Summary (TSUM) form.

Use the Validation Codes (VAL) form to define noncourse category codes. These codes are stored in the NON.COURSE.CATEGORIES record of the ST.VALCODES file.

Noncourse Factors

Noncourse factors identify different circumstances that may have occurred when an individual took a noncourse item, particularly a test. For example, you could have a code that indicates a fire drill and use this code if a fire drill occurred while someone was taking a test such as the SAT.

Use the Validation Codes (VAL) form to define noncourse factor codes. These codes are stored in the NON.COURSE.FACTORS record of the ST.VALCODES file.

Noncourse Grade Usage Types

Noncourse grade usage type codes identify how Colleague will treat the grades or scores an individual receives for a noncourse when that individual has multiple occurrences of the same noncourse. Valid noncourse grade usage types are

You associate these codes with each noncourse item that you define on the Noncourses (NONC) form. Colleague uses these codes to set the status of each noncourse recorded for an individual.

Noncourse grade usage type codes are stored in the NON.COURSE.GRADE.USES record name of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

See “Student Noncourse Statuses” on page 277 for more information on how noncourse grade usage codes are used in evaluating student academic credits.

Table 69: Noncourse Grade Usage Type Codes

Noncourse Grade Usage Types

Indicates that Colleague should use the…

LAST most recent grade/score

BEST best grade/score

SUB best subcomponent grade/score


Ge

Noncourse Types

Noncourse types identify each kind of noncourse item. Noncourse types include “tests,” “community work,” “life experience,” and “portfolio.”

Use the Validation Codes (VAL) form to define noncourse types. These code are stored in the NON.COURSE.TYPES record of the ST.VALCODES file.

Note Codes

Note codes designate standardized note texts which a staff member might assign to a student. These notes can be printed on a transcript or grade report.

Examples of note codes are:

• UNSAT – Unsatisfactory

• FAM – Family problems

• CONAD – Contact advisor

Use the Note Codes (NOTC) form to define note codes. These codes are stored in the NOTE.CODES file.

Other Restriction Codes

Other restriction codes identify manual restrictions that can be assigned to courses or sections, then used as evaluation factors in rules.

Use the Other Restrictions Codes (ORES) form to define other restriction codes. These codes are stored in the OTHER.RESTRICT.CODES file.


Ge

Packaging Groups

Packaging group codes are used to group together students for automatic packaging. Use the Packaging Group Rules (PGRL) form to define a rule table or a subroutine that assigns a packaging group code to a student. Examples of packaging groups include:

Use the Validation Codes (VAL) form to define packaging group codes. These codes are stored in the PACKAGE.GROUPS record of the ST.VALCODES file.

Parents In College

Parents in college codes are used on the Parent Info (PPI#) form to indicate whether one, both, or neither of a student’s parents are in college for FAFSA processing. The following codes are defined:

• 0 Neither

• 1 One Parent

• 2 Both Parents

Parents in college codes are stored in the PARENTS.IN.COLLEGE record of the ST.VALCODES file. You should modify these codes only with the assistance of an Ellucian representative.

Table 70: Examples of Packaging Group Codes

Packaging Group Code Description

NEWFR New First Time Freshmen

NEWTR New Transfer Student

RETUG Returning Undergraduate

GRAD Graduate (New or Return)

CE Continuing Education


Ge

Pell Attended Campuses

Attended campus Pell institution number codes are used to indicate the Pell institution number of the campus attended by a student. Examples of attended campus Pell institution number codes include:

Use the Validation Codes (VAL) form to define attended campus Pell institution number codes. These codes are stored in the ATTENDED.CAMPUSES record of the ST.VALCODES file.

Pell Enrollment Statuses

Pell enrollment status codes are used to describe the current enrollment status of a student for the purpose of Pell payment data reporting. Pell enrollment status codes include:

Pell enrollment status codes are stored in the PELL.ENRL.STAT record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. Do not modify these codes without the assistance of an Ellucian representative.

Table 71: Examples of Attended Campus Pell Institution Number Codes

Attended Campus Pell Institution Number Code Description

003409 Ellucian University — Fairfax

006533 Ellucian University — San Francisco

Table 72: Pell Enrollment Status Codes

Pell Enrollment Status Code Description

1 Full-time

2 Half-time

3 3/4 time

4 Other

5 Less than 1/2 time


Ge

Pell Entitlement Options

Pell entitlement options are used to indicate the methodology to be used by the Pell grant entitlement subroutine when calculating the Pell entitlement. Pell entitlement options are:

Pell entitlement option codes are stored in the PELL.ENT.OPTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Pell Payment Methodology Codes

Pell payment methodology codes are used to describe the payment methodology used to calculate a student’s Federal Pell Grant. Pell payment methodology codes include:

Pell payment methodology codes are stored in the PELL.PAY.METHOD record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. Do not modify these codes without the assistance of an Ellucian representative.

Table 73: Pell Entitlement Option Codes

Pell Entitlement Option Code Description

1 Full Funding

2 Scheduled Reduction

3 Full Funding/Flat Reduction

4 Pell Ratable Reduction

5 Linear Scheduled Reduction

Table 74: Pell Payment Methodology Codes

Pell Payment Methodology Code Description

1 Formula 1

2 Formula 2

3 Formula 3

4 Formula 4

5 Formula 5


Ge

Pell Reconciliation Verification Status

Pell reconciliation verification status codes are used on the Pell Reconciliation Inquiry (PERI) form to indicate the student’s Pell verification status. The following codes are defined:

• A —Accurate

• C —Calculated

• N — Not Selected for Verif

• R — Reprocessed

• S — Selected,30% or not QAP

• T — Tolerance

• V — Verified

• W — Without Documentation

These codes are stored in the PELL.RECON.VERIF.STAT.2002 record of the ST.VALCODES file and should be modified only with the assistance of an Ellucian representative.

Person Tax Statuses

Person tax status codes identify any specific tax status that you want to keep track of. “Exempt” is an example of a person tax status.

Person tax status codes are maintained on the Validation Codes (VAL) form. These codes are stored in the PERSON.TAX.STATUSES record of the ST.VALCODES file.

After you have defined person tax status codes, you can associate them with any AR account holder using the AR Accountholders (ARAC) form.

Petition Statuses

Petition status codes are used to define the status of each petition on a student’s record. These petitions are used to grant the student permission to enroll in certain courses, such as overload courses, and in course sections that require an instructor’s consent. These codes are assigned to students using the Student Petitions (STPE) form. See Using Registration for more information.

Use the Petition Statuses (PTST) form, shown in Figure 12 on page 250, to define petition status codes. They are stored in the PETITION.STATUSES file.


Ge

Figure 12: Example of the Petition Statuses (PTST) Form

Each petition status you define must have the following components:

• Description

• Delete overload

• Petition granted

Delete Overload. You may want the petition status to be removed from the student’s petition record for the term if the student drops below overload status. This can be used to allow a student to carry an overload based on one scenario, but the student’s schedule is to be re-evaluated if the student goes from overload back to regular load and then wants to go to overload again.

If you set this parameter to “Yes,” and the student drops back to a non-overload condition, the overload petition status for the term will be nulled out so the student cannot go into overload status again without permission. If you set this parameter to “No,” the status will stay on the student’s record and allow overload registration.

Colleague uses this parameter to control whether a student can register for courses that cause an overload.

Petition Granted. If you want Colleague to consider a petition status as valid, then set this parameter to “Yes.” When a petition status with this parameter set to “Yes” is assigned to a student, it means the petition was granted to the student.

For example, a status of “Pending” would have this parameter set to “No.” When the “Pending” status was assigned to a student’s term overload petition, that student would not be allowed to register for a course that will cause him to be in overload. A status of “Approved would have this parameter set to “Yes.” If the “Approved” status was assigned to the student’s term overload petition, the student would then be allowed to register for overload courses.


Ge

If a student has a petition status with this parameter set to “No,” Colleague will not allow the student to register for certain courses. If a course section requires a petition or instructor consent, the student must have a petition status with this parameter set to “Yes” before he can register for the course section.

Profile Parent Marital Statuses

Profile parent marital statuses codes are used on the Parent Information (PPI#) form to indicate the parent marital status for FAFSA processing. The following codes are defined:

• 1 Never Married

• 2 Married/Remarried

• 3 Separated

• 4 Divorced

• 5 Widowed

Profile parent marital statuses codes are stored in the PROFILE.PAR.MARITAL.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Program Designations

The Program Designations codes describe which academic programs are VA programs so that the institution can use Colleague to identify this information and so that other processes in Colleague can use the distinction to help with compliance. The codes also designate which programs are Department of Education Title IV Funded.

Special processing 1 contains a VA or an FA code to designate if this applies to VA Student Processes or Financial Aid Processes.

Use the Validation Codes (VAL) form to define program designations codes. The codes are stored in the PROGRAM.DESIGNATIONS record of the ST.VALCODES file.

Program Statuses

Program status codes define the status of academic programs offered at your institution (for example, active, inactive, pending, or obsolete).

Use the Validation Codes (VAL) form to maintain program status codes. Program status codes are stored in the PROGRAM.STATUSES record of the ST.VALCODES file.


Ge

Prospect Status Codes

Prospect status codes identify where a prospect is in the admissions process. Examples of prospect status codes include:

• INQ – Inquiry

• SER – Serious

Use the Validation Codes (VAL) form to define prospect status codes. These codes are stored in the PROSPECT.STATUSES record of the ST.VALCODES file.

Recipient

Recipient codes identify agencies that are designated to receive electronic loan files. The recipient of electronic application data can be a lender, guarantor, or other service provider. For the guarantor, the recipient ID is a three-digit number assigned by the National Council of Higher Education Loan Programs (NCHELP). For lenders and service providers, the recipient ID is the six-digit number assigned by the US Department of Education.

Create a recipient record for each potential recipient of electronic application data—even if you have already created a guarantor or lender record on the Loan Guarantor (GUAR) or Lending Inst Definition (LID) form.

Receipt Reversal Reasons

Receipt reversal reason codes describe why a cash receipt was reversed. Examples of receipt reversal reason codes are:

• NSF – non-sufficient funds

• AMT – amount error

• CCR – Recommendation Types

Recommendation Types

As part of the admissions process at your institution, you may require that an applicant submit a specified number of letters of reference or recommendation (referred to herein as “recommendations”). These recommendations can come from a wide variety of people, for example, family friends, clergy, high school guidance counselors, community leaders, employers, alumni, and faculty.


Ge

A recommendation type is a code to categorize recommendations received by any individual for whom you do not want to create a PERSON record.

When you record the receipt of recommendations you may want to capture certain information about them. For example, you may want to record the name of the individual who sent the recommendation. In Colleague, however, recording an individual’s name is associated with creating a record for that individual in the PERSON file. But with recommendations, you may not want to create that record. If you do not expect to receive other recommendations from the person providing the recommendation, or if you do not expect to correspond with the person in any way, you would use recommendation type codes.

Use the Recommendation Type (RECT) form to define recommendation type codes. These codes are stored in the RECOMMENDATION.TYPES file.

Using Recommendation Types

For example, some of the recommendation type codes at Ellucian University are:

• Personal

• Clergy

• Professional

• Alumni

• Relative

When an applicant submits a letter of recommendation from a family friend, the admissions office uses the personal recommendation type when recording the recommendation (Figure 13).


Ge

Figure 13: Applicant Reference/Appointments (REFA) form

When an applicant submits a letter of recommendation from someone such as a faculty member or other individual currently on the PERSON file, or someone such as a high school guidance counselor who may not presently be on the PERSON file but about whom Ellucian University wants to record information, this letter of recommendation is recorded as a reference (Figure 13).

Recruitment Purposes

Recruitment purpose codes identify the reason why you recruited a specific applicant. Examples of recruitment purpose codes include:

• FTBL – Football

• BASK – Basketball

• NMRT – National Merit Scholar

Use the Validation Codes (VAL) form to define recruitment purpose codes. These codes are stored in the RECRUIT.PURPOSES record of the ST.VALCODES file.

Refund Formulas

Refund formula codes describe how Colleague will return registration, room, or meal plan charges incurred by a student or other individual.


Ge

Refund formula codes are maintained on the Refund Formulas (REFF) form. These codes are stored in the REFUND.FORMULAS file.

See “Defining Registration Refunds” on page 478 for complete details about defining and using refund formulas.

Refund Portion Codes

Refund portion codes identify whether a refund is calculated based on the full or unused portion of the charge. Colleague is defined with two refund portion codes: “F” for full and “U” for unused. You cannot add other codes.

Refund portion codes are stored in the REFUND.PORTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Registration Audit Selection

Registration audit selection codes are used to indicate whether audit credits should be included in the calculation of registered credits for financial aid purposes. Registration audit selection codes are:

Registration audit selection codes are stored in the REG.AUDIT.SELECTION record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Registration Billing Rate Fields

Registration billing rate fields identify the complete set of Colleague data elements you use to create unique groups of billing characteristics for registration billing. For example, if your tuition billing is determined by a student’s residency status (for example, in-state), academic level (for example, undergraduate), and student type (for example, athlete), then residency status, academic level, and student type are the data elements that define

Table 75: Registration Audit Selection Codes

Registration Audit Selection Code Description

AUDIT Audit Only

NONAUDIT Exclude Audit

ALL All Courses


Ge

your registration billing rate fields. Define specific registration rate tables for each unique combination of these data elements that you use for billing purposes. For example, you might have one registration rate table for in-state undergraduates, another for out-of-state undergraduates, and so forth.

Registration billing rate fields are maintained on the Registration Rate Billing Fields (RRBF) form. These codes are stored in the REG.RATE.FIELDS file.

See “Defining Student Billing Characteristics” on page 495 for complete details about defining registration billing rate fields.

Registration Controls

Registration control codes are sets of parameters that define the different types of registration available to students. Each control code can have a unique combination of registration rules and checks. For example, for arena-type registration you may have one set of registration lines for undergraduates and another for graduates. The operators working in the undergraduate registration lines would use the registration controls that limit the registration to undergraduate students. Another use for the registration controls is to limit the courses offered for registration at one campus while allowing students at the main campus to register for all course, regardless of where they are taught.

After you have defined your registration control codes, you assign these registration control codes to groups of staff members who register students. You can assign multiple registration control codes to one group, but each staff member must select a single control to use during a particular registration session. You can define registration users with authority to override many of the checks you establish with registration control codes.

If a staff member enters a registration session without an assigned registration control code, Colleague will assign her the default control code “Nameless.” Ellucian delivers this “Nameless” record with Colleague.

Registration control codes are maintained on the Registration Controls (RGCT) form. These codes are stored in the REG.CONTROLS file.

See “Understanding Registration Controls” on page 805 for more information about defining your registration controls.

Registration Process Periods

Registration process period codes describe the various times during which an individual can register for courses and determine when various types of registration processing can be done. The actual dates for these time periods are defined for each academic term. The term dates default into new course sections, but can be modified, as appropriate.

When you define your registration controls, you can choose during which registration process periods Colleague should evaluate each eligibility rule and registration check.


Ge

The available registration process codes are:

Preregistration, Registration, and Add/drop process periods are used with term based courses. The Other process period is used with non-term based courses.

These codes are stored in the REG.TIME.PERIODS of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Registration Rate Tables

Registration rate tables define each unique set of billing characteristics that determine your different registration billing scenarios. For example, if an in-state undergraduate is billed at a different rate than an out-of-state undergraduate, define one registration rate table for each of these groups of students. Each registration rate table describes who Colleague bills by that table (the billing characteristics), and the following other information, as applicable:

• Tuition rates

• Add, drop, and withdrawal policies

• Registration term rates

• Waiver policies

Registration rate tables are maintained on the Registration Rate Tables (RGRT) form. These codes are stored in the REG.RATE.TABLES file.

See “Defining a Registration Rate Table” on page 515 for complete information about registration rate tables.

Table 76: Registration Process Period Codes

Registration Process Periods Description

P Preregistration

R Registration

A Add/drop

O Other


Ge

Registration Refund Days to Exclude

Registration days to exclude codes identify the days that Colleagues excludes when calculating a specific refund. The valid options for this code are:

You identify the days to exclude from the refund calculation for each refund formula that you define.

Colleague lets you identify specific days as holidays for refund purposes only, but not necessarily for scheduling purposes. For example, you may not want to identify an Instructor Retreat day as a campus holiday for scheduling purposes, but you may want to exclude that day from your registration refund calculations.

Similarly, you may need to identify days as holidays but include them in your refund calculations. For example, you may want to identify Spring Break as a holiday for scheduling purposes, but still include those days when it comes to calculating registration refunds. You can also identify specific days as holidays for both scheduling purposes and refund purposes, such as Labor Day.

Colleague uses the second special processing code for CALENDAR.DAYS.TYPES to identify those days that should be excluded from refund calculations. For each day that you want Colleague to consider as a holiday for registration refund purposes, you need to enter HO in the second special processing code. See the Getting Started with the Core System manual for information about defining calendar day types.

Registration days to exclude codes are stored in the REG.REFUND.COUNT.EXCL.DAYS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Registration Refund Policies

Registration refund policies allow for the entry of rules-based billing refunds. You identify rules which are associated with specific refund formulas. If the rules evaluate to true when the registration billing process is run, the corresponding refund formula is used to calculate any refund due.

Registration refund policies are maintained on the Registration Refund Policy (RGRP) form. These codes are stored in the REG.REFUND.POLICIES file.

Table 77: Registration Refund Days to Exclude Codes

Registration Refund Days to Exclude Description

SA Saturday

SU Sunday

HO holidays


Ge

Registration Term Rate Tables

Registration term rate tables identify charges that you assess each registration period (such as term or session). Associate each term rate table with one or more registration rate table. When Colleague uses a registration rate table to calculate a student’s registration charges, if that rate table is associated with a term rate table, Colleague will assess charges from that term rate table. Examples of charges that are defined on a registration term rate table include health services fees and student union fees.

Registration term rate tables are maintained on the Registration Term Rate Tables (RTRT) form. These codes are stored in the REG.TERM.RATE.TABLES file.

See “Defining Registration Term Rates” on page 518 for complete information about registration rate tables.

Relation Codes

Relation codes indicate a person’s family relationship to the student. Examples include, parent, stepparent, sibling, and spouse.

Relation codes are stored in the RELATION.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Repeat Grade Use Codes

Repeat grade use codes indicate which instance of a repeated course Colleague should use in calculating GPA. These codes have been predefined by Colleague and you do not have to set them up.

The repeat grade use codes are:

Table 78: Repeat Grade Use Codes

Repeat Grade Use CodesIndicates that Colleague should use the…

BEST best grade received for the course

LAST grade for the course taken most recently

AVG average of all grades for this course

CUST custom subroutine defining grade usage


Ge

If you want to use a custom subroutine to evaluate repeat courses, then use the repeat grade use code “Cust” for Custom. When this code is used then a custom subroutine must be defined and used for properly handling of repeat courses.

Repeat grade use codes are stored in the REPEAT.GRADE.USES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Replacement Codes

If a student repeats a course, Colleague will mark the previous instances of the course in the student’s record with a replacement code of “R.” This will be done to indicate which courses Colleague should not use when calculating a student’s grade point average, credits attempted, or credits completed.

If a student has taken the same course more than once, all but one instance will have a replacement code. Colleague uses only one instance of a course when calculating a student’s GPA.

A value of “R” must always be in this code table since that is the replacement code Colleague assigns to a replaced course. However, you can add other codes as you decide they are necessary. You can then manually assign these codes to a student’s record. Colleague only considers courses without a replacement code in GPA calculations.

Examples of replacement codes are:

• R – Replaced by Colleague (required for processing)

• M – Manual

Use the Validation Codes (VAL) form to define replacement codes. These codes are stored in the REPLACEMENT.CODES record of the ST.VALCODES file.

Requisite Waiver Reasons

The Requisite Waiver Reason codes identify why a requisite waiver was granted or denied.

Any code that has special processing code of 1 requires entry of associated comments in order to create the waiver.

Use the Validation Codes (VAL) form to define requisite waiver reason codes. These codes are stored in the REQUISITE.WAIVER.REASONS record of the ST.VALCODES file.


Ge

Residency Statuses

Residency status codes identify the residency of a student. These codes are not used directly by Colleague, but you can define billing rules which reference them.

Examples of residency status codes are:

Use the Residency Statuses (RSST) form to define residency status codes. These codes are stored in the RESIDENCY.STATUSES file.

Restrict Connectors

Restrict connector codes are used to indicate the rule logic to be applied to the rule tables for global award eligibility criteria, award eligibility criteria, and student eligibility criteria. Restrict connector codes are:

Restrict connector codes are stored in the RESTRICT.CONNECTORS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 79: Examples of Residency Statuses

Examples of Residency Status Codes Description

INST In state

OUTST Out of state

COM Commuter

FORGN Foreign

Table 80: Restrict Connector Codes

Restrict Connector Code Description Detailed Description

A AND The financial aid applicant satisfies the eligibility criteria only if Colleague evaluates all rules in the eligibility rule table as true.

O OR The financial aid applicant satisfies the eligibility criteria if Colleague evaluates at least one rule in the eligibility rule table as true.


Ge

Restriction Codes

Restriction codes describe various restrictions or holds your institution can place on a student’s record. For example, these restrictions may be for parking or library violations. Colleague uses rules you define when evaluating these assigned codes to decide whether or not certain processing should be allowed. For example, your institution might decide to not release a transcript to a student with a parking restriction code on his record.

You can assign a numerical severity to each restriction code as you define it. This severity and your office code will automatically default into a student’s record if this restriction code is assigned. The severity may be changed at the time of assignment. Once a restriction code has been assigned to a student, only someone with the same office code as the assigning office can remove it.

Use the Restriction Codes (REST) form to define restriction codes. These codes are stored in the RESTRICTIONS file.

See “Procedure for Defining Academic Records Parameters” on page 358 for more information on setting the rules associated with these restriction codes. See Using Academic Records for more information on entering restriction codes into a student’s record.

Return of Funds Institutional Charges

Return of funds institutional changes codes identify the AR categories and/or codes that represent institutional charges at your institution. The institutional charges that you define using the Define ROF AR Code/Category (DRAC) form are processed when you use the Calculate Return of Funds (ROFC) form to process a student who has withdrawn from your institution. Examples of institutional charges include such charges as tuition and fees, room and board, books, and others.

Use the Define ROF AR Code/Category (DRAC) form to define institutional charges at your institution for return of funds processing. Return of funds institutional charges codes are stored in the ROF.INST.CHARGES file.

Return of Funds Title IV Categories

Return of funds Title IV category codes are delivered by Ellucian and identify and prioritize Title IV awards as specified by federal regulations for the return of funds calculation.

For the delivered FSEOG category, you must specify on the Title IV Category Maintenance (TLCM) form the method your institution uses to match FSEOG funds. You can also use the TLCM form to maintain Title IV codes to reflect federal changes.


Ge

Use the Title IV Category Maintenance (TLCM) form to specify your institution’s FSEOG matching method and to maintain delivered codes to reflect federal changes. Return of funds Title IV category codes are stored in the TIV.CATEGORIES file.

Reversal Types

Reversal type codes describe each type of cash receipt reversal. Valid reversal type codes are:

Reversal type codes are stored in the RCPT.REVERSAL.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Roles

Role codes identify positions members may hold within an organization, for example, chairman or president.

Use the Roles (ROLE) form to define roles at your institution. Role codes are stored in the ROLES file.

Room Assignment Statuses

Room assignment status codes identify statuses for room assignments (for example, active, canceled, or temporary). Colleague refers to the room assignment status to determine billing information, including refunds.

Use the Validation Codes (VAL) form to define room assignment status codes Room assignment codes are stored in the ROOM.ASSIGN.STATUSES record of the ST.VALCODES file.

Table 81: Reversal Type Codes

Reversal Type Codes Description

C correct cash receipt

R reverse cash receipt

N non-sufficient funds


Ge

Room Rate Periods

Room rate period codes describe the billing period for room rentals. Valid room rate periods include:

• D – Daily

• W – Weekly

• M – Monthly

• Y – Yearly

• T – by Term

Use the Validation Code (VAL) form to define room rate period codes. Room rate period codes are stored on the ROOM.RATE.PERIODS record of the ST.VALCODES file.

Room Wings

Room wings codes represent the wings of buildings at your institution such as East wing, or the George Washington wing.

Use the Validation Codes (VAL) form to define room wings codes. The room wings codes are stored in the ROOM.WINGS record of the CORE.VALCODES file.

Roommate Characteristics

Roommate characteristics codes represent characteristics of a person (for example, nonsmoker, male, female, major) for roommate matching.

Use the Validation Codes (VAL) form to define roommate characteristic codes. The roommate characteristics codes are stored in the ROOMMATE.CHARACTERISTICS record of the ST.VALCODES file.


Ge

Rounding Rules

Rounding rule codes are used to indicate how annual award amounts should be rounded during automatic packaging. Rounding rule codes are:

Rounding rule codes are stored in the ROUNDING.RULES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Rule Process Flags

Rule process flag codes are used to indicate the rule logic to be applied to the budget duration rule table defined on the Budget Duration Rule (BDRL) form. Rule process flag codes are:

Rule process flag codes are stored in the RULE.PROCESS.FLAGS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 82: Rounding Rule Codes

Rounding Rule Code Description Detailed Description

H Higher Colleague rounds up. For example, Colleague will round $300.01 to $301.00.

L Lower Colleague rounds down. For example, Colleague will round $300.99 to $300.00.

C Closest Colleague rounds to the nearest unit. For example, Colleague will round $300.49 to $300.00 and $300.50 to $301.00.

Table 83: Rule Process Flag Codes

Rule Process Flag Code Description Detailed Description

C Cumulative Colleague evaluates each rule in the budget duration rule table. The result of each true rule will contribute to the budget duration for the financial aid applicant.

F First Valid Colleague evaluates the budget duration rule table up to the first true rule. The result of first true rule will be the budget duration for the financial aid applicant.


Ge

Rule Table Types

Rule table type codes are used to indicate the type of rule table record stored in the RULE.TABLE.ACYR file. Each type of rule table is maintained on its own form. The rule table type code restricts the rule table records that are available at a particular LookUp prompt.

For example, all rules created on the Packaging Percent Rules (PCTR) form will have a PCT rule table type code. The File Resolution form for the Rule Table LookUp from fields which require a percent rule table ID will display only rule tables with the PCT rule table type code.

Rule table types are:

Rule table type codes are stored in the RT.TYPES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Rural Indicator Codes

Rural indicator codes identify an individual’s residence as being either rural or non-rural. Valid codes are “R” for rural and “N” for non-rural. Use rural indicators when recording a medical school application on the Medical Application (MDAP) form.

Rural indicator codes are stored in the RURAL.INDICATORS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Table 84: Rule Table Type Codes

Rule Table Type Code Description

AMT Amount

ATP Attendance Pattern

CBI CB/Inst

ELIG Eligibility

PCT Percent

PKG Package Groups

YEAR Year in College

CRT Calc Result Type

LOC Location

PKDF Package Definition


Ge

SAP Appeal Action Codes

Satisfactory academic progress (SAP) appeal action codes are used to indicate an event in the SAP appeal process. Examples of SAP appeal action codes include:

SAP appeal action codes are defined on the SAP Appeal Action Codes (SPAC) form. These codes are stored in the SAP.APPEALS.CODES file.

SAP Report Options

Satisfactory academic progress (SAP) report option codes are used to indicate the type of audit report produced by the Batch SAP Calculation (SAPC) process. SAP report option codes are:

Table 85: SAP Appeal Action Codes

SAP Appeal Action Code Description

STUDINIT Student Initiates Appeal

APPLGNTD Appeal Granted

APPLDEND Appeal Denied

SAPOVRP Override SAP Status to Probationary

SAPOVRS Override SAP Status to Satisfactory

RMVOVR Remove SAP Status Override

STUDCNCL Student Cancels Appeal

Table 86: SAP Report Option Codes

SAP Report Options Code Description

A All audit reports

N None

T Totals Page Only

TS Totals & Summary Pages

TD Totals & Detail Pages

S Summary Page Only

D Detail Pages only


Ge

SAP report option codes are stored in the SAP.RPT.OPTIONS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

SAP Statuses

Satisfactory academic progress (SAP) status codes are used to indicate the result of a SAP status calculation. Examples of SAP status codes include:

Use the Validation Codes (VAL) form to define SAP status codes. These codes are stored in the SAP.STATUSES record of the ST.VALCODES file.

SAP Type

Satisfactory academic progress (SAP) type codes are used to indicate the types of credits to be included in a SAP status calculation. See “SAP Statuses” on page 268 for information about SAP status codes.

Examples of SAP type codes include:

SAP type codes are defined on the SAP Type Definition (SPTD) form. These codes are stored in the SAP.TYPE file.

Table 87: Examples of SAP Status Codes

SAP Status Code Description

S Satisfactory

U Unsatisfactory

P Probationary

Table 88: Examples of SAP Type Codes

SAP Type Code Description

PELL Pell SAP Calc

CLRABRTN Clara Barton SAP Calc

MFA Masters of Fine Arts SAP Calc


Ge

Schedule Types

Schedule type codes define when courses are scheduled to meet, such as evening or daytime. Schedule type codes are defined on the Schedule Types (SCTY) form. These codes are stored in the SCHED.TYPES file.

Secondary School Subjects

Secondary school subject codes identify the academic subjects recorded from a secondary school transcript. Examples of secondary school subject codes include math, English, and social sciences.

Use the Validation Codes (VAL) form to define the secondary school subject codes. These codes are stored in the SECONDARY.SCHOOL.SUBJECTS record of the ST.VALCODES file.

Section Statuses

Section status codes define the status (for example, active or inactive) of individual course sections. Colleague refers to a section’s status when you register students for a section.

Use the Validation Codes (VAL) form to define section statuses. Section status codes are stored in the SECTION.STATUSES record of the ST.VALCODES file.

Self Description Codes

Self description codes identify how an applicant describes himself on his admissions application. Use self description codes when recording information about a medical school applicant on the Medical Applicant (MAPL) form. Examples of self-description codes include:

• AA – African American

• AI – American Indian

• Z – no response

Use the Validation Codes (VAL) form to define the self-description codes. These codes are stored in the SELF.DESCRIPTIONS record of the ST.VALCODES file.


Ge

Sessions

Sessions define the academic session offered at your institution. Examples of sessions include winter or summer. You use sessions, along with the year, to define each academic term. For example, the 97FA academic term is a combination of the 1997 academic year and the fall (FA) session.

Use the Sessions (SESS) form to define session codes. Session codes are stored in the SESSIONS file.

Session Cycles

Session cycle codes define the sessions when a course is offered. These codes are used to identify those courses offered only in fall or only in spring.

Use the Session Cycles (SECY) form to define session cycle codes. These codes are stored in the SESSION.CYCLES file.

Session Types

Session types identify the types of sessions under which academic programs can be offered. These types are used with Canadian statistical reports. These types use special processing to identify the unit of measurement for sessions so that the system can calculate the number of sessions a student has completed in an academic program, as follows:

If a session types does not have a special processing code assigned, then the system cannot determine the number of sessions completed.

Use the Validation Codes (VAL) form to define session types. These codes are stored in the SESSION.TYPES record of the ST.VALCODES file.

Table 89: Special Processing Codes for Session Types

Special Processing Code Description

1 Calendar year

2 Calendar months

3 Academic year

4 Semester

5 Trimester

6 Summer session


Ge

SOC Service Programs

The SOC Service Program codes describes the SOC Service Programs. A Service Program is used in the SOC agreements to determine the DNS Network for the students program of study as well as listed on the SOC agreement.

SOC is Servicemember Opportunity Colleges, and may be applicable to active military, their spouses, or dependents.

Use the Validation Codes (VAL) form to define SOC service program codes. The codes are stored in the SOC.SERVCE.PROGRAMS record of the ST.VALCODES file.

SOC Branches of Service

The SOC Branches of Services codes describes the list of possible values for the Branch of Service (or “Family”) field on the SOC Student Agreement.

If you modify this validation code table, and should do so to add any new values that would be valid in the Branch of Service (or “Family”) field on the SOC Student Agreement.

The following are the Special Processing Code 1 values that can used:

• A - Army

• AG - Army National Guard

• N - Navy

• M - Marine Corps

• CG - Coast Guard

• AF - Army Family

• NF - Navy Family

• MCF - Marine Corps Family

• CGF - Coast Guard Family

• O - Other

Use the Validation Codes (VAL) form to define SOC branch of service codes. The codes are stored in the SOC.BRANCHES.OF.SERVICE record of the ST.VALCODES file.


Ge

SOC Credit Types

The SOC Credit Types codes describes the Service Members Opportunity College (SOC) credit types used by the SOC agreement. This categorizes each course into specific columns on the SOC agreement as Transfer, MOS, etc.

Use the Validation Codes (VAL) form to define SOC credit type codes. The codes are stored in the SOC.CREDIT.TYPES record of the ST.VALCODES file. You should modify these codes only with the assistance of an Ellucian representative.

SOC Networks

The SOC Network codes describes the Servicemembers Opportunity College Degree (SOC) Degree Network values which varies between branch of service. The table is used on the Academic Program form and stored in the ACAD.PROGRAMS record as an association with the branch of service as the controller.

Use the Validation Codes (VAL) form to define SOC network codes. The codes are stored in the SOC.NETWORKS record of the ST.VALCODES file.

Sort Graduate Codes

Sort Graduate Codes identify the possible primary sorting options for graduates during final graduation auditing.

Use the Validation Codes (VAL) form to define sort graduate codes. These codes are stored in the SORT.GRADS record of the ST.VALCODES file.

Special Services Needed Codes

Special services needed codes identify the source of a student’s special service and whether or not the service was determined to be needed. These codes are used with the California Community Colleges MIS Reporting functions.

Use the Validation Codes (VAL) form to define special services needed codes. These codes are stored in the SPECIAL.SERVICES.NEED.CODES record of the ST.VALCODES file.


Ge

Specializations

This file contains the codes defining the areas of academic specializations. After you create a requirement, you can identify the requirement as a specialization using one of the specialization codes you defined.

Use the Specializations (SPEC) form to define specialization codes. Specialization codes are stored in the SPECIALIZATIONS file.

Sponsorship Statuses

Sponsorship status codes define the current status of either a sponsored course section or a sponsored student. You can have as many different sponsorship statuses that you need, but you must have at least four status codes that use the following special processing codes:

Sponsorship status codes are defined on the Validation Code (VAL) form. These codes are stored in the SPONSORSHIP.STATUSES record of the ST.VALCODES file.

See Using Accounts Receivable/Cash Receipts for more information about using sponsorship status codes. See Archiving AR Transactions for more information about archiving sponsorship transactions.

Table 90: Special Processing Codes for Sponsorship Statuses

Processing Code Description

1 Use this special processing code to indicate that the sponsorship has an ”Open” status. You can continue to modify the sponsorship, including adding students to the sponsorship and processing charges against the sponsorship.

2 Use this special processing code to indicate that the sponsorship has a “Frozen” status. You cannot modify the sponsorship or add students. You can, however, continue to process charges against a frozen sponsorship and record payments against outstanding sponsorship statements.

3 Use this special processing code to indicate that the sponsorship has a “Closed” status. You cannot modify the sponsorship, add students to the sponsorship, or process charges against the sponsorship. You can, however, record payments against outstanding sponsorship statements.

4 Use this special processing code to indicate that the sponsorship has a “Archived” status. The sponsorship’s invoices and payment transactions have been archived using the Archive AR Transactions (ARCV) process.


Ge

Staff Room Assignment Codes

Staff room assignment codes represent room assignment records for staff members.

Staff room assignment codes are defined on the Validation Code (VAL) form. These codes are stored in the ROOM.ASSIGN.STAFF.CODES record of the ST.VALCODES file.

State Report Period Name Codes

State report period name codes identify alpha descriptions of the start reporting period numbers to include on printed reports. These codes are used with the Texas state reporting options.

Use the Validation Codes (VAL) form to define state report period name codes. These codes are stored in the STATE.REPORT.PERIOD.NAMES record of the ST.VALCODES file.

State Report Codes

State report codes are used to validate Texas state report names and to provide report descriptions for form displays. These codes use special processing to identify the type of work file used for these reports, as follows:

Use the Validation Codes (VAL) form to define state report codes. These codes are stored in the STATE.REPORTS record of the ST.VALCODES file.

Student Academic Credit Statuses

Student academic credit status codes identify the status of an individual’s course credits, such as new, added, dropped, withdrawn, deleted, or cancelled. Colleague uses these status codes to determine whether to include the credit in GPA calculations and how to grade and bill the course.

Table 91: Special Processing for State Report Codes

Special Processing Code Description

1 COURSE work file

2 STUDENT work file


Ge

Student academic credit status codes also classify transfer equivalencies (either course or noncourse), such as “PR” for preliminary equivalency evaluation. Colleague uses these status codes to control whether the equivalency should be in preliminary status so that someone can review it or in final status so that it can be used for transcripts, GPA calculations, or in the Degree Audit module.

Some of the student academic credit status codes have special processing codes associated with them that tell Colleague when to do specific things. For example, when registering for a course during regular registration, Colleague will assign whatever status code is associated with the special processing code 1. When checking academic requirements or requisites for a course, Colleague will consider only the student’s credits that have a special processing code 1, 2, and 7. When checking academic requirements for Degree Audit, Colleague will additionally consider special processing code 8.

Colleague also uses the special processing codes in the default determination of student term statuses. If the student term status is not rules-based, then the special processing codes associated with student academic credit status codes affect the default setting of the academic term status.

Table 92 shows the special processing codes, when these statuses are assigned, and in what totals these credits can be included.

Table 92: Student Academic Credit Status Special Processing Codes

Special Processing Code Assigned When …

Credits Can Be Included

in These Totals1

1 a course is added during the preregistration or registration process period

• registered credit counts

• attempted credit counts

• completed credit counts

2 a course is added during the add/drop registration process period

• registered credit counts



3 a course is dropped during add/drop registration process period



4 all active courses are withdrawn • attempted credit counts


5 a course was dropped during registration

(used for historical purposes only)

6 a course cancelled by the institution (used for historical purposes only)

7 a course is an approved equivalency • attempted credit counts



Ge

You can add statuses without special processing codes attached, as desired. Colleague will ignore credits with these statuses when a specific special processing code is being processed.

Use the Validation Codes (VAL) form to define student academic credit status codes. These codes are stored in the STUDENT.ACAD.CRED.STATUSES record of the ST.VALCODES file.

See “Student Term Statuses” on page 280 for further explanation of student term status codes.

Student Academic Credit Status Reasons

Student academic credit status reasons identify the reason for a change in a student’s academic credit status, such as why a student may have dropped a course.

Use the Validation Codes (VAL) form to maintain your student academic credit status reason codes. These codes are stored in the STUDENT.ACAD.CRED.STATUS.REASONS record of the ST.VALCODES file.

Student Load Codes

Student load codes describe the academic load of a student for a particular academic term. You can define student load rules that Colleague will evaluate at registration to determine which code to assign to a student.

If a student has a code of “Overload,” the student will need a petition to be allowed to register for the extra courses.

If you do not set up specific rules defining student load for each academic level, Colleague uses the special processing codes associated with the student load codes to assign them.

8

(Used in Degree Audit

Only)

a course is a preliminary equivalency • attempted credit counts

1.Credits with this status are available for inclusion in these credit totals. But depending upon the associated grade and credit type they might not be included in attempted or completed credit totals.

Table 92: Student Academic Credit Status Special Processing Codes (continued)

Special Processing Code Assigned When …

Credits Can Be Included

in These Totals1


Ge

Table 96 on page 281 shows examples of student load codes, associated special processing codes, and how Colleague applies them.

Use the Validation Codes (VAL) form to define student load codes. These codes are stored in the STUDENT.LOADS record of the ST.VALCODES file.

See “Student Load Rules” on page 350 for more information about defining your student load rules.

Student Miscellaneous Codes

You can define ten separate student miscellaneous code tables. These codes can be defined to meet your institution’s individual needs. Colleague will not use these codes directly, but you can define rules based on them.

Enter these codes on the Student Miscellaneous (STMC) form. If you want to enter free-form information in these fields, define the first ‘code’ in each of the tables as three asterisks, “***”.

Use the Validation Codes (VAL) form to define student miscellaneous codes. There are ten separate records for these codes. They are stored in the STU.MISC1 … STU.MISC10 records of the ST.VALCODES file.

Student Noncourse Statuses

Student noncourse statuses describe the status of noncourse work entries for a given student. Examples of student noncourse codes include “accepted,” “notational only,” “needs confirmation,” or “withdrawn.” You should associate at least one student noncourse

Table 93: Student Load Special Processing Codes

Special Processing Code Colleague will apply the code if a student …

1 is registered for less than full time.

2 is registered for full time.

3 is registered for more than full time.


Ge

status code with each of the special processing codes this code uses. Each of these special processing codes is described below.

Table 94: Student Noncourse Statuses

Processing Code Definition

1 Use this special processing code to identify the student noncourse status code which indicates the student has withdrawn from the institution. When a student withdraws, Colleague changes the status of any noncourse work that is in progress at that time to this status code. Noncourse work with this status code is not counted in the student’s academic credit.

2 Use this special processing code to identify the student noncourse status code which indicates the noncourse work you want Colleague to use when calculating the student’s academic credit. Colleague uses this status code when a student has multiple occurrences of the same noncourse item (for example, takes the SAT Math test twice). When you define each noncourse item, you indicate how Colleague should handle multiple occurrences of that noncourse item for one student (using the most recent grade, the best grade, or the best subcomponent associated with the noncourse item). The grade use values that can be assigned to noncourses are defined in the NON.COURSE.GRADE.USES validation code.

The student noncourse status codes with special processing codes of “2” and “3” are used together. If a student accumulates more than one student noncourse record for the same noncourse, Colleague looks at the Grade/Score to Use field (on the Noncourses [NONC] definition form) to determine which status to assign.

For example, Ellucian University defined the Math component of the SAT to take the best grade received. If an applicant reports multiple SAT scores, Colleague identifies the best Math score recorded for that applicant and assigns the occurrence of the noncourse item with the best score the status code associated with the “2” special processing code (the status with a special processing code of “2” might be called “Accepted”). At the same time, Colleague changes the status of the other (previous) instances of the same noncourse for the student to “3” (the status with a special processing code of “3” might be called “Notational”). In this way, previous instances of the noncourse are kept in the record for historical purposes but are not used to calculate a student’s academic credit.

3 Use this special processing code to identify the student noncourse status codes that indicate the noncourse work Colleague will not use when calculating the student’s academic credit when there are multiple occurrences of the same noncourse item. In the Ellucian University example described for processing code 2 above, Colleague assigns the status code with the “3” special processing code to the occurrences of the Math SAT that do not represent the individual’s best scores on the test.


Ge

You can use the status code fields as a means of calculating a student’s academic credit as well in prospect rating rules, application rating rules, and application program admit rules.

Use the Validation Codes (VAL) form to define student noncourse status codes. These codes are stored in the STUDENT.NON.COURSE.STATUSES record of the ST.VALCODES file.

See “Noncourse Grade Usage Types” on page 244 for further explanation of noncourse grade usage codes.

Student Program Statuses

Student program status codes identify various statuses of a student within an academic program, such as active, withdrawn, or completed. Some of these statuses contain special processing codes that direct Colleague to automatically assign program statuses at specific times. Table 96 on page 281 shows how the student program status codes relate to the special processing codes and when Colleague will assign these statuses to a student’s program record.

Use the Validation Codes (VAL) form to define student program status codes. These codes are stored in the STUDENT.PROGRAM.STATUSES record of the ST.VALCODES file.

Table 95: Student Program Status Special Processing Codes

Special Processing Code Assigned when …

1 a student’s program record is created for an application. This status will indicate that this is a preliminary student program.

2 the individual is accepted and actually becomes a student.

3 a student’s program record is moved to the person’s academic credentials file. This status designates completion.

4 the individual has ended their academic program. This does not include students who have completed their program or withdrawn from the institution.

the individual has withdrawn from the institution.


Ge

Student Remark Codes

Student remark codes indicate the office or other source of a remark about a student, such as an advisor or the business office.

Use the Validation Codes (VAL) form to define student remark codes. These codes are stored in the STUDENT.REMARK.CODES record of the ST.VALCODES file.

Student Remark Types

Student remark type codes categorize remarks about students which allow reporting by remark types, such as personal or academic.

Use the Validation Codes (VAL) form to define student remark type codes. These codes are stored in the STUDENT.REMARK.TYPES record of the ST.VALCODES file.

Student Special Service Codes

Student special service codes indicate special academic services required by a student, such as a tutor is required or a student is on probation. These codes are displayed but not otherwise used by Colleague.

Use the Validation Codes (VAL) form to define student special service codes. These codes are stored in the STUDENT.SPECIAL.SERVICES record of the ST.VALCODES file.

Student Term Statuses

Student term status codes identify various statuses a student can have during a term, such as preregistered, registered, transcripted, or withdrawn. The codes are assigned using rules you define and can be based on different characteristics of the student’s course sections for the term. See “Student Term Status Rules” on page 353 for more information about defining your student term status rules.

If you do not define student term status rules for an academic level then Colleague assigns the student term status by looking at the statuses of the student’s courses for the


Ge

term. Table 96 shows the special processing codes associated with the student term status codes and how Colleague would assign them to a student.

You must use these special processing codes, but you can rename the code itself, if appropriate.

Use the Validation Codes (VAL) form to define student term status codes. These codes are stored in the STUDENT.TERM.STATUSES record of the ST.VALCODES file.

Student Types

Student type codes classify students beyond their academic classifications, for example as veterans, employees or athletes. These codes can be used to flag groups of students for special purposes, such as billing.

Use the Student Type Codes (STTC) form to define student type codes. These codes are stored in the STUDENT.TYPES file.

Subjects

Subject codes define the subjects taught at your institution. The subject code is combined with the course number to make up the course name (ENG 101). Examples of subject codes are:

• CALC – Calculus

• GVT – Government

Use the Subjects (SUBJ) form to define subject codes. These codes are stored in the SUBJECTS file.

Table 96: Student Term Status Special Processing Codes

Special Processing Code Description Colleague assigns this code …

P Preregistered if all courses for the term have a status date before the registration start date for the term.

R Registered if any course for the term has a status date after the registration start date for the term.

T Transcripted if all courses for the term have been graded.

W Withdrawn if all courses for the term are inactive but not Withdrawn.

X Deleted if all courses for the term are Withdrawn.


Ge

Suite Flags

Suite flag codes are used to indicate the status of a suite of an FA file suite. Examples of suite flags codes include:

Suite flags are stored in the SUITE.FLAGS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Tax Categories

Tax categories group together tax codes for the purpose of printing the taxes on an account statement. For example, if you want all state sales tax to print on a single line, regardless of which state the tax is for, then you would use the same tax category code for each sales tax code. You can define tax categories to use special processing codes that will indicated the sort order of the codes when they are printed on the statement. For example, all tax codes with tax categories that have a “1” special processing code will print before any codes with a tax category that has a “2” special processing code. If a tax category does not have a special processing code associated with it, it will print after the other codes are sorted and before the tax codes that do not have tax categories.

Tax categories are maintained on the Validation Codes (VAL) form. These codes are stored in Core in the TAX.CATEGORIES record of the ST.VALCODES file.

Tax Return Type

Tax return type codes are numeric codes that indicate the tax return a student files or that the student does not file a tax return. Tax return codes are used for need analysis processing on the FAFSA.

Tax return type codes are stored in the TAX.RETURN.TYPE record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Table 97: Examples of Suite Flag Codes

Suite Flag Code Description

A Archive

C Create

D Delete


Ge

Teaching Arrangements

Teaching arrangement codes identify the various teaching arrangements at your institution. For example, your institution may assign a faculty member to a section with either a teacher’s aide, or graduate assistant helping teach the course. You can use these codes to define the various teaching arrangements.

Use the Validation Codes (VAL) form to define the teaching arrangement codes. Teaching arrangement codes are stored in the TEACHING.ARRANGEMENTS of the ST.VALCODES file.

Term Note Types

Term note type codes categorize student term notes into groups where the notes should be used, such as on a transcript, fad-term, or final grade report. These codes are displayed but are not used directly by Colleague.

Use the Validation Codes (VAL) form to define term note type codes. They are stored in the TERM.NOTE.TYPES record of the ST.VALCODES file.

Topic Codes

Topic codes identify topics that may be associated with courses at your institution. These topics can be particularly useful for continuing education courses.

Use the Topic Codes (TOPC) form to define topic codes. Topic codes are stored in the TOPIC.CODES file.

Total Contribution Type

Total contribution type codes indicate the type for the Total Contribution amount displayed in the Summary Calculations group of the Individual Need and Budgets (INB) form.

Total contribution type codes are stored in the FC.PGI.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

Transcript Categories

Transcript categories are used to identify external transcript entries for a person. These codes can be used for sorting reports but are not used for processing.

Use the Validation Codes (VAL) form to define transcript categories. These codes are stored in the TRANSCRIPT.CATEGORIES record of the ST.VALCODES file.

Transcript Groupings

Transcript grouping codes describe groups of student academic credit based on selection criteria, such as all undergraduate academic level activities, that Colleague will use as the baseline to produce transcripts academic evaluations.

Transcript grouping codes are maintained on the Transcript Groupings (TRGR) form. These codes are stored in the TRANSCRIPT.GROUPINGS file.

See “Understanding Transcript Groupings” on page 427 for details about setting up transcript grouping codes.

Transfer Statuses

Transfer statuses identify how transferable credits are for courses taken at another institution. These codes are used for California Community College MIS processing.

Use the Validation Codes (VAL) form to define transfer statuses. These codes are stored in the TRANSFER.STATUSES record of the ST.VALCODES file.

Trust Codes

Trust codes indicate on the PROFILE Student Assets (PSA1) form if the student trust was established by the student’s parents or others.

Trust codes are stored in the TRUST.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.


Ge

Tuition Discounts

Tuition discount codes describe reductions to an individual’s charges. Examples of tuition discounts include employee, senior citizen, and veterans discounts. You can associate discounts with:

• a specific course section so that all students who take the course will receive the discount

• a student so that the discount applies to all courses that student registers for

• a specific course section record for a student so that the discount applies only when a student is eligible for the discount and he registers for a course section that is also eligible for the discount

You can apply a discount to an individual’s charges as either a fixed amount or as a percentage of the total charge, but not as both.

Tuition discount codes are maintained on the Tuition Discounts (DISC) form. These codes are stored in the DISCOUNTS file.

See “Defining Tuition Discounts” on page 528 for complete details on defining tuition discounts including a description of the difference between a discount and a waiver.

Tuition Rate Tables

Tuition rate tables describe the tuition charges that Colleague calculates when a student registers for class. The tuition rate table that Colleague uses is based on a number of factors, including the course sections that the student registered for and specific characteristics about the student.

Tuition rate tables codes are maintained on the Tuition Rate Tables (TRTB) form. These codes are stored in the TUITION.RATE.TABLES file.

See “Understanding Tuition Rate Tables” on page 506 for complete information about defining tuition rate tables.

VA Certifications

The VA Certification codes describes the codes that indicate whether or not a course section has been certified to the Veterans Administration for a student who is receiving veterans benefits.

One code must have special processing code set to 1, to indicate “certified.” If more than one code has special processing of 1, the first code will be used as the default “certified” code.


Ge

Use the Validation Codes (VAL) form to define VA certification codes. These codes are stored in the VA.CERTIFICATION record of the ST.VALCODES file.

VA Forms

The VA Form codes describes the VA Forms which are recorded on the Veteran Students Information (VETS) form. Define all VA forms within this table where they can be entered on the Veteran Student Information (VETS) form along with an associated expiration date.

Use the Validation Codes (VAL) form to define VA form codes. These codes are stored in the VA.FORMS record of the ST.VALCODES file.

VATEA Economic Status Source Codes

VATEA economic status source codes identify the source of a vocational student’s economically disadvantaged status. These codes are used for California Community Colleges MIS reporting.

Use the Validation Codes (VAL) form to define VATEA economic status source codes. These codes are stored in the VATEA.ECONOMIC.STATUS.SOURCES record of the ST.VALCODES file.

VATEA Economic Statuses

VATEA economic statuses are used to identify economically disadvantaged vocational students. These codes are used for California Community Colleges MIS reporting.

Use the Validation Codes (VAL) form to define VATEA economic statuses. These codes are stored in the VATEA.ECONOMIC.STATUSES record of the ST.VALCODES file.

Verification Field Statuses

Verification field status codes are used to indicate whether a verification field will be evaluated based on equality checking or tolerance checking during the verification process. The verification process compares verification data to data in the financial aid application. Verification data that are evaluated based on equality checking must be equal to the data in the financial aid application. Verification data that are evaluated based on tolerance checking must be within an allowable deviation.


Ge

Verification field status codes are:

Verification field status codes are stored in the VERIF.FIELDS.STATUSES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Verification Codes

Verification codes are used to indicate the verification status of a financial aid application. They are:

Verification codes are stored in the VERIFICATION.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Veteran Benefit Eligibility Codes

The Veteran Benefit Eligibility codes describes eligibility codes used on the Veteran Students (VETS) form. For example, these codes could include active military, veterans, spouses, and dependents.

Table 98: Verification Field Status Codes

Verification Field Status Code Description

E Equality

T Tolerance

Table 99: Verification Codes

Verification Code Description

1 Institution Selected

2 CPS Selected

3 COLLEAGUE Requested

4 Verification Letter Sent

5 Data Entered/Updt Pending

6 Updated but not Complete

7 Verification Complete

8 Institution Not Verifying


Ge

Veteran benefit eligibility codes are stored in the VET.BEN.ELIGIBILITY.CODES record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form.

Veteran Benefits

The Veteran Benefit codes describe the Veteran Education Benefits used on the Veteran Students (VETS) form. This is to capture the valid Veteran Education Benefits that the student is eligible for.

Veteran benefit codes are stored in the VETERAN.BENEFITS record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form.

Visa Classification

Visa classification codes indicate the classification of an international student’s visa for PROFILE processing.

Visa classification codes are stored in the VISA.CLASSIFICATION record of the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should modify these codes only with the assistance of an Ellucian representative.

Waitlist Ratings

Waitlist rating codes identify a set of rules used to prioritize students on a waitlist for a specific course. For example, you may want to allow students of a particular major to have a higher priority or ranking on the waitlist over students in a different area of study who want to register for the same section.

Use the Course Waitlist Ratings (CWLR) form to define waitlist rating codes. These codes are stored in the CD.WAITLIST.RATING file.


Ge

Waitlist Statuses

Waitlist status codes identify the status of a student on a course or course section waitlist, such as active, enrolled or dropped.

Table 100: Special Processing Codes for Waitlist Status Codes

Special Processing Code Code Description Colleague Applies If …

1 A Active Active on waitlist. The student is still waiting to get into the section.

2 E Enrolled Inactive. This code is assigned by the system when the student is registered for the waitlisted section.

3 D Dropped Inactive. The student was dropped from the waitlist. This could happen when a student registers from the waitlist, but after being enrolled, the student drops or withdraws from the section.

4 P Permission to Register

Active on waitlist and given permission to register. The student has been given “permission to register,” which is a certain amount of time to enroll in the section. This is equal to WAIT.STATUS.DATE plus SEC.WAITLIST.NO.DAYS.

As long as students are within this window, they are allowed to register, regardless of capacity. The number of students with permission to register is subtracted from the available seats, because the students have been promised seats. If students do not register within the time allotted, their permission is expired when the Waitlist Availability (WLAV) or the Waitlist Closure (WLCL) process is run.

Note: Registration checks, warnings, and rules are not applied when a student is given permission to register. However these are applied when a student is placed on a waitlist or registered from a waitlist.

5 X Expired Inactive. The student has allowed the permission to register time to expire. If no special processing code of 5 is set up at your institution, a special processing code of 3 is used instead.


Ge

6 C Canceled Inactive. The section has been canceled and students’ waitlist statuses change to cancel. If no special processing code of 6 is set up at your institution, a special processing code of 3 is used instead. Reactivating canceled sections does not re-enroll or re-waitlist students.

7 L Closed Inactive. The waitlist has been closed, meaning that the period to get in the section is over and there were some people on the waitlist who never got in any section. If no special processing code of 7 is set up at your institution, a special processing code of 3 is used instead. When any student who has waitlisted for a section has a waitlist status with a special processing code of 7, no other student may be added to the waitlist of that section.

This status can be assigned only through the Waitlist Closure (WLCL) form to close an entire waitlist and is applied to active waitlist records as a batch. However, if any students on the waitlist to be closed have a permission to register status that has not expired, those records are not closed.

8 OS Other Section Enrollment

Inactive. When a student is waitlisted in multiple sections of the same course and then registers in one of the sections, the other waitlisted sections may be deactivated and marked as OS for “other section.” This is determined by the settings on the Registration Parameters (RGPP) form.

If no special processing code of 8 is set up at your institution, a special processing code of 2 is used instead. This status is used on the Registration (RGN) form, the Waitlist Availability (WLAV) form, and the following waitlist management forms:

• Course Waitlist Management (CWLM)

• Section Waitlist Management (SWLM)

• Course Waitlist Alternatives (CWLA)

• Section Cross-List Waitlist (SXWL)

Table 100: Special Processing Codes for Waitlist Status Codes (continued)

Special Processing Code Code Description Colleague Applies If …


Ge

Warning! Ellucian recommends that you do not modify the special processing codes.

Use the Validation Codes (VAL) form to define waitlist status codes. They are stored in the WAIT.LIST.STATUSES record of the ST.VALCODES file. Any status that does not have a 1 or 4 assigned will show on waitlist forms in the previously waitlisted section of that form.

Note: The special processing codes must be numeric so that they sort properly in the WLAV process, as returned by the computed column WAIT.STATUS.ACTION1.

Waive or Charge Codes

Waive or charge codes are used in AR waiver policies to identify whether the course/credit amount or the tuition amount is waived or charged. The values for this file are “W” for waived and “C” for charged.

Waive or charge codes are stored as WAIVE.OR.CHARGE.CODES in the ST.VALCODES file and can be viewed on the Validation Codes (VAL) form. You should only modify this code with the assistance of an Ellucian representative.

Withdraw Reasons

Withdrawal reason codes indicate the reason a student is taking a hiatus or withdrawing from your institution, such as a low GPA or financial reasons.

Use the Withdrawal Reasons Codes (WTHR) form to define withdrawal reason codes. These codes are stored in the WITHDRAW.REASONS file.

Yearly Cycle Codes

Yearly cycle codes define the yearly schedule by which certain courses are offered. For example, your institution may offer courses every other year, or every three years.

Use the Yearly Cycles (YRCY) form to define the yearly cycle codes. Yearly cycle codes are stored in the YEARLY.CYCLES file.


Ge

Defining Validation Codes

Before You Begin

Before working directly with Colleague Student validation codes, a few preparatory steps are recommended. You should:

1. Review basic codes concepts.

Refer to “Understanding Student Codes” on page 67.

2. Become familiar, if you are not already, with the methods and codes your institution currently uses to track Colleague Student information.

3. Ensure that all concerned parties have had a chance to give input into the process of planning your institution’s validation codes.

The information systems, admissions, accounting, registrar, campus life, and academic records offices should work together to define these codes.

4. Use the worksheet provided to plan your validation codes on paper, before entering any of them into Colleague Student.

Use the worksheet “Validation Code Tables” on page 306.

Understanding Validation Codes

Use the Validation Codes (VAL) form to define codes for validation tables. You can access the VAL form from any menu.

You can specify the maximum size of any code you define, as well as the code’s appearance on forms, by choosing to fill the unused field space with zeroes. For example, if you set the maximum length for a code to “5” spaces, then set the Zero Fill Numbers flag to “Yes” and enter a code of “1,” the code will appear as “00001.”

Note: For any code you define using alphanumeric characters, the Zero Fill Numbers flag is automatically set to “No.”

Special Processing Codes

Some validation code tables use special processing codes to facilitate other processing. When you use a validation code with a special processing code, Colleague executes the process associated with the special processing code.

If you choose to modify the delivered codes, and a code you are modifying has special processing, you are responsible to ensure that all of the special processing codes delivered are represented in the codes you define. If you do not, any given Colleague process that may be looking for a specific special processing code will not perform properly. For example, if special processing codes “1” through “8” are delivered, be sure


Ge

you have defined a code corresponding to each of the eight special processing codes. The special processing codes are hard-coded in the programs to drive specific processing. In some cases, these statuses are actually assigned by Colleague based on the special processing code.

Example. In Figure 14, the MEAL.ASSIGN.STATUSES validation code table has four codes that use special processing codes: Cancelled, Terminated, Late Assignment, and Refunded. Each of these statuses affects billing. When you assign one of these statuses to a meal plan assignment, Colleague will execute the process associated with the special processing code. At Ellucian University (EU), when a meal plan is tagged with a status of “Cancelled,” all charges are reversed. When the individual who changed the status on the student’s meal plan record finishes from the Meal Plan Assignment (MPAS) form, Colleague processes the information in the Accounts Receivable module and issues a refund (how the refund is issued will be determined by the way your institution has set up the Accounts Receivable module).

Components of a Validation Code

Validation codes are defined on the Validation Codes (VAL) form.

Figure 14: Example of the Validation Codes (VAL) Form

Procedure for Defining a Validation Code

Complete the following steps to define any code tables you will need to implement Colleague Student at your institution.

Warning! To define or modify Core validation code tables, you must enter core from the DBMS prompt (Core codes are stored in the


Ge

CORE.VALCODES file). If you enter VAL from the ST main menu, or any menu in Colleague Student, you will access only Colleague Student validation codes (ST.VALCODES).

1. Enter VAL at any menu prompt.

The Validation Codes form is displayed.

2. Enter the ID of the code you want to define.

The ID of the code is displayed in the header of the VAL form.

3. Enter an individual code for this validation code table.

For example, if you are creating a code for prospect statuses, enter a code for each status you want to define, such as INQ for Inquiry or SER for Serious.

4. Enter the description of the associated code.

The code description is displayed and the cursor moves to the Min element.

5. Enter the minimum characters required to identify the associated code.

The number of minimum characters required to identify the associated code is established, and the cursor moves to the Special Processing element.

For example, if you named a code SER (for serious prospect), you could use this field to indicate a minimum number of acceptable characters that can be entered for this code, by entering S in this field. You will only have to enter S in a code field to identify this code.

6. Do you want to define special processing for this code table?

Enter the special processing information.

Move the cursor to the next Code group element. Continue with Step 8.

Space is provided for two special processing codes.

Move the cursor to the next Code group element and continue with Step 8.

7. Do you want to change the maximum code size for this code table?

Move to the Maximum Code Size field and enter the value you want. Continue with Step 9.

Continue with Step 9.

8. Repeat Step 4 through Step 8 until all the codes you want are defined for this validation code.

When you are finished completing the VAL form, save the information. The menu from which you accessed VAL is displayed.


Ge

Codes Worksheets

In This Chapter

This chapter provides worksheets that you can use to assist you in setting up the codes defined as part of setting up Colleague Student.

295tting Started with Colleague Student | Codes Worksheets

Ge

Admit Status Codes

Table 101: Admit Status Codes Worksheet

Admit Status Code Description


Ge

Application Status Codes

Table 102: Application Status Codes Worksheet

CodeDescription

Processing Code1

Column Number

1.The processing codes used for the application status codes are listed on the back of this worksheet.


Ge

Table 103: Application Status Codes

Processing Code Definition Additional Information

AP Applied When an application first receives an application status with this processing code, Colleague will take a snapshot of the prospect information. This will occur if you entered “Y,” for the Snapshot Prospect Data parameter on the Admissions Parameters (ADPA) form.

CO Complete

AC Accepted When an application first receives a status that uses this processing code, Colleague will update the Admit from State and Admit from Country fields (on the Admit From [ADFR] form) from the applicant’s residency state and county, if available.

WL Waitlisted

RE Rejected

MS Moved to Student

When an applicant’s data is copied to the STUDENTS file, Colleague will update the application with the application status that uses this as a processing code.

You can define only one application status code with this special processing code.

WI Withdrawn


Ge

AR Categories

Table 104: AR Categories Worksheet

Code Description


Ge

AR Codes

Table 105: AR Codes Worksheet

AR Code1:

1.GL Distribution Rules: Use the worksheets “Rule Construction—English Statements” on page 320 and “Rule Construction Translation” on page 322 to define each distribution rule.

Description:

Default Charge: AR Category:

Default Credit: Priority:

Office Codes:

Appl Fee (Circle one): Yes No

GL Numbers Percent Amount Distribution

Rule2

2.Optional for AR codes whose GL distribution is based on rules. See “General Ledger Distribution Rules” on page 151 for details. Use the worksheets “Rule Construction—English Statements” on page 320 and “Rule Construction Translation” on page 322 worksheets to map out these rules.

GL Number:

Deferred GL Number:

GL Number:

Deferred GL Number:

GL Number:

Deferred GL Number:

GL Number:

Deferred GL Number:

GL Number:

Deferred GL Number:

GL Number:

Deferred GL Number:

Tax Code Rule:

Tax Code:

Tax Code Rule:

Tax Code:

Tax Code Rule:

Tax Code:

GL Subroutine:


Ge

AR Tax Codes

Table 106: AR Tax Codes Worksheet

Tax Code:

Description:

AR Tax Liability GL Account:

Tax Code Category:

Effective Date Compound Sequence Tax Percent


Ge

AR Types

Table 107: AR Types Worksheet

AR Type:

Description:

GL Account #:

Office Codes

Table 108: AR Types Worksheet

AR Type:

Description:

GL Account #:

Office Codes


Ge

Deposit Types

Table 109: Deposit Types Worksheet

Deposit Type Code:

Description:

GL Account Number:

Interest Rate:

Interest Rate GL Account Number:

Auto Allocation?

Allocation Rules:1

1.Use the worksheets “Rule Construction—English Statements” on page 320 and “Rule Construction Translation” on page 322 to define these rules.


Ge

Non-AR Receipt Codes

Table 110: Non-AR Receipt Codes Worksheet

Code:

Description:

Office Codes:

GL Account Percent


Ge

Recommendation Type Codes

Table 111: Recommendation Type Codes Worksheet

Recommendation Type Code Description


Ge

Validation Code Tables

Use a copy of this worksheet to list all the validation code tables you define for Colleague Student.

Table 112: Validation Code Tables Worksheet

Code Description Min EntrySpecial Processing


Ge

Understanding the Rules Processor

In This Chapter

This chapter includes information on creating and using rules. Table below lists the topics in this chapter.

Before You Begin

Before you can create and use rules, the data elements that you use to define those rules must already be set up in the Run-Time CDD (Central Data Dictionary.) For a brief explanation of the Run-Time CDD, see 312. If you want to create a rule using a data element that is not available or you want more detailed information about the Run-Time CDD, contact your system administrator.

Understanding Rules

The rules processor is a feature of the Core System that is used by several modules across all Ellucian products to define processing conditions and to determine whether those conditions are met. You can use rules to define a set of unique criteria for selecting records and/or performing certain processes. For example, you may need a rule that defines the criteria that a student must meet to receive financial aid. Using the rules processor, you can create this new rule and then use it to evaluate student data to determine the list of students who are eligible to receive financial aid.

For a detailed example of using the rules processor, refer to “A Rules Processor Example” on page 317.

Table 113: Topics in This Chapter

Topic Page

Understanding Rules 309

Working with Rules 311

Procedure for Building Rules 316

Procedure for Validating Rules 317

A Rules Processor Example 317

309tting Started with Colleague Student | Understanding the Rules Processor

Ge

How Colleague Evaluates Rules

When Colleague evaluates a rule, it checks the components of the rule to see if they meet the conditions you defined in the rule. If the components meet all of the conditions, the rule evaluates as true. If any of the components (within a logical “AND” string) do not meet the conditions, the rule evaluates as false.

Note: Rule order is important in Colleague. In most cases, if a rule (in a series) evaluates as true, Colleague stops evaluating at that point; that is, it will not read any further rules in the series.

When Colleague evaluates a rule as true, it carries out the module-specific conditions associated with that rule. Some predefined rules processor applications exist for each module in Colleague Student. Table provides examples of how some of the modules in Colleague Student use the rules processor. This table does not provide an exhaustive or complete list of all rules processor uses in all modules; it is here for example purposes only.

Note: For more specific information about module-specific conditions associated with rules, see the documentation on rules in the appropriate module’s procedural manual.

Rule Evaluation Results Forms

When Colleague evaluates and processes a rule, the results of the processing sometimes display on the Rule Evaluation Results (RLES) form. This form lists all rules that failed in processing. You can detail from the RLES form to the Rules Evaluation Detail (REDT) form to see a detailed list of all rules that failed processing.

Table 114: Sample Uses of the Rules Processor

Where it is Used... How it is Used...

Financial Aid • to define award eligibility criteria

• to define award amounts

• to evaluate standards of progress

Academic Records • to determine academic level standing

• to define class levels

Accounts Receivable • to evaluate registration billing

• to define refund rules

Admissions • to assign admissions representatives

• to rate applications

Registration • to evaluate student registration eligibility

• to evaluate course eligibility during registration


Ge

Note: You cannot directly access the RLES and REDT forms. They display automatically as a result of rule processing. Currently, the Registration and Academic Records modules use these forms. Refer to the appropriate module’s procedural documentation for more information.

Working with Rules

The four basic steps you follow when working with rules are:

1. Determining the rules you need. Based on your institution’s policies and requirements, determine what business rules you need.

2. Building the rule. Use the Rules Definition (RLDE) form to create a rule to evaluate the data you want to consider. A rule evaluates data and determines whether the conditions defined in the rule are true or false

3. Validating the rule. After you create the rule, you can use the Rules Test and Debug (RLTD) form to validate it. Enter the RLTD form, choose test records that you know will either pass or fail the rule then verify the results.

4. Assigning the rule. After you define the rule, you must assign that rule to a specific process. When you assign a rule, you specify the processing that will take place when that rule evaluates true for a record. If the rule is true, the processing occurs; if the rule is false, the processing does not occur.

Note: See the appropriate sections on assigning rules in the procedural documentation for the module in which you want to use rules. Each module’s procedural documentation provides procedures for and examples of assigning rules within that module.

How to Build Rules

Each of the forms you use to assign rules in a module allows access to the Rules Definition (RLDE) form (see Figure 15.) Use the RLDE form to:

• view an existing rule to determine if it meets your needs

• create a rule


Ge

Figure 15: The Rules Definition (RLDE) Form

The following sections explain the concepts that you should understand before using the RLDE form to build rules.

The Run-Time CDD

The fields (data elements) from the file(s) you want to use to build a rule must be defined in the Run-Time CDD. The Run-Time CDD is a dictionary of all files and fields in all applications.

The rules processor uses Run-Time CDD data elements and virtual fields from various files, along with common logical operators, in the construction of rules.

You can use the forms listed in Table to create, search for, and view files, data elements, and virtual fields. You can access all of these forms from the Rules Menu (RULE) form or by typing the appropriate mnemonic from anywhere in the system.

Refer to the online help for detailed information on how to use these forms.

Table 115: Forms Associated with Rules

Form Name Mnemonic

File Specifications RFS

File Element Inquiry RFEI

Database Element Presentation RDEP

Database Element Linkages RDEL

Virtual Fields RDVF


Ge

Colleague stores files in a file named RT.FILES and fields (data elements) in the RT.FIELDS file (see Table ). Any files and fields that you specify on the RLDE form must already exist in the RT.FILES or RT.FIELDS files, respectively.

Note: If a file or field that you want to use to define a rule does not exist in the Run-Time CDD files, contact your system administrator for assistance.

Office Codes

If you want to create a rule that only one office can use, you can specify the code for the office that has exclusive access to this rule in the Office Code field. When you restrict a rule to a particular office, only users from that office can access that rule. If you want all users to have access to a rule, do not enter an office code in the Office Code field.

Primary View File

When defining a rule, you must define the primary file in which the evaluated data is stored. You must define this file in the Run-Time CDD (in the RT.FILES file) before you can specify it on the RLDE form. A primary view file consists of that file and its subsidiary files. For example, if the primary view file is PERSON, any subsidiary file of PERSON (i.e., another file with the same key) is valid.

If all of the data elements that you want to evaluate are stored in one file, list that file as the primary file on the RLDE form. If you want to evaluate data elements from more than one file, list the file that contains most of the elements that you want to evaluate. For information about accessing data elements that are not stored in the primary file, see “Data Elements” on page 314.

Table 116: The Run-Time CDD Files

RT.FILES RT.FIELDS

Lists all files defined for use with the rules processor.

Lists all data elements defined for use with the rules processor. For each data element, this file also specifies the file in which the data is stored.

Example:

STUDENTSPERSONAPPLICANTS

Example:

LAST.NAMEPERSONSTU.RESIDENCY.STATUSSTUDENTSSTU.TYPESTUDENTS


Ge

Subroutine Name

In the Subroutine Name field you can detail to the Rules Subroutine Definition (RLSD) form to create or maintain a subroutine that will be called instead of line by line evaluation. On RLSD you can manipulate an already defined subroutine, but you will be forced to save the changes under a different subroutine name. You can also create a new subroutine that must have the following arguments:

• A.RECORD.ID - Key to the record to be evaluated

• A.FILE.SUITE.YEAR - The Year of any file suite processing

• A.EVALUATE.ALL.RULES - Y or N flag to specify evaluation of all lines within a rule so that the results of the evaluation can be returned in the AL.CONDITIONS argument and displayed on a calling form.

• A.ERROR.OCCURRED - Error flag returned on errors or if the rule evaluates to false.

• A.MSG - Error Message either from rules message or from data extraction errors.

• AL.CONDITIONS - Multi-valued, Multi-Attribute return argument containing results of evaluation.

When saving a new subroutine, the name of the subroutine will begin with S_ and end with _RULE. For example, S_REGCRS1_RULE where REGCRS1 is the name of the rule that the subroutine was generated for. The actual source code from the generation is then stored in the RULES.SOURCE file.

When you finish from RLSD and ultimately the RLDE form, Colleague generates the rule and names it. You must define the subroutine on the RLDE form, and not in the tool kit.

Data Elements

When breaking down rule criteria into simple statements that are then rewritten using language that the rules processor can understand (the rule construction), a key component of this process is identifying the dictionary items used.

For the data elements that are stored in other files, you must specify how to get to the data element from a pointer in the primary file. Use the Rules Definition Detail (RLDT) form (see Figure 16) to specify the data element you want to use and the pointer to use when retrieving it. If you need help setting up a pointer to a data element stored in another file, contact your system administrator.

Note: Whenever possible, use data elements rather than virtual fields in rule construction to facilitate faster processing.


Ge

Figure 16: The Rules Definition Detail (RLDT) Form

How to Validate Rules

Use the Rules Test and Debug (RLTD) form to test and debug a rule as you create it. You can specify a sample record to use during the test for evaluation purposes. This utility steps through the rule evaluator program and shows you the result of each step in the program. You can also turn on the debugger software for S.EVALUATE.RULES and S.GET.DATA and print the results to the form.

If the Left Expression and Right Expression fields are CDD elements and have an output conversion specified, that conversion will be applied to the Left Result and Right Result. This makes fields like dates readable, but can have an unexpected impact on decimal fields such as GPAs.

For example, if you use the following expression: WITH STA.CUM.GPA LE 3.171 and the value of STA.CUM.GPA is 3.17143, the expression will fail. However, the value for Left Result displayed on RLTD will be 3.171 because STA.CUM.GPA has an output conversion that specifies three decimal places. This could lead you to believe that the rule is not functioning properly.


Ge

Figure 17: The Rules Test and Debug (RLTD) Form

How to Assign Rules

The modules that use the rules processor have specific forms that you use to assign an existing rule for evaluating a specific condition. From these forms, you can either enter a predefined rule or access the Rules Definition (RLDE) form to create a rule. Colleague limits the selection or creation of rules on these forms to predefined primary view files. When you assign a rule, you specify the action that you want to occur if the condition defined in the rule is true.

See the procedural documentation for the appropriate module if you need more information about the specific situations in which rules are assigned and used.

Procedure for Building Rules

Follow the procedure described in below to build a rule.

1. Define your requirements and identify your necessary business rules.

2. Access the Rules Definition (RLDE) form.

You can access this form directly if you want to create rules before assigning them.

If you want to create rules as you are assigning them, you can access this form from the module-specific form in which you are assigning rules.

3. Add a rule.


Ge

At the Rule LookUp prompt, enter a new rule name. Enter A to add the rule.

If you enter the name of an existing rule, the form displays information about that rule. Be sure to use a unique name for a new rule.

4. Complete the RLDE form.

To create a rule for use only by a specific office, enter an office code in the Office Code field.

If you want this rule to evaluate a data element that is stored in a file other than the primary file, access the Rules Definition Detail (RLDT) form as a detail form from the appropriate row of the Connector field (on the RLDE form.) Use the RLDT form to define how to access the data element through a pointer from the primary file.

Use the online help for more information about a particular field.

See your system administrator if you need help specifying the correct primary file, finding the appropriate data element, or using a data element that is not stored in the primary file.

5. Save the record.

Procedure for Validating Rules

Follow the procedure described below to validate a rule.

1. Access the Rules Test and Debug (RLTD) form.

After creating a rule or when using a rule with which you are unfamiliar, directly access the RLTD form to test it.

2. Retrieve the rule.

At the Rule LookUp prompt, enter the name of the rule that you want to validate.

3. Complete the RLTD form.

When testing a rule, you must have records in mind that you know will either pass or fail the rule criteria. It is a good idea to test a rule for both success and failure conditions before assuming that the rule works.

4. Evaluate the rule test results.

If the rule contains errors, return the RLDE form to correct them.

A Rules Processor Example

To understand how rules are defined and used, consider the rules processor as it is used in assigning admissions representatives to applicants. In this example, the rule determines whether applicant criteria are met. When the rule is linked to the admissions


Ge

representative assignment process in the Admissions module, admissions representatives are assigned to applicants whose data meets the criteria defined in the rule.

The process of assigning admissions representatives to applicants varies by institution. The criteria may be as simple as assigning representatives to applicants based on their state of residence, or it may be based upon a combination of an applicant’s intended course of study, high school, or SAT scores. The rules processor compares an applicant’s data against these criteria and determines the appropriate admissions representative to assign.

As an example, a particular institution assigns admissions representatives based on applicants’ intended career goals. The admissions office has one representative for each of the following areas:

• Computer career applicants

• Business career applicants

• Medical career applicants

• Undecided applicants

To properly assign all applicants to these four admissions representatives, you must create four rules that evaluate the appropriate criteria— one for each representative. This example takes you through the process of creating the rule for computer career applicants.

The first step in defining the criteria for an applicant is to break down the requirements into their basic components. These components, written in simple statements, become the building blocks for the rule construction. The criterion for our simple admissions example contains the following component:

• Intended goal is a computer career

The next step is to translate this simple statement into a format that the rules processor can use. The rules processor requires that you state rules using a connector, a dictionary item, an operator (such as equal to, less than, or greater than), and a value against which to compare.

You must rewrite the admissions rule for the rules processor as it appears in Table 117.

Table 117: Example of Admissions Rule Construction

Connector Data Element Name Operator1

1.Valid operators are EQ: equal to; LE: less than or equal to; LT: less than; GE: greater than or equal to; GT: greater than; NE: not equal to; LIKE: like pattern; UNLIKE: unlike pattern; MATCHES: matches pattern; and, SAID: sounds like.

Value Needed2

2.This value is an example only. Your specific career goal codes may be different from the one appearing here. You can also specify another data element here if you want the value of one data element to be compared to the value of another data element when Colleague evaluates the rule.

WITH APP.CURRENT.CAREER.GOAL EQ “COMP”


Ge

In the rule shown in Table 117, the connector “WITH” is evaluated as “AND WITH.” For any rule that you build using multiple statements, the connector “AND” is implied between the statements unless you explicitly state “OR.”

The component of the applicant’s file that is being evaluated is the career goal (the APP.CURRENT.CAREER.GOAL dictionary item.) This dictionary item is available from the dictionary of the APPLICANTS file, which is the primary file. Colleague includes the data element name (listed in Table 117) in the dictionary of the APPLICANTS file; therefore, the APPLICANTS file is the primary file used for this rule.

When assigning admissions representatives, Colleague reads the applicant’s file to ensure that this statement holds true. If the statement is true, Colleague assigns the appropriate representative. If the statement is false, Colleague does not assign the

representative to this applicant.1

1.See Using Admissions for complete details on assigning admissions representatives.


Ge

Rules Worksheets

In This Chapter

This chapter provides general worksheets for you to use when constructing rules for use with Colleague Student. As you set up each module of Colleague Student, you will have the option of defining a number of different rules for use in processing your data. Make as many copies of the worksheets provided in this chapter as needed to help you map out your rules.

There are two rules worksheets:

Rule Construction—English Statements

Table 118: Worksheets for Defining Rules

Worksheet Purpose

Rule Construction—English Statements Use this worksheet to write out each of your business rules for a particular area in simple English statements, such as “must have a GPA greater than 2.8.”

Rule Construction Translation Use this worksheet to translate your general English statements into the rules processor syntax.

Use this worksheet when you define individual rules on the Rules Definition (RLDE) form.

Table 119: Rule Construction – English Statements Worksheet

Rule:

English Statements

320tting Started with Colleague Student | Rules Worksheets

Ge

Table 119: Rule Construction – English Statements Worksheet

Rule:

321tting Started with Colleague Student | Rules Worksheets

32

2G

etting Sta

rted with C

olleague S

tudent

|R

ules Wo

rksheets

R

Right-hand Expression

ule Construction Translation

Table 120: Rule Construction Translation Worksheet

Connector Left-hand Expression Relation

Getting Started with Colleague StudentAcademic Records

Ge

Defining Academic Records Rules

In This Chapter

The sections in this chapter provide instruction on academic rules that may be in place at your institution, and how to define them in Colleague. If you need help defining academic record parameters, see “Defining Academic Records Parameters” on page 356.

Before You Begin

Before you read this chapter and begin defining your academic records rules you should read “Understanding the Rules Processor” on page 309 for information about the basic principles of the Colleague rules processor.

Understanding Academic Records Rules

In the Academic Records module you can define rules to control specific processes. The specific rules that you define in this module are referenced in Table 121.

Table 121: Rules Defined in the Academic Records Module

Rule Reference

Graduation Honors 325

Academic Standing 331

Academic Term Registration 336

Class Level 339

Enrollment Status 342

Grade Point Averages 344

Print Restrictions 346

Student Loads 350

Student Term Status 353

324tting Started with Colleague Student | Defining Academic Records Rules

Ge

The following sections explain each of the rules that you can define for the Academic Records module.

Graduation Honors Rules

If students can receive various honors upon graduation, such as Magna Cum Laude, you must define the rules Colleague uses to assign those graduate honors to qualifying students. You can define graduation honors rules for either:

• Academic levels

• Academic programs

Think of academic level graduate honor rules as default rules. You can set up a unique set of graduate honors rules for some or all of your academic programs. If you do not define academic program graduate honors rules for a particular program, then the graduation honors processor checks the associated academic level to see if there are academic level graduate honor rules there and uses those, if they exist. This means that academic level graduate honors rules are only evaluated when there are no academic program graduate honors rules for a particular program. If there are no honors rules defined at either level, Colleague will not assign graduation honors to students in that academic program.

For example, Ellucian University bestows distinctive honors on some of its nursing graduates. To define these nursing honors, EU defined rules for the Nursing academic program. No academic program honors are defined for the other academic programs. Instead, EU defined academic level graduates honors that Colleague uses for all EU graduates except for nursing students who are evaluated using the Nursing academic program graduation honor rules.

Use Table 122 to determine which forms to use to define the type of graduation honors rules your institution needs and where to find more information about each.

When Colleague Evaluates the Graduate Honors Rules

Colleague evaluates your graduate honors rules during the Graduate Honors Update (GRHU) process. Colleague evaluates all of the honors rules and assigns the honors codes associated with the rules that evaluate true. As a result, students may receive multiple honors.

Table 122: Forms Used to Define Graduation Honors Rules

Type Form Reference

Academic level Academic Level Grad Honors (ALGH) 326

Academic program Graduation Honor Rules (GHRL) 329


Ge

How to Define Academic Level Graduate Honors Rules

Academic level graduate honors rules are evaluated if a graduating student is associated with an academic program which does not have specific honors rules. If you want to define honors for a particular academic program, see “How to Define Academic Program Graduate Honors Rules” on page 329.

Use the Academic Level Grad Honors (ALGH) form to define your default graduate honor rules and to associate each honors rules with the honors code Colleague assigns when the rule is true. You can access the ALGH form directly from the menu or by detailing from the Academic Levels (ACLV) form. Use the STUDENT.ACAD.LEVELS file as the primary view for your academic level graduate honors rules.

You must define a graduate honors rule for every honors code potentially assigned to a student in the academic level. You can define graduate honors rules so that a student may receive multiple honors, such as Magna Cum Laude and University Fellow. If there is a group of honors of which a student might only receive one, you must define the graduate honors rules so that they are mutually exclusive.

For example, Ellucian University bestows both a Cum Laude and Magna Cum Laude honor, but never both to the same student. A student must earn a GPA greater than 3.5 to receive the honor of Cum Laude or greater than 3.7 to receive the honor of Magna Cum Laude. If a student earns a GPA of 3.8, EU bestows only the honor of Magna Cum Laude. Therefore, EU has defined the rule associated with Cum Laude as “GPA >= 3.5 and < 3.7” and the rule associated with Magna Cum Laude as “GPA >= 3.7.” Figure 18 shows the forms EU used to define these academic level graduate honors rules.


Ge

Figure 18: Example of Defining Academic Level Graduate Honors Rules

Procedure for Defining Academic Level Graduate Honors Rules

Note: Before you define academic level graduate honors rules, the appropriate offices at your institution must define the academic levels for which you are defining rules. See “Defining Academic Levels” on page 410 for more details.

Complete the following procedure to define your academic level graduate honors rules.

1. Define your graduate honors codes.


Ge

See “Honors Codes” on page 234.


Use the worksheet “Academic Level Graduation Honors Rules — English Statements” on page 435.

3. Identify the data elements you need to construct the rules

Note: The data elements you use must be from the STUDENT.ACAD.LEVELS file, or one of the subsidiary files associated with it.


See “Understanding the Rules Processor” on page 309 for more information about primary views.



5. Go to the Academic Level Grad Honors (ALGH) form.

6. Enter the academic level for which you want to define graduate honor rules.

Colleague displays the academic level in the header and the cursor moves to the first line of the Graduate Honor Rule group.

7. Enter the name of the graduate honors rule.

The Record not found--Enter (A)dd or RETURN to Reenter prompt is displayed.

If the rule displays on the ALGH form and the cursor moves to the Graduate Honor field, continue with Step 11.

8. Enter A.


9. Enter the rule.

Use the information from the worksheet.

Refer to“Understanding the Rules Processor” on page 309 for information about the Rules Definition form.

10. Save the rule.

The ALGH form redisplays with the cursor in the Graduate Honor field.

11. Enter the honors code Colleague assigns when this rule is true.

The cursor moves to the next line of the Rules group.

12. Repeat this procedure, beginning with Step 7, for each graduate honors rule for this academic level.

13. Save the graduate honors rules record.


Ge

How to Define Academic Program Graduate Honors Rules

Academic program graduate honors rules are defined for a particular academic program. You do not have to define honors rules for each academic program, but only those programs that have special honors associated with them.

If a graduating student is associated with an academic program which does not have specific honors rules, Colleague uses the default rules defined for the associated academic level. See “How to Define Academic Level Graduate Honors Rules” on page 326 for more information about defining default graduation honors.

Use the Graduate Honor Rules (GHRL) form to define your academic program graduate honor rules and to associate each honors rules with the honors code Colleague assigns when the rule is true. Use the STUDENT.ACAD.LEVELS file as the primary view for your academic program graduate honors rules.

Figure 19: Defining Academic Program Graduate Honors

You must define a graduate honors rule for every honors code potentially assigned to a student in the academic program. You can define graduate honors rules so that a student may receive multiple honors, such as Magna Cum Laude and University Fellow. If there is a group of honors of which a student might only receive one, you must define the graduate honors rules so that they are mutually exclusive.


Ge

Procedure for Defining Academic Program Graduate Honors Rules

Note: Before you define academic program graduate honors rules, the appropriate offices at your institution must define the academic programs for which you are defining rules. See Using Curriculum Management for more information about defining your academic programs.

Complete the following procedure to define your academic program graduate honors rules.

1. Define your graduate honors codes.

See “Honors Codes” on page 234.


Use the worksheet “Academic Program Graduation Honors Rules — English Statements” on page 436.


Note: The data elements you use must be from the STUDENT.ACAD.LEVELS file, or one of the subsidiary files associated with it.





5. Go to the Graduate Honor Rules (GHRL) form.

6. Enter the academic program for which you want to define graduate honor rules.

Colleague displays the academic program in the header and the cursor moves to the first line of the Graduate Honor Rule group.

7. Enter the name of the graduate honors rule.


If the rule displays on the GHRL form and the cursor moves to the Graduate Honor field, continue with Step 11.

8. Enter A.


9. Enter the rule.

Use the information from the worksheet.


Ge

Refer to “Understanding the Rules Processor” on page 309 information about the Rules Definition form.

10. Save the rule.

The GHRL form redisplays with the cursor in the Graduate Honor field.

11. Enter the honors code Colleague assigns when this rule is true.


12. Repeat this procedure, beginning with Step 7, for each graduate honors rule for this academic level.

13. Save the graduate honors rules record.

Academic Standing Rules

Your institution has standards by which all of your students are measured. These standards might be academic, financial, or any other criteria you decide are appropriate to constitute a student’s academic standing. If a student meets these standards, you might say that student is in good academic standing with your institution. If a student falls below these standards, you might say that student is on probation.

You define different standards for each academic level, term and program of your institution. For example, your criteria for a graduate student to be considered in good standing might be different from your criteria for an undergraduate student. Similarly, your criteria for considering a nursing student in good standing might be different from your criteria for a music student.

You can define your standards for each academic standing type using rules. Colleague evaluates the rules you define and assigns each student an associated academic standing code, such as “GOOD” or “PROB” based on the results of these rules.

You do not need to set up rules for every academic level, term, and program of your institution. You only need to define rules for those academic levels, terms, or programs that have special standards. Define default standing rules that Colleague should use in all other circumstances. For example, Ellucian University considers its nursing program to have higher standards than most of its other programs. Ellucian University has defined academic program standing rules for this program alone. Colleague evaluates the academic standing of students in all other programs using the academic program standing default rules.

When Colleague Evaluates the Academic Standing Rules

Colleague evaluates your academic standing rules when you run the Calculate Academic Standing (CACS) process and assigns the associated standing code if the rule evaluates to true.

If you do not define an academic standing rule for a particular level, term, or program, Colleague uses the default rules you define for each type. For example, if a student is


Ge

enrolled in a standard academic program for which you have not defined any academic program standing rules, Colleague uses the academic program academic standing default rules to evaluate the student’s standing. If you do not define default rules, Colleague assigns no academic standing codes to students in the programs without specific program standing rules.

How to Define Academic Standing Rules

You can define three types of academic standing rules:

• Academic level

• Academic term

• Academic program

You can also define default standing rules for each type. The six types, the three specific types plus the three defaults, are defined on different forms and use different primary file views. Refer to Table 123 to help you decide which primary file view to use to define each rule and which form to use to associate each rule with the standing code Colleague assigns when the rule is true.

Case Study: Defining Academic Level Standing Rules

Ellucian University has defined two academic level standing rules for the academic level of ‘Undergraduate.’ The academic standing codes associated with those rules are 'GOOD’ and ‘PROB.’ An undergraduate student at Ellucian University is assigned an academic standing code of ‘GOOD’ for Good Standing, if he has a GPA greater than 2.0. A student is assigned an academic standing code of ‘PROB,’ for Probation, if he has completed at least one credit hour and has a GPA less than 2.0.

Table 123: Forms and Primary File Views Used to Define Standing Rules

To Define the Academic Standing Rule...

Use the Primary File View … Use the Form...

Academic Level STUDENT.ACAD.LEVELS Academic Level Standing Rules (ALST)

Academic Level Term STUDENT.TERMS Academic Level Standing Rules (ALST)

Academic Program STUDENT.PROGRAMS Academic Program Standing Rules (APST)

Academic Level Default

STUDENT.ACAD.LEVELS Academic Records Parameters (ACPR)

Academic Level Term Default

STUDENT.TERMS Academic Records Parameters (ACPR)

Academic Program Default

STUDENT.PROGRAMS Academic Level Standing Rules (ALST)


Ge

Figure 20 shows the forms Ellucian University used to set up their academic level standing rules. Notice that the RLDE form was accessed separately for each rule defined.

Figure 20: Example of Defining Academic Level Standing Rules

Case Study: Defining Academic Level Term Standing Rules

Ellucian University also defined an academic level term standing rule to determine which undergraduate students should be on the Dean’s List for an academic term. Colleague will evaluate this rule for all undergraduate students and assign the standing code of “DL” to the students who pass the following three criteria:

• Every grade for the term is above 1.75 (C-)

• The cum GPA for the term is above 3.5

• More than 12 credits completed during the term


Ge

Figure 21 shows the forms Ellucian University used to set up this academic level term standing rule for the Dean’s List. Notice that an additional rules detail form was used for one of the criteria. This was necessary because the data element referenced in the rule was not from the primary file view, STUDENT.ACAD.LEVELS. EU had to tell Colleague how to locate the desired data element. See “Understanding the Rules Processor” on page 309 for more information about using data elements not in your primary file view.

Figure 21: Example of Defining a Term Standing Rule


Ge

Procedure for Defining Academic Standing Rules

Note: Before you define academic standing rules, the appropriate offices at your institution must define the academic programs, academic levels and academic terms for which you are defining rules. See Using Curriculum Management for more information about defining your academic programs. See “Defining Academic Levels” on page 410 and “Procedure for Defining Academic Terms” on page 426 for more details.

Complete the following procedure to define your academic standing rules.

1. Define your academic standing codes.

See “Academic Standing Codes” on page 138.


Use one of the following worksheets:

• “Academic Level Standing Rules — English Statements” on page 437

• “Academic Level Term Standing Rules — English Statements” on page 438

• “Academic Program Standing Rules — English Statements” on page 439


Note: The data elements you must use for each type of academic standing rule are from different files. See Table 123 on page 332 for the primary file view for the type of standing rule you are defining.





5. Go to the appropriate form for the type of academic standing rule you want to define.

See Table 123 on page 332 for a list of appropriate forms.

6. Enter the name of the academic standing rule.


If the rule displays on the form and the cursor moves to the Standing field, continue with Step 10.

7. Enter A.


8. Enter the rule.


Ge



9. Save the rule.

The form redisplays with the cursor in the Standing field.

10. Enter the academic standing code Colleague assigns when this rule is true.


11. Repeat this procedure, beginning with Step 6, for each academic standing rule of this type you want to define.

12. Save the record.

13. Repeat this procedure, beginning with Step 2, for each type of academic standing rule you want to define.

Academic Term Registration Rules

If you allow different groups of students to register at different times, then you must define academic term registration rules. Colleague uses these rules to determine who is allowed to enroll during which registration time period.

If you decide not to define registration rules for an academic term, then all students will be allowed to register for the term during all registration process periods.

When Colleague Evaluates the Academic Term Registration Rules

Colleague evaluates your academic term registration rules during registration. When a student registers for a term based course, Colleague evaluates your academic term registration rules. If a student passes a rule, he can register for the course if the current date is between the associated start and end dates. If the student does not pass the rule, he cannot register at that time. There is no override to this rule.

How to Define Academic Term Registration Rules

Use the Academic Terms (ACTM) form to define your academic term registration rules and the associated start and end dates. Use the STUDENTS files as the primary view for the academic term registration rules.


Ge

Case Study: Defining Academic Term Registration Rules

Ellucian University allows seniors the privilege of registering first for an academic term. EU has defined an academic term registration rule called CLASSSR, which identifies all students who are seniors. The associated dates determine when this segment of students, seniors, can register for courses associated with this academic term. Figure 22 shows the forms Ellucian University used to set up this academic term registration rule.

Figure 22: Example of Defining a Term Registration Rule


Ge

Procedure for Defining Academic Term Registration Rules

Note: Before you define academic term registration rules, the appropriate offices at your institution must define the academic terms for which you are defining registration rules. See “Procedure for Defining Academic Terms” on page 426 for more information about defining your academic terms.

Complete the following procedure to define your academic term registration rules.


Use the worksheet “Academic Term Registration Rules — English Statements” on page 440.


Note: The data elements you use must be from the STUDENTS file, or one of the subsidiary files associated with these.





4. Go to the Reporting Year and Terms (RYAT) form.

5. Enter the reporting year of the academic term for which you want to define registration rules.

Colleague displays a list of all academic terms defined for that reporting year.

6. Select the academic term from the list for which you want to define registration rules.

7. Detail to the Academic Terms (ACTM) form.

Colleague displays the Academic Terms (ACTM) form with the selected academic term record.

8. Go to the Registration Rules field.

9. Enter the name of the academic term registration rule.


If the rule displays on the form and the cursor moves to the Start Date field, continue with Step 13.

10. Enter A.



Ge

11. Enter the rule.



12. Save the rule.

The ACTM form redisplays with the cursor in the Start Date field.

13. Enter start and end dates which apply to this registration rule.

The cursor moves to the next line in the Registration Rule group.

14. Repeat this procedure, beginning with Step 9, for each term registration rule.


Class Level Rules

Each academic level you define has an associated set of class levels, such as freshmen, sophomores, juniors, and seniors. You must define a class level rule for every class level code.

When Colleague Evaluates the Class Level Rules

Colleague evaluates your class level rules when you run the Class Level Update (CLUP) process.

How to Define Class Level Rules

Use the Academic Levels (ACLV) form to associate each class level rule with the class level code Colleague assigns when the rule is true. You can also use the Class Level Rules (CLVR) form to define your class level rules. Use STUDENT.ACAD.LEVELS file as the primary view for your class level rules.

If you want class levels to display in a particular order on grading forms or reports, you must give each class level a sequence number. Colleague uses this sequence number on grading forms where students are displayed in descending class order. On these forms students from the ‘highest’ class level (for example, seniors) are displayed first. Normally, the lowest sequence number would be assigned to the class with the least number of completed credits. Each higher sequence number would be associated with a class with successively greater numbers of credits completed. If you do not assign a sequence, the display order will be an alphanumeric sort by class level codes.

For example, Ellucian University has defined four class levels for the “UG” academic level. EU has defined the associated class level rules based on a student’s completed credits. For example, if EU students have completed less than 24 credits, then they are


Ge

considered “Freshmen.” Table 124 shows EU’s undergraduate class levels, the associated class level rules and the sequence for each.

Figure 23 shows the forms Ellucian University used to set up their class level rules. The RLDE form was accessed separately for each rule defined.

Figure 23: Example of Defining Class Level Rules

Table 124: Class Level Example

Class Levels Class Level Rules Sequence

Freshmen WITH STA.COMPLETE.CREDS LE “24” 1

Sophomores WITH STA.COMPLETE.CREDS LE “48” 2

Juniors WITH STA.COMPLETE.CREDS LE “72” 3

Seniors WITH STA.COMPLETE.CREDS LE “96” 4


Ge

Procedure for Defining Class Level Rules

Note: Before you define class level rules, the appropriate office at your institution must define the academic levels for which you are defining class levels. See “Defining Academic Levels” on page 410 for more information about defining your academic levels.

Complete the following procedure to define your class level rules.

1. Define your class level codes.

See “Class Levels” on page 171.


Use the worksheet “Class Level Rules — English Statements” on page 441.


Note: The data elements you use must be from the STUDENT.ACAD.LEVELS file, or one of the subsidiary files associated with these.





5. Go to the Academic Levels (ACLV) form.

The cursor displays at the Academic Level LookUp prompt.

6. Enter the academic level at the LookUp for which you want to define class levels.

Colleague displays the ACLV form with that academic level record.

7. Go the Class Level Rules field.

The cursor moves to first line of the group.

8. Enter the name of the class level rule.


If the rule displays on the form and the cursor moves to the Class Level field, continue with Step 12.

9. Enter A.


10. Enter the rule.



Ge


11. Save the rule.

The CLVR form redisplays with the cursor in the Class Level field.

12. Enter the class level code Colleague assigns when the rule is true for a student.

The cursor moves to the Sequence field.

13. Enter the sequence number for this class level. Colleague uses this number to determine sort order on grading forms and reports.

The cursor moves to the next line of the Class Level Rules group.

Normally, the lowest sequence number would be assigned to the class with the least number of completed credits.

If you do not assign a sequence, the display order will be alphanumeric by class level codes.

14. Repeat this procedure, beginning with Step 8, for each class level rule associated with the academic level.


Enrollment Status Rules

If your institution assigns student enrollment statuses, you must define rules for each status. Colleague evaluates these rules to determine which enrollment status to assign to a student.

When Colleague Evaluates Enrollment Status Rules

Colleague evaluates your enrollment status rules whenever a student is created from an application.

How to Define Enrollment Status Rules

Use the Acad level Enroll Status Rule (ALES) form to associate your rules with the enrollment status code Colleague assigns when the rule is true. Use the APPLICATIONS file as the primary file view for your enrollment status rules.

Procedure for Defining Enrollment Status Rules

Complete the following procedure to define your enrollment status rules.


Ge

1. Define your student enrollment status codes.

See “Enrollment Statuses” on page 190.


Use the worksheet “Enrollment Status Rules — English Statements” on page 442.


Note: The data elements you use must be from the APPLICATIONS file, or one of the subsidiary files associated with these.





5. Go to the Acad Level Enroll Status Rule (ALES) form.

Colleague displays the ALES form with the cursor at the Academic Level LookUp prompt.

6. Enter the desired academic level at the LookUp.

Colleague displays the selected academic level in the ALES form header. The cursor moves to the first line of the Enrollment Status Rule group.

7. Enter the name of the enrollment status rule.


If the rule displays on the form and the cursor moves to the Enrollment Status field, continue with Step 11.

8. Enter A.


9. Enter the rule.



10. Save the rule.

The ALES form redisplays with the cursor in the Enrollment Status field.

11. Enter the enrollment status code Colleague assigns when this rule is true.

The cursor moves to the next line of the Enrollment Status Rule group.

12. Repeat this procedure, beginning with Step 7, for each enrollment status rule for this academic level.


Ge


Grade Point Averages Rules

Colleague automatically calculates a term GPA and a cumulative GPA for each transcript. Colleague can calculate two other GPAs, the default being a major GPA and a minor GPA. However, you can redefine these two GPAs differently for each of your transcript groups. You can do this by selecting which academic activities Colleague should use to calculate these GPAs.

If you do not define GPA rules for a transcript group, Colleague uses the default GPAs of major and minor.

When Colleague Evaluates Grade Point Averages Rules

Colleague evaluates the grade point averages rules whenever a transcript is evaluated or printed.

How to Define Grade Point Averages Rules

Use the STUDENT.ACAD.CRED file as the primary file view for your grade point averages rules. Use the Transcript Grouping (TRGR) form to define your grade point averages rules. You can also access the GPA 1 Rules (GPA1) and GPA 2 Rules (GPA2) forms directly from the menu.

For example, Ellucian University defined a transcript grouping called “UG/GR” which allows both undergraduate and graduate courses to appear on a student’s transcript. EU decided it wanted two additional GPAs to appear on each transcript in this grouping. The first additional GPA EU wanted was the student’s ‘Major’ GPA using only the courses the student had taken from his major. Since GPA1 will automatically be defined as a ‘Major’ GPA, EU left the GPA1 rule blank. The second GPA rule EU wanted was a calculation of a student’s ‘Academic Level’ GPA. EU defined GPA2 to compute the grade point average of courses in each academic level separately.

Procedure for Defining Grade Point Averages Rules

Complete the following procedure to define your grade point averages rules.


Use the worksheet “GPA Rules — English Statements” on page 443.



Ge

Note: The data elements you use must be from the STUDENT.ACAD.CRED file, or one of the subsidiary files associated with it.





4. Go to the Transcript Groupings (TRGR) form.

Colleague displays the TRGR form with the cursor at the Transcript Grouping LookUp prompt.

5. Enter the transcript grouping for which you are defining GPA rules.

Colleague displays the selected transcript grouping in the TRGR heading.

6. Move to the GPA1 Rules field or GPA2 Rules field, as appropriate.

7. Enter the name of the grade point average rule.


If the rule displays on the form and the cursor moves to the GPA1 (2) Label/Break field, continue with Step 11.

8. Enter A.


9. Enter the rule.



10. Save the rule.

The TRGR form redisplays with the cursor in the GPA1 Label/Break Field.

11. Enter the label you want to appear describing this GPA.

The cursor moves to the Break field.

12. Enter the field on which you want the GPA calculation to break.

13. Repeat this procedure, beginning with Step 7, for your GPA2 rule.



Ge

Print Restriction Rules

If there are conditions under which you would withhold a student’s transcript or grades, you can define print restriction rules Colleague will evaluate before printing a transcript or grade report for a student.

For example, you may want to withhold a transcript if the student has outstanding parking violations on his record. To do this you would define a transcript print restriction rule which would evaluate a student’s record for parking violations. If there are outstanding parking violations on the student’s record, then he would not receive a copy of his transcript.

Grades can still be recorded for a student who is restricted from obtaining a printed copy of his grades or transcript. Colleague manages the student’s grades in a regular manner, but does not print them out at the request of a student who fails the print restriction rules you have defined. When the prohibiting restrictions are removed from the student’s record, by the office who originally assigned them, Colleague will allow the requested printout.

Grade print restriction rules do not affect a student’s ability to receive a printed copy of his transcript. Likewise, transcript print restriction rules do no affect a student’s ability to receive a printed copy of his grades. You must set up both types of restriction rules if you do not want a student to receive either printout under some conditions.

If you do not define any print restriction rules, then any student can have a copy of his grades or transcript produced regardless of any restrictions he may have on his record.

When Colleague Evaluates Print Restrictions

Colleague evaluate your print restriction rules whenever a request is made for a printout of a student’s grades or transcript. If any of these rules evaluate to “false,” Colleague will not print the requested grades or transcript for the student.

How to Define Print Restriction Rules

You can define two types of print restrictions:

• transcript print restrictions

• grade print restrictions

Use the STUDENTS file as the primary file view for your print restriction rules. Use Table 125 to decide which form to use to define your print restrictions rules.

Table 125: Forms for Entering Print Restrictions

If you want to enter... Use the...

Restrictions for printing grades Grade Print Restrictions (GRPR) form.

Restrictions for printing transcripts

Transcript Print Restrictions (TRPR) form.


Ge

Case Study: Defining Print Restrictions

Ellucian University does not want students with parking violations on their records to be able to receive either a transcript or a grade printout. EU defined identical grade and transcript print restriction rules which Colleague evaluates whenever a printout request is made. Figure 24 shows the forms EU used to define their transcript print restriction rule.

Restrictions for printing both grades and transcripts

Academic Records Parameters (ACPR) form as a starting point. Detail to the Grade Print Restrictions (GRPR) form and then the Transcript Print Restrictions (TRPR) form.

Table 125: Forms for Entering Print Restrictions

If you want to enter... Use the...


Ge

Figure 24: Example of Defining Print Restrictions

Procedure for Defining Print Restriction Rules

Complete the following procedure to define your print restriction rules.

1. Define your restriction codes.

See “Restriction Codes” on page 262.


Use one of the following worksheets:


Ge

• “Transcript Print Restriction Rules — English Statements” on page 444

• “Grade Print Restriction Rules — English Statements” on page 445


Note: The data elements you use must be from the STUDENTS file, or one of the subsidiary files associated with these.





5. Go to the Academic Records Parameters (ACPR) form.

The cursor is on the first field on the form.

If you want to define transcript print restrictions, continue with next step.

If you only want to define grade print restrictions, continue with Step 14.

6. Move to the Transcript Print Restrictions field.

7. Detail to the Transcript Print Restrictions (TRPR) form.

The cursor is at the Rules LookUp prompt.

8. Enter the name of the print restrictions rule.


If the rule displays on the form and the cursor moves to the next line in the Transcript Restriction group, continue with Step 12.

9. Enter A.


10. Enter the rule.



11. Save the rule.

The TRPR form redisplays with the cursor at the Rules LookUp prompt.

12. Repeat this procedure, beginning with Step 8, if you want to define additional transcript print restrictions.

13. Save the Transcript Print Restrictions record.

Colleague redisplays the ACPR form.


Ge

If you also want to define grade print restrictions, continue with the next step.

Otherwise, continue with Step 22.

14. Move to the Grade Print Restrictions field.

15. Detail to the Grade Print Restrictions (GRPR) form.

The cursor is at the Rules LookUp prompt.

16. Enter the name of the grade restrictions rule.


If the rule displays on the form and the cursor moves to the next line in the Grade Restriction group, continue with Step 20.

17. Enter A.


18. Enter the rule.



19. Save the rule.

The GRPR form redisplays with the cursor at the Rules LookUp prompt.

20. Repeat this procedure, beginning with Step 16, if you want to define additional grade print restrictions.

21. Save the Grade Print Restrictions record.

Colleague redisplays the ACPR form.

22. Save the Academic Records Parameters record.

Student Load Rules

You can define student load rules which Colleague uses to determine which student load code to assign to a student. You need to define a rule for every student load code you use. You can define a different set of student load rules for each academic level.

If a student attempts to register in a course that, subsequently, causes him to receive an overload code, an overload petition may be required before Colleague will allow the student to enroll in that course.

Note: If you use this form to create an overload rule, it will override any overload rules that are set on the Academic Levels (ACLV) form.


Ge

When Colleague Evaluates Student Load Rules

Colleague evaluates student load rules during registration when you run the Recalculate Term Status/Load (RTSL) process.

How to Define Student Load Rules

Use the Student Load/Status Rules (STLD) form to associate your load rules with the student load code Colleague assigns when the rule is true. Use the STUDENT.TERMS file as the primary file view for your student load rules.

For example, Ellucian University has three student load codes: P, for Part-time load; F, for Full-time load; and O, for Overload. EU has defined an associated student load rule for each code using the forms shown in Figure 25.

Figure 25: Example of Defining Student Load Rules


Ge

Procedure for Defining Student Load Rules

Complete the following procedure to define your student load rules.

1. Define your student load codes

See “Student Load Codes” on page 276.


Use the worksheet “Student Load Rules — English Statements” on page 446.


Note: The data elements you use must be from the STUDENT.TERMS file, or one of the subsidiary files associated with these.





5. Go to the Student Load/Status Rules (STLD) form.

Colleague displays the STLD form with the cursor at the Academic Level LookUp prompt.

6. Enter the academic level for which you want to define student load rules.

Colleague displays the academic level in the header. The cursor is at the first line of the Student Load Rules group.

7. Enter the name of the student load rule.


If the rule displays on the form and the cursor moves to the Load field, continue with Step 11.

8. Enter A.


9. Enter the student load rule.



10. Save the rule.

The STLD form redisplays with the cursor in the Load field.

11. Enter the student load code Colleague assigns when this rule is true.


Ge

The cursor moves to the next line in the student load rules group.

12. Repeat this procedure, beginning with Step 7, for each student load rule.


Student Term Status Rules

Colleague automatically assigns student term statuses according to the statuses of the student’s courses for an academic term. If you want Colleague to assign the student term statuses using other criteria, you can define rules which Colleague will use instead of the default.

When Colleague Evaluates Student Term Status Rules

Colleague evaluates your student term status rules when you run the Recalculate Term Status/Load (RTSL) process.

How to Define Student Term Status Rules

Use the Student Load/Status Rules (STLD) form to associate your rules with the student term status Colleague assigns when the rule is true. Use the STUDENT.TERMS file as the primary file view for your student term status rules.

For example, Ellucian University has defined a set of student term status rules as shown in Figure 26.


Ge

Figure 26: Example of Defining Student Term Status Rules

Procedure for Defining Student Term Status Rules

Complete the following procedure to define your student term status rules.

1. Define your student term status codes.

See “Student Term Statuses” on page 280.


Use the worksheet “Student Term Status Rules — English Statements” on page 447.


Note: The data elements you use must be from the STUDENT.TERMS file, or one of the subsidiary files associated with these.


Ge





5. Go to the Student Load/Status Rules (STLD) form.

Colleague displays the STLD form with the cursor at the Academic Level LookUp prompt.

6. Enter the academic level for which you want to define student term status rules.

Colleague displays the academic level in the header. The cursor is at the first line of the Student Load Rules group.

7. Go to the Student Term Status Rules field.

The cursor moves to the first line of the Student Term Status Rules group.

8. Enter the name of the student term status rule.


If the rule displays on the form and the cursor moves to the Status field, continue with Step 12.

9. Enter A.


10. Enter the student term status rule.



11. Save the rule.

The STLD form redisplays with the cursor in the Load field.

12. Enter the student term status code Colleague assigns when this rule is true.

The cursor moves to the next line in the student term status rules group.

13. Repeat this procedure, beginning with Step 10, for each student term status rule.



Ge

Defining Academic Records Parameters

In This Chapter

Topics in this chapter will first help you understand what academic parameters are and why they are used and then how to define them for your institution.

Understanding Academic Records Parameters

The parameters for the Academic Records module let you set data entry defaults as well as define areas where specific processing occur automatically. Define these parameters on the Academic Records Parameters (ACPR) form, shown in Figure 27. Each of these parameters is explained below.

Figure 27: Academic Records Parameters (ACPR) Form

Academic Standing Default Rules

Print Restriction Rules

Withdrawal Approval

356tting Started with Colleague Student | Defining Academic Records Parameters

Ge

Noteworthy Fields on the ACPR Form

The following fields are particularly useful when setting up the academic records parameters.

Generate Random IDs

If your institution uses blind grading to insure impartiality, Colleague can generate unique random ID numbers based on either academic terms or course sections. For example, law schools often assign random ID numbers to each student in a course section. Grades can then be entered in Colleague using these random IDs.

You can generate random ID numbers by indicating your choice of either term or course section on the Academic Records Parameters (ACPR) form. If you select “Term,” Colleague assigns a unique random ID to every student when they are assigned an academic term. If you select “Section,” Colleague assigns a unique random ID to every student when they register for a course section.

If you leave the Generate Random IDs field blank on the ACPR form, Colleague does not assign random IDs. You then cannot assign grades using the Final Grading by Random ID (FGRR) form or the Midterm Grading by Random ID (MGRR) form.

Academic Level Standing Default Rules

Colleague calculates a student’s academic level standing and academic level term standing based on rules that you define. If you choose to set up one or all of your academic levels or academic terms without associated standing rules, you need to define default standing rules. Colleague uses these default academic standing rules whenever it is calculating standing for a student with an academic level which has no associated standing rules.

Each academic level standing rule has an associated academic standing code that Colleague assigns to the student if the rule is evaluated as true.

See “Academic Standing Rules” on page 331 for information about defining specific academic standing rules.

Transcript/Grade Print Restrictions

If there are conditions under which you would not allow a student to receive a printed copy of their transcript or grades, Colleague lets you define these restrictions by detailing to other forms from the Academic Records Parameters (ACPR) form. For example, you may want to withhold a student’s transcript if the student has outstanding parking violations on his record.

These restrictions are defined using rules. See “Print Restriction Rules” on page 346 for information about how to set up these restriction rules.

Petition Status

When you assign petitions for a student, there is an associated petition status code. If you enter a default value on the Academic Records Parameters (ACPR) form, Colleague puts


Ge

this value into the student’s record whenever a petition is added. If you do not define a default, then the petition status must be entered manually every time a petition is added to a student.

For example, you might set the default petition status code to “P,” for Pending. Whenever you add a petition, the petition status would automatically be set to “P.” This default value can be changed to another valid petition status code at data entry.

Withdrawal Approval Required

Your institution may choose to require certain withdrawal approvals before a student may officially withdraw. On the Academic Records Parameters (ACPR) form you can set defaults for three required approvals. These three defaults are yes/no parameters specifying whether or not specific approval is required before a student may officially withdraw. Examples of offices that may require such approval are the dean’s office, the registrar, and the business office.

If you set any of these defaults to “Yes,” the corresponding approval must be recorded on the Student Withdrawal (SWTH) form before Colleague will update the applicable files. For example, if you set the Withdrawal Approval 1 Required field to “Yes” on the Academic Records Parameter (ACPR) form, then the Approval 1 field must be filled in on the SWTH form before a student may officially withdraw. If the parameter field is set to “No,” then the Approval 1 field may be left blank.

See Using Academic Records for more information about how these approvals are used.

Comparison Grade Scheme

If your institution has implemented multiple grade schemes, use this field to select the Comparison Grade Scheme that you want to use. The Comparison Grade Scheme allows you to normalize grades from other grade schemes.

When you select a Comparison Grade Scheme, grades in that grade scheme will be available for selection in the Comparison Grade field on the Grade Codes (GRDC) form. From the GRDC form, grades in your institution’s various grade schemes can be defined with a Comparison Grade from the Comparison Grade Scheme.

The Comparison Grade enables requisite checking, and Degree Audit program evaluation.

Warning! If the Comparison Grade Scheme is changed or deleted, then all associations to it will be removed.

Procedure for Defining Academic Records Parameters

Follow the steps below to define the default parameter for the Academic Records module.

1. Read “Defining Academic Records Parameters” on page 356.


Ge

You may also want to read some of the chapters which describe the processing that these parameters define to get a complete understanding of how the parameters affect these processes.

2. Read “Academic Standing Rules” on page 331.

Read “Print Restriction Rules” on page 346.

3. Complete the worksheet “Academic Records Default Parameters” on page 448.

4. Use the Academic Records Parameters (ACPR) form to define your parameters.


Ge

Setting Up Active Military and Veteran Student Information

In This Chapter

This chapter describes how to set up and track information for active military and veteran students. The following sections detail this process:

• Tracking Active Military Student Information

• Tracking Veteran Student Information

• Tracking Servicemembers Opportunity Colleges (SOC) Agreement Information

• Setting Up Military and Veteran Student Parameters

• Using the Enrollment Activity Report

360tting Started with Colleague Student | Setting Up Active Military and Veteran Student Information

Ge

Before You Begin

Before you can set up active military and veteran student information, the following codes should be set up in Colleague:

Tracking Active Military Student Information

The following forms are used to track information for active military students.

• Military Student Information (MILS)

• Person Military Statuses (PEMS)

Table 126: Codes Needed Before You Can Track Military Students

Description Reference

DEGREE.TYPES Refer to “Defining Colleague Student Codes” on page 137 for information about defining these codes.MIL.BEN.ELIGIBILITY.CODES

MIL.BENEFITS

MIL.PAY.GRADES

MIL.STATUSES

MIL.VET.REMARK.CODES

MIL.VET.REMARK.TYPES

PERSON.MILITARY.BRANCHES

PERSON.MILITARY.STATUSES

PROGRAM.DESIGNATIONS

SOC.SERVICE.PROGRAMS

SOC.BRANCHES.OF.SERVICE

SOC.CREDIT.TYPES

SOC.NETWORKS

SOC.SERVICE.PROGRAMS

VA.CERTIFICATION

VA.FORMS

VET.BEN.ELIGIBILITY.CODES

VETERAN.BENEFITS


Ge

• Military/Veteran Student Remarks (MVSR)

These are described in the sections below.

Entering Information for Active Military Students

Use the Military Student Information (MILS) form to enter information related to military service and benefits for a student who is an active military servicemember, or the spouse or dependent of an active military servicemember. This form contains information about various military benefits for this student, any Servicemembers Opportunity Colleges (SOC) Student Agreements, and other military-related information.

Figure 28: The Military Student Information (MILS) Form

Noteworthy Fields on the MILS Form

The fields described in this section are important for tracking active military students. See online help for information about other fields.

Primary Military Status

Displays the latest primary military status and branch for the student. Detail on this field to access the Person Military Statuses (PEMS) form to enter information for student military statuses and status history. For more information about the PEMS form, see “Entering Military Statuses” on page 367.

Primary Military Status Start/End Dates

The starting and ending date of the Military Status are displayed.


Ge

Selective Serv Reg

Enter Yes if the student has registered for selective service; otherwise, enter No.

Number

If the person has registered for selective service under the laws of the United States, enter his registration number in this data field in the format 99-9999999-9. If the person is not required to register, leave this field blank.

Remarks

Detail to enter remarks on the Military/Veteran Student Remarks (MVSR) form about this active military student, or spouse or dependent of an active military servicemember. For more information about the MVSR form, see “Entering Remarks for Active Military or Veteran Students” on page 368.

Cur SOC Elig

Enter Yes if this student is eligible for a Servicemembers Opportunity Colleges (SOC) Student Agreement. This field is applicable only if this student is an active military servicemember, or a spouse or dependent of an active military servicemember.

If you enter “Yes” in this field, then today’s date will default in the SOC Elig Dt field.

SOC Elig Dt

Enter the date when the student is eligible for a Servicemembers Opportunity Colleges (SOC) Student Agreement. This date defaults to today’s date when the Cur SOC Elig field is set to “Yes,” but can be changed.

Visiting Student

Enter Yes if this student is enrolled at another institution, but is taking classes at this institution. Leave this field blank if the student is not enrolled at another institution.

A student who is enrolled at another institution, but taking classes at this institution is referred to as visiting student or a “reverse transfer” student.

Visiting From

Enter the institution where the student is enrolled.

If this student is a visiting student, enter the institution where the student is enrolled. Military or veteran terminology may refer to this as the host institution or the parent school. This institution must be on the list of institutions that the student has attended, on the Institutions Attended Summary (IASU) form. If the institution is not displayed, detail to the IASU form to add it.


Ge

Military Installation

Enter the military installation where the servicemember is stationed. This student will be the servicemember, or the spouse or dependent of the servicemember. You can use the Military Installation LookUp to enter this information.

The military installation must be on the MIL.INSTALLATIONS file. To add a new military installation, access the Military Installations (MINS) form.

GEO Ed Center

If applicable, this field displays the GEO Ed center that is associated with the Military Institution. GEO Ed centers are entered on the Military Installations (MINS) form.

Overall Comm Code

When you enter a communication code and then save the information on this form, this code is assigned to this student. You can use the Comm Code LookUp to enter this information.

If a default communication code has been entered on the Military & Veteran Student Parameters (MVSP) form in the Overall Military field, that code is used on new records. This default can be added or changed.

Branch

Select the military branch under which the student qualifies for active military benefits.

Your institution’s military branches are defined on the SOC.BRANCHES.OF.SERVICE validation table by using the Validation Codes (VAL) form in the ST application.

Military Benefit Elig Code

Select the appropriate code indicating how this student qualifies for active military benefits.

Your institution’s military statuses are defined on the MIL.BEN.ELIGIBILITY.CODES validation table by using the Validation Codes (VAL) form in the ST application.

Military Benefit

Select an active military benefit for which this student qualifies. Use this field to track any benefits related to active military service that this student receives. You can also enter benefits that this student previously received or may receive in the future by using the Start Dt and End Dt fields to show a specific time frame for the benefits.

Your institution’s military benefits are defined on the MIL.BENEFITS validation table by using the Validation Codes (VAL) form in the ST application.


Ge

Start Dt

Enter the beginning date for this benefit. Use this field to indicate whether the benefit is current for this student. This field allows you to track information about previous, current, and future active military benefits.

End Dt

Enter the ending date for this benefit. Use this field to indicate whether the benefit is current for this student. This field allows you to track information about previous, current, and future active military benefits.

Comm Code

When you enter a communication code, and then save the information on this form, this code will be assigned to the student. The default communication code comes from the Military & Veteran Student Parameters (MVSP) form in the Military Student Benefits field, and is used when data is changed on this row of the window. This default can be removed or changed.

SOC Serv Program

Select the appropriate service program for the Servicemembers Opportunity Colleges (SOC) Student Agreement for this student. This field is required for each SOC Student Agreement.

These values are defined on the SOC.SERVICE.PROGRAMS validation table in the ST application and are maintained by Ellucian.

Acad Program

Select the academic program to which this SOC Student Agreement applies. The list of programs is limited to those programs associated with this student. This field is required for each SOC Student Agreement.

If the academic program has not been previously associated with the student, access the Student Academic Program (SACP) form to add it.

Installation

Enter the military installation where the servicemember was stationed when this SOC Student Agreement was made. This student will be the servicemember, or the spouse or dependent of the servicemember. You can use the Military Installation LookUp to enter this information.

The military installation must be on the MIL.INSTALLATIONS file. To add a new military installation, access the Military Installations (MINS) form.


Ge

Branch

Select the branch of the armed forces under which this SOC Student Agreement was made. This is the branch of service that is associated with the servicemember’s MOS and pay grade for this SOC Student Agreement.

Your institution’s military branches are defined on the PERSON.MILITARY.BRANCHES validation table by using the Validation Codes (VAL) form in the CORE application.

MOS/Rating

Enter the servicemember’s military occupational specialty (MOS), which is known as rating in some branches of the armed services. For example: CGW-ELC-002. This is the MOS that will be reported on the SOC Student Agreement, and is associated with the branch of military service and pay grade for this SOC Student Agreement.

Pay Grade

Select the servicemember’s pay grade. For example: E-7. This is the pay grade that will be reported on the SOC Student Agreement, and is associated with the branch of military service and MOS for this SOC Student Agreement.

Your institution’s military pay grades are defined on the MIL.PAY.GRADES validation table by using the Validation Codes (VAL) form in the CORE application.

Cmpl Dt

Enter the date on which this SOC Student Agreement was initially completed.

Updt Dt

Enter the date when this SOC Student Agreement was last updated. If you enter a date and there is an associated completion date, the Update Date must be on or after the date entered in the Cmpl Dt field.

Posted Dt

Enter the date when this SOC Student Agreement was sent to an external entity, such as SOC. For institutions that post the SOC Student Agreement to the GoArmyEd portal, use this field to store the date the agreement was posted to GoArmyEd.

If you enter a date and there is an associated completion date, the posted date must be on or after the date entered in the Cmpl Dt field.


Ge

Entering Military Statuses

Note: You can access the PEMS form directly, or detail from the Military Student Information (MILS) or the Veteran Students Information (VETS) forms by detailing on the Primary Military Status field.

Use the Person Military Statuses (PEMS) form to enter information specific to military or veteran statuses. Use the PEMS form to access information about a person’s military status and status history. Only one status in any given date range can be designated as primary. Each status consists of a status, branch, start date, and end date. Data on this form is sorted in reverse chronological order.

Figure 29: The Person Military Statuses (PEMS) Form

Noteworthy Fields on the PEMS Form

The fields described in this section are important for entering military statuses for a person. See online help for information about other fields.

Military Status

Select the military status for the person. Each Military Status is identified using the status, branch, and start and end dates. Only one status in any given date range can be designated as primary. Select the appropriate military status for this person.

Branch

Select the branch of the armed services that applies to this person.


Ge

Start Date

Enter the beginning date on which this Military Status became effective for the person. Military Statuses may change over time and must be identified with a start date.

End Date

If applicable, enter the last date on which this military status was in effect for this person. Military Status changes are identified by adding a new line for the new status and ending the existing or old Military Status.

Primary

Enter Yes if the military status that corresponds to this field is the primary status for this person; otherwise, enter No. Only one primary military status may be identified for any given time period

Entering Remarks for Active Military or Veteran Students

Note: You can access the MVSR form directly, or detail from the Military Student Information (MILS) or the Veteran Students Information (VETS) forms by detailing on the Remarks field.

Use the Military/Veteran Student Remarks (MVSR) form to record remarks about a student who is an active military servicemember or veteran, or the spouse or dependent of an active military servicemember or veteran.

Remarks are similar to comments that you enter about a person, except that after you enter a remark, you can select codes to categorize the remark. You can then use these codes for reporting or printing specific categories of remarks.

Before you can enter any information about a remark on the MVSR form, you must first detail to the UTEDTC Military/Veteran Student Remarks form and enter the remark. After saving the remark, you are returned to the MVSR form, where you can enter the appropriate codes and other information related to your remark.

The following two fields on the MVSR form allow you to select codes that your institution has defined for use with remarks:

• Type. Indicates the type of remark.

• Reference. Identifies the source of the remark.


Ge

Figure 30: The Military/Veteran Student Remarks (MVSR) Form

Noteworthy Fields on the MVSR Form

The fields described in this section are important for entering remarks about a student who is an active military servicemember or veteran.

[Remark Entry]

Detail to add or update the text of a remark for this student. To add the text for a new remark for this student, move to the first blank line in the window and detail to the UTEDTC Military/Veteran Student Remarks form. To update the text of an existing remark, detail on the line containing the remark that you want to update.

You cannot enter data in any of the other fields in this window group without first entering a remark on the UTEDTC form.

Type

Select a code defined by your institution that indicates the type of remark you are entering for this student.

Your institution’s codes used for this field are defined in the MIL.VET.REMARK.TYPES validation table by using the Validation Codes (VAL) form in the ST application.

Author

Enter the author of this remark. Enter the ID number, name, or other identifying data of the person on staff who provided this remark.


Ge

Reference

For this remark, select a code defined by your institution that describes the source of the information you are entering for this student.

Your institution’s codes used for this field are defined on the MIL.VET.REMARK.CODES validation table by using the Validation Codes (VAL) form in the ST application.

Date

Enter the date on which this remark was added. This date defaults to today’s date when the remark is saved on the detail form UTEDTC Military/Veteran Student Remarks form, but can be changed.

Text

Displays the first line of the text entered for the remark on the detail form UTEDTC Military/Veteran Student Remarks.

Procedure for Entering Active Military Student Information

1. Access the Military Student Information (MILS) form. Enter information related to military service and benefits for a student who is an active military servicemember, or the spouse or dependent of an active military servicemember. For more information about the MILS form, see online help.

2. (Optional) Detail on the Primary Military Status field to access the Person Military Statuses (PEMS) form to enter information for student military statuses and status history. For more information about the PEMS form, see online help. Save your information to return to the MILS form.

3. (Optional) Detail on the Remarks field to enter remarks on the Military/Veteran Student Remarks (MVSR) form about this active military student, or spouse or dependent of an active military servicemember. For more information about the MVSR form, see online help. Save your information to return to the MILS form.

4. (Optional) In the Visiting From field, if this institution has not been previously associated with the student, detail to the Institutions Attended Summary (IASU) form to add it. For more information about the IASU form, see online help. Save your information to return to the MILS form.

5. In the Acad Program field, if the academic program has not been previously associated with the student, access the Student Academic Program (SACP) form to add it. For more information about the SACP form, see online help.Save your information to return to the MILS form.

6. (Optional) Detail on the following fields to track additional information for the student:

• Demographic Info

• Transfer and Equivalency Info


Ge

• Admissions Info

• Financial Aid Info

• Student Academic Info

• Contact and Appt Summary

• Accounts Receivable Info

• Communications Management

7. Save information on any detail form that you visited.

8. Save your information on the MILS form.

Tracking Veteran Student Information

The following forms are used to track information for veteran students.

• Veteran Students Information (VETS)

• Person Military Statuses (PEMS)

• Military/Veteran Student Remarks (MVSR)

• Veteran Student Term Information (VTRM)

• VA Forms Expiration Notification (VAFE)


Entering Veteran Students Information

The Veteran Students Information (VETS) form allows you to enter information specific to veteran students and eligible family members. Use the VETS form to access information regarding veteran students that is specific to their military career. Use this data for decision-making regarding VA program benefits, VA Certification, and also for ad-hoc reporting purposes.


Ge

Figure 31: The Veteran Students Information (VETS) Form

Noteworthy Fields on the VETS Form

The fields described in this section are important for entering information about a student who is a veteran. See online help for information about other fields.

Primary Military Status

Displays the latest primary military status and branch for the student. Detail on this field to access the Person Military Statuses (PEMS) form to enter information for veteran student statuses and status history.

Start Date

Displays the Start Date for the primary Military Status.

End Date

Displays the End Date for the primary Military Status.

VA File Number

Enter the VA File Number for this student. The data in this field is encrypted for storage in the database. This data will typically contain all or part of the student’s Social Security number.


Ge

Visiting Student

Enter Yes if this student is enrolled at another institution, but is taking classes at this institution. Leave this field blank if the student is not enrolled at another institution.

A student who is enrolled at another institution, but taking classes at this institution is referred to as visiting student or a “reverse transfer” student.

Visiting From

Enter the institution where the student is enrolled.

If this student is a visiting student, enter the institution where the student is enrolled. Military or veteran terminology may refer to this as the host institution or the parent school. This institution must be on the list of institutions that the student has attended, on the Institutions Attended Summary (IASU) form. If the institution is not displayed, detail to the IASU form to add it.

Citizenship

Displays the citizenship of this student. This field is maintained on the Biographic Information (BIO) and Foreign Person Information (FINF) forms.

Overall Comm Code

Enter a communication code to assign to this student.

When you enter a communication code, and then save the information on this form, this code will be assigned to the student.

If a default communication code has been entered on the Military & Veteran Student Parameters (MVSP) form in the Overall Veteran field, that code is used on new records. This default can be removed or changed.

Remarks

Detail to enter remarks on the Military/Veteran Student Remarks (MVSR) form about this veteran student, or spouse or dependent of a veteran.

Active Military Info

Detail to access the Military Student Information (MILS) form and view or maintain information about an active military student.

Veteran Benefit

Select a veteran benefit for which this student qualifies.

Use this field to track any benefits related to this student’s veteran status that the student receives. You can also enter benefits that this student previously received or may receive


Ge

in the future by using the Start Date and End Date fields to show a specific time frame for the benefits.

Start Dt

Enter the beginning date for this benefit. Use this field to indicate whether the benefit is current for this student. This field allows you to track information about previous and future veteran benefits.

End Dt

Enter the date on which this benefit ends.

Use this field to indicate whether the benefit is current for this student. This field allows you to track information about previous and future veteran benefits.

Delimiting Dt

Enter the date by which the veteran must use this benefit, if applicable.

Veteran Benefit Elig Code

Select a veteran benefit eligibility code for this student.

The Veteran Benefit Eligibility codes are defined on the VET.BEN.ELIGIBILITY.CODES validation table by using the Validation Codes (VAL) form in the ST application.

Branch

Select the branch of the armed services related to this veteran benefit.

The Branch codes are defined on the PERSON.MILITARY.BRANCHES validation table by using the Validation Codes (VAL) form in the Core application.

Comm Code


When you enter a communication code, and then save the information on this form, this code will be assigned to the student. The default code comes from the Military & Veteran Student Parameters (MVSP) form and is used when data is added or changed in the Veteran Benefits window. This default can be removed or changed.

VA Forms

Select the applicable VA forms for the student.

The VA forms that have been received from the student are recorded here, along with an associated expiration date, if applicable. You can also enter or modify the communication code for each form recorded. If there is a communication code recorded, then it will be assigned to the student when you save the VA forms data.


Ge

The VA Forms codes are defined on the VA.FORMS validation table by using the Validation Codes (VAL) form in the ST application.

Exp Date

VA Forms may expire. If the form you are entering has an expiration date, then enter it here.

Comm Code

When you enter a communication code, and then save the information on this form, this code will be assigned to the student. The default code comes from the Military & Veteran Student Parameters (MVSP) form and is used when data is added or changed in this window. This default can be removed or changed.

Term

After a student registers for classes within a term, the term is displayed here. For more information, detail to access the Veteran Student Term Information (VTRM) form.

Acad Lvl

After a student registers for classes, the Academic Level associated to the Term for which the student is registered is displayed.

Reg Cred

After a student registers for classes within a specific term and academic level, then the total credits that the student registered for within this term and academic level are displayed.

Net Cert Amt

Enter the Net Certified Amount for this Term and Academic Level.

When a student has registered for classes with a specific term and academic level, then you can enter a Net Certified Amount on that term and academic level. Detail on the Term field to access the Veteran Student Term Information (VTRM) form, and then enter specific information for VA certification per course.

Entering Military Statuses

For information on entering military statuses for veterans, see “Entering Military Statuses” on page 367.


Ge

Entering Remarks for Veteran Students

For information on entering remarks for veterans, see “Entering Remarks for Active Military or Veteran Students” on page 368.

Recording a Student’s VA Certifications

The Veteran Student Term Information (VTRM) form allows you to record a student’s VA certifications for a term and academic level.

Because this process provides information about whether each of the student’s courses in this term applies towards a VA program, the system will determine whether results of a previous degree audit evaluation are available for the selected student program, and the student’s program will be evaluated if no evaluation results are found.

The VTRM form displays all of this student’s registration activity for the selected term and academic level, and allows you to indicate whether each section is certified for this student. This form also allows you to research and enter the net certified amount.

Note: If a net certified amount is entered and a default communication code was specified on the Military & Veteran Student Parameters (MVSP) form in the VA Net Certified Amount field, that communication code will display on this form. You can enter, change, or delete the communication code as appropriate. If you save from this form with an entry in the Comm Cd field, that communication code will be posted to this student’s record.

Figure 32: The Veteran Student Term Information (VTRM) Form


Ge

Noteworthy Fields on the VTRM Form

The fields described in this section are important for entering a student’s certifications for a term and academic level. See online help for information about other fields.

Stu Term Stat

Displays the status of this student in this term, in descending date order, so the most recent status is always first.

[Stu Term Stat] Dt

Displays the date of the associated status for this student in this term.

Selected Stu Pgm

Displays this student's academic program. If this student has more than one academic program in this academic level, it displays the one that you selected when you accessed this form.

[Stu Pgm] Start Dt

Displays the date that this student program began for this student. If the student has started and stopped and then restarted, this displays the most recent start date.

Pgm Stat

Displays the most recent status of this student program.

Ant Cmpl

Displays the date this student is expected to complete this academic program.

Loc

Displays the location that is associated with this student’s academic program.

Deg

Displays the degree that is associated with this academic program.

Last Eval Date/Time

Displays the date and time when the Degree Audit program evaluation was run for this student program. If changes have occurred after this date that might affect the evaluation results, use the Evaluate Student Program (EVAL) form to run a new evaluation. Otherwise, the information displayed in the VA Pgm column may be outdated.


Ge

For more information about evaluating student programs, see the Using Degree Audit manual.

Section Name

Displays a list of course sections for the student for the term for the academic level. This includes only courses from this institution, not equivalencies from tests or transfer courses.

Stat

Displays the most recent status related to this student’s enrollment in this section.

Stat Dt

Displays the date associated with the most recent status for this student’s enrollment in this section.

Billing Amt

Displays the billing amount that is directly attributable to this student’s enrollment in this section. This is the same value that is shown for the same course section in the top panel of the Registration Billing Summary (RGBS) form for this student and term. This does not include any term-based charges that do not arise directly from a specific course section.

VA Pgm

This field indicates whether this course applies to a VA program for this student.

If the Selected Stu Pgm is not designated as a VA program, this field will display “No.”

If the Selected Stu Pgm is designated as a VA program:

• If this course applies to that program, this field will say Appl (Applied).

• If this course does not apply to that program, but is related, this field will say Rel (Related).

The system uses a Degree Audit evaluation to determine whether a course applied to a student’s program. Be aware that an evaluation is a snapshot of a student’s degree progress at a moment in time. You may see different evaluation results if you run the evaluation again at a different point time. If existing evaluation results are available, those will be used; otherwise, the system will evaluate this student’s program when this form is opened.

There are three variations of applied courses:

1. Courses that are fully applied to the program’s requirements.

2. Courses that apply, but are extra.

3. Courses that apply only to the student’s GPA.


http://clients.datatel.com/apps/objectViewer.cfm?referrerID=647ADE24-5056-9F79-EBEA190443FAAD26&objectID=873EEEBD-B799-11D5-AF510002A5070708

Ge

If you need detailed information about how a student’s courses apply to their student program, look at a Degree Audit evaluation report for that student’s program.

Pgm Cert

Displays the academic program that was used as the criteria for determining whether to certify this student’s course section. This will be blank unless the Stu Cert field for this course section indicates it has been certified. The system automatically sets this field when the Stu Cert field is entered.

Repeat

Displays “Yes” if this is a repeated course.

You can detail to the Student Course Repeat (STRP) form to view full information about each of the times this student has taken this course.

Reg Cred

Displays the number of credit or clock hours for which the student registered.

Stu Cert

Select a code to indicate VA certification for this student. This field indicates whether this course section has been VA certified for this student.

Cert Dt

Enter the date when the certification decision was made for this course section for this student.

Total Section-based Charges

Displays the sum of the Billing Amt values for all the course sections displayed in the Course Sections window.

Net Certified Amount

Enter the net amount that was certified to the Veterans Administration (VA) for this term and academic level for this student.

Net Certified Amount Dt

Enter the date that the net amount was certified to the Veterans Administration (VA) for this term and academic level for this student.


Ge

Remarks

Detail to enter remarks on the Military/Veteran Student Remarks (MVSR) form about this active military or veteran student, or spouse or dependent of an active military servicemember or veteran.

Comm Cd


When you enter a communication code, and then save the information on this form, this code will be assigned to this student.

If a default communication code has been entered on the Military & Veteran Student Parameters (MVSP) form in the VA Net Certified Amount field, that code is used when the Net Certified Amount is entered or changed on this form. This default can be removed or changed.

Procedure for Tracking Veteran Students Information

1. Access the Veteran Students Information (VETS) form. Enter information for the veteran student. For more information about the VETS form, see online help.

2. (Optional) Detail on the Primary Military Status field to access the Person Military Statuses (PEMS) form to enter information for student military statuses and status history. For more information about the PEMS form, see online help. Save your information to return to the VETS form.

3. In the Visiting From field, if this institution has not been previously associated with the student, detail to the Institutions Attended Summary (IASU) form to add it. For more information about the IASU form, see online help. Save your information to return to the VETS form.

4. (Optional) Detail on the Remarks field to enter remarks on the Military/Veteran Student Remarks (MVSR) form about this veteran student, or spouse or dependent of a veteran. For more information about the MVSR form, see online help. Save your information to return to the VETS form.

5. If a student has registered for classes with a specific term and academic level, then you can enter a Net Certified Amount on that term and academic level. Detail on the Term field to access the Veteran Student Term Information (VTRM) form, and then enter specific information for VA certification per course. The VTRM form allows you to view additional information that is available when a student registers for classes within a term.Save your information to return to the VETS form.

6. (Optional) Detail on the following fields to track additional information for the student:

• Demographic Info

• Transfer and Equivalency Info

• Admissions Info

• Financial Aid Info


Ge

• Student Academic Info

• Contact and Appt Summary

• Accounts Receivable Info

• Communications Management

7. Save information on any detail form that you visited.

8. Save your information on the VETS form.

Notifying VA Students About Expiring VA Forms

Use the VA Forms Expiration Notification (VAFE) form to select all VA students who have VA forms that will expire within a defined time frame, and to assign a Document code to these students. The date is calculated based on a number of months to notify these students in advance. The Document code will notify the students of any VA forms that will be expiring on or before this calculated date.

Figure 33: The VA Forms Expiration Notification (VAFE) Form

Noteworthy Fields on the VAFE Form

The fields described in this section are important for assigning a Document code to students who have VA forms that will expire within a defined time frame.

Processing Option

Select the processing option.


Ge

Select the appropriate processing option. The options are:

• R – Report Only

• G – Generate LTREQ records and Print Report

Document to Send

Enter the Document code, or use LookUp to select the Document code to send to the students. The Document code entered here will be assigned to each person who has a VA form that will expire within the time frame defined in the Months Prior to Expiration field.

Expiration dates for VA forms are entered on the Veteran Students Information (VETS) form.

Months Prior to Expiration

Enter how many months in advance that you want to notify students of the expiration of their VA forms. Each VA student with a VA form that will expire before the number of months defined here will be assigned the Document code specified in the Document to Send field. A date is calculated and displayed.

Benefits Expiration date

Displays the date calculated from the Months Prior to Expiration field. Any VA student with a VA form that has an expiration date before this date will be assigned the Document code specified in the Document to Send field.

Procedure for Notifying VA Students About Expiring VA Forms

1. Access the VA Forms Expiration Notification (VAFE) form.

2. Select the appropriate processing option and document code.

3. Enter how many months you want to use to find VA forms that will expire. A date is calculated and displayed.

Any VA student with a VA form that has an expiration date before this date will be assigned the Document code you specified.

4. Save your information on the VAFE form.

Tracking Servicemembers Opportunity Colleges (SOC) Agreement Information

A Servicemembers Opportunity Colleges (SOC) Student Agreement is a degree plan specifically for students who serve as active duty military and their eligible family


Ge

members. The SOC Agreement Generation (SOCG) process generates a SOC Student Agreement that is saved in Excel on the user’s computer. This agreement can be saved and edited before finalizing it for submission to SOC or the student.

The SOC Student Agreement is populated with data from the Degree Audit Evaluation process that is utilized in the SOC Agreement Generation (SOCG) process.

A record of the SOC Student Agreements generated can be maintained in Colleague on the Military Student Information (MILS) form, including the dates on which they were completed, updated and posted.

The following forms are used to track information for active military students.

• SOC Agreement Generation (SOCG)

• Edit SOC Agreement Template (SOCT)


The SOC Agreement Header

When generating a SOC Student Agreement, Colleague populates information in the header of the agreement if it is maintained in the system.

1. The SOCAD[], SOCNAV[], etc. checkboxes come from the SOC Service Program field on the Military Student Information (MILS) form.

2. The Associates or Bachelors checkboxes come from the special processing code of the Degree Type of the Degree associated with the Academic Program.

3. The Also Army Career Degree checkbox is populated from the Army Career Deg field on the Academic Programs (PROG) form for the Academic Program, and then subject to some rules.

4. The College Name comes from the Host Organization specified on ID and LookUp Parameters (PID2) form.

5. The DNS Network comes from the Network field associated with the SOC Degree Network Service Program specified on the PROG form for the Academic Program.

6. The Degree Title comes from the Title of the Academic Program on the PROG form, or the Custom Program Title for the student on Student Acad Program Addition (STPA) form if specified.

7. The Student Name is formatted from the PREFERRRED name and address hierarchy.

8. The Branch of Service (or “Family”) is taken Branch field in the SOC agreement window on the MILS form.

9. The Pay Grade comes from the Pay Grade field in the SOC agreement window on the MILS form.

10. The MOS /Rating comes from the MOS/Rating field in the SOC agreement window on the MILS form.

11. The Mil. Installation comes from The Installation field in the SOC agreement window on the MILS form.


Ge

12. The Signature of College Official, Name of College Official, and Title are not automatically filled in by Colleague. The Date associated with the signature is set to the current date by Excel formula.

13. The Semester Hours and Quarter Hours checkboxes are not automatically set by Colleague. These should be set in the Excel template using the Edit SOC Agreement Template (SOCT) form, so that they are already populated as each new SOC agreement is generated.

14. Other Degree Requirements (residency, GPA, etc.) is populated with information about required GPA and Institutional credits, but should be suitably edited by the user in the final version of the SOC agreement.

Header fields that will need to be populated by the institution include the following. Institutions can modify the template so that every SOC Student Agreement produced already has this information reflected, where applicable:

• Signature of College Official

• Name of College Official and Title

• Semester Hours or Quarter Hours

• Other Degree Requirements

Edit SOC Agreement Template

Use the Edit SOC Agreement Template (SOCT) form to edit the Microsoft Excel template used when generating a SOC Student Agreement on the SOC Agreement Generation (SOCG) form.

Figure 34: The Edit SOC Agreement Template (SOCT) Form

Users can modify the fixed portions of the template that will be included in all generated SOC Student Agreements. For example, you may want to permanently check either


Ge

Semester Hours or Quarter Hours in the template, or you may want to add standard comments to the bottom of the worksheet.

Note: Any modifications to the data output reflected on the SOC Student Agreement can be made directly on each SOC Student Agreement produced for the student from the SOCG process before sending it to SOC or to the student.

Generating a SOC Agreement

Use the SOC Agreement Generation (SOCG) form to generate a SOC Student Agreement.

Figure 35: The SOC Agreement Generation (SOCG) Form

Before a SOC Student Agreement can be generated on the SOCG form, information for the agreement must be entered for a student on the Military Student Information (MILS) form. You can detail to the MILS form, if necessary.

After you select a student for whom you want to create an agreement, enter Yes in the Select to Generate field, choose any additional options, and then save the form. The SOCG process will create two files:

• SOC.AGREEMENT.TEMPLATE.XLSM. This file incorporates the SOC-specified formatting in a Microsoft Excel template file.

• SOCDATA_ nnnnnn_nnnnnnnn_nnnn. XML (where n represents numerical data). This file contains the data for the student.

You will be led through a series of prompts that allow you to save these two files. After you save the files to a location of your choice, you are returned to the SOCG form.


Ge

You must now use these two files to create the SOC Student Agreement for this student. To do this, follow these steps:

1. Access the folder where you saved the Excel template file. Doubleclick the file to open it.

2. Click the Generate SOC Agreement From XML Data File button in the Excel worksheet. The Browse dialog box will appear.

3. Doubleclick the XML data file for this student.

A new Excel window will launch and automatically populate a worksheet to create a SOC Student Agreement with the information from the student's data file.

You can make any modifications necessary to the SOC Student Agreement for a student before sending it to SOC or to the student. When you are done, save the SOC Student Agreement to a location of your choice.

When generating a SOC Student Agreement, you may also elect to maintain the following fields to designate your SOC Student Agreement dates as part of the generation process. These fields are located on the SOCG form:

• Completed Date (Enter the date when the SOC Student Agreement was originally completed)

• Update Date (Enter the date when the SOC Student Agreement was last updated. If you enter a date and there is an associated completion date, the Update Date must be on or after the date entered in the Completed Date field.

• Posted Date (Enter the date when this SOC Student Agreement was sent to an external entity, such as SOC. For institutions that post the SOC Student Agreement to the GoArmyEd portal, use this field to store the date the agreement was posted to GoArmyEd).

In addition, you can detail to the Military Student Information (MILS) form to maintain other data about the SOC Student Agreement.

Requirements, Subrequirements, and Groups

The SOC Student Agreement format is a list of required courses, while Colleague degree requirements are a three level hierarchy of requirement, subrequirement, and group. The specific course requirements are specified at the group level. Colleague course requirements are sometimes specified more generally than specific courses. For instance the requirement may be to take 6 credits of 200 level courses from the Humanities department, and any courses meeting that criteria can satisfy the requirement. In addition, a requirement can require only some, but not all of its subrequirements, and a subrequirement can require only some, but not all of its groups. Colleague degree requirements are translated to the SOC Student Agreement format as follows:

1. Colleague requirements are shown as bold headings in the SOC Student Agreement, numbered as they are in the student program evaluation report.


Ge

2. Requirements in the SOC Student Agreement are divided into a section for each subrequirement or each group depending on settings. Each section begins with a row that contains the subrequirement label or group label in bold.

3. If the section's requirement consists of only specific courses to be taken, these courses are listed on rows below the label, the required and remaining credits listed with each course. If the course has been completed, the awarded credit is shown on the row as well.

4. If the section's subrequirement or group consists of requirements that are more general than specific courses, the total number of credits required and remaining for the section are listed on the same row as the section label.

If completed courses have been applied to the section's subrequirement or groups, they are listed on subsequent rows along with their awarded credit. The remaining credit value on the section's label row is computed by subtracting all of the awarded credit from the total required credit value.

The print text of the subrequirement and groups may also be displayed on subsequent rows. Exactly what print text displays for each section is controlled by settings.

Consider the following Colleague degree requirement shown in a student program evaluation.

Figure 36: Student Program Evaluation

Then see how the same requirement and coursework is displayed in the SOC Student Agreement.


Ge

Figure 37: Example of a SOC Student Agreement

Additional options are available, and are explained in subsequent sections of this manual.

Specifications Requiring Specific Courses

A Colleague requirement specification may indicate that specific courses be taken. For instance “TAKE MATH-101, MATH-102”. In this case the courses will be listed in the SOC Student Agreement, one to a row, whether the student has taken the course or not. The required credits for each course will be listed on the same row as the course, along with remaining credits. If the student has taken the course, the awarded credits will also be listed on the row with the course. The remaining credits cell in the spreadsheet will be a formula that subtracts the awarded credit from the required credit.

When the course has not been taken, the required credits will be the number of credits recorded for the course in Colleague. If a range of credits is recorded for the course, the minimum credits will be shown on the SOC Student Agreement.

This only applies when all requirement specifications in a particular section of the SOC Student Agreement are in this format. If a section in the SOC Student Agreement corresponds to a subrequirement with two groups, and only the specification for one group is in the form of specific courses to take, the section in the SOC Student Agreement will be formatted as a specification that is more general than specific courses, as described in the next section.

Figure 38: Example of SOC Student Agreement with Specific Courses Required


Ge

Specifications Requiring General Courses

A Colleague requirement specification may be more general than a specific course, such as “TAKE 6 CREDITS FROM DEPT CHEM”. In these cases the total required credits for the entire section in the SOC Student Agreement are listed on the label row of the section. The remaining credits for the entire section are also listed on the label row. If any completed coursework has been applied to the section, those courses will be listed in the section, one to a row. The awarded credit for each course will be listed on the row with the course. The remaining credit cell on the label row will be a formula that subtracts the sum of awarded credit on the individual course rows from the required credit value on the label row.

Figure 39: Example of a SOC Student Agreement with General Course Requirements

Options for Mapping Subrequirements and Groups to SOC Student Agreements

There are two primary options for mapping subrequirements and group to the SOC Student Agreement sections.

1. A subrequirement maps to a section.

2. A group maps to a section.

Mapping a Subrequirement to a Section

When a subrequirement is mapped to a section in the SOC Student Agreement spreadsheet, the Subrequirement Name as entered on the Subrequirement Specification (SRSP) form is used as the label on the section label row.

If all of the specifications in the subrequirement are that specific courses be taken, the required credits of each course are shown on each course's row. Otherwise the sum of required credits for all groups in the subrequirement are listed as the required credits on


Ge

the label row of the section. Any applied coursework is listed below the label row, one course per row.

The mapping of a subrequirement to a section can be specified directly for the subrequirement, or generally through a default setting. It can be specified for a particular subrequirement on the SOC Group Settings (ASGP) form, which is reached by detail from the Subrequirement Specifications (SRSP) form. Set the field “Display Groups Individually in SOC” to No on ASGP to specify that the subrequirement should be mapped to a section. If “Display Groups Individually in SOC” is blank on ASGP, the value in the “Display Groups Individually” on the SOC Student Agreement Generation (SOCG) form when the SOC Student Agreement is generated is used. A value of “No” in this field also indicates that a subrequirement should be mapped to a section. The field on SOCG will be automatically populated from a field of the same name on the Military & Veteran Student Parameters (MVSP) form, but can be modified. If the field on both SOCG and MVSP are blank, a default value of “No” is applied.

When Not All Groups in a Subrequirements are Required

A subrequirement can be specified such that it contains Y groups, but only X groups are required for completion of the subrequirement. In this case the SOC Student Agreement generation will count only X groups when computing the total number of required credits. It will sum the required credits of the first X groups, assuming that all groups require the same number of credits. If this is not the case, the spreadsheet must be edited manually after it is generated.

If the subrequirement is still in progress and coursework has been applied to more than X groups, only coursework for X groups is displayed in the SOC Student Agreement. Otherwise the total awarded credits sum at the bottom of the spreadsheet would be incorrectly large. Applied courses from the remaining groups are shown in a message in a row at the end of the section, indicating that they may also apply. However no awarded credits are counted for those courses. The groups for which to show awarded credit are selected in the following order, until X groups have been identified. Any groups that are completed, followed by any groups that are in progress, followed by any remaining groups.

Mapping a Group to a Section

When a group is mapped to a section in the SOC Student Agreement spreadsheet, the group label is used as section label if present, otherwise the label is the word “Group” followed by the number of the group in the subrequirement.

If all of the specifications in the group are that specific courses be taken, the required credits of each course are shown on each course's row. Otherwise the sum of required credits for the group is listed as the required credits on the label row of the section. Any applied coursework is listed below the label row, one course per row.

The mapping of a group to a section can be specified directly for the group's subrequirement, or generally through a default setting. It can be specified for a particular subrequirement on the SOC Group Settings (ASGP) form, which is reached by detail from the Subrequirement Specifications (SRSP) form. Set the field “Display Groups Individually in SOC” to Yes on ASGP to specify that all groups in the subrequirement should be


Ge

mapped to a separate section in the SOC Student Agreement. If “Display Groups Individually in SOC” is blank on ASGP, the value in the “Display Groups Individually” on the SOC Agreement Generation (SOCG) form when the SOC Student Agreement is generated is used. A value of “Yes” in this field also indicates that a subrequirement should be mapped to a section. The field on SOCG will be automatically populated from a field of the same name on the Military & Veteran Student Parameters (MVSP) form, but can be modified. If the field on both SOCG and MVSP are blank, a default value of “No” is applied.

If not all of the groups in the subrequirement are required, groups cannot be mapped to separate sections for the subrequirement. This specification will not be allowed on the ASGP form, and this specification will not be applied as a default value.

Displaying the Subrequirement Label

When groups are mapped to sections, the display of the subrequirement label on the SOC Student Agreement is options. Along with “Display Groups Individually in SOC” on the ASGP form is a field “Show Subrequirement Header with Group”. Along with “Display Groups Individually” on the SOCG form and the MVSP form is a field “Show Subrequirement Header with Groups”. This second setting is applied in the same way as the first: A value specified directly for the subrequirement is used if present, else the value default entered on the SOCG form is used. If no value is entered on the SOCG form or the MVSP form, a default value of “No” is used.

The “Show Subrequirement Header with Group” setting is only used when groups are mapped to sections for the subrequirement. If “No”, no rows are displayed in the spreadsheet for the subrequirement, and the group label row preceding each group section is in bold.

If “Yes”, the groups will be preceded in the SOC Student Agreement spreadsheet by a row containing the Subrequirement Name as a bold label. The group label row preceding each group section is not bold.

You may want to use first setting when each group stands on its own without reference to a subrequirement. You may want to use the second setting when you wish the group label to be displayed on the SOC Student Agreement, but you would like them to appear together underneath the subrequirement. For instance, you may implement the second case when each group represents a single course to be taken, but the course may be one of two courses.

Subrequirement and Group Print Text

Subrequirement and group print text are displayed in the SOC Student Agreement according to rules and settings.

When a subrequirement is mapped to a section in the SOC Student Agreement, subrequirement print text is displayed and group print text is not displayed. This behavior can be change for a particular subrequirement as explained below. In addition, alternate print text can be specified just for the SOC Student Agreement.


Ge

When a group is mapped to a section in the SOC Student Agreement, group print text is displayed. This can also be changed for a particular group as explained below. Subrequirement print text is never displayed when the subrequirement's groups are mapped to separate sections in the SOC Student Agreement.

Subrequirement print text is displayed on separate rows of the spreadsheet just below the subrequirement label row. When a group is mapped to a section of the spreadsheet, group print text is displayed on separate rows just below the group label row. When groups are included in subrequirement section, group text is interspersed with course rows, just prior to any coursework for the group.

The default behavior for print text can be modified on the SRSP form and the ASGP form. Through the Alternate SOC Print Text field on the SRSP form, print text can be specified for a subrequirement that will be used in the SOC Student Agreement in place of the regular print text. In the Show Print Text in SOC field on the SRSP form you can specify that the subrequirement print text be hidden even though it would normally be displayed.

Through fields of the same name on the ASGP form the same specifications can be made for group print text. In the case of group print text you can specify that it be displayed when it would normally be hidden or vice versa. This is specified separately for each group. Note that the first line of group print text is treated as a group label, and subsequent lines are treated as print text. This is the same way that the Degree Audit evaluation treats group print text.

The Show Print Text for Complete Sections field on the SOCG form and the MVSP form can cause print text to be hidden for completed sections on the SOC Student Agreement. The default is to display print text whether the section is completed or not.

Exception Print Text

If an exception is applied to a requirement, subrequirement or group through the Exceptions and Overrides (EXOV) form, any exception print text will be displayed in the SOC Student Agreement. It will be displayed just under the requirement label row in the case of a requirement, and just after print text in the case of a subrequirement or group.

Awarded Credits

Awarded credits for complete coursework are displayed in the nine awarded credits columns of the SOC Student Agreement as follows.

Credit for coursework taken at the institution is shown in the Resident column.

Credit for transfer coursework is shown in the Transfer column.

Credit for non-courses is shown in the remaining seven columns. The particular column to use can be specified for the related non course in the SOC Credit Type field on the Noncourses (NONC) form. If no value is specified on the NONC form, the credit is placed in the Other column. In addition a note is added to the SOC Student Agreement indicating


Ge

that the credit column of the non-course could not be determined. This is meant to alert you to this fact, and then to deleted by you from the spreadsheet.

SOC DNS Course Category Codes

A course can be related to a SOC DNS Course Category Code on the Additional Course Information (ACOI) form, the DNS Course Categories (DNSC) form, and the Assign DNS Categories (ADNS) forms. If a course is written to the SOC Student Agreement, any DNS Course Category Code associated with it will be displayed in the column of that name in the spreadsheet.

This applies whether the course was taken at the institution, or is a transfer or non-course equivalency to a course at your institution. The DNS Course Category Code of the course at your institution is used. Only codes ending with “A” are displayed for academic programs connected to an associates degree, and only codes ending with a “B” are displayed for academic programs connected to a bachelors degree. Start and end Dates of the DNS Course Category Code as well as start and end dates of the assignment of the code to the course are used to determine whether the code should be displayed. Entry of these dates is optional.

Setting Up Military and Veteran Student Parameters

To set up parameters for military and veteran students, use the following forms:

• MVSP

• MINS

These forms are explained in the next sections.

Setting Up Defaults for Military and Veteran Student Forms

The Military & Veteran Student Parameters (MVSP) form is used to define defaults and parameters used on the following Military and Veteran Student forms:

• Military Student Information (MILS)

• Veteran Student Information (VETS)

• Veteran Student Term Information (VTRM)

• SOC Agreement Generation (SOCG)


Ge

Figure 40: The Military & Veteran Student Parameters (MVSP) Form

Noteworthy Fields on the MVSP Form

The fields described in this section are important for entering parameters that are used on the Military and Veteran Student forms.

Overall Military

Enter the default overall communication code to be used when you enter a new Military Student record on the Military Student Information (MILS) form. This default will display in the Overall Comm Code field.

Overall Veteran

Enter the default overall communication code to be used when you enter a new Veteran Student record on the Veteran Students Information (VETS) form. This default will display in the Overall Comm Code field.

Military Student Benefits

Enter the default communication code to be used each time information is added or updated within a Military Benefit defined on the Military Student Information (MILS) form. This default will display in the associated Comm Code field.

Veteran Student Benefits

Enter the default communication code to be used each time information is added or updated within a Veteran Benefit defined on the Veteran Students Information (VETS)


Ge

form. This default will display in the associated Comm Code field to record correspondence with the student.

VA Forms Received

Enter the default communication code to be used when a new form requirement or a change in an assigned form is recorded on the Veteran Students Information (VETS) form. This default will display in the associated Comm Code field to record correspondence with the student.

VA Net Certified Amount

Enter the default to use when a veteran student has funds certified for an enrollment period. This default will display on the Veteran Student Term Information (VTRM) form in the Comm Cd field if you enter or change the Net Certified Amount when the Comm Cd field is blank.

Default Credits Per Course

Enter the hours required per course for SOC Student Agreement generation.

This setting applies only to the generation of a SOC Student Agreement.

• When a requirement specifies only courses and no credits, such as TAKE 2 COURSES; FROM SUBJECT MATH; the number of credits per course will be multiplied by the required number of courses to determine a number of credits required in the SOC Student Agreement.

• If a requirement specifies both courses and credits, such as TAKE 2 COURSES; FROM SUBJECT MATH; MINIMUM 6 CREDITS; then the number of required credits in the SOC Student Agreement will be taken from the requirement, and this field will not be used.

Enter the value to be defaulted if no value is entered on the SOC Agreement Generation (SOCG) form in the Credits for Course field. The SOCG form will show this value to start. If no value is entered here or on the SOCG form, a value of 3 is used.

Display Groups Individually

Specify if groups are displayed individually in the SOC Student Agreement.


The Display Groups Individually setting controls whether groups are displayed as separate sections in the SOC Student Agreement, or whether they are combined into a single subrequirement section.

Enter the value to be defaulted when no value is specified for a particular subrequirement on the SOC Group Settings (ASGP) form (in the Display Groups Individually in SOC field) or on the SOC Agreement Generation (SOCG) form (in the Display Groups Individually field). The SOCG form will show this value to start.


Ge

Enter Yes to display each group in a separate section on the SOC Student Agreement. Enter No to combine groups into a subrequirement section.

If this field is blank, the value “No” will be used.

This is the default value to be used when no other value is entered on the SOCG form. The default value applies only to subrequirements for which a value has not been specifically assigned on the SOC Group Settings (ASGP) form in the Display Groups Individually in SOC field.

Show Subrequirement Header with Groups

Specify whether to display a subrequirement header with individual groups.

When Display Groups Individually is set to “Yes” for a subrequirement, this is the default specification of whether the subrequirement header will be displayed prior to the groups. This setting can also be specified for a particular subrequirement on the SOC Group Settings (ASGP) form, and as a default on the SOC Agreement Generation (SOCG) form. When no value is specified in either of these locations, this default value is used. The SOCG form shows this value to start.

When Display Groups Individually is set to “Yes” for a subrequirement and this field is set to “Yes”, a subrequirement header will precede the group headers in the SOC Student Agreement. The subrequirement header will be bold and the group headers will not. The required credits will still be shown with each group.

This feature can be useful when most groups in the subrequirement provide a choice of courses, but require only one. The result in the SOC Student Agreement is a subrequirement header followed by a list of groups which each require only one course.

If this setting is blank or set to “No” and Display Groups Individually is set to “Yes”, no subrequirement header will be shown in the SOC Student Agreement and the group headers will be bold.

Show Print Text for Completed Sections

Specify whether print text should be displayed for completed sections.


Enter “Yes” to show print text and exception print text with a completed section in the SOC Student Agreement. If you enter “No”, print text and exception text are not shown with a completed section. Only the section heading displays, followed by the list of courses that apply to the subrequirement.

When the subrequirement is configured to display groups individually such that there is a separate section for each group in the SOC Student Agreement, this setting applies to the group individually. The setting depends on whether the group is complete.

When the subrequirement is configured to include all groups in a single section of the SOC Student Agreement for the subrequirement, this setting applies to the entire subrequirement. The setting depends on whether the entire subrequirement is complete.

If this field is blank, the value “Yes” will be used by default.


Ge

VA Program Evaluation Include Code

Enter the Degree Audit include code that is required for evaluating whether a student’s courses apply to a VA program. This setting is used on the Veteran Student Term Information (VTRM) form.

Valid values are any of the Degree Audit include codes from the DA.EVAL.INCLUDE.CODES validation code table except for D (DATE). Date is not valid, because the context of Veteran Student Term Information does not allow for the user to enter an evaluation cutoff date. If this field is left blank, Colleague defaults a value of R (Registered/Preregistered) is used.

Setting Up Military Installation

Use the Military Installations (MINS) form to build the Military Installations code table used by the Servicemembers Opportunity Colleges (SOC). These codes are stored in the MIL.INSTALLATIONS file.

Figure 41: The Military Installations (MINS) Form

Noteworthy Fields on the MINS Form

The fields described in this section are important for entering military installations.

Description

Enter the military installation description to be displayed on the applicable military information forms.


Ge

GEO Ed Center

If applicable, enter the GEO Ed Center that is associated with this military installation. Not all military installations have a GEO Ed Center.

Using the Enrollment Activity Report

Colleague provides the two following options for reporting upon enrollment activity for a set of students:

• Enrollment Activity Report (RGER)

• Enrollment Activity Export to Excel (RGERE)

Enrollment Activity Report

Use the Enrollment Activity Report (RGER) process to create a view of registration enrollment activity for a select set of students during a particular date range. You can select the date range on which to report registration enrollment activity, as well as filters to apply to the activity reported. In addition you can specify criteria to select the students reported.

Figure 42: Example of the Enrollment Activity Report (RGER) Form

The Enrollment Activity Report includes the following data:

• Student Name.

• ID.


Ge

• Academic Program. Lists all the academic programs that were active during the date range. If more than a single program is reported for a student, each program is labeled with a reference number. The number is used to identify which student programs each enrolled course section applies or relates to. Student academic programs that are no longer active are denoted with an asterisk.

• Award. Lists all of benefits awarded to the student, and are in effect during the reported date range. This includes Financial Aid, Active Military, and Veterans Affairs awards.

• Term.

• Registration Credit. Displays the total number of credits the student is registered for during the term. Note: this is the total registered credit for the term; it may reflect enrolled course sections not displayed in the report.

• Course Section.

• Grade. Displays the student's verified grade for the course section.

• Last Date Attend. The student's last date of attendance in the course section.

• Status/Date. Lists the registration status and date for enrollment activity in a course section.

• Program Evaluation. Identifies whether the enrolled course section applies or relates toward meeting the requirements of the student's academic program of study. If the student has multiple active academic programs, they are referenced by number to identify which the enrolled course section applies or relates. This column is left blank for course sections that neither apply nor relate to an active student program. Note: a Degree Audit evaluation must have been run in order for this data to be reported.

Enrollment Activity Export to Excel

Use the Enrollment Activity Export to Excel (RGERE) form to export the Enrollment Activity Report data to an Excel spreadsheet. This is accomplished by clicking on the Excel icon that is displayed among the window controls.

Note: You must be using version 4.2 or greater of the user interface in order to export the data to Excel.


Ge

Figure 43: Example of the Enrollment Activity Export to Excel (RGERE) Form

The Excel spreadsheet that results from the export contains the following information:

• Student Name.

• ID.

• SSN. Displays the Social Security Number (SSN) for the student in the format set in the SSN Display Option field on the Enrollment Activity Report (RGER) form.

• Home Location. Displays the home locations for the student. Only the locations that are active during the date range on the Enrollment Activity Report (RGER) form are displayed.

• Academic Program. Displays upto three academic programs for the student. The active programs must have been active during the date range on the Enrollment Activity Report (RGER) form. The program does not need to be currently active to be reported. If both active and inactive programs are reported for the student, the currently active programs are reported first.

• FA Awards. Displays the financial aid benefits awarded to the student with a category of “Accepted” during the date range on the Enrollment Activity Report (RGER) form.

• Military Benefits.

• Veteran Benefits.

• Term.

• Registration Credits.

• Section Name.

• Grade. Displays the student's verified grade for the course section.

• Last Date Attended. Displays the student's last recorded date of attendance in the course section.

• Registration Status. Displays the registration status for the student's enrollment activity in the course section.


Ge

• Status Date/Time.

• Program Evaluation.Displays the relationship between how the enrolled course section applies toward meeting the requirements of the student's primary academic program.


Ge

Defining Grades

In This Chapter

This chapter includes information and instruction for defining your institution’s grade scheme and grades.

Before You Begin

Before you can define grades, the following codes should be set up in Colleague:

Understanding Grades and Grade Schemes

Before you can enter any grades for your students, you must first set up at least one grade scheme and then a set of grades for that grade scheme. The grade scheme and the associated set of grades define a complete grading pattern. For Colleague to correctly compute grade point averages for your students, you will need a grade scheme for each unique grouping of grades that your institution uses.

For example, Ellucian University has a separate grade scheme for its undergraduate courses, grade graduate courses and remedial courses.

The following sections discuss grade schemes and grades in more detail.

Grade Schemes

A grade scheme is a group of grades that represent a complete grading pattern. Different grade schemes let you set different values to the same grade in different circumstances. For example, Ellucian University has set up an undergraduate grade scheme which includes the following group of grades: “A,” “B,” “C,” “D,” and “F.” The grade of “A” in EU’s

Table 127: Codes Needed Before You Can Define Grades

Description Reference

Repeat grade use codes 259

402tting Started with Colleague Student | Defining Grades

Ge

undergraduate grade scheme evaluates to 4.0, while the grade of “A” in a law school grade scheme evaluates to a 4.25.

You can set up as many different grade schemes as you need to cover all your grading possibilities.

You may also need to define grade schemes for other institutions from which you frequently receive transfer students. The Admissions Module uses grade scheme codes when establishing equivalencies for transfer courses. See Using Recruitment/Admissions Management for more information on how grade schemes are used in the Admissions Module.

Use the Grade Schemes (GRSC) form, shown in Figure 44, to define the grade scheme codes. The GRSC form contains the following components:

• Grade Scheme Definition

• Repeat Grade Calculation

• Grades in Grade Scheme

These components will be discussed in more detail in this section.

Figure 44: Grade Schemes (GRSC) Form

Grade Scheme Definition

You can define when your grade schemes are valid by setting a start and end date for each grade scheme. For example, you might want to define a new grade scheme to be used next fall term, but not during the current term. To do this, set the start date to the beginning of the fall term. Colleague will not allow the use of that grade scheme until the fall term.

Grade Scheme Definition

Repeat Grade Calculation

Grades in Grade Scheme


Ge

Repeat Grade Calculations

Some courses may have an associated retake policy. This retake policy defines whether the course may be taken more than one time and how many times for credit. Some courses may be taken more than once, but only once for credit. For example, a student may wish to improve their grade in a given course. Other courses may be taken multiple times for credit, such as Band.

If a course has a retake policy allowing a course to be taken only once for credit, Colleague uses only one grade for the course when calculating GPA. Within the grade scheme, you must define which instance of a repeated course Colleague should use. The calculation can be defined in one of the following ways:

• Always use the latest grade recorded

• Use the best grade received

• Use an average of all grades received for the same course

If you prefer some other calculation of repeat grades, see your system administrator about the possibility of a custom subroutine to meet your needs.

See “Defining Course Defaults” on page 652 for more information about defining registration retake policies for courses.

See “Repeat Grade Use Codes” on page 259 for additional information on defining repeat grade use codes.

Grades in Grade Scheme

Each grade scheme includes a unique group of grades. List the grades to be included in the grade scheme on the GRSC form. These grades must be further defined by detailing to the Grade Codes (GRDC) form.

The next section discusses defining grades in more detail.

Grades

Grade codes correspond to the actual grades your faculty give students in each course. You must define the grade schemes your institution will use before you can define the grades themselves. See “Grade Schemes” on page 402 for more information on defining grade schemes.

For each grade scheme you have defined, you must define a group of grades to be associated with that grade scheme. From the Grade Scheme (GRSC) form detail to the Grade Codes (GRDC) form to define the grades in this grade scheme.

The Grade Codes (GRDC) form, shown in Figure 45, contains the following components:

• Grade Definition


Ge

• Automatic Grade Processing

• Inclusions

• Repeat Value

These components will be discussed in more detail in this section.

Figure 45: Components of the Grade Codes (GRDC) Form

Grade Definition

Each grade in a grade scheme has a numeric value that is used in GPA calculations. For example, Ellucian University has defined an “A” for an undergraduate grade scheme to be equal to 4.0 when calculating the grade point averages. However, in the EU graduate school grade scheme, an “A” has been defined with an 4.25 value.

Note: If you anticipate that a grade may be used for a placement course or test which may be a requisite for another course, the grade value must be greater than 0.1. For example, if a grade of “P,” for “Passing,” or “AU,” for “Auditing,” is adequate for a requisite, then define the grade values greater than.01.

You can also define a legend, or description, for each grade. Colleague will default the actual name of the grade as the legend, but you can change this, if desired. For example, Ellucian University leaves many of its letter grades, like “A,” “B,” and “C,” with the default legend of “A,” “B,” and “C.” However, for the grade “I,” Ellucian University has defined a more descriptive legend of “Incomplete.”

Grade Definition

Automatic Grade Processing

Inclusions

Repeat


Ge

Automatic Grade Processing

You will need to define primary grades, such as “A,” “B,” and “C,” to be given to students who are taking courses for academic credit. But you can also define grades to be given to students who are taking courses for pass/nopass or audit, such as, “P,” “NP,” and “AU.” You can also define grades to be given to students who withdraw from a course, such as “WP” for Withdrew Passing and “WF” for Withdrew Failing.

You can define your primary grades so that Colleague will automatically translate them for you, if the student being graded is:

• Taking the course pass/nopass

• Auditing the course

• Withdrawn from the course

Your instructors can then grade all students without worrying about each student’s status in the class. After grades are entered and verified, Colleague will translate each grade depending upon how you defined the associated grade scheme.

You can also define a grade to be given to a student who has not completed the given course work, such as, “I” for Incomplete. You can define this incomplete grade to translate into a primary grade, such as “F,” if the student does not complete the course work by a certain date.

If you are going to use any of these special processes, the setup involves two passes through these forms.

• Define all of the grades to be used in the grade scheme. That is, all of the primary grades such as, “A,” “B,” and “C,” plus the other grades you want to use for automatic processing, such as “WP,” and “WF.”

• Update and file the grade scheme.

• Reaccess the GRSC form and define the automatic grade processing for each grade by detailing again to the GRDC form.

Pass/NoPass, Withdraw, and Audit Grades

For each primary grade you have defined, you must:

• decide how you want Colleague to translate the grade if the student being graded is taking the course pass/nopass, or auditing, or has withdrawn

• enter the grade you want the student to receive in each situation

For example, Ellucian University has defined the grade “A” in the “UG” grade scheme as shown in Figure 45 on page 405. If an instructor enters an “A” for a student and the student is taking the course pass/nopass, the grade will be translated into a “P.” If the student withdraws, the grade will be translated into “WP.” If the student is auditing the course, the grade will be translated into “AU.”


Ge

Incomplete Grades

If you want to define a grade that could be given to a student who has not completed the given coursework, then set up one, and only one, grade in your grade scheme to be an incomplete grade. Ellucian University has called this grade, “I.”

When an instructor enters an incomplete grade for a student, he must also enter an expiration date. If the student does not complete the course work by that date, Colleague will automatically translate the incomplete grade into the grade defined in the grade scheme. This translation will be done upon accessing the grade in any process that recalculates the student’s GPA, including printing of grade reports and transcripts. For Ellucian University the UG incomplete grade of “I” translates into “F.”

Do not define additional processing for the incomplete grade. If multiple processing is necessary, Colleague will translate the incomplete grade first and then translate the translated grade again using the primary grade definition. For example, if an Ellucian University student is assigned an incomplete grade and then later withdraws from the course, Colleague will translate the incomplete grade into “F” after the incomplete grade expiration date, and then translate the “F” as a withdrawn grade into “WF.”

See the Using Academic Records manual for more information on where these grades are used.

Inclusions

The academic credits associated with each course a student takes can be totaled to track his academic progress. You can decide which academic credits you want Colleague to include in a student’s credit totals. For example, Ellucian University does not include academic credits of audited courses in a student’s GPA credits. EU includes academic credits of withdrawn courses in a student’s attempted credit totals, but not in his completed credit totals.

You need to decide whether or not the academic credits of a course should be included in a student’s credit totals when a student receives each grade.

You need to define for each primary grade whether the academic credits associated with a course receiving that grade will or will not be included in the following calculations:

• Attempted credits

• Completed credits

• GPA credits

If a student repeats a course that he can take only one time for credit, Colleague marks the original course as replaced. You need to decide whether or not the replaced academic credits should be included in a student’s credit totals. Considering each primary grade as if it were the grade received in the original course, you must define whether the replaced academic credits associated with it will or will not be included in the following calculations:

• Replaced attempted credits

• Replaced completed credits


Ge

• Replaced GPA credits

Each of these decisions to include academic credit can be overridden by your credit type setup. See “Enrollment Statuses” on page 190 for more information about defining your credit type codes.

Repeat Value

If you defined the Repeat Grade Usage policy for a grade scheme as “Take Best Grade,” Colleague will look at the highest grade whenever a student repeats a previously taken course. However, if the student receives the same grade again, then you might want Colleague to always use the first instance of the course in transcripts and GPAs. To tell Colleague to use the first instance, set the repeat value to a number slightly less than the original grade value.

For example, Ellucian University has set the repeat value for a “B” in the undergraduate grade scheme to 2.99 where the original grade value is 3.00. When an undergraduate student repeats a class in which he originally received an “B,” and receives a “B” again, Colleague will look at the original 3.00 and compare it to the repeat value of 2.99. The first course, with the higher value of 3.00, will be used in GPA calculations and listed on the student’s transcript.

Procedure for Defining Grades

Use the following procedure to define your grade schemes and the associated grades. Repeat the process for each grade scheme you define.

1. Use the worksheet “Grades Schemes and Grades” on page 449 to map out your grade schemes and the associated grades.

Complete a separate worksheet for each grade scheme you will define.

2. Access the Grade Schemes (GRSC) form to define your grade scheme.

3. Detail to the Grade Codes (GRDC) form to define the following for every grade in your grade scheme:

• Grade Value

• Grade Legend

• Inclusions

• Repeat Value

Remember to define grades to be used in setting up the automatic processing grades (step 6). For example, WP for withdrawn passing.

Use on-line help for more information about each field.

4. Save the record for the grade scheme.


Ge

5. Re-access the Grade Schemes (GRSC) form and the grade scheme code you just defined in steps 3, 4 and 5.

You will now complete the setup of your primary grades in this grade scheme. For each primary grade, detail to the Grade Codes (GRDC) form to define the following automatic processing grades:

• Pass Nopass Grade

• Withdraw Grade

• Audit Grade

• Incomplete Grade

6. Save the record for the grade scheme.


Ge

Defining Academic Levels

In This Chapter

This chapter provides information on the components of an academic level and how to define your institution’s own academic levels.

Before You Begin

Before you can define academic levels, the following information must already by setup.

Understanding Academic Levels

Your institution must have one, but will most likely have several, academic groupings called academic levels. Examples of academic levels are undergraduate, graduate, continuing education, and vocational. Academic levels you define will later be assigned to various academic programs as you set them up. Each academic program will be associated with an academic level.

For each academic level you must define an associated set of class levels. For example, Ellucian University has an academic level of undergraduate with valid classes of freshman, sophomore, junior and senior. You must define each class level with a rule Colleague uses to assign students to the proper class.

Table 128: Information Needed Before You Can Define Academic Levels

Item Reference

Academic program statuses 279

Class levels 171

Documents Using Communication Management

Enrollment statuses 190

Grade schemes 402

Honor codes 234

Transcript groupings 284

410tting Started with Colleague Student | Defining Academic Levels

Ge

You can set data entry defaults for each academic level. These defaults are assigned to academic programs or equivalencies associated with the academic level. These defaults include the following:

• Transcript grouping

• Grade scheme

• Equivalency minimum grade

You must also define general characteristics of each academic level. These characteristics include the following:

• Half time, full time and overload hours

• Whether the academic level is a graduate level

• Type of credit on which to base a student’s full time status

• Estimated number of months to complete a program associated with this level

• Optional repeat check custom subroutine

You can also define various rules to be evaluated in each academic level. These rules include the following:

• Enrollment status rules

• Graduation honor rules

• Academic standing rules

You can also define how Colleague handles student absences from course sections for each academic level.

Components of an Academic Level

Use the Academic Levels (ACLV) form to define each academic level. Each academic level has the following major components:

• Class levels

• Defaults

• Characteristics

• Rules

• Absences table

Each of these components are discussed in this section.


Ge

Figure 46: Components of Academic Levels

Class Levels

For each academic level you define, you must define a unique set of class levels, such as junior and senior, which are valid for the academic level.

For each class level you must define an associated rule that determines a student’s class level. When a rule evaluates to true, Colleague assigns the associated class level code to the student.

If you want class levels to display in a particular order, you must give each one a sequence number. Colleague uses this sequence number on grading forms where students are displayed in descending class order. On these forms students from the ‘highest’ class level (for example, seniors) are displayed first. Normally, the lowest sequence number would be assigned to the class with the least number of completed credits. Each higher sequence number would be associated with a class with successively greater numbers of credits completed. If you do not assign a sequence, the display order will be an alphanumeric sort by class codes.

For example, Ellucian University has defined four class levels for the “UG” academic level. Table shows these class levels, the associated class level rules and the sequence for each.



Freshmen ‘WITH STA.COMPLETE.CREDS LE “24” ‘ 1

Sophomores ‘WITH STA.COMPLETE.CREDS LE “48” ‘ 2


Ge

See “Class Level Rules” on page 339 for more information on setting up class level rules.

Defaults

You can set data entry defaults that are inherited by all academic programs associated with an academic level. You can modify any of these defaults for any academic program, as necessary. Table shows which defaults you can define for an academic level and how they are used.

Characteristics

You can define various characteristics that make each academic level unique. Table shows which characteristics you can define for an academic level and how they are used.

Juniors ‘WITH STA.COMPLETE.CREDS LE “72” ‘ 3

Seniors ‘WITH STA.COMPLETE.CREDS GT “72” ‘ 4

Table 130: Academic Level Defaults

Default How used… Detail to the…

Transcript Grouping

This transcript grouping defaults to all academic programs associated with this academic level.

Transcript Grouping (TRGR) form

Grade Scheme

This grade scheme defaults to all academic programs associated with this academic level.

Grade Scheme (GRSC) form

Equivalency Minimum Grade

This is the minimum grade a transfer student must receive for an external course before he can receive an equivalency at your institution.

This grade must be in the default grade scheme defined above. Colleague compares this grade value to grade values possible from the transferring institution. The external grade whose grade point value is closest to your default minimum grade (but not less) will be the minimum grade required on an equivalency.

no detail

Table 131: Academic Level Characteristics

Characteristic Description

Full Time Hours This is the minimum number of hours required for a student to be considered full time.




Ge

Overload Hours This is the maximum number of hours that a student at this academic level can take before the number of credits are considered an overload.

If a student’s credit hours are greater than this maximum, you can require a special override authorization be needed at registration.

NOTE: If you have created an overload rule from the Student Load/Status Rules (STLD) form, it will override the setting in this field.

Half Time Hours This is the number of hours required for a student to be considered half time. This is used as a default for the National Student Loan Clearinghouse report front end screens.

Graduate Level This yes/no parameter indicates whether this academic level is a graduate level.

Type of credit This indicates whether a student’s full/part-time status is based on academic credits or billing credits.

Completion Months This is the number of months an average student completes an academic programs within this academic level. This number of months is added to a student’s academic program start date to calculate his anticipated completion date.

Default Academic Program/Status

This is the academic program and program status that will be assigned to a student when he registers for a course that is not associated with one of his active academic levels.

If you do not define a default academic program, you may later have a problem with “dangling” student records with no associated student program records.

You may need to leave this field blank temporarily until you define your academic programs. Define some of your programs with this academic level. Then return to ACLV and enter one of those programs.

You can detail to the Academic Programs (PROG) form to maintain the academic program.

Repeat Check Custom Subroutine

This is the name of a custom subroutine Colleague should use to calculate the check for repeat courses. If you leave this field blank, Colleague will check for repeat courses using specifications associated with each course section.

See your system administrator for more information about custom subroutines.

Table 131: Academic Level Characteristics (continued)

Characteristic Description


Ge

Rules

You can define rules which will be evaluated in the academic level. Table shows which defaults you can define for an academic level and how they are used.

Table 132: Academic Level Rules

Rules Definition Detail to the…For More Information…

Enrollment Status

Colleague evaluates these rules when a student is created from an application. The first rule in the list that evaluates to true will have the associated enrollment status assigned to the student.

If you do not define enrollment status rules or if none of the rules evaluate to true, Colleague will not assign an enrollment status to the student.

Acad Level Enroll Status Rule (ALES) form.

See “Enrollment Status Rules” on page 342.

Graduate Honors

Colleague evaluates these rules, during the graduation processor, if an academic program has no specific graduate rules. Any rule that evaluates to true will have the associated honor assigned to the student.

If you do not define graduate honor rules for either the academic program or the academic level, Colleague will not assign graduate honors to students.

Academic Level Grad Honors (ALGH) form.

See “Graduation Honors Rules” on page 325.


Ge

Absences Table

Enter the number of days on which a section in a selected level meets.

Based on this number, a student receives the associated document when he or she has been absent for the associated number of days.

Because the individual entries are treated as ranges, the association is kept in ascending order according to this number of days. For example, you may set up an association as follows:

Absences: 1

Document: X

In this example, a student absent for 1 day in sections that meet up to 20 days total is assigned the document code “X” by the processes where the absence is noted.

Use the “Absences Table Worksheet” on page 450 to help you define your absences table. See Using Communications Management for more information about defining your documents.

Academic Standing

Colleague evaluates these rules when running the academic standing processor to determine a student’s academic standing for this academic level. You can define rules for these types of academic standing:

• academic level standing

• academic level term standing

• default academic program standing

If you do not define academic level standing rules, Colleague uses the default standing rules you defined on the Academic Records Parameter (ACPR) form.

Colleague uses the default academic program standing rules if an academic program in this level does not have specific academic standing rules associated with it.

Academic Level Standing Rules (ALST) form.

See “Academic Standing Rules” on page 331.

Table 132: Academic Level Rules

Rules Definition Detail to the…For More Information…


Ge

Defining Academic Terms

In This Chapter

This chapter provides information on the components of an academic term and how to define your institution’s own academic terms.

Understanding Academic Terms

An academic term describes the various academic time periods used by your institution. These terms may be traditional Fall and Spring terms for an academic year or they can be defined in whatever way meets your institution’s needs. For example, you can have mini-terms within a larger term. Each term has start and end dates associated with it.

Note: You should not change or delete an academic term once it has been entered and updated, because they are used throughout Colleague Student.

Academic terms are grouped for reporting purposes into reporting years. This lets you set up situations where terms overlap one another but you still want to associate them to one year for reports. For example, Ellucian University set up a reporting year 2011 which includes the following academic terms: Fall 2011, Winter 2012, Spring 2012, and Summer 2012.

You must first define at least one reporting year and associate academic terms to one. Then you can further define each academic term. Each of these steps are discussed in this chapter.

Academic Term Naming Conventions

Colleague supports user-defined academic term names (IDs) that are up to seven alphanumeric characters in length. Due to course section lookup issues, the only restriction on naming terms is that the name cannot be all numeric. While traditional term names include the year and session, Colleague currently does not require any or all of the actual year to be present in the name. When defining a term, attributes of the term include the four-digit academic year, a description, and an optional reporting term that can identify year and session information for the term without having it appear in the term name itself.

You should develop a standard and consistent naming convention for your institution's terms during your implementation cycle. If you choose to include the year as a part of your term names, you may want to use a four-digit format for the year. Using a two-digit year

417tting Started with Colleague Student | Defining Academic Terms

Ge

format in term names can cause problems if you keep more than 100 years' worth of terms, since eventually the term IDs will begin repeating. For example, with a two-digit year format in term names, there will be no distinction between the Fall term in 1950 (50/FA) and the Fall term in 2050 (50/FA).

Be aware that if you move to a four-digit year format in your term names, there will be a naming discrepancy for a while because your older term names will still be in the old format (such as 93/FA) and your new terms will use your new format (such as 2011/FA). Within Colleague, terms are sorted based on start and end dates rather than names, and will properly be displayed in chronological order. However, sorting terms for general query purposes may yield undesirable results if the formats of your term names are mixed. For example, if you have term names such as 93/FA and 2011/FA and sort records based on the term name (ID), 2011/FA will appear in the list before 93/FA. To sort terms in chronological order for general queries, sort the terms by start date.

Academic Terms Within a Reporting Year

Use the Reporting Years and Terms (RYAT) form as the starting point to define academic terms.

Figure 47: Reporting Years and Terms (RYAT) Form

Each academic term within a reporting year contains the following major components:

• Start/end dates

• Reporting term

• Calculated/actual sequence

Each component is discussed in this section.


Ge

Start/End Dates

The academic term start and end dates are used as a default whenever start and end dates are needed and a particular term is entered. For example, a course section that is associated with an academic term will have the academic term start and end dates default as the start and end date of the course section. You can modify these dates after they are entered for a specific instance, if necessary.

Reporting Term

Each academic term can be grouped with another term, if desired, for reporting purposes. For example, if the academic term 2012/S1 is a six week mini-term scheduled for the first part of the summer term, it might be grouped with the 2012/SU term. Thus 2012/SU would be the reporting term for the academic term of 2012/S1.

The default report term is the academic term itself.

Calculated/Actual Sequence

Colleague calculates a sequence that it uses as the sorting order of academic terms on forms and reports. This sequence is calculated based on the start date of each academic term in the reporting year. For example, the calculated sequence of ‘1’ is assigned to the term with earliest start date in the reporting year and a ‘2’ to next start date.

If you add an academic term with a start date between two existing terms, Colleague will calculate sequence numbers for the terms with start dates after the new term. Colleague will recalculate the sequence numbers every time any term start date is modified. You will receive a warning that resequencing has occurred.

If you would prefer the academic terms were in a different report order, you can override this calculated sequence. Enter the actual sequence you prefer in the Act Seq field. You will receive a warning if you attempt to give two terms the same sequence number.

Further Defining an Academic Term

From each academic term listed on the RYAT form, detail to the Academic Terms (ACTM) form to further define each academic term.

Use the Academic Term (ACTM) form to further define each academic term. An academic term contains the following components:

• Academic term definition

• Term process dates

• Registration rules


Ge

ATD

TPD

TRR

TC

• Term calendar

• Census dates

These components are discussed in detail in this section.

Figure 48: Academic Term (ACTM) Form

Academic Term Definition

You can associate each academic term with a particular session, financial aid years, reporting term and a commencement date. The academic term commencement date will default as a student’s commencement date if this academic term is noted as the student’s graduation term.

If your institution has academic levels or locations that have separate term schedules, you must designate those distinctions as you define each academic term. List which academic levels and/or locations “own” this particular academic term. You can reference these academic levels and locations in rules to restrict which students can register for this term. If you do not list academic levels or locations, then students with any level or location can register for course sections associated with this academic term.

For example, Ellucian University has a separate term schedule for their graduate level courses. Therefore, EU has defined these terms with an academic level of graduate. Only students with an academic level of graduate are eligible to register for course sections associated with these academic terms.

You can detail to the Term Location Dates (TLOC) form from the Location field. See “Term Location Dates” on page 425 for more information about this form.

cademic erm efinition

erm rocess ates

erm egistration ules

erm alendar

Ce


Ge

Term Process Dates

Define the start and end dates for various term processes. These term process dates default into new course sections and meal plan and housing assignments associated with this academic term. If you also define term location process dates, the location process dates will default into course sections associated with both the academic term and the location. See “Term Location Dates” on page 425 for more information about defining term location process dates.

You should familiarize yourself with the procedures involving each date, so that you get the expected results. The types of process dates you can define are:

• Registration process period dates

• Residence life dates

• Drop grades required date

This section will discuss each of these types of process dates and indicate where to look for more information on each.

Registration Process Period Dates

Registration is divided into time segments called registration process periods. During each of these periods, specific registration processes occur. Table lists these periods and a description of each.

You must define the start and end dates for the different registration process periods for each academic term. These dates default into all new course sections associated with a particular academic term as the sections are set up. During registration, when a student attempts to enroll in a course section, Colleague will check the current date and determine which registration process period applies for that section.

Note: Since a student can register for sections in multiple terms, he can be in different process periods for each section. For example, a student at

Table 133: Registration Process Period Definitions

Registration Process Period Description

Preregistration Time period before regular registration

Registration Time period for regular registration

Add Time period after regular registration during which a student can add a section to his schedule. A student cannot add sections after the Add End Date.

Drop Time period after regular registration during which a student can drop a section to his schedule. A student cannot drop sections after the Drop End Date.


Ge

registration can be in the preregistration period for all the sections of one term and the add period for all the sections of another term.

Depending upon which registration process period is current, Colleague performs different processes. These differences include the status code assigned to a course section in a student’s schedule, which rules and checks are evaluated, and how billing is calculated.

Colleague assigns the appropriate student academic credit status code to a course section in a student’s schedule. For example, if a student registers for a section during the preregistration or registration time period, Colleague assigns a status code of “N” for New. But if a student registers for a section during the add period, Colleague assigns a status code of “A” for Add.

Colleague evaluates various rules and checks in different registration process periods as defined in your registration controls. You should also consider these registration process period dates as you define your registration user groups.

See “Defining Registration Controls” on page 805 for more information about defining your registration controls and “Assigning Registration Controls to Registration Users” on page 826 for more information about registration user groups.

These registration process period dates also affect course charges, refunds, add/drop fees, and billing rates. For example, Ellucian University charges a student an additional fee if he enrolls in a section during the add process period.

See Using Accounts Receivable/Cash Receipts for more information about the effect of registration process period dates on billing.

Residence Life Dates

Define the start and end dates that default into all meal plan and housing assignments you associate with this academic term. If you do not define dates here, Colleague will use the associated academic term start and end dates.

These dates also affect billing rates and refunds.

See “Setting Up a Meal Plan” on page 861 for more information about setting up meal plans and Using Residence Life for information about making housing assignments. See Using Accounts Receivable/Cash Receipts for more information about the effect of these dates on billing.

Billing Dates

Define the start and end dates that determine a term’s active date range for billing. These dates determine whether charges for a past or future term can be billed.

If you do not enter a start date, charges for a term can be billed immediately. If you enter a start date, then charges for a term cannot be billed until that start date arrives.

Colleague defaults the term end date into the billing end date for that term. If you want charges for a term to be billed after the end of a term, enter a later date, or use the batch billing process to force rebilling for an inactive term.


Ge

See “Setting Up Billing Defaults and Parameters” on page 453 for information about how Colleague uses these billing dates along with other billing parameters.

Drop Grades Required Date

Define the date after which a grade is required even if a student chooses to withdraw from a section. This date defaults into all newly created course sections that are associated with this academic term. When a student drops or withdraws from a section after this date, the instructor must give him a grade. This grade will usually be “withdrew passing” or “withdrew failing.”

If you do not define a date here and you decide you want to require grades after a certain date, you can define the date for each course section individually.

If you also define term location drop grades required dates, they will default into new course sections that are associated with this academic term and a particular location. See “Term Location Dates” on page 425 for more information about defining term location drop grades required dates.

See “Understanding Grades and Grade Schemes” on page 402 for more information about setting up withdraw grades. See Using Curriculum Management for more information about defining a drop grade required date for a course section.

Example of Term Process Dates

Ellucian University has defined the registration process dates for its 2012/SP academic term as shown in Figure 48 on page 420. Consider how each of these dates work together and affect what registration processing a student can do at a given time and with what consequence.

Preregistration is about three months long. The registration period is about six weeks long. Notice that the registration period continues two days into the actual start of the academic term. During these two days a student can add or drop sections from his schedule with no penalty. (Their bill will be recalculated to reflect the changes, but there are no additional fees.) A student can add sections through February 13, although EU does charge a late registration fee for these sections. A student can drop sections between January 15 and February 8 without receiving a grade or affecting his GPA. EU will charge the student a drop fee. If a student drops a section between February 9 and April 10, he will receive a grade. (EU has set up a grade scheme that defines automatic processing of a grade entered for a withdrawn student into either WP, for Withdrew Passing, or WF, for Withdrew Failing, whichever is appropriate.) EU has defined these grade so that they are included in the calculation of a student’s GPA. EU charges a drop fee for a section dropped during this period. A student cannot drop a section at all after April 10.

Term Registration Rules

You can also define registration rules for each academic term. Colleague will evaluate these rules at registration to determine which group of students can register between the associated start and end dates for course sections associated with this academic term. If


Ge

you do not define registration rules for an academic term, then all students will be allowed to register for this term during all registration process periods.

The associated dates must be between the preregistration and registration process period dates for this academic term.

For example, Ellucian University has defined a rule called CLASSSR that identifies all students who are undergraduate seniors. The dates associated with this rule define when this segment of students can register for courses associated with this academic term.

See “Academic Term Registration Rules” on page 336 for more information about how to set up your term registration rules.

Term Calendar

You can define various calendar events that relate specifically to a particular academic term. For example, spring break, commencement, and freshmen orientation are all events that take place during the semester that you want to include on the calendar.

Detail to the Campus Calendars (CMPC) form from the Term Calendar field to view more details about the events scheduled during this term calendar.

Figure 49: Campus Calendars (CMPC) Form

See Using Scheduling for more information on defining calendars and special days using the Campus Calendar Special Days (CMPS) form.

Census Dates

These census dates are the dates during which census reports need to be run for this academic term. These dates default into the new course sections associated with this


Ge

academic term, where they can be used to determine when a course section needs to be included in a census.

If you also define term location census dates, they will default into new course sections that are associated with this academic term and a particular location. See “Term Location Dates” on page 425 for more information about defining term location census dates.

Term Location Dates

You can define different process and census dates for each location associated with an academic term that overrides any dates defined on the Reg User Term Dates (RGUT) or the Academic Term (ACTM) forms. You detail on the Location field to the Term Location Dates (TLOC) form.

Figure 50: Term Location Dates (TLOC) Form

If you define term location dates, these dates will default into new course sections which are associated with the academic term and the location. If you do not define term location dates, the term dates will be used. Either set of dates can be overridden at the course section level.

Note: You will receive a warning if you enter a term location preregistration start date that is earlier than the term start date. If this is appropriate for your institution, then continue. Colleague will allow this entry.

For example, preregistration on one of your campuses is only one month long as opposed to three months on other campuses and you would use the TLOC form to adjust the preregistration dates for that particular campus. These more restrictive dates default into new course sections associated during the academic term and on that campus. The


Ge

academic term preregistration dates defaults into new course sections that are associated with this term but are not at this location. The dates can be overridden at the course section level for either location.

Note: These dates can also be overridden by registration user groups at the corresponding level. See “Assigning Registration Controls to Registration Users” on page 826 for more information.

Procedure for Defining Academic Terms

Use the Reporting Years and Terms (RYAT) form as your starting point for defining academic terms. For each reporting year list all associated academic terms.

For each academic term listed on the RYAT form, detail to the Academic Term (ACTM) form to further define each term. See “Defining Academic Terms” on page 417 and online help for more information.


Ge

Defining Transcript Groupings

In This Chapter

This chapter provides information and instruction on the components of transcript groupings, setting up GPA, and defining your institution’s transcript groupings.

Before You Begin

Before you can define transcript groupings, the following information must already be setup.

Understanding Transcript Groupings

You will probably want to generate a transcript for every student at your institution. You can separate all these transcripts into smaller, more manageable groups of transcripts according to the academic activities you select. You will need to define each of these groups with an unique transcript grouping ID, a set of academic credit criteria, additional GPA setup, and sort and print order information.

For example, Ellucian University has defined a transcript grouping ID of “UG” that specifies an academic level of “undergraduate.” All transcripts created with the transcript

Table 134: Information Needed Before You Can Define Transcript Groupings

Code Reference

Academic levels 410

Location codes online help for the Locations (LOCN) form

Departments online help for the Departments (DEPT) form

Divisions online help for the Divisions (DIV) form

Schools online help for the Schools (SCHL) form

Course levels 176

Subjects 281

427tting Started with Colleague Student | Defining Transcript Groupings

Ge

grouping code of “UG,” will use only academic activity with an academic level of “undergraduate.”

Only course sections that both require a grade and have verified grades will ever be included on a transcript. You can choose to include non-graded courses among your selection criteria for a group.

Components of a Transcript Grouping

Use the Transcript Groupings (TRGR) form, shown in Figure 51, to define your transcript groups. Each transcript grouping you define, has the following components:

• Selection criteria

• Print setup

• GPA setup

Each of these components are discussed in this section.

Figure 51: Components of a Transcript Grouping

Selection Criteria

Select criteria you want Colleague to include in this transcript group. Colleague will include all academic credit with verified grades which match your criteria. You can define each transcript grouping using any combination of the following:

• Academic levels

• Locations

GPA Setup

Print Setup

Selection Criteria


Ge

• Credit types

• Departments

• Divisions

• Schools

• Course levels

• Subjects

• Non-graded credits

If you leave any of these fields blank, Colleague will not exclude any academic credit based on that criteria.

For example, a transcript grouping of “UG/MATH” might specify an academic level of “undergraduate” and a department of “MATH.” All transcripts created with the transcript grouping code of “UG/MATH,” would use only academic activity that was both “undergraduate” and from the Math department.

Another selection criteria you can define specifies whether academic credit that does not require a grade should be included in this transcript grouping. Only academic credit that meets your other selection criteria will be included. Courses, which require a grade but have not yet been graded, will never be included on a transcript.

Print Setup

You can define the way the transcripts in each transcript grouping will look when they are printed, including the following:

• Sort fields

• Sort order

• Break fields

• Printer

Each of these options are discussed in this section.

Sort Fields

You can define which fields Colleague will use in sorting the records printed on the transcripts. You need to use actual data element names from the STUDENT.ACAD.CRED file. The fields are sorted in the order in which they are listed on the TRGR form. For example, if STC.END.DATE is the first entry and STC. TERM is the second entry, then Colleague will sort the records by end date and then by term within each end date.


Ge

Sort Order

The sort order instructs Colleague how to sort the selected sort fields. Each sort field entry must have an associated Sort Order entry. For example, if STC.END.DATE is the first entry in the Sort Field field, then the associated Sort Order might be “Ascending.” Colleague would then sort the records on the transcript in ascending end date order.

Break Fields

You can define how the transcripts are broken out when printed. At these breaking points, Colleague will calculate and print totals and GPAs. For example, if you define the transcript grouping of “UG” with a break field of STC.TERM, a break will occur whenever the term changes. Colleague will calculate term totals and term GPAs and print them at each break point.

Printer

From the Printer field on the Transcript Groupings (TRGR) form you can detail to the Transcript Grouping Printing (TGPR) form to further define your printing requirements.

Figure 52: Forms Used to Define Transcript Grouping Printing

GPA Setup

Colleague will calculate a term GPAs and a cumulative GPA for each transcript. Two other GPAs can also be calculated for each transcript group. The default GPAs Colleague will calculate are a major GPA and a minor GPA. However, you can define two other GPAs


Ge

that will override these defaults. These additional GPAs can be set up to appear on a student’s transcript.

For example, suppose you define a transcript grouping that allows both undergraduate and graduate courses to appear on a student’s transcript. You might decide to have a GPA calculated for just the undergraduate courses.

Each of the two additional GPA you can define has the following components:

• Defining rules

• Label

• Break field

Each GPA component are explained in this section.

GPA Rules

You can set up two additional GPAs for each transcript grouping you have defined. Colleague will calculate these GPAs according to rules you define. You need to specify which subselection of academic activity use to calculate these GPAs.

For example, Ellucian University has a transcript grouping ID of UG/GR that allows both undergraduate and graduate courses to appear on a student’s transcript. Ellucian University has set up an additional GPA, an “academic level” GPA, which will compute the GPA of courses in each academic level separately.

You can view the additional GPA rules you have defined by accessing the GPA 1 Rules (GPA1) or the GPA 2 Rules (GPA2) forms. You can access either form from the TRGR form or the main menu.

If you do not define additional GPA rules, Colleague will calculate the default GPAs. The default for GPA1 is a major GPA. The default for GPA2 is a minor GPA.

See “Grade Point Averages Rules” on page 344 for details on defining your GPA rules.

GPA Label

You can set up your transcripts to include the additional GPAs you have defined. You can tell Colleague how to label your newly defined GPAs. For example, if you had defined GPA1 to calculate just the graduate courses on a student’s transcript, you might want the GPA1 label to be “Graduate GPA.”

GPA Break Field

You can define where Colleague will display the additional GPAs. When you designate a break field, Colleague will put a break in the transcript when there is a change in that field, compute the GPA on that group of records, and print the calculated GPA, along with the designated label, if any, in the break.


Ge

For example, the Ellucian default is to calculate GPA1 as a major GPA. Since a student can have more than one academic program, the GPA 1 Break Field should contain “STC.GPA1.ACAD.PROGRAMS,” and a separate GPA would be computed for the majors of each academic program for the student. Similarly, if you want to use the GPA2 default of a minor GPA, enter “STC.GPA2.ACAD.PROGRAMS” in the field GPA 2 Break Field and a separate GPA would be computed for the minors of each academic program for the student.

If you define GPA1 rules but the GPA 1 Break field is left blank, then only the cumulative GPA1 will be calculated. Likewise, you must define the GPA 2 Break field if you have defined GPA 2 rules.

Procedure for Defining Transcript Groupings

Use the Transcript Groupings (TRGR) form to define your transcript groupings. See “Understanding Transcript Groupings” on page 427 and online help for more information.


Ge

Academic Records Worksheets

In This Chapter

This chapter provides worksheets that you can use to assist you in setting up the Academic Records module.

Table 135: Academic Records Worksheets

Worksheet ReferenceProcedure Reference

Academic Level Graduation Honors Rules— English Statements

435 “Graduation Honors Rules” on page 325

Academic Program Graduation Honors Rules— English Statement

436 “Graduation Honors Rules” on page 325

Academic Level Standing Rules — English Statements

437 “Academic Standing Rules” on page 331

Academic Level Term Standing Rules — English Statements


Academic Program Standing Rules — English Statements


Academic Term Registration Rules— English Statements

440 “Academic Term Registration Rules” on page 336

Class Level Rules— English Statements 441 “Class Level Rules” on page 339

Enrollment Status Rules— English Statements

442 “Enrollment Status Rules” on page 342

GPA Rules — English Statements 443 “Grade Point Averages Rules” on page 344

Transcript Print Restriction Rules — English Statements

444 “Print Restriction Rules” on page 346

Grade Print Restriction Rules — English Statements

445 “Print Restriction Rules” on page 346

Student Load Rules — English Statements 446 “Student Load Rules” on page 350

433tting Started with Colleague Student | Academic Records Worksheets

Ge

Student Term Status Rules— English Statements

447 “Student Term Status Rules” on page 353

Academic Records Default Parameters 448 “Procedure for Defining Academic Records Parameters” on page 358

Grade Schemes and Grades 449 “Procedure for Defining Grades” on page 408

Absences Table Worksheet 450 “Absences Table” on page 416

Table 135: Academic Records Worksheets (continued)

Worksheet ReferenceProcedure Reference


Ge

Academic Level Graduation Honors Rules — English Statements

Table 136: Academic Level Graduation Honors Rules – English Statements Worksheet

Academic Level:

Graduation Honors Criteria Honors


Ge

Academic Program Graduation Honors Rules — English Statements

Table 137: Academic Program Graduation Honors Rules – English Statements Worksheet

Academic Program:

Graduation Honors Criteria Honors


Ge

Academic Level Standing Rules — English Statements

Table 138: Academic Level Standing Rules – English Statements Worksheet

Academic Level:

Standing Criteria Standing


Ge

Academic Level Term Standing Rules — English Statements

Table 139: Academic Level Term Standing Rules – English Statements Worksheet

Academic Level:

Academic Standing Criteria Standing


Ge

Academic Program Standing Rules — English Statements

Table 140: Academic Program Standing Rules – English Statements Worksheet

Academic Program:

Academic Standing Criteria Standing


Ge

Academic Term Registration Rules — English Statements

Table 141: Academic Term Registration Rules – English Statements Worksheet

Academic Term:

Registration CriteriaStart Date

End Date


Ge

Class Level Rules — English Statements

Table 142: Class Level Rules – English Statements Worksheet

Academic Level:

Class Level Code Class Level Criteria Sequence


Ge

Enrollment Status Rules — English Statements

Table 143: Enrollment Status Rules – English Statements Worksheet

Academic Level:

Enrollment Status Criteria Status


Ge

GPA Rules — English Statements

Use this worksheet to define your grade point averages rules. You can define two additional GPA rules for each transcript grouping.

Table 144: GPA Rules – English Statements Worksheet

Transcript Grouping:

GPA 1 Rules:

GPA 2 Rules:


Ge

Transcript Print Restriction Rules — English Statements

Table 145: Transcript Print Restriction Rules – English Statements Worksheet

Transcript Print Restrictions


Ge

Grade Print Restriction Rules — English Statements

Table 146: Example Grade Print Restriction Rules – English Statements Worksheet

Grade Print Restrictions


Ge

Student Load Rules — English Statements

Table 147: Student Load Rules – English Statements Worksheet

Academic Level:

Student Load Criteria Load


Ge

Student Term Status Rules — English Statements

Table 148: Student Term Status Rules – English Statements Worksheet

Academic Level:

Student Term Status Criteria Status


Ge

Academic Records Default Parameters

Table 149: Academic Records Default Parameters Worksheet

Generate Random IDs: Term / Course Session / None

Academic Level Default Rules Standing

Academic Level Term Default Rules Standing

Petition Status:

Student Withdrawal Approvals

Office Required

1. Yes/No

2. Yes/No

3. Yes/No


44

9G

etting Sta

rted with C

olleague S

tudent

|A

cadem

ic Record

s Worksheets

GR

epeat V

alue

Rep

lacedA

ttemp

ted C

redits

Rep

lacedC

om

pleted

Cred

its

Rep

laced

GP

A C

red

its

rades Schemes and Grades

For each grade scheme you define use a separate worksheet.

Table 150: Grades Schemes and Grades Worksheet

Grade Scheme:

Start/End Date:

Repeat Grade Usage:

Grade Value Legend

Translating Grades Include In …

Au

dit

Pass N

op

ass

Dro

p/ W

ithd

raw

Inco

mp

lete

Attem

pted

Cred

its

Co

mp

lete

d C

red

its

GP

A C

red

its

Ge

Absences Table Worksheet

Table 151: Absences Table Worksheet

Number of Meeting Days Not Greater Than

Number of Student Absences Document To Be Sent


Accounts Receivable

Ge

Setting Up Billing Defaults and Parameters

In This Chapter

This chapter provides information and instruction for setting up billing defaults and parameters for:

• General billing

• Registration billing

• Room billing

• Meal plan billing

Before You Begin

Before you set up your billing defaults and parameters, you should define the following:

Table 152: Information Needed Before Setting Up Billing Defaults And Parameters

Information Needed Reference

AR codes 149

Locations online help for the Locations (LOCN) form

Award periods1

1.Use award periods for defining the financial aid transmittal parameters

164

AR types 159

Academic levels 410

Refund policies and formulas 478

453tting Started with Colleague Student | Setting Up Billing Defaults and Parameters

Ge

You should also read the following chapters before you set up the billing defaults and parameters described in this chapter:

General Billing Defaults and Parameters

Colleague uses certain defaults and parameters for registration, room, and meal plan billing. Because many of the different sets of billing defaults and parameters contain some common elements (such as when the charges are posted to accounts receivable), these common items are described in this section. Items that are specific to each type of billing are described in the following sections:

Components of Billing Defaults And Parameters

You define each set of billing defaults and parameters—the parameters and defaults set for a specific type of charge—on a form specific to that type of charge, for example, registration billing parameters. Table 162 on page 477 lists the individual forms used to set the parameters for each type of billing. Figure 53 illustrates some of the billing parameter forms.

Table 153: Information You Should Read Before Setting Up Billing Defaults And Parameters

Chapter Purpose

Using Accounts Receivable/Cash Receipts

To understand how Colleague generates registration, room, and meal plan charges

“Understanding the Rules Processor” on page 309

To understand Colleague’s rule processor

Table 154: Finding Information in this Chapter

For Information about … See …

Registration billing defaults and parameters

“Registration Billing Defaults and Parameters” on page 466

Room billing defaults and parameters “Room Billing and Meal Plan Billing Defaults and Parameters” on page 474

Meal plan billing defaults and parameters “Room Billing and Meal Plan Billing Defaults and Parameters” on page 474


Ge

Figure 53: The Billing Parameters Forms

You can see from the examples in Figure 53 that many of these billing defaults and parameters have several elements in common. The following common elements are described in this section:


Ge

• Update AR Immediately

• Billing Cutoff Date

• Section Cancellations

• Section Cancel Cutoff Date

• Deferred Billing

• Default AR Types

Refer to the sections about the different billing types for information about the other parameters you set.

Posting Charges to AR

The Update AR Immediately parameter determines when Colleague creates AR billing records for automatically generated charges. If you set this parameter to “Yes,” Colleague creates postings and invoice records as soon as a transaction is recorded. For example, Colleague creates registration billing invoices as soon as a student’s registration information is updated. If a transaction is term-related, Colleague also takes into account whether the term is active for billing in determining whether to create billing records.

If you set this parameter to “No,” you must run a batch billing process before AR reflects the automatic charges. The specific batch process run to post charges depends on the type of billing. Table 155 lists each of the billing types that provide an Update AR Immediately parameter and the batch process you run to create the respective charges.

The billing start date and the billing cutoff date, as well as how you have set the Update AR Immediately parameter, determines the billing records Colleague creates.

Table 155: Processes that Generate Unposted Billing Records

Billing Type Batch Process Reference

Registration billing Batch Reg/Room/Meal Billing (BILL)


Section cancellation billing

Batch Reg/Room/Meal Billing (BILL)

Section Batch Status Change (SBSC)

Using Accounts Receivable/Cash ReceiptsUsing Curriculum Management

Room billing Batch Reg/Room/Meal Billing (BILL)


Meal plan billing Batch Reg/Room/Meal Billing (BILL)


Sponsor billing Sponsored Student Billing (SSRP and SSTB)



Ge

If you have set the Update AR Immediately parameter to “Yes,” Colleague uses the date you define as the cutoff date to determine which charges to post to AR. If a billing record has a billing start date after the cutoff date, Colleague does not create that billing record when the transaction is recorded. For example, if the billing start date for a registration charge is 09/15/09, and the billing cutoff date is 09/13/09, Colleague does not post that charge to AR until you run the batch registration billing process.

If you set the Update AR Immediately parameter to “Yes,” and you do not establish a billing cutoff date, then Colleague posts all charges to AR as soon as the transaction is entered.

Note: If you set the Update AR Immediately parameter to “No,” you cannot establish a billing cutoff date.

Table 156 summarizes how Colleague uses the Update AR Immediate parameter and the cutoff date.

If the generated charges are term-related, Colleague also uses the term’s billing start and end dates, defined on the Academic Terms (ACTM) form, to determine whether to post the charges. If a term is not currently active for billing on the date that a transaction occurs, Colleague does not create the charges.

Table 156: Update AR Immediate Parameter and Cutoff Date

Setting of the Update AR Immediately Parameter

Cutoff Date Entered?

Yes No

Yes Colleague immediately posts to AR any charges with a billing start date prior to the cutoff date as long as the billing period is active.

You need to run the batch billing process to post charges with a billing start date greater than the cutoff date, or for a term that is no longer active for billing.

Colleague immediately posts to AR all charges as long as the billing period is active.

No Colleague does not post any automatic charges until you run the batch billing process. The batch billing process has its own cutoff date.


Ge

Table 157 summarizes how Colleague uses a term’s billing start and end dates to determine whether the term is active for billing.

See “Billing Dates” on page 422 for information about defining the billing start and end dates for a term. See Figure 56 on page 463 to see how Colleague uses the billing parameters explained in this chapter along with a term’s billing start and end dates to determine whether to post charges.

Table 158 summarizes how Collegue determines the term of an item to be billed.

Table 157: Term Billing Start and End Dates 1

1.Term billing start and end dates are defined on the Academic Terms (ACTM) form.

Today’s Date

Term

Bill Item?Billing Start Date

Billing End Date

1/15/09 1/20/09 5/30/09 No

1/15/09 (blank) 5/30/09 Yes

2/25/09 1/20/09 5/30/09 Yes

6/1/09 1/20/09or

blank

5/30/09 No

Table 158: Determining the Term Used When Billing an Item

Billing Process Term From

File/Data Element

Registration billing STUDENT.ACAD.CRED

STC.TERM

Section cancellations COURSE.SECTIONS

SEC.TERM

Meal plan billing MEAL.PLAN.ASSIGNMENT

MPAS.TERM

Room assignment billing ROOM.ASSIGNMENT

RMAS.TERM

Student sponsorship billing AR.INVOICES

INV.TERM


Ge

Section Cancellations

The Section Cancel Update AR Immediately parameter determines when colleague creates AR billing records when a course is cancelled. If you set this parameter to “Yes,” Colleague creates postings and invoice records as soon as the section is cancelled as long as the billing period is active. For example, Colleague creates credit adjustments as soon as a student’s registration information is updated.

If you set this parameter to “No,” you must run the batch billing process (BILL) before AR reflects the credit adjustments.

Section Cancel Cutoff Date

The section cancel date and the section cancel cutoff date, as well as how you have set the Section Cancel Update AR Immediately parameter, determines the billing records Colleague creates.

If you have set the Section Cancel Update AR Immediately parameter to “Yes,” Colleague uses the date you define as the cutoff date to determine which credits to post to AR. If a billing record has a cancel date after the cutoff date, Colleague does not create that billing record when the transaction is recorded. For example, if the section cancel date for a course section is 09/15/09, and the billing cutoff date is 09/13/09, Colleague does not post that credit to AR until you run the batch registration billing process.

If you set the Section Cancel Update AR Immediately parameter to “Yes,” and you do not establish a section cancel cutoff date, then Colleague posts all credits to AR as soon as the transaction is entered.

Note: If you set the Section Cancel Update AR Immediately parameter to “No,” you cannot establish a section cancel cutoff date.

If the generated charges are term-related, Colleague also uses the term’s billing start and end dates, defined on the Acadmic Terms (ACTM) form, to determine whether to post the charges. Table 157 on page 458 summarizes how Collegue uses a term’s billing start and end dates to determine whether the term is active for billing.

Immediate Billing Control

You can view and maintain the Update AR Immediately parameters and associated cutoff dates for all applications of that parameter on the Immediate Billing Control (IMBC) form (Figure 54) or from the individual parameter forms.


Ge

Figure 54: Example of Immediate Billing Control for All Billing Processes

Note: You can modify the Update AR Immediately parameter on either the IMBC form or the billing parameter form for each billing process. When you modify the parameter on one form, the change is reflected on the other.

Location-Specific Immediate Billing Parameters

You can also establish immediate billing parameters by location. When determining the location of an item to be billed, Colleague uses the location assigned to each item as summarized in Table 159.

Table 159: Determining Location Used When Billing an Item

Billing Process Location From

File/Data Element

Registration billing STUDENT.COURSE.SEC

SCS.LOCATION

Section cancellations COURSE.SECTIONS

SEC.LOCATION

Meal plan billing MEAL.PLANS

MEAL.LOCATIONS


Ge

Relationship between Default Billing Parameters and Location-Specific Billing Parameters.

When you define a set of billing parameters for a specific location, Colleague puts in the default billing parameters (those on the Immediate Billing Control [IMBC] form). You can then change those defaults as you need. However, if you want only certain billing parameters to be location-specific, you should remove the default settings associated with a specific location. Then, if you choose to change any of the default parameters you do not want to be location-specific, Colleague uses those parameters. Figure 54 illustrates how Ellucian University has set up its default billing parameters and one set of location-specific parameters.

Room assignment billing BUILDINGS

BLDG.LOCATION

Student sponsorship billing AR.INVOICES

INV.LOCATION

Table 159: Determining Location Used When Billing an Item (continued)

Billing Process Location From

File/Data Element


Ge

Figure 55: Location-Specific and Default Billing Parameters

Because of the setting of the registration Update AR Immediately parameter on the Location Billing Parameters form, Colleague does not create registration billing records for students registering at the main campus. However, Colleague immediately updates AR with room or meal plan charges that anyone enters for the main campus because the billing parameters specific to the main campus do not indicate a setting for room or meal plan billing.

If the business office does not want room charges to update AR immediately, they change only the default settings for room charges and Colleague does not update AR with room charge transactions recorded.

See Figure 56 on page 463 for how Colleague determines which parameters (location or immediate) to use when creating billing records.


46

3G

etting Sta

rted with C

olleague S

tudent

|S

etting Up B

illing D

efaults and Param

eters

No

Yes

Bill

Figure 56: Immediate Billing Workflow Diagram

GetUpdate AR Immediately flag and Cutoff Date from IMBC

LocationExists?

LocationUpdate AR Immediately

Update AR Immediately flag= YES?

Cutoff Date = blank orCutoff Date >Item Start Date

TermExists?

LocationUpdate AR Immediately flag Exists?

Today’s Date Within Term Billing Date Range?

Yes

Yes

Yes Yes

No

No

N

No

Do Not Bill

No

Y

Get Location Update AR Immediately flag and Cutoff Date from LOCB

Ge

Deferred Billing

Colleague recognizes revenue from charges based on the billing period associated with that charge relative to the date the charge is posted to accounts receivable. For example, Ellucian University’s fiscal year is from July 1 through June 30. Figure 57 illustrates three different EU billing periods relative to two fiscal years (FY2009 and FY2010). If, during fiscal year 2009, Colleague posts a charge to accounts receivable with a billing period of 3/1/09–5/30/09, Colleague recognizes the revenue associated with that charge as current revenue.

If, during fiscal year 2009, Colleague posts a charge to accounts receivable with a billing period of 9/1/09–12/31/09, Colleague defers the revenue associated with that charge until FY2010.

If, during fiscal year 2009, Colleague posts a charge to accounts receivable with a billing period of 6/1/09–8/31/09, Colleague either recognizes the revenue as current revenue, defers the revenue, or recognizes a portion of the revenue as current revenue and defers the remaining portion.

You determine how Colleague records the revenue for charges that have a billing period that crosses fiscal years through the deferred revenue code.

Figure 57: Example Billing Periods

Deferred Revenue Code

Colleague defers revenue from charges that cross fiscal years based on the deferred revenue code you assign to each billing parameter.

Note: Registration, room billing, and meal plan parameters can have unique deferred revenue codes that control when Colleague defers revenue for each type of charge.

The deferred revenue codes you can use are

• S – start date

• E – end date

• P – part in each year

FY2009 FY2010

6/1/09 8/31/09

B

3/1/09 5/30/09

A

9/1/09 12/31/09

C


Ge

Start Date. When you set the deferred revenue code to “S,” Colleague posts all revenue to the fiscal year of each charge’s start date.

End Date. When you set the deferred revenue code to “E,” Colleague defers all revenue to the fiscal year of each charge’s end date.

Partial. When you set the deferred revenue code to “P,” Colleague prorates the revenue based on the period of time the charge is covered by the current fiscal year and the next fiscal year.

Deferred Revenue General Ledger Account

Colleague defers revenue by posting the deferred portion to the general ledger account associated with the AR code being charged. See “AR Codes” on page 149 for information about defining a deferred revenue GL account for specific AR codes.

Note: Colleague does not defer charges for any AR codes that are defined without a deferred revenue general ledger account.

Default AR Types

You identify the AR type Colleague uses for each type of billing by defining either a single default AR type or using AR type rules.

Note: Colleague does not require you to enter a default AR type when you define the billing parameters. However, Colleague cannot generate these charges without an AR type.

AR Type Rules

If you use more than one AR type for automatic charges, use AR type rules to tell Colleague when to use each of these AR types. For example, for registration charges you might use a student receivables AR type and a sponsor receivables AR type.

When Colleague creates a billing record, it evaluates your AR type rules defined for that billing type and uses the AR type associated with the rule that evaluates true. If a rule does not evaluate as true, Colleague uses the default AR type. See Using the Default and Rules-based AR Types below.

Default AR Types

Colleague uses the default AR type for all billing records that do not have an AR type assigned based on the result of a rule being true. If you use the same AR type for all charges, identify the default AR type and do not use the AR type rules.


Ge

Using the Default and Rules-based AR Types

To minimize the number of rules you need to create for assigning AR types to billing records, use the default AR type to identify the majority of your billing types and write your rules to cover the exceptions. For example, if most of your registration receivables are student receivables, enter your student receivable AR type in the Default AR Type field on the Registration Billing Parameters (REBP) form. Then create rules that identify each of the other receivable types you have for registration billing, such as employee receivables.

Tips for Writing AR Type Assignment Rules

When you define the rules for assigning a specific AR type to a billing record

Registration Billing Defaults and Parameters

Registration Billing Parameters

The registration billing defaults and parameters are set on the Registration Billing Parameters (REBP) form.

Table 160: Tips for Writing AR Type Assignment Rules

Tip Reference

Map out your rules in simple English statements

use the worksheet “Rule Construction—English Statements” on page 320

Work with your system administrator to translate the English statements to the rule processor’s syntax

use the worksheet “Rule Construction Translation” on page 322

For AR type assignment rules used with registration billing, create the rules with a primary file view of the REG.AR.POSTINGS file

see “Understanding the Rules Processor” on page 309 for information about primary files views

For AR type assignment rules used with room billing, create the rules with a primary file view of the ROOM.ASSIGNMENT file


For AR type assignment rules used with meal plan billing, create the rules with a primary file view of the MEAL.PLAN.ASSIGNMENT file



Ge

Figure 58: Registration Billing Defaults & Parameters

This sections describes the Discount Limits group. See “Default AR Types” on page 465 for information about the Update AR Immediately parameter and the default AR type. See online help for information about the other fields on this form.

Discount Limits

Use the Discount Limits group on the Registration Billing Parameters (REBP) form to establish default discount limits based on academic level. These discount limits apply to courses with a section-based billing method. For example, if you set a 25 percent discount limit for graduates, then, when you establish the billing parameters for a graduate course that use section-based billing method, Colleague defaults this 25 percent maximum in the Disc Max Pct field on the Course Billing Information (CRSB) form. As with any defaults, you can override the default value for an individual course or an individual course section (on the Section Billing Information [SECB] form).

See “Defining Tuition Discounts” on page 528 for more information about tuition discounts. See “Understanding a Course Section’s Billing Information” on page 501 for more information about billing method and course and course section billing parameters.

Periodic Registration Billing Parameters

When you use standard registration billing, Colleague calculates a student’s tuition and fees at the time the student enrolls in a course section. Colleague bases these charges on the student’s enrollment or the number of billing credits enrolled for. When you use periodic registration billing, Colleague calculates the student’s tuition and fees for an initial time period and possibly for additional time periods up to the end of the student’s enrollment in the course section. This section describes how Colleague processes periodic registration charges and how you set up registration billing for periodic billing.


Ge

How Colleague Calculates Periodic Registration Charges

The first steps Colleague takes when generating a student’s charges is to evaluate each course section to determine if standard or periodic registration billing applies. Figure 59 illustrates Colleague’s evaluation process to determine if periodic billing applies to a course section.

Figure 59: Steps Before Calculating Periodic Registration Billing

Once Colleague determines that a course section is billed using the periodic billing method, it calculates the student’s registration charges using the parameters and defaults you define for periodic billing (see “Setting Up Colleague for Periodic Registration Billing” on page 470).

In general, Colleague calculates a student’s periodic registration charges as follows:

1. Calculate the total enrollment period

2. Calculate the total time period for which the student is being billed

3. Calculate the charges for each time period

Each of these steps is described in detail below.

Calculate the Total Enrollment Period. The total enrollment period is the amount of time the student is enrolled in the course section. Colleague calculates the total enrollment

period as , where “start date” and “end date” are the days that

the student’s enrollment in the course section starts and ends.1 Colleague calculates the enrollment period in terms of the base billing period you define for all periodic billing. For

Is the Periodic Billing flag for the course section set

to “Y”?

Yes

No

Is the Billing Method for the course section

set to “T”?

Start

Use standard registration billing

No

The Billing Method for the course section is “S.”

Calculate periodic registration billing.

Yes

Evaluate the registration rate fields and locate the

registration rate table with values matching the student’s values and with the Periodic

Billing set to “Yes.”

Is a match found?

No

Stop the billing process and issue an error message.

Yes

end date start date – 1+


Ge

example, if the base billing period is “monthly,” Colleague calculates the student’s total enrollment in months. If there are any partial period within the total enrollment, Colleague calculates those fractions separately.

Calculate the Total Time Period Being Billed. The total time period for which Colleague bills a student’s enrollment in a periodically billed course section is the total enrollment period compared to the maximum number of periods you bill at once. If the student’s enrollment period is less than the maximum number of periods, Colleague bills the student once for the total enrollment. For example, if the student is enrolled for a course section for four months and the maximum number of months per billing period is five, Colleague bills the student once for the total enrollment.

If the student’s total enrollment is greater than the maximum number of periods you bill at once, Colleague determines the total time period billed based on the Number of Periods

per Billing and Number of Days Advance Billing parameters.1 The following is an example set of parameters for periodic billing:

If a student enrolls in a periodically billed course section with a start date of January 1, 2010, and an end date of December 31, 2010, the student’s total enrollment is 12 months. If Colleague generates the registration charges for the student on March 10, 2010, Colleague calculates the number of billing periods as follows:

1. Add the number of days advance billing to the system date. This represents the billing start date. In the above example, 5 days after March 10, 2010, is March 15, 2010.

2. Determine the number of periods (in this example, months), between the enrollment start date and the billing start date. In the above example, there are 3 months between January 1, 2010 and March 15, 2010 (for this part of the calculation, Colleague does not consider fractions of periods).

3. Compare the number of months that Colleague bills at once with the number of months in the current billing period. If the number of months per bill is not equal to the number of months in the billing period, Colleague rounds up to the next multiple of the number of months per bill. In this example, 3 is less than 4, so Colleague rounds up to 4. Thus, Colleague bills this student for 4 months of the course section enrollment.

1.Because each student may start and end a course section at any time, Colleague uses the dates that the student starts and ends the enrollment in the course section, and not the default start and end dates for the course section.

1.Define the Number of Periods per Billing and Number Days Advance Billing parameters on the Periodic Registration Billing Parameters (PRBP) form. See “Setting Up Colleague for Periodic Registration Billing” on page 470 for details.

Table 161: Example Parameters for Periodic Billing

Base Billing Period Monthly

Max Periods for Single Billing 4

Number of Periods per Billing 4

Number Days Advance Billing 5


Ge

Calculate the Charges for Each Time Period. Once Colleague determines the length of time that it bills the student, it multiples that value by the total charges defined for the course section. For example, if the total tuition and other charges for the course section described in the above example is $500 per month, Colleague bills the student $2,000

( ) on March 10, 2010.

Colleague determines the charges for course sections billed based on a tuition table from the tuition rate table, registration term rate table, and the waiver policy associated with the appropriate registration rate table. Colleague determines the charges for section-based billed course sections from the tuition and other charges associated with that course section.

Setting Up Colleague for Periodic Registration Billing

To use periodic registration billing, you must:

• Identify each course or course section you bill using this method and mark them for periodic billing

• Determine if Colleague calculates the courses sections charges from a registration rate table or from billing information associated with each course section and define the appropriate billing information

• Set your global periodic registration billing parameters

These items are described below.

Identify Courses or Course Sections. You can define either a course or course sections for periodic registration billing. If all sections associated with a particular course use periodic registration billing, then set the Periodic Billing parameter on the Course Billing Information (CRSB) form to “Yes.” Colleague defines each section you create for this course with this setting, which you can change on a section-by-section basis.

If only specific sections associated with a particular course use periodic registration billing, then set the Periodic Billing parameter on the Section Billing Information (SECB) form to “Yes,” for each applicable section.

500 4


Ge

Figure 60: Example Courses and Course Sections

Periodic Billing Paramet


Ge

Table-based or Section-based Billing. When you define course sections with periodic billing and with the table-based billing method, you must define the appropriate registration rate tables for each group of students who register for the course section. Each registration rate table must have the Periodic Billing parameter set to “Yes.” For example, if you have a graduate-level course section defined with periodic billing, you must have a version of each graduate registration rate table with the Periodic Billing parameter set to “Yes.”

Note: If you define a course section using table-based billing and periodic billing, and Colleague cannot find a registration rate table with the Periodic Billing parameter set to “Yes” that matches the student’s billing characteristics, Colleague does not calculate charges for the student.

See “Defining Table-Based Tuition” on page 504 for information about defining a registration rate table.

When you define course sections with periodic billing and with section-based billing method, define the billing information for that section in the same manner as a course section that does not use periodic billing. See “Defining Section-Based Tuition” on page 512 for details on setting the billing information for section-based billed course sections.

Setting Periodic Billing Parameters. Use the Periodic Registration Billing Parameters (PRBP) form to define the parameters that control how Colleague processes all course sections using periodic billing.

Figure 61: Example Periodic Registration Billing Parameters

Note: Refer to “How Colleague Calculates Periodic Registration Charges” on page 468 for details on how Colleague uses the parameters defined on the PRBP form.


Ge

Base Billing Period. The base billing period describes the frequency with which you generate periodic registration charges. This field also describes the rate period Colleague uses to generate charges for periodically billed course sections. Valid base billing periods are:

• W – Weekly

• M – Monthly

• Y – Yearly

If, for example, you set the base billing period to monthly, all registration charges you define for periodically billed course sections are monthly rates and the billing periods you identify in the remaining fields on the PRBP form are months.

Max Periods for Single Billing. The maximum periods for a single billing indicates how many billing periods Colleague bills at once for any student. For example, the parameters defined in Figure 61, indicate that Colleague bills four months at a time for each periodically billed course section. When a student’s enrollment in a periodically billed course section is less than or equal to this maximum, Colleague generates one invoice that represents the total charges for that enrollment. When a student’s enrollment is greater than this maximum, Colleague generates multiple invoices to cover the charges for that enrollment.

Number Periods per Billing. If the length of a student’s enrollment is greater than the maximum number of periods for a single billing, Colleague determines the number of billing periods it uses to calculate the registration charge from this value. In the example illustrated in Figure 61, if the billing period is greater than four months, Colleague generates a bill in four month increments, unless the total enrollment period is less than the next monthly increment.

Number of Days Advance Billing. Colleague uses the number of days advance billing to determine when it should bill a student for periodically billed course sections. Colleague adds this number of days to the billing period start date to determine the billing period end date. The billing period start date is either the enrollment start date (when calculating the first invoice) or the start date of the next billing period (which is the same as the end date of the last billing period). As described in “How Colleague Calculates Periodic Registration Charges” on page 468, Colleague determines the number of periods that it bills by calculating the number of periods in-between these start and end dates and comparing the number of billing periods with the Max Periods for Single Billing.

Partial Period Rounding and Rounding Unit. When the enrollment period or billing period of a periodic billing is not a whole number of periods, Colleague uses the Partial Period Rounding and the Rounding Unit parameters to round the partial periods. Valid options for the Partial Period Rounding are:

• U – Round up

• D – Round down

• N – Round to the nearest

The Rounding Unit tells Colleague the unit of rounding, such as 0.25. The rounding unit must be less than or equal to 1 and divide evenly into 1. Therefore, 0.25 and 0.125 are valid, but 0.333 is not a valid rounding unit.


Ge

Colleague determines the partial period by

1. Taking the days remaining from the whole periods.

2. Dividing the number of days by the number of days in the base period (if the base period is week, divide by 7; if the base period is month, divide by 30; if the base period is year, divide by 360).

3. Round the results according to the Partial Period Rounding and the Rounding Unit parameters.

Calculate Periods Subroutine. If you want Colleague to round the partial periods differently than with the Partial Period Rounding and Rounding Units parameter, your system administrator can write a subroutine to perform the rounding calculations. Use a subroutine in place of the Partial Period Rounding and Rounding Units parameters.

Room Billing and Meal Plan Billing Defaults and Parameters

Note: This section describes how to define the parameters for billing records generated from the Residence Life module. If you do not use Colleague’s Residence Life module you do not need to define these parameters.

Use the Room Billing Parameters (RMBP) form to set room billing defaults and parameters. Use the Meal Plan Billing Parameters (MLBP) form to set meal plan billing defaults and parameters. Figure 62 illustrates these forms.


Ge

Figure 62: Room Billing and Meal Plan Billing Defaults & Parameters

In addition to the billing defaults and parameters described in “General Billing Defaults and Parameters” on page 454, the parameters for both room billing and meal plan billing include defaults for refund formulas.

Default Refund Formulas

The refund formulas that Colleague uses when it creates room or meal plan billing records are determined by the refund formula parameters you define for each type of billing. There are two methods for identifying the refund formula that Colleague uses: refund formula rules and the default refund formula.


Ge

Rules-based Refund Formulas

If you use more than one refund formula for either room charges or meal plan charges, use refund formula rules to indicate when Colleague applies each of these refund formulas. When Colleague creates a billing record for either room or meal plan charges, it evaluates the refund formula rules defined for that billing type and uses the refund formula associated with the rule that evaluates true. If a rule does not evaluate as true, Colleague uses the default refund formula.

Default Refund Formula

Colleague uses the default refund formula for all billing records that do not have a refund formula assigned based on the result of a rule being true. If you identify a default refund formula and do not use refund formula rules, Colleague uses the same refund formula for all charges.

Using the Default and Rules-based Refund Formulas

To minimize the number of rules you need to create for assigning refund formulas to billing records, use the default refund formula to identify the majority of your billing situations and write your rules to cover the exceptions. For example, if most of your room charges have the same refund formula, use that refund formula as the default refund formula. Then create rules to identify each of the other refund formulas you use for room billing.

Writing Refund Formula Rules

Complete the following steps to define refund formula rules.

1. Define your refund formulas for room billing and meal plan billing.

See “Procedures for Defining Refunds” on page 490.




Note: The data elements you use must be from the ROOM.ASSIGNMENT file for room refund rules or from the MEAL.PLAN.ASSIGNMENT file for meal plan refund rules. See “Understanding the Rules Processor” on page 309 for more information about primary views.


4. Go to the Room Billing Parameters (RMBP) form to define room refund rules or Go to the Meal Plan Billing Parameters (MLBP) form to define meal plan refund rules.

5. Go to the Refund Rule field.

6. Enter the name of each refund rule.


Ge


If the name of the rule displays and the cursor moves to the Refund Formula field, continue with Step 9.

7. Define the rule.


The RMBP form or the MLBP form is redisplayed.

9. Enter the refund formula Colleague uses when the associated rule is true.

10. Repeat this procedure for each refund formula rule.

11. Save the billing parameters.

Procedure for Setting Up Billing Defaults and Parameters

Table 162: Forms Used for Setting Up Billing Defaults and Parameters

To Set Up … Use the …

Registration billing defaults and parameters

Registration Billing Parameters (REBP) form

Room billing defaults and parameters Room Billing Parameters (RMBP) form

Meal plan billing defaults and parameters

Meal Plan Billing Parameters (MLBP) form


Ge

Defining Registration Refunds

In This Chapter

In this chapter we describe refunds in general terms and also explain how you will set up refunds for registration charges, room charges, and meal charges. Refer to Table 163 for the sections in this chapter that describe the different aspects of refunds.

Table 163: Information about Refunds

Topic Reference

Refund formulas “Understanding Refund Formulas” on page 479

Registration refunds “Understanding Registration Refunds” on page 484

Registration refund policies “Understanding Registration Refund Policies” on page 486

Room charge refunds “Understanding Room Charge and Meal Plan Charge Refunds” on page 488

Meal charge refunds

478tting Started with Colleague Student | Defining Registration Refunds

Ge

Before You Begin

Understanding Refund Formulas

A refund formula describes the terms under which you return specific charges incurred by an individual. In Colleague, you define refund formulas that Colleague uses to automatically calculate a refund for registration charges, room charges, and meal plan charges.

Components of a Refund Formulas

Use the Refund Formulas (REFF) form to define each of your refund formulas.

Table 164: Information Needed Before You Can Define Refunds


An understanding of how Colleague calculates refunds for registration charges, room charges, and meal plan charges


An understanding of the rules processor



Ge

Figure 63: Example of a Refund Formula

The following fields and group of fields from the Refund Formula (REFF) form are described in this section:

• Count Section Meeting

• Days Excluded

• Days Before Start

• Days Used

• Pct Used

• Refund Portion

Refer to the online help for information about any of the fields on the REFF form.

Count Section Meeting

Note: This option applies to registration refunds only

Use the Count Section Meeting field for registration refunds to indicate how Colleague uses the section meetings. If you enter Y, Colleague determines the refund based on the number of times a course section has met when the refund is issued. If you enter N, Colleague determines the refund based on the number of calendar days elapsed in the period from the start of the course section to the time the refund is issued. If you set this parameter to “N,” Colleague excludes any days specified in the Days Excluded field.

Days Before Start group

Days Used group

Percent Used group


Ge

Days Excluded

Note: This option applies to registration refunds only and is used only when the Count Section Meeting parameter is set to “No.”

Use the Days Excluded field to identify the specific days that Colleague excludes from the refund calculation. Valid entries are:

• SA – Saturday

• SU – Sunday

• HO – Holidays

For example, the refund formula illustrated in Figure 63 uses calendar days, and not section meeting days, and excludes Sundays and Holidays from the refund calculation. For a course section that begins Monday, August 25, 1997, Colleague uses the 100 percent refund rate until Tuesday, September, 2, 1997, because between August 25, 1997, and September 2, 1997, there are 7 calendar days, excluding Sundays and holidays.

You can define specific days as holidays solely for the purpose of calculating registration refunds without needing to define them as holidays for scheduling purposes. For example, you may not want to identify an Instructor Retreat day as a campus holiday for scheduling purposes, but you may want to exclude that day from your registration refund calculations.

Similarly, you may need to identify days as holidays but include them in your refund calculations. For example, you may want to identify Spring Break as a holiday for scheduling purposes, but still include those days when it comes to calculating registration refunds. You can also identify specific days as holidays for both scheduling purposes and refund purposes, such as Labor Day.

Holidays are defined in the CALENDAR.DAY.TYPES valcode table in Core. See Getting Started with the Core System for details.

Days Before Start

Use the fields in the Days Before Start group to identify how Colleague should calculate a refund that is processed prior to the start of the billing period. For example, if you refund 100 percent tuition and room and board charges if the student withdraws prior to the start of the semester, enter 1 in the Days Before Start field and enter 100 in the Refund Pct field.

Colleague uses the formula defined in this group for any refunds you process prior to the first day of the billing period. From the first day forward, Colleague uses the refund described in either the Days Used or the Pct Used groups.

The fields in the Days Before Start group are optional. If you leave this group is left empty, Colleague determines the refund amounts from the rates defined in either the Days Used or the Pct Used group.


Ge

Days Used

Use the fields in the Days Used group to define refund percentages based on the number of days in the billing period that were used. Figure 63 illustrates the following tuition refund formula.

Only three lines of the Days used group display at once on the REFF form.

Withdrawal during the first week of the semester100%

Withdrawal during the second week of the semester80%

Withdrawal during the third week of the semester60%

Withdrawal during the fourth week of the semester40%

Withdrawal during the fifth week of the semester20%

Withdrawal after the fifth week of the semester0%

Colleague interprets the values in the Days Used field in Figure 63 as follows:

When Colleague processes a refund, it uses the time periods described by the Days Used fields to determine which refund percent to apply. For example, under the refund formula illustrated in Figure 63, a student who withdraws from classes 21 or more days after the start of the course section would be refunded 60% of their full tuition amount.

Note: Colleague calculates refunds based on the start date of the course section —not the start date of the term.

Note: You cannot use both the Days Used group and the Percent Used group in one refund formula.

Percent Used

The fields in the Percent Used group are similar to the fields in the Days Used group but the refund is calculated by determining the percentage of the total charge that was used

Table 165: Interpreting the Days Used Group on the Refund Formulas (REFF) Form

Line NumberValue in the Days Used Fields Colleague’s Interpretation

1. 7 less than 7 days into the billing period

2. 14 7 to 14 days into the billing period




6. 36 over 36 days into the billing period


Ge

instead of the number of days used. See 483 for an example using the Percent Used group.

Note: You cannot use both the Percent Used group and the Days Used group in one refund formula.

Note: See Count Section Meeting and “Days Excluded” on page 481, and “How Colleague Calculates Days Used for Room and Meal Plan Refunds” on page 489 for additional information about how Colleague calculates days/percentage used.

Refund Portion

The Refund Portion field— used the same in the Days Used group and the Percent Used group—describes whether Colleague bases a refund on the full amount billed or the unused portion of the charge. Use a full amount refund portion when your refund formula is based on the original amount billed. For example, the tuition refund formula illustrated in Figure 63 is based on the full amount of the tuition charges. Individual’s who withdraw from courses and are refunded under this formula receive a percentage (determined by the Refund Pct field) of their full tuition charge.

Tips for Defining Refund Formulas

How Many Unique Refund Formulas Should I Define?

You can have one or more formulas that are used for different types of charges or you can define one refund formula for each type of charge. For example, Ellucian University uses the same refund formula for room charges and for meal plan charges, but uses different refund formulas for registration charges.

Note: For registration charges, you also have the added flexibility of defining different refund formulas for when a course section is dropped and for when a student withdraws from the institution.

What If We Don’t Refund a Charge?

If you do not refund a specific type of charge—for example, course section fees—you can leave the refund formula blank for that type of charge.

How Do I Define a Prorated Refund Formula?

Figure 64 illustrates an example of a refund formula that pro rates charges.


Ge

Figure 64: Example of a Prorated Refund Formula

Colleague interprets this refund formula as “if zero to 100 percent of the item is used, 100 percent of the unused portion is refunded.” For example, if an individual terminates their meal plan after using 35 percent of the plan, Colleague refunds 100 percent of the unused portion—or 65 percent of the original charge.

Understanding Registration Refunds

Registration billing refunds are based on registration refund policies for specific registration charges such as tuition and term rate charges. For example, you can define individual registration refund policies for when a student drops a course, as well for when a student withdraws from a course. Registration refund polices identify the default refund formula used to calculate most refunds of this type. They also allow you to enter individual rules-based refund formulas used to calculate course rate refunds as well term rate refunds.

Associate a registration refund policy with each type of registration charge that you refund. Table 166 lists each type of registration charge and where you enter the appropriate registration refund policy.

Note: f you do not refund one or more of the specific charges listed in Table 166, you do not have to associate a registration refund policy with that charge.


Ge

Table 166: How to Use Registration Refund Policies for Registration Charges

Type of Charge

Where To Identify the Registration Refund Policy

Form Field

Table-based tuition

All tuition generated from the Tuition Charges group on the Tuition Rate Tables (TRTB) form.

Tuition Rate Tables (TRTB) Tuition Drop Registration Refund Policy and Tuition Withdrawal Registration Refund Policy

Note: If you define a different registration refund policy for a specific course section using the Section Billing Information (SECB) form, that policy overrides the registration refund policy you enter for the charge on the TRTB form.

Section-specific fees defined in the Misc. Fee field on the Section Billing Information (SECB) form.

Tuition Rate Tables (TRTB) Section Fee Drop Registration Refund Policy and Section Fee Withdrawal Registration Refund Policy

Charges defined in the Other Charges group on the Section Billing Information (SECB) form, unless overridden for a specific AR code (see below).

Tuition Rate Tables (TRTB) Other Charges Drop Registration Refund Policy and Other Charges Withdrawal Registration Refund Policy

Specific charges defined in the Other Charges group on the Section Billing Information (SECB) form.

Registration Billing Rates

(RGBR)1Drop Registration Refund Policy and Withdrawal Registration Refund Policy


Ge

Understanding Registration Refund Policies

For registration billing, you first need to define the refund formulas used to calculate refunds of individual registration charges generated from tuition rate tables, section-based tuition overrides, and registration term rate tables. You then associate the refund formulas with specific registration refund policies. For each registration refund policy, you must identify a default refund formula for Colleague to use if no rules are defined, or if none of the rules defined evaluate to true. You can enter rules for specific refund formulas in the

Section-based tuition

All tuition generated from the Tuition group on the Section Billing Information (SECB) form.

Section Billing Information

(SECB)1Drop Registration Refund Policy and Withdrawal Registration Refund

Policy1

Specific charges defined in the Other Charges group on the Section Billing Information (SECB) form.



Registration Term Charges

All registration term rate charges generated from a specific registration term rate table.

Registration Term Rate Tables (RTRT)

Default Drop Registration Refund Policy and Default Withdrawal Registration Refund Policy

Specific registration term rate charges defined in the Term Charges group on the Registration Term Rate Tables (RTRT) form.



Specific registration term rate charges defined in the Rule-Based Charges group on the Registration Term Rate Tables (RTRT) form.


Registration Refund Policy (associated with the specific rule-based charge).

1.When all of a course’s sections are billed using section-based tuition, define the drop and withdrawal registration refund policies in the Drop Reg Refund Policy and Wdrw Reg Refund Policy fields on the Course Billing Information (CRSB) form. Colleague defaults these registration refund policies to each of the course’s sections where you can modify them on the Section Billing (SECB) form and the Registration Billing Rates (RGBR) form as appropriate.

Table 166: How to Use Registration Refund Policies for Registration Charges

Type of Charge

Where To Identify the Registration Refund Policy

Form Field


Ge

Course Rate Rules and Term Rate Rules groups. If one of the rules evaluates to true, the corresponding refund formula is used.

Components of a Registration Refund Policy

Use the Reg Refund Policy (RGRP) form to define each of your registration refund policies.

Figure 65: Registration Refund Policy for Course-Related Charges

The following fields and groups of fields from the Reg Refund Policy (RGRP) form are described in this section:

• Default Refund Formula

• Course Rate Rules & Refund Formulas

• Term Rate Rule & Refund Formula

Default Refund Formula

Use the default refund formula field to identify the refund formula used to calculate most common refunds of this type. This is the refund formula used when there are no rules-based formulas entered, or when the rules entered do not evaluate to true.

Course Rate Rule & Refund Formula

Use the Course Rate Rule & Refund Formula group to define the refund formula(s) you want to use for course-based charges such as tuition, section miscellaneous fees, and


Ge

section other charges. You enter a rule that Colleague will use to determine when the associated refund formula applies. For example, you can create rules and corresponding refund formulas to determine how refunds are calculated for full-time tuition, overload tuition, and part-time tuition as shown in Figure 65.

Term Rate Rule & Refund Formula

Use the Term Rate Rule & Refund Formula group to define the refund formula(s) you want to use for term-based charges such as activity fees and health service fees. You enter a rule that Colleague will use to determine when the associated refund formula applies. For example, you can create rules and corresponding refund formulas to determine how refunds are calculated for activities or healthcare related fees (Figure 66).

Figure 66: Registration Refund Policy for Term-Related Charges

Understanding Room Charge and Meal Plan Charge Refunds

Note: This section describes how to define refund formulas for charges generated from the Residence Life module. If you do not use Colleague’s Residence Life module you do not need to define these formulas.

Room and meal plan refund formulas are part of the billing parameters for each type of charge. For both room and meal plans you will define, at a minimum, a default refund formula. You can also define additional refund formulas that are associated with rules. Colleague determines which refund formula to use by first evaluating each of the rules. If


Ge

one of the rules is true for the student Colleague uses the refund formula associated with that rule. If none of the rules are true for that student, Colleague uses the default refund formula.

How Colleague Calculates Days Used for Room and Meal Plan Refunds

For room charges, Colleague determines the number of days used based on the start date of the assignment and the termination date of the assignment. For example, if a room assignment was made for 09/01/97 through 12/20/97 and that assignment was terminated on 10/01/97, Colleague will calculate the amount of the refund based on 30 days of usage.

For meal plan charges, Colleague uses the number of units of the meal plan that the individual used in lieu of the number of days used. Since meal plans are based on the number of meals (units) purchased, the number of days is not meaningful. For example, three meals could have been used on one day or over a period of days. Therefore, when a meal plan is terminated, the individual’s usage of the meal plan—either in terms of the number of units or the percentage used—is recorded on the Meal Plan Assignment (MPAS) form. When the refund formula is based on the number of days used, Colleague uses the number of units used from the MPAS form to calculate the number of days used as follows:

For example, if there were 50 meals in a meal plan that lasted 100 days and individual only used 10 meals, Colleague would calculate the number of days used as:

Using Rules with Room & Meal Plan Refund Formulas

You can define one refund formula for cancelling either room or meal plan assignments and use rules to indicate when Colleague applies special circumstance formulas, such as a room termination due to financial hardship.

For example, Ellucian University refunds all students their room charges based on one formula unless the student terminates a room assignment because of specific family hardships. To accommodate this scenario Ellucian University

1. Defined the hrshp room assignment status code to indicate termination due to hardship. This status code has a “1” special processing code, indicating a terminated room assignment.

2. Defined a standard refund formula and a hardship refund formula, using the Refund Formula (REFF) form.

Days Used Meals UsedTotal Meals---------------------------- Days in the Period=

1050------x100 20days=


Ge

3. Defined a rule that checks a student’s room assignment record for the “hrshp” status code.

4. Entered the standard refund formula in the Default Refund Formula field, the rule defined in Step 3 in the Refund Rule field, and the hardship refund formula in the Refund Formula field next to the rule on the Room Billing Parameters (RMBP) form.

Note: You can override the refund formula associated with a student’s room or meal plan charges by entering a different refund formula on the Room Billing Override (RMAB) form or the Meal Plan Billing Override (MPLB) form, respectively.

Procedures for Defining Refunds

This section provides procedures for defining:

• Registration refund policies & formulas

• Room charge refund formulas

• Meal plan charge refund formulas

Procedure for Defining Registration Refund Policies & Formulas

Complete the following steps to define registration refund policies and formulas for each registration charge:

1. Read Using Accounts Receivable/Cash Receipts for an understanding of how Colleague generates refunds when a student drops course sections or withdraws from the institution.

2. Determine how many different refund formulas you will need to cover all registration charges.

Table 166 on page 485 lists each registration charge for which you can define a refund.

Note: For each registration charge, you can define a separate drop refund formula and withdrawal refund formula, use the same refund formula for both drop and withdrawal situations, or use no refund formula for either situation.

3. Define each refund formula.

Use the worksheet “Refund Formulas” on page 605 to write out the formulas before entering them.


Ge

If you are also defining refund formulas for room charges and meal plan charges, you might want to complete this step for all refunds, to ensure that wherever there is duplication you only define one formula.

4. Use the Refund Formula (REFF) form to enter each refund formula.

5. For each registration charge, determine a registration refund policy which identifies the default refund formula to use for this type of charge, and any rules-based refund formulas for course rate or term rate charges.

Use the “Registration Refund Policies” on page 606 to identify which registration refund formulas to use with each registration refund policy.

Complete this step for all registration refunds to ensure that wherever there is duplication, you only define one registration refund policy.

6. Use the Reg Refund Policy (RGRP) form to enter each registration refund policy.

7. Assign each refund registration refund policy to the appropriate registration charge.

Use the worksheets “Registration Charges & Refund Policies” on page 607 and “Course & Course Section Registration Refund Policies” on page 608 as a guide.

Procedure for Defining Room Charge Refund Formulas

Complete the following steps to define refund formulas for room charges:

1. Read Using Accounts Receivable/Cash Receipts to understand how Colleague calculates refunds for room charges.

2. Determine how many different refund formulas you will need to cover room charges.


Use the worksheet “Refund Formulas” on page 605 to write out the formulas before entering them.

If you are also defining refund formulas for registration charges and meal plan charges, you might want to complete this step for all refunds, to ensure that wherever there is duplication you only define one formula.

4. Define any rules you will need for assigning room assignment refund formulas.

See “Using Rules with Room & Meal Plan Refund Formulas” on page 489. Use the worksheets “Rule Construction—English Statements” on page 320 and “Rule Construction Translation” on page 322 to write out your refund rules before entering them on the RLDE form.

See “Understanding the Rules Processor” on page 309.


6. Use the Rule Definition (RLDE) form to enter each refund rule.

7. Access the Room Billing Parameters (RMBP) form.

8. Enter the default refund formula in the Default Refund Formula field.


Ge

9. If you use additional refund formulas based on rules, enter the rules and the associated refund formula in the Refund Rules field.

You can access the Rules Definition (RLDE) form from the Refund Rule field if you have not already entered the necessary rules.

Procedure for Defining Meal Plan Charge Refund Formulas

Complete the following steps to define refund formulas for meal plan charges:

1. Read Using Accounts Receivable/Cash Receipts to understand how Colleague calculates refunds for room charges.

2. Determine how many different refund formulas you will need to cover meal plan charges.


Use the worksheet “Refund Formulas” on page 605.

If you are also defining refund formulas for registration charges and room charges, you might want to complete this step for all refunds, to ensure that wherever there is duplication you only define one formula.

4. Define any rules you will need for assigning meal plan refund formulas.

See “Using Rules with Room & Meal Plan Refund Formulas” on page 489. Use “Rule Construction—English Statements” on page 320 and “Rule Construction Translation” on page 322 to write out your refund rules before entering them on the RLDE form.

See “Understanding the Rules Processor” on page 309.


6. Use the Rule Definition (RLDE) form to enter each refund rule.

7. Access the Meal Plan Billing Parameters (MLBP) form.

8. Enter the default refund formula in the Default Refund Formula field.

9. If you use additional refund formulas used based on rules, enter the rules and the associated refund formula in the Refund Rules field.

You can access the Rules Definition (RLDE) form from the Refund Rule field if you have not already entered the necessary rules.


Ge

Setting Up Registration Billing

In This Chapter

Registration billing is an aggregation of charges and credits incurred as a result of the registration process. This chapter describes these charges and credits—broadly categorized as tuition charges and other registration charges. You define tuition charges, which represent the cost of course instruction, as a tuition rate table (table-based tuition) or as charges unique to an individual course section (section-based tuition). See “Defining Table-Based Tuition” on page 504 and “Defining Section-Based Tuition” on page 512 for details on defining tuition charges.

Other registration charges encompass all other charges and credits that a student incurs from the registration process. Table 167 lists these charges, and the sections within this chapter that describe each.

Colleague assesses table-based tuition charges and all other registration charges based on information found in one of many registration rate tables. Each registration rate table represents a unique combination of billing attributes and charges. The key to defining registration rate tables is establishing a general set of billing characteristics that describe your institution’s billing scenarios. “Defining Student Billing Characteristics” on page 495 explains these student billing characteristics and how to define them for your institution.

Table 167: Information about Other Registration Charges

For Information About … See …

Charges such as health and activity fees that you assess each registration term (referred to as registration term rates)

“Defining Registration Term Rates” on page 518.

Charges or fees associated with a specific course section

“Course Section Billing Information for Table-Based Tuition Billing” on page 504 and “Course Section Billing Information for Section-Based Tuition Billing” on page 513.

Fees for adding or dropping a course section during add/drop registration

“Defining Add/Drop/Withdrawal Policies” on page 520.

Refund policies and formulas “Understanding Registration Refunds” on page 484.

Tuition discounts “Defining Tuition Discounts” on page 528.

Tuition waivers “Defining Tuition Waiver Policies” on page 522.

493tting Started with Colleague Student | Setting Up Registration Billing

Ge

Tips for Setting Up Registration Billing

This chapter includes various tips for setting up the different components of registration billing. Many of these tips describe specific setup and processing options that you might want to consider before you begin setting up registration billing. Look for these items in sections labeled “Tips for …”

Before You Begin

Before you begin the setup procedures described in this chapter you should complete the following:

AR codes are an integral part of registration billing. Before you begin setting up the different components of registration billing described in this chapter, you should define the following AR codes:

Table 168: Items Needed Before Setting Up Registration Billing

Item Reference

Become familiar with the basic terminology used to describe billing with Colleague’s Accounts Receivable module


Understand how Colleague generates registration charges


Understand Colleague’s rule processor and where it can be used for registration charges


Define the necessary AR codes Table 169 below

Define the necessary refund formulas and policies for registration charges

“Defining Registration Refunds” on page 478

Table 169: AR Codes Needed to Set Up Registration Billing

AR Code For … Use on … Reference

Tuition forfeitures Tuition Rate Tables (TRTB)

“Components of a Tuition Rate Table” on page 507

Course section fees

Course section fees forfeiture

Tuition charges

Tuition discounts Tuition Discounts (DISC) “Components of a Tuition Discount” on page 528


Ge

Note: You can define unique AR codes for each application listed above or you can define one AR code for use in multiple applications. For example, you may have different AR codes for full-time tuition, part-time tuition, and overtime tuition, or you may have one code for all types of tuition.

See “AR Codes” on page 149 for information about defining AR codes.

Defining Student Billing Characteristics

The financial information in your school’s course catalog identifies one or more student populations for whom you maintain specific billing information. For example, Ellucian University (EU) bills tuition and other related charges differently if the student is an in-state or an out-of-state students; graduate or undergraduate; athlete or employee. Thus, EU bases its general billing characteristics on a student’s residency, academic level, and

student type. Table 170 illustrates some of EU’s billing scenarios.1

The items listed in the left-hand column of Table 170 represent student billing characteristics. Student billing characteristics describe the way that you differentiate

AR add charges AR Add/Drop/Withdrawal Policies (ADWP)

“Components of an AR Add/Drop/Withdrawal Policy” on page 521AR drop charges

AR withdrawal charges

Registration term charges Registration Term Rate Tables (RTRT)

“Components of a Registration Term Rate Table” on page 518

Table 170: Example Registration Rate Tables

Student Billing Characteristics


UGIF UGOF ATHL1

1.You may want to use waivers for special student groups such as athletes and employees. See “When to Use Student Type as a Billing Field” on page 501 for information about deciding how to use student type as a billing characteristic.

EMP1 GRI GRO

Residency in-state out-of-state

in-state in-state in-state out-of-state

Academic Level UG UG UG UG GR GR

Student Type n/a n/a ATH EMP n/a n/a

Table 169: AR Codes Needed to Set Up Registration Billing (continued)

AR Code For … Use on … Reference


Ge

groups of students for registration billing and form the basis for building all registration rate tables. A registration rate table represents each unique combination of billing characteristics that describe how you bill specific student populations for tuition and related charges (see “Defining a Registration Rate Table” on page 515).

You define student billing characteristics as a set of registration rate billing fields from the Colleague database. Once you identify the fields that represent your billing characteristics, you can build multiple registration rate tables that distinguished by the unique set of values associated with each billing field. For example, Ellucian University bases its billing characteristics on residency, academic level, and student type. The business office used the SCS.RESIDENCY.STATUS, STC.ACAD.LEVEL, and SCS.CURRENT.STU.TYPE fields to identify these characteristics and create a group of registration rate fields that includes these fields.

1. “Defining Table-Based Tuition” on page 504 describes Ellucian University’s complete billing schedule.


Ge

Figure 67: Student Billing Characteristics and Registration Rate Tables

When the business office defined EU’s billing characteristics, they realized that the student type designation is applicable only to some of the university’s student populations. For example, you may bill all in-state undergraduates at the same rate, unless they are an athlete or an employee. Other student type characteristics, such as first-time freshmen and veterans, do not have unique billing rates. Because SCS.CURRENT.STU.TYPE is not


Ge

a required component of all registration rate tables, the business office entered “No” in the Required field for SCS.CURRENT.STU.TYPE. The business office then built registration rate tables that did not include the SCS.CURRENT.STU.TYPE field (such as the UGIF registration rate table illustrated in Figure 67).

Components of Student Billing Characteristics

Use the Registration Rate Billing Fields (RRBF) form to define the basic student characteristics that all your registration rate tables use.

Figure 68: Example Registration Rate Billing Fields

Effective Date

Because you can define more than one set of billing fields, each group of fields is associated with an effective date. Colleague uses the effective date to determine which set of characteristics to use for a particular registration charge. When Colleague calculates a registration charge, it compares the registration billing period start date with the effective dates for each group of billing fields. Colleague uses the group of billing fields whose effective date is less than or equal to the billing period start date for each course


Ge

section being billed. For example, Ellucian University has the following groups of billing fields:

To calculate a registration charge with a billing start date of 09/1/97, Colleague would use the characteristics defined by billing fields #3 (09/1/97 is after 07/01/82 but before 07/01/98).

Note: You only need to define a new set of billing fields, with a new effective date, when you begin to bill based on a different set of billing characteristics. Each time individual rates change, define a new tuition or registration term rate table. Each time the combination of values describing a distinct group of students changes, is added, or is removed, add or modify a specific registration rate table.

Field Name

Use the billing fields group to define each field you use as a characteristic for grouping students. You identify the fields that define your characteristics by entering the data element name in the Field Name field. The data element that you choose must be accessible from the STUDENT.COURSE.SEC file.

Required

Use the Required flag to identify whether a field is required on the individual registration rate tables. If you enter “Y,” then each registration rate table that you define using this set of billing fields must include a value for this field. For example, the rate tables illustrated in Figure 68 both include the SCS.CURRENT.STU.TYPE field. However, this field was defined on the RRBF form with the required flag set to “No,” therefore, this field is not required on the registration rate tables. Both the STU.RESIDENCY and the STU.ACAD.LEVEL fields were flagged on the RRBF form as required, therefore, these fields contain values on each of the registration rate tables.

Tips for Defining Student Billing Characteristics

This section provides tips for:

• Determining the appropriate billing fields

Table 171: Example Billing Fields

Registration Rate Fields ID Effective Date

1 07/01/60

2 07/01/75

3 07/01/82

4 07/01/98


Ge

• When to use student type as a billing characteristic

• Using unique billing tables and policies

Determining the Appropriate Billing Fields

The key to building appropriate registration rate tables is determining the correct database elements to use as billing fields when you define your student billing characteristics. When you begin building your tables, express in “English” terms your billing characteristics. However, there may be a number of ways to extract this information about an individual.

Colleague bills registration charges from the information found in records in the STUDENT.COURSE.SEC file. Colleague creates one record for each course section that the student registers for at the time the registration information is recorded. For example, when a student registers for five courses, Colleague creates five records in the STUDENT.COURSE.SEC file for that student. Each record contains information about the course section assignment, including information such as the billing credits, discount overrides, and whether the billing information has been posted to accounts receivable.

The fields that you select as your billing fields must either reside in the STUDENT.COURSE.SEC file or Colleague must be able to find the information through the links from the STUDENT.COURSE.SEC file to other Colleague files. For example, because the student’s ID is stored in the STUDENT.COURSE.SEC record, Colleague can find any information from files that keyed by the student’s ID, such as the STUDENTS file.

Common student billing characteristics include residency and academic level. Colleague stores this information about a student in the STUDENTS file. However, both the residency and academic level are multi-valued fields, which means Colleague stores a history of all the changes in a student’s residency and academic level. If you simply select the academic level or residency fields from the STUDENTS file, Colleague may not find the correct value. If you want to use the student’s academic level and residency status at the time they registered for each course section, then you should choose as your billing fields the virtual fields in the STUDENT.COURSE.SEC file that provide this information (Table 172).

Table 172 lists some of the more common billing characteristics and the corresponding fields that we suggest you use as billing fields. This list includes academic level and residency, as well as student type. Refer to, When to Use Student Type as a Billing Field for more information about using student type as a billing field.

Table 172: Example Billing Characteristics

Characteristic Field Description

Academic level STC.ACAD.LEVEL STC.ACAD.LEVEL is a virtual field that returns the student’s academic level associated with each course section the student has registered for. This virtual field is in the STUDENT.COURSE.SEC file.


Ge

When to Use Student Type as a Billing Field

If you use student type to determine if an individual is billed at a different rate from other students, then use student type as a billing field. However, if you use student type to determine whether a student receives a waiver, associated a waiver policy with the registration rate table. See Defining Tuition Waiver Policies for information about defining waiver policies.

The difference between using separate registration rate tables and waiver policies is subtle and best considered in light of how you need to book the revenue associated with the tuition charges to the general ledger. If your comptroller prefers to see the total tuition charges incurred by all students, less any waivers applied, associate waiver policies with a registration rate table to reduce the tuition charge. If your comptroller does not need to see waivers separate from tuition, then use separate registration rate tables. Remember also that multiple registration rate tables may share the same registration term rate tables and ar add/drop/withdrawal policies. So having numerous registration rate tables does not necessarily mean extra set up work (see “Do I Need Different Billing Tables and Policies?” on page 517).

Understanding a Course Section’s Billing Information

Note: When you set up billing information for course sections, you initially define this information for each course. Each course section inherits the billing information defined for the course when you build the course section. You can then modify any of this billing information as necessary for each individual course section. Because Colleague uses the billing information defined for a course section (specifically, the billing

Residency SCS.RESIDENCY.STATUS SCS.RESIDENCY.STATUS is a virtual field that returns the student’s current residency status at the time she registered for each course section. This virtual field is in the STUDENT.COURSE.SEC file.

Student type SCS.CURRENT.STU.TYPE SCS.CURRENT.STU.TYPE is a virtual field that returns the student’s student type status at the time he started each course section. This virtual field is in the STUDENT.COURSE.SEC file.

Table 172: Example Billing Characteristics (continued)

Characteristic Field Description


Ge

information for a student’s course section record), the discussion of registration billing and billing set up refers to course sections.

Each course section is associated with a set of billing information. At a minimum, this billing information tells Colleague where to get the tuition information for billing the course section. You can define a course section’s tuition information on a tuition rate table or as part of the course section itself.

The other billing information provided with each course section describes the course section’s:

• Drop registration refund policy

• Withdrawal registration refund policy

• Discounts

• Other charges associated with the course section

Components of Course Section Billing Information

Use the Course Billing Information (CRSB) form to define the billing information for a course. If you need to modify the billing information for a particular course section, use the Section Billing Information (SECB) form. Figure 69 illustrates both the course billing information for Ellucian University’s MATH*113 course and the course section billing information for MATH*113*01. Because the MATH*113*01 section is billed exactly the same as defined for the course, the Section Billing Information (SECB) form displays the same information as the Course Billing Information (CRSB) form.


Ge

Figure 69: Example of a Billing Information for a Course and Course Section

As mentioned above, each course section’s billing information contains, at a minimum, the information Colleague uses to determine whether the tuition for a course section is calculated from a tuition rate table or from the course section’s billing information. Colleague makes this determination from the code in the Billing Method field. The two billing methods are “T,” indicating that the course section uses a tuition rate table and “S,” indicating that the course section uses the tuition information associated with the course section. Colleague uses the other fields on both the Course Billing Information (CRSB) form and the Section Billing Information (SECB) form differently depending on the billing


Ge

method code that is used; therefore, these fields are described in the discussion of table-based tuition and course section-based tuition.

Defining Table-Based Tuition

Tuition based on the characteristics of the student is table-based tuition. Section-based tuition is when the tuition for a specific course section is the same regardless of the characteristics of the students who register for the course section (see “Defining Section-Based Tuition” on page 512). To set up table-based tuition, you must:

• Complete the course section billing information for each course section.

• Define your tuition rate tables.

Course Section Billing Information for Table-Based Tuition Billing

“Understanding a Course Section’s Billing Information” on page 501 explains that each course section must have billing information defined for it. You define billing information for the course and each section of that course inherits the information. To have Colleague calculate the tuition charges for any course section from a tuition rate table, you must enter T in the Billing Method field of the Course Billing Information (CRSB) form and it defaults into any sections you create from the course. Or you can enter it directly on the Section Billing Information (SECB) form (Figure 70).

Table 173: More information about course section billing


Table-based tuition “Defining Table-Based Tuition” on page 504

Course section-based tuition “Defining Section-Based Tuition” on page 512


Ge

Figure 70: Example of Section Billing Information for Table-based Billing

Important Components of Course Section Billing Information for Table-based Billing

When you define a course section with a “T” billing method, you can use the following fields on either the Course Billing Information (CRSB) form or the Section Billing Information (SECB) form:

• Billing Method

• Billing Period Type

• Billing Credits

• Schedule Type

• Misc Fees

• Comments

• the fields in the Other Charges group

The important fields for defining table-based billing are described below. Refer to online help for information about the other fields.

Billing Method. You must enter “T” in the Billing Method field if you want Colleague to use a tuition rate table to calculate the tuition charge for a course section.

Billing Period Type. Colleague uses the billing period type—either “T,” for term or “R,” for reporting term—when calculating registration charges to determine how the course will be grouped for billing. For example, if a student has ten unbilled course sections, Colleague


Ge

determines the grouping based on the billing period type. Colleague determines the grouping from the billing period type as follows:

See Using Accounts Receivable/Cash Receipts for additional information about how Colleague uses the billing period type.

Schedule Type. Schedule type codes describe when a course section typically meets. If this information has bearing on how the course section is billed, you can define a different set of tuition rates based on schedule type. For example, if an evening section is billed differently than a daytime section, you would enter the schedule type code for evening courses and then, as part of the tuition rate table, define the appropriate billing information for the evening courses. See “Defining Tuition Charges Based on Schedule Types” on page 511 for details.

Other Charges. Use the Other Charges group to define additional registration charges that are associated with a particular course section. For example, you would define lab fees or special equipment fees as an other charge associated with a course section. Each entry in this group represents a single charge. You can define multiple charges and each charge can use either the same AR code or a different AR code.

See Using Accounts Receivable/Cash Receipts for a complete description of how Colleague interprets the fields in this group. Refer to online help for additional information about individual fields in this group.

Understanding Tuition Rate Tables

A tuition rate table describes how Colleague calculates tuition charges and identifies a number of different registration refund policies Colleague uses when a student drops or withdraws from course sections or withdraws from your institution. Each tuition rate table represents a unique tuition schedule.

Table 174: Billing Period Types

If the Billing Period Type is … Then the Grouping is…

Term with other courses for the same term

Reporting term with other course for the same reporting term.


Ge

For example, Ellucian University’s tuition rates for the 1997/98 academic year are illustrated in Table 175.

To implement its tuition rate structure (Table 175), EU's business office defined the following registration rate tables, each with a unique tuition rate table:

• Undergraduate, in-state

• Undergraduate, out-of-state

• Undergraduate, in-state, athlete

• Undergraduate, out-of-state, athlete

• Undergraduate, employee

• Graduate, in-state

• Graduate, out-of-state

• Graduate, employee

Notice that, for the purpose of establishing the registration rate tables, EU did not include academic load (full-time or part-time) as a billing characteristic (EU’s business office did not build a registration rate table for full-time, undergraduate, in-state and a separate table for part-time, undergraduate, in-state). Instead, the business office made the distinction between full-time and part-time in each tuition rate table. Figure 71 illustrates how academic load is handled in the in-state, undergraduate (UGIF) tuition rate table.

Components of a Tuition Rate Table

Use the Tuition Rate Tables (TRTB) form to define each tuition rate table.

Table 175: Ellucian University’s Tuition Rate Table

In-StateOut-of-State

Athletes1

1.You may want to use waivers for special student groups such as athletes and employees. See “When to Use Student Type as a Billing Field” on page 501 for information about deciding how to use student type as a billing characteristic.

Employees1In-StateOut-of-State

Full Time Undergraduate

$2,775.00 $5,550.00 $2,600.00 $5,200.00 $2,775.00

Part Time or Overload Undergraduate, per credit

$187.00 $374.00 $187.00 $374.00 $140.00

Graduate, per credit

$195.50 $391.00 n/a n/a $155.50


Ge

Figure 71: Example of a Tuition Rate Table

The TRTB form has two main sections: Policies & Defaults and Tuition Charges. Refer to online help for information about the Policies and Defaults section. The Tuition Charges group is described below.

The Tuition Charges Group

Each entry in the Tuition Charges group represents a potential charge to a student. The AR codes listed in the Tuition Charges group illustrated in Figure 71 represent Ellucian University’s charges for overtime tuition (TUIOV), part-time tuition (TUIPT) and full-time tuition (TUIFT) and the associated amounts and conditions under which Colleague assesses these charges. Colleague uses the information from the Calc, Sec/Cred, Min Cred, Max Cred and Rule fields to determine if a particular charge (as represented by the AR code) is assessed. For example, EU’s overtime tuition charge of $187.00 is assessed when a student, who is billed by this tuition rate table, is registered for a minimum of 18 credits. Using Accounts Receivable/Cash Receipts explains in detail how Colleague interprets the entries in this group of fields. Read this chapter and understand how these fields work together before you define your tuition rate tables.

The following fields from the Tuition Charges group of the Tuition Rate Tables (TRTB) form are described below.

• Calc

• Sec/Cred

• Min Cred and Max Cred

• Rule

Tuition Charges

Policies & Defaults


Ge

Refer to online help for information about all the fields in this group. Refer to Using Accounts Receivable/Cash Receipts for an explanation of how all the fields in the Tuition Charges group work together.

Calc. Use the Calc field to determine how the tuition amount in a specific line of the Tuition Charges group is computed. The options for this field are

• “A” for all credits or courses. Use the “A” calculation type if Colleague should multiply the amount from the Amount field by the total credits as determined by the Sec/Cred field.

• “F” for fixed amount. Use the “F” calculation type if Colleague should compute the tuition for this item as a fixed amount (the value in the Amount field).

• “E” for excess amount. Use the “E” calculation type if Colleague should compute the tuition for this item as a per credit or per course amount in excess of the specified minimum number of credits.

Sec/Cred. Use the Sec/Cred field to identify if Colleague should use the total number of registered courses or the total number of registered credits to calculate the amount in a specific line of the Tuition Charges group. For example, when Colleague calculates tuition from the tuition rate table illustrated in Figure 71, it first calculates the number of credits that the student is registered for and compares that number to the minimum and maximum credit requirements identified in the Min Cred and Max Cred fields, respectively. If you use the number of courses registered for, Colleague counts the number of courses and then compares that value to the minimum and maximum credit requirements identified in the Min Cred and Max Cred fields, respectively.

Colleague also uses the Sec/Cred setting to determine how to allocate the total tuition charge to each course section that was included in the calculation for that registration charge. For example, in Using Accounts Receivable/Cash Receipts, Jonathan Garfield’s registration charges for the Fall 1997 semester at Ellucian University were described. Jonathan had registered for the following course sections:

For the purpose of calculating his table-based tuition charge, Jonathan is registered for 13 credits. Colleague calculated Jonathan’s table-based tuition charge for the four course sections listed above as $3,525.00.

Min Cred and Max Cred. Use the Min Cred and Max Cred fields to identify the total number of credits that a student must be registered for before Colleague calculates the

Table 176: Example Sections and Credits

Course Section Number of Credits

MATH*113*01 4

CIS*142*03 3

ENG*101*02 3

FRS*101*01 n/a1

1.Colleague billed this course section from the section-based tuition for the course section.

ENG*239*02 3


Ge

charges for a specific item in the Tuition Charges group. Colleague interprets these fields as

Total Credits > Min Credit and Total Credits < = Max Credit

For example, if you enter 12 in the Min Cred field and leave the Max Cred field blank, Colleague determines whether the total credits are greater than 12.

Rule. Use a tuition charge rule to have Colleague evaluate a group of course sections and determine whether the associated charge is assessed. When you use tuition charge rule, Colleague evaluates that rule before looking at the other criteria defined in the Tuition Charges group to determine if the course sections in the group are eligible for that specific charge.

For example, the TUIOV AR code shown in the tuition rate table illustrated in Figure 71 is an overload charge assessed when a student is registered for over 18 credits. However, Ellucian University only counts course sections that a student is taking for credit when computing the number of credit hours. Therefore, the business office included the NO.AUDIT rule to determine if a student is auditing a course section. This rule is illustrated in Figure 72.

Figure 72: Example of a Tuition Charges Rule

If a student, who is being billed by the UGI97 tuition rate table, is registered for six course sections, one of which she is auditing, Colleague does not use the audited course section when it calculates the number of credit hours that she is registered for.

Tips for Defining Tuition Rate Tables

This section provides tips for:

• Defining tuition charges based on schedule type


Ge

• Naming tuition rate tables

• Using rules to identify which tuition charges to assess

Defining Tuition Charges Based on Schedule Types

If you need to associate any of the charges that you define in the Tuition Charges group with a different AR code or charge a different rate because of the schedule type associated with the course section, you can define that information on the Registration Billing Rates (RGBR) form. The RGBR form provides the same information that you enter on one line of the Tuition Charges group on the TRTB form, but also lets you define additional billing information based on schedule type.

For example, the billing rate table illustrated in Figure 73 may apply to the courses that a student registers for based on the student's characteristics. However, one of the course sections may be an evening class, for which you want to charge a different rate. Instead of defining a different rate table to cover those rates, use the Registration Billing Rates (RGBR) form.

Figure 73: Registration Billing Rate Table Defined by Schedule Type

Naming Tuition Rate Tables

When you create a tuition rate table, give that table a unique, ten character name. Colleague allows you to use any naming convention you want to define these tables, but you should consider using meaningful names for each tuition rate table. For example, you might want to use an abbreviated description of the student characteristics for whom the table is used. If you have one set of tuition rate for in-state undergraduates and another for out-of-state undergraduates you might want to abbreviate these characteristics, using your residency code for in-state or out-of-state, along with your academic level code undergraduate. Because the tuition rate table may change each year to reflect new tuition


Ge

rates, you might want to include the year for which a rate table applies in the table name. For example, INSTUG97 and OUTSTUG97, for the in-state undergraduate tuitions for 1997/98 and the out-of-state undergraduates for 1997/98, respectively.

Using Rules with Tuition Charges

If a charge listed in the Tuition Charges group is not calculated for all course sections that a student may be registered for, then use a rule to select the specific course sections (see “The Tuition Charges Group” on page 508). When you define these rules

• Use the worksheet “Rule Construction—English Statements” on page 320 to map out the rules in English statements.

• Use the worksheet “Rule Construction Translation” on page 322 to map out the rules in the rule processor’s syntax (see “Understanding the Rules Processor” on page 309).

Note: Rules defined for a tuition rate table must use the STUDENT.COURSE.SEC file as the primary view (see “Understanding the Rules Processor” on page 309 for more information about primary file views).

Defining Section-Based Tuition

If all students who register for a particular course section should be billed at the same tuition rate, then define section-based tuition for that course section.

Note: Even if you define the tuition charges for a specific course section, Colleague includes that course section when calculating the other registration charges associated with the registration rate table. Refer to Using Accounts Receivable/Cash Receipts for a detailed explanation of how Colleague calculates other registration charges. See “Defining a Registration Rate Table” on page 515 for details about other registration charges.

When Colleague calculates a student’s tuition, it separates all unbilled course sections by the billing period type. Colleague groups together all course sections with a billing method of “T” and calculates the tuition using the appropriate tuition rate table for that student. Colleague calculates the tuition for all course sections with a billing method of “S” independently of any other unbilled course sections. For example, if a student registered for five classes, three of which have a “T” billing method and the other two have an “S” billing method, Colleague would first group together the course sections with a “T” billing method and use the appropriate tuition rate table to calculate the tuition for those course sections. Then Colleague would calculate, as two separate tuition calculations, the tuition for each course section that has an “S” billing method. See Using Accounts Receivable/Cash Receipts for additional details about this process.


Ge

Course Section Billing Information for Section-Based Tuition Billing

To have Colleague calculate the tuition charges for any course section from the billing information associated with the course section, you must enter S in the Billing Method field of the either the Course Billing Information (CRSB) form or the Section Billing Information (SECB) form.

Note: If you want all sections associated with a particular course billed by the section, then define the billing information on the Course Billing Information (CRSB) form. If you want only certain sections associated with a particular course billed by the section, then define the billing information on the Section Billing Information (SECB) form. See “Deciding Whether to Define Billing Information at the Course or the Course Section Level” on page 515 for defining section-based tuition.

Figure 74 illustrates the billing information of Ellucian University’s freshman seminar. Because each freshman who takes this course is charged the same tuition rate, regardless of any other billing characteristic, the business office used section billing information to define the tuition for this course section.

Figure 74: Example of Section Billing Information for Section-based Billing

Important Components of Section-based Billing

When you define a course section with a “S” billing method, you can use the following fields on either the Course Billing Information (CRSB) form or the Section Billing Information (SECB) form:

• Billing Method


Ge

• Billing Period Type

• Billing Credits

• Schedule Type

• Drop Reg Refund Policy

• Wdrw Reg Refund Policy

• the fields in the Discount group

• Disc Max Pct

• Disc Max Amt

• Comments

• The fields in the Tuition group

• The fields in the Other Charges group

The important fields for defining section-based billing are described below. Refer to online help for information about the other fields.

Billing Method. You must enter “S” in the Billing Method field if you want Colleague to use the billing information on this form to calculate the tuition charge for a course section.

Registration Refund Policies. Use these fields to identify the registration refund policy to use when a student drops or withdraws from a section.

For example, you can specify that 80% tuition will be refunded after a section has started. If a course uses table-based billing, the registration refund policy you enter here will override any registration refund policy specified by the registration rate table. If a course uses section-based billing, the registration refund policy you enter here will be used as the default when refunding tuition and other charges, but you can override each individual charge. If you do not enter a policy for a course that has section-based billing, no refund will be given.

Note: If you want all sections associated with a particular course billed by the section, then define the billing information on the Course Billing Information (CRSB) form. If you want only certain sections associated with a particular course billed by the section, then define the billing information on the Section Billing Information (SECB) form. See “Deciding Whether to Define Billing Information at the Course or the Course Section Level” on page 515 for defining section-based tuition.

Discount Code. See “Defining Tuition Discounts” on page 528 for more information.

Disc Max Pct and Disc Max Amt. Use these fields to limit the total amount of discounts that a student may receive for this course section. These fields are used to set a cap on the total of multiple discounts for which a student may be eligible. If you use tuition discounts and do not set limits to the maximum amount of a discount that a student may receive, then Colleague may discount all—or more—of a student’s tuition.


Ge

Tuition Group. Define the amount of tuition charged for a course section in the Tuition group. Colleague uses these fields to calculate the amount of tuition charged to each student who registers for the course section. Refer to online help and the following sections of this manual for complete information about these fields:

Deciding Whether to Define Billing Information at the Course or the Course Section Level

If the tuition for all sections of a particular course is calculated as section-based billing, then you should define this billing information on the Course Billing Information (CRSB) form and let Colleague copy that information to each section built from that course. If you need to, you can then modify any of the default billing information for one or more sections.

For example, if the tuition for only one section of a particular course uses section-based billing, then define the course with a billing method of “T” and change the billing method to “S” for the section that use the section-based billing. Then define the billing information for that course section only.

If the sections of a particular course use a mixture of table-based and section-based tuition, decide whether you want the section billing information with the course and then remove it for those sections that use a table, or if you want to define the course for table-based tuition and modify the sections that use section-based tuition. In general, it is best to define the billing information for the course (on the CRSB form) to reflect the billing scenario for the majority of that course’s sections.

Defining a Registration Rate Table

The registration rate table is the cornerstone to registration billing. Each registration rate table defines, for a specific group of students, how Colleague calculates tuition, other

Table 177: Locating Information about the Tuition Group on the CESB Form

For Information About… See …

The important fields in this group “The Tuition Charges Group” on page 508

How Colleague uses these fields to calculate the tuition for a course section



Ge

BP

registration charges, add/drop/withdrawal fees, and waivers. Before you define your registration rate tables you should read the following sections of this manual:

Components of a Registration Rate Table

Use the Registration Rate Tables (RGRT) form to define each registration rate table that you need to meet each of your unique billing situations.

Figure 75: Example of a Registration Rate Table

Each registration rate table contains two main sections: the student billing characteristics and the billing tables and policies. The student billing characteristics describe who is billed by a specific registration rate table. Billing characteristics are described in “Defining Student Billing Characteristics” on page 495.

The billing tables and policies describe how each student is billed. Specifically, the billing tables and policies identify

• Tuition charges

• Other registration charges

Table 178: Items to Read Before Defining Registration Rate Tables


Student billing characteristics “Defining Student Billing Characteristics” on page 495

How Colleague uses the registration rate tables


Student Billing Characteristics

illing Tables & olicies


Ge

• Add, drop, withdrawal policies

• Waiver policies

The remaining sections of this chapter describe each of these components. Refer to Table 179 to locate the sections of this chapter that describe each of these components.

Tips for Defining Registration Rate Tables

Do I Need Different Billing Tables and Policies?

The characteristics that you use to group together students for the purpose of registration billing should result in groups that have, at a minimum, unique tuition schedules (as defined through a tuition rate table). However, the other pieces of a registration rate table—the registration term rates tables, AR add/drop/withdrawal policies, and waiver policies—might be shared by a number of different registration rate tables.

For example, Ellucian University has five different registration rate tables for undergraduates: in-state, out-of-state, in-state athletes, out-of-state athletes, and employees. Each of these registration rate tables use different tuition rate tables, but they all share the same AR add/drop/withdrawal policy (the university has only one such policy).

In general, you can “mix and match” these tables in whatever combination fits your needs, but you should consider the following points:

• If you have two or more registration rate tables that use the exact same set of tables and policies, then you should consider whether you have properly defined your student billing characteristics. For example, if your billing characteristics check for whether a student is a resident or commuter student but your registration rate tables are not different for either residents or commuters, then perhaps this is not a valid characteristic.

• You do not need a unique tuition rate table for each registration rate table. However, unless at least one other component of the registration rate table is different between the tables, then you should again consider the purpose of having different registration rate tables for those groups of students.

Finally, remember that you do not have to define a registration term rate, AR add/drop/withdrawal policy, or waiver policy for all registration rate tables. However, be aware that if

Table 179: Finding Information about Registration Rate Table Components

For information about … See …

Tuition rate tables “Defining Table-Based Tuition” on page 504

Add/drop/withdrawal policies “Defining Add/Drop/Withdrawal Policies” on page 520

Term-based charges “Defining Registration Term Rates” on page 518

Tuition waiver policies “Defining Tuition Waiver Policies” on page 522


Ge

you do not define one or more of these components for a particular registration rate table, then Colleague does not apply the charges or waivers to the students billed under that registration rate table.

Naming Registration Rate Tables

When you define a registration rate table, you can either enter a unique name, or have Colleague assign a numeric ID as the rate table name. We suggest that you assign unique names for each registration rate table.

If you choose to enter your own unique name of each registration rate table, consider using an abbreviated description of the student characteristics for whom the table is used. For example, if you have one set of tuition rates for in-state undergraduates and another for out-of-state undergraduates you might want to abbreviate these characteristics using your residency code for in-state or out-of-state, along with your academic level code undergraduate. For example, use INSTUG and OUTSTUG, for the in-state undergraduate tuitions and the out-of-state undergraduates, respectively.

If you use the same registration rate table every year, even as your specific rates change, you do not need to use a year in the name of the registration rate table. By following this naming standard, as well as the suggestion for naming tuition rate tables described in “Naming Tuition Rate Tables” on page 511, you might have a registration rate table called INSTUG that uses the INSTUG97 tuition rate table.

Defining Registration Term Rates

If you return to the financial pages of your institution’s course catalog, you might see charges that your institution assesses whenever a student registers for class but that are not tied to a specific course section or number of credit hours. Charges such as activity fees and health services fees are examples of these types of fees. In Colleague, you define these fees on a registration term rate table.

Components of a Registration Term Rate Table

Use the Registration Term Rate Tables (RTRT) form to define each term rate table.


Ge

CCCC

Figure 76: The Registration Term Rate Tables (RTRT) Form

Each term rate table describes the default drop and withdraw registration refund policies for charges incurred from this table and the term charges. You can define term charges based on either courses/course credits or based on rules.

Course/Course Credit-Based Charges

Use the Course/Course-Credit Based Charges group of fields to define term charges assessed based on a certain number of credits. Colleague interprets the fields in this group similar to the way it interprets the Tuition Charges group on the Tuition Rate Table (TRTB) form. See Using Accounts Receivable/Cash Receipts for a complete description of how Colleague interprets these fields to assess term charges.

The registration term rate table illustrated in Figure 76 defines two different charges, an activity fee (the ACT AR code) and a health services fee (the HLT AR code). Colleague assesses both of these fees to a student if he has more than 12 credit hours and if the registration rate table used to calculate his registration charges uses this registration term rate table.

Rules-Based Charges

If you assess term-specific charges based on factors other than the number of courses or course credits that a student is taking during any given term, you may define the charges using rules. When the rule you write evaluates true (when the conditions of the rule are met for an individual student), Colleague assesses the associated charge.

To define rules Colleague uses to determine when to apply a term charge to a student's account you need:

• A rule that uses the REG.AR.POSTINGS file as the primary view.

ourse/ourse redit-Based harges

Rule-Based Charges


Ge

• An AR code to charge if the rule is evaluated true.

• An amount that is either a fixed amount or based on a field from the REG.AR.POSTINGS file.

• An optional registration refund policy.

Defining Add/Drop/Withdrawal Policies

If your institution charges a fee whenever a student adds or drops course sections during the add/drop period or withdraws from classes or from your institution, then define the amount of these fees as an AR add/drop/withdraw policy. You associate each add/drop/withdrawal policy with one or more registration rate tables. Thus, if you have one policy that applies to undergraduates and another that applies to graduates, then define two policies. Then associate the undergraduate policy with all your undergraduate registration rate tables and your graduate policy with all your graduate registration rate tables.

Types of Policies

You can define add/drop/withdraw policies as either a flat charge that is assessed regardless of the activity or as a specific policy for adding or dropping a course or withdrawing from a course section or from the institution.

Flat Charge Policy

If you want to charge a flat rate whenever an individual adds or drops a course or withdraws from the institution, then you can define a flat charge add/drop/withdraw policy. For this policy you would define one AR code and one charge amount (the Flat Charge AR Code and Flat Charge Amount fields, respectively). Whenever this policy is used, Colleague charges the AR code with the amount you enter for all course section adds and drops processed through registration and for all academic withdrawals.

Add, Drop, and Withdraw Specific Policies

Use an add, drop, and withdraw specific policy to charge different AR codes for adding or dropping a course section and for withdrawing from the institution. Complete the Add fields, the Drop fields, and the Withdraw fields to define this type of policy. For each policy you can use any combination of the Add, Drop, and Withdraw fields. However, if you leave one of these three groups empty, a charge is not created when that event occurs. For example, if you leave the Withdraw fields blank, then when that policy is used, Colleague does not generate charges if an individual withdraws from the institution.

Note: You must complete either the Flat Charge fields or any combination of the Add fields, the Drop fields, and the Withdraw fields for each add/drop/withdraw policy.


Ge

Components of an AR Add/Drop/Withdrawal Policy

Use the AR Add/Drop/Withdraw Policies (ADWP) form to define your AR add/drop/withdraw policies.

Figure 77: The AR Add/Drop/Withdraw Policies (ADWP) Form

Tips for Defining AR Add/Drop/Withdrawal Policies

The Number of Policies

Although you associate add/drop/withdrawal policies with registration rate tables, you may not need to define a unique policy for each registration rate table. For example, Ellucian University has the following registration rate tables:

• In-state, undergraduate

• In-state, undergraduate, athlete

• Out-of-state, undergraduate

• Out-of-state, undergraduate, athlete

• Undergraduate, employee

• In-state, graduate

• Out-of-state, graduate

• Graduate, employee

Flat Charge

Add, Drop, and Withdrawal Specific Charges


Ge

However, the university has only two add/drop/withdrawal policies: one for undergraduates and one for graduates. The undergraduate policy is associated with each of the undergraduate registration rate tables and the graduate policy is associated with each of the graduate registration rate tables.

Naming Add/Drop/Withdrawal Policies

You should give each of your add/drop/withdrawal policies a name that is indicative of the policy being defined. You might also want to use the year for which the policy is effective to distinguish between similar policies for different years. For example, Ellucian University’s add/drop/withdrawal policies for the 1997/98 academic year are UG97 and GR97 while the policies for the 1996/97 academic year were UG96 and GR96.

Defining Tuition Waiver Policies

A waiver policy describes a reduction in the tuition and other charges incurred by all individuals billed by a specific registration rate table. Use a waiver policy when you want to recognize all the revenue associated with tuition and related charges while expensing the amount of these charges not billed the student to a separate general ledger account. For example, if an employee of your institution always receives a specific waiver of tuition and other charges, then you would:

1. Define an employee registration rate table.

2. Apply the appropriate tuition rate table, add/drop/withdrawal policy, and registration term rate table to the registration rate table.

3. Enter the waiver policy defined for employees on the employee registration rate table.

Before You Begin

Using Accounts Receivable/Cash Receipts explains in detail how Colleague calculates waivers based on the different options for setting up a waiver policy. You should read this section before you set up each waiver policy.

Define the appropriate AR codes for each waiver policy. See “Components of a Waiver Policy” on page 522 for information about AR codes needed for a waiver policy and “AR Codes” on page 149 for information about how to define AR codes.

Components of a Waiver Policy

Use the AR Waiver Policies (WAVP) form to define each waiver policy. Once you have defined a waiver policy you can assign it to one or more registration rate tables.


Ge

Figure 78: Example of a Waiver Policy

The following fields and group of fields are described below:

• Waive or Charge

• Tuition Waiver AR Code

• Max Number of Courses

• Max Number of Credits

• Max Tuition

• Other Charges group

Refer to online help for information about the other fields on the WAVP form.

Waive or Charge

A waiver policy can calculate the amount of tuition and other charges that Colleague generates as either a waiver or a charge. If you want Colleague to waive tuition and other charges—up to the maximum described in either the Max Number of Credits, Max Number of Courses, or Max Tuition fields—then enter W in the Waive or Charge field. If you want Colleague to charge tuition and other charges—up to the maximum described in either the Max Number of Credits, Max Number of Courses, or Max Tuition fields—then enter C in the Waive or Charge field.

For example, if you set a waiver policy as “waive” and you define the maximum number of courses as three, then Colleague waives the tuition and other charges associated with the first three course sections that the student registered for and charge the student for the tuition and other charges associated with all the remaining course sections.

Other Charges Group


Ge

If you set the waiver policy to “charge” and you define the maximum number of courses as three, then Colleague charges the tuition and other charges associated with the first three course sections that the student registered for and waive the tuition and other charges associated with all the remaining course sections.

Note: The remainder of this section describes a waiver policy that is set as a “waive”—by entering W in the Waiver or Charge field. Where necessary, the difference between “waive” and “charge” waiver policies are described.

Tuition Waiver AR Code

To waive tuition charges you must indicate the AR code that represents the debit to the appropriate general ledger accounts. If you do not enter an ar code in the Tuition ar Code field, Colleague does not waive any tuition charges.

When Colleague calculates the registration charges for an individual using a registration rate table that contains a waiver policy, the full tuition amount is credited to the general ledger accounts associated with the normal tuition AR code. The amount of the waiver is then posted as a debit to the general ledger accounts associated with the AR code defined here.

Max Number of Courses

Note: You can use the Max Number of Courses or the Max Number of Credits or the Max Tuition field to limit the course sections to which the waiver is applied. You cannot use all three methods for a single waiver policy.

If the amount of tuition that is waived is limited to a certain number of course sections that a student has registered for during a billing period, then use the Max Number of Courses field to identify the maximum number of course sections to which the waiver apply. For example, if a waiver policy for employees states Colleague should waive only the first three courses, then enter 3 in the Max Number of Courses field.

If the Waive or Charge field is set to “C,” then Colleague charges tuition up to the maximum number of course sections identified, and then waive the charges for the remaining course sections. For example, if the waiver policy states has a maximum number of courses of three, then Colleague calculates the tuition for the first three course sections and waives the charges for all other course sections.

Max Number of Credits



Ge

If the amount of tuition that is waived is limited to a certain number of billing credits that a student has registered for during a billing period, then use the Max Number of Credits field to identify the maximum number of billing credits to which the waiver applies. For example, if a waiver policy for employees states Colleague waive only the first 12 billing credits, then you would enter 12 in the Max Number of Credit field.

Colleague waives incomplete credits as a portion of the remaining credits to the total credits. For example, a student might register for the following course sections:

If Colleague waives a maximum of 12 credits, then it waives 100 percent of the tuition for MATH*101*01, ENGL*101*03, CHEM*112*02. However, Colleague only waives two-thirds of the tuition for PHYS*100*01 (there are 2 billing credits remaining out of the 3 billing credits for PHYS*100*01). Colleague charges 100 percent of the tuition for MUSIC*104*01.

If the Waive or Charge field is set to “C,” then Colleague charges tuition up to the maximum number of billing credits identified, and then waive the charges for the remaining credits. For example, if the waiver policy states has a maximum number of billing credits is 12, then Colleague calculates the tuition for the course sections until 12 billing credits are reached and waives the charges for all other course sections.

Max Tuition


If the amount of tuition that is waived is limited to a set amount of tuition, then use the Max Tuition field to identify the maximum tuition amount. For example, if a waiver policy for employees states Colleague waive only $2,500.00 in tuition, then you would enter 2500 in the Max Tuition field.

Table 180: Sample Maximum Number of Credits

Course Section Billing Credits

MATH*101*01 3

ENGL*101*03 3

CHEM*112*02 4

PHYS*100*01 3

MUSIC*104*01 4


Ge

For example, a maximum of $2,500 is waived, and a student registered for the following course sections:

Because the total tuition is greater than the maximum Colleague waives with this policy, Colleague waives the maximum $2,500 and charges the student the difference of $275 (which Colleague associates with the MUSIC*104*01 course section).

If the Waive or Charge field is set to “C,” then Colleague charges tuition up to the maximum tuition amount identified, and then waive the charges for the remaining tuition. For example, if the waiver policy states has a maximum tuition amount is $2,500, then Colleague charges the tuition for the course sections until $2,500 is reached and waives the charges for all other course sections.

Other Charges Group

Use the Other Charges group on the AR Waiver Policies (WAVP) form to identify course-based fees and charges and term charges that you want included in the waiver policy. Define course-based fees and charges on the Course Billing Information (CRSB) form or the Section Billing Information (SECB) form. Colleague assesses course-based fees to anyone who registers for that course section.

Use the Registration Term Rates Table (RTRT) form to define term charges. Colleague assesses the charges on the term rate table to all students billed by a registration rate table that includes a registration term rate table.

If you want to waive all or part of any of these fees and charges, you must include the appropriate AR code in the Waived Charge AR Code of the Other Charges group. You must also identify

• The AR code to which Colleague posts the waived charges (in the Waiver AR Code field).

• The percent of the eligible charge Colleague waives.

The amount of a charge Colleague waives depends on the waiver method you use. For example, if you define a waiver policy to waive up to a maximum number of courses, then Colleague waives the course-based charges—up to the percentages indicated in the Other Charges group—associated with any course sections whose tuition is waived.

Table 181: Sample Maximum Tuition

Course Section Tuition Charged

MATH*101*01 $489.71

ENGL*101*03 $489.71

CHEM*112*02 $652.94

PHYS*100*01 $489.71

MUSIC*104*01 $652.93

Total $2,7750.00


Ge

Registration term charges, on the other hand, are eligible to be waived when the waiver method is by maximum number of courses based on the number of courses waived as a percent of the number of courses registered for. For example, if Colleague waives a maximum of 5 courses, and a student registered for 5 courses, then 100 percent of the registered courses were waived and as a result, 100 percent of the term charges are eligible to be waived.

Note: A course-based charge or a term charge cannot be waived if, as a result of the registration billing process, the student was not assessed that charge. Therefore, the first criteria Colleague uses to determine if a charge is waived if the student was assessed that charge for the billing period.

Comparing Waivers and Tuition Discounts

Table 182 provides a comparison of waivers and tuition discounts.

Whether you use waivers or discounts to reduce the amount of registration charges that a student incurs, you should realize Colleague posts as revenue the full amount of each registration charge to the appropriate general ledger accounts and posts an expense in the amount of the waiver or the discount.

Table 182: Comparison of Waivers and Discounts

Waiver Discount

Types of Charges Covered

A waiver can cover all registration charges (tuition, course-based fees, and term charges) incurred by a student.

A discount applies to tuition charges associated with a course section that is defined to use section-based (and not table-based) billing.

Types of Students Covered

All students billed by the registration rate table that includes a waiver policy.

All students who register for the course section that contains a discount receives the discount, unless the discount type is “B,” in which case only students who also have the same discount code assigned to them receives the discount (see “Tuition Discount Types” on page 529).

Where Defined On the AR Waiver Policies (WAVP) form.

On the Tuition Discounts (DISC) form.


Ge

Defining Tuition Discounts

Tuition discounts describe reductions in tuition and other charges that Colleague generates from billing information associated with a specific course section that uses section-based billing. When you define a tuition discount you choose to apply the discounts to:

• A specific course

• Aspecific course section

• An individual student

If you assign a discount to a specific course, then Colleague defaults the discount to all course sections created from that course. You can, however, remove the discount from one or more course sections after the course section is created. For example, if you apply a discount to MATH*153 then the discount defaults to each course section of MATH*153. However, if the discount should not apply to MATH*153*06, then you can remove the discount from that course section.

You can also apply a discount to a specific course section, without first applying that discount to the course. For example, if only students who register for ENGL*220*05 should receive a discount, then you do not have to associate the discount for the course ENGL*220, but may associate it with ENGL*220*05.

Whether you apply a discount to all sections of a particular course or only to specific sections, Colleague applies that discount to all students who register for that course section.

Use the Course Billing Information (CRSB) form to assign a discount to a course. Use the Section Billing Information (SECB) form to assign a discount to or remove a discount from a specific course section.

Note: You must define a discount as type “C” or type “B” to associate that discount with a course or course section. If you use the “B” discount type, Colleague applies the discount only when a student with the same discount code registers for the course section. You must define a discount as type “S” or type “B” to associate that discount with a course or course section. If you use the “B” discount type, Colleague applies the discount only when the student registers for a course section with that same discount code.

Use the Additional Student Profile Information (ASPR) form to apply a discount to a particular student.

Components of a Tuition Discount

Use the Tuition Discounts (DISC) form to define tuition discounts. Colleague stores these codes in the DISCOUNTS file.


Ge

Figure 79: The Tuition Discounts (DISC) Form

This section describes the following fields on the Tuition Discounts (DISC) form:

• Type

• Rules

See the online help for information about the other fields on the DISC form.

Tuition Discount Types

The discount type identifies where you can apply the discount. The options for this field are:

• C. Associate discounts of this type with a specific course section so that all students who take the course section receive the discount. Use this discount code on either the Course Billing Information (CRSB) form or the Section Billing Information (SECB).

• S. Associate discounts of this type with a student so that the discount applies to all section-billed course sections for which the student registers. Use this discount code on either the Additional Student Profile Information (ASPR) form or on the Section Billing Override form. If you associate the discount with the student (on the ASPR form), then Colleague discounts all courses the student registers for that use section-based billing. If you associate the discount with the student on the Section Billing Override form, then Colleague applies the discount to the tuition charges it generate for that course section only.

• B. Associate discounts of this type with a specific course section record for a student. Colleague does not apply a “B” type of discount to a student’s tuition charges unless you associate that discount with both the student and with one or more of the course sections for which the student registers. Therefore, you must associate the discount with both a course (on either the Course Billing Information [CRSB] form or the Section


Ge

Billing Information [SECB] form) and with a student (on either the Additional Student Profile Information [ASPR] form or on the Section Billing Override form).

Colleague stores discount types in the DISCOUNT.TYPES record of ST.VALCODES. You should only modify this code with the assistance of an Ellucian representative.

Tuition Discount Rules

For any discount that you define as an “S” type, you can identify the students eligible for the discount with tuition discount rules. When you apply a discount code to a student’s record (on the Additional Student Profile Information [ASPR] form), Colleague evaluates all the rules associated with that discount code. If the student passes all the rules, Colleague assigns that discount code. For example, for a tuition discount that only applies to senior citizens, you might define a rule that checks the student’s current age. If a student is older than a specified age (for example, 65), that discount can be applied. Figure 80 illustrates an example of a rule using the STU.AGE virtual field in the STUDENTS file.

Figure 80: Example of a Tuition Discount Rule

Note: When you apply a discount to a student on the Section Billing Override form, the discount code can be either an “S” type or a “C” type and Colleague ignores any assignment rules associated with the discount code.

To define rules for tuition discounts

• Use the worksheet “Rule Construction—English Statements” on page 320 to map out the rules in simple English statements.


Ge

• Use the worksheet “Rule Construction Translation” on page 322 to translate the English statements to rules processor syntax (see “Understanding the Rules Processor” on page 309).

• Your rules must have a primary file view of the STUDENTS file.

How Colleague Calculates and Applies Tuition Discounts

When a student registers for a course section, Colleague creates a record in the STUDENT.COURSE.SEC file that contains all the student-specific information about that course section registration. This record includes information Colleague uses to create registration billing records. The student’s STUDENT.COURSE.SEC record contains a complete list of all the discounts that apply to a specific occurrence of a student’s course section registration. Colleague compiles this list

• From any discounts associated with the course section that the student registered for.

• From any discounts associated with the student.

Note: You can modify (add, delete, or change the amount or percentage) the discounts Colleague initially associates with a student’s STUDENT.COURSE.SEC record. See Using Accounts Receivable/Cash Receipts for more information about overriding course section billing information.

When Colleague creates the registration billing record for the student, Colleague creates an invoice line item that reflects the total tuition charge for that course section and a second invoice line item that reflects all discounts that apply to that tuition charge.

Difference Between Tuition Discounts and Waivers

See “Comparing Waivers and Tuition Discounts” on page 527 for a description of the difference between tuition discounts and waivers.

Procedure for Setting Up Registration Billing

Complete the following steps to set up table-based registration billing.

1. Complete the items listed in “Before You Begin” on page 494.

2. Identify the student billing characteristics on which you base registration billing.

See “Defining Student Billing Characteristics” on page 495.

Work with your system administrator to identify the fields from the database that describe your billing characteristics.

3. Define your billing characteristics in terms of fields within the Colleague database.


Ge

Use the Registration Rate Billing Fields (RRBF) form.

The billing characteristics defined on the RRFB form represent your institution’s general student billing characteristics. Use these billing fields to build unique registration rate tables (see Step 4).

See “Defining Student Billing Characteristics” on page 495.

4. Define registration rate tables for each unique set of billing characteristics using the Registration Rate Tables (RGRT) form.

See “Tips for Defining Registration Rate Tables” on page 517.

See “Defining a Registration Rate Table” on page 515.

5. Define your tuition rate tables using the Tuition Rate Table (TRTB) form.

Associate each tuition rate table with at least one registration rate table.

See “Defining Table-Based Tuition” on page 504.

6. Define your term rate tables using the Registration Term Rate Tables (RTRT) form.

Associate each registration term rate table with at least one registration rate table.

See “Defining a Registration Rate Table” on page 515.

7. Define your add/drop/withdrawal policies using the AR Add/Drop/Withdrawal (ADWP) form.

Associate each add/drop/withdrawal policies with at least one registration rate table.

See “Defining Add/Drop/Withdrawal Policies” on page 520.

8. Define your tuition waiver policies using the Waiver Policies (WAVP) form.

Associate each tuition waiver policy with at least one registration rate table.

See “Defining Tuition Waiver Policies” on page 522.

9. Access the Course Billing Information (CRBS) form for each course billed by a rate table.

For each course

• Enter T in the Billing Method field

• Complete the remaining fields as appropriate for the billing period method selected.

See “Defining Table-Based Tuition” on page 504 and “Defining Section-Based Tuition” on page 512.

10. Modify each course-section’s billing information as needed.

Use the Section Billing Information (SECB) form to modify a specified course section.

You need to modify the billing information for a course section only if that course section has billing information that is different from its parent course. See “Deciding Whether to Define Billing Information at the Course or the Course Section Level” on page 515.


Ge

Defining Room Rates and Meal Plan Rates

In This Chapter

This chapter describes how to define room rates and meal plan rates for use with the Residence Life module. If you do not use Colleague’s Residence Life module you do not need to define these rates.

Before You Begin

Before you can define room rates or meal plan rates, the following must be defined:

Defining Room Rates

Room rates describe the amount your institution charges for renting different types of rooms. You define as many different room rates as you need to meet the different rental situations you have, including the length of the rental (such as daily, weekly, or by term), the person who is renting the room (for example a student or a guest), and even the timing of the room rental (for example summer or fall/spring).

Table 183: Information Needed Before Defining Room Rates or Meal Plan Rates

Procedure Information Needed Reference

Defining Room Rates AR codes “AR Codes” on page 149

Buildings1

1.In addition to the building codes, each room in each building you use with room billing must have an associated room rate class. See the documentation for the Facilities Profile module for more information.

The documentation for the Facilities Profile module

Room rate classes The documentation for the Facilities Profile module

Defining Meal Plan Rates AR codes “AR Codes” on page 149

Meal plans 861

533tting Started with Colleague Student | Defining Room Rates and Meal Plan Rates

Ge

Figure 81 illustrates the different components of a room rate. This section describes each of these components and how they fit together.

Figure 81: Overview of the Components of a Room Rate

The mnemonics shown along the arrows in this figure represent the forms where you define these relationships. For example, use the Rooms (RMSM) form to define room rate classes for each room. Table 184 lists each form identified in the figure and provides a reference for more information about the form.

Understanding Room Rates

You associate each room you rent with at least one room rate table via the room’s rate class and building. The rate table defines how much you charge for that room on a daily, weekly, monthly, yearly, or term basis. If you charge different rates for the same room depending on who is renting that room, Colleague lets you define multiple room rate tables for a building and rate class. For example, you might charge students one rate for dorm rooms and a different rate when a guest or a faculty member rents the same dorm room.

Table 184: Forms Used to Define a Room Rate

Form Reference

Rooms (RMSM) “Using Facilities Profile” in Using Curriculum Management

Buildings (BLDG) “Using Facilities Profile” in Using Curriculum Management

Room Rate Assignment (RRTS) “Components of a Room Rate” on page 537

Room Rate Tables (RRTP) “Components of a Room Rate” on page 537

Room Rate Class

Room

Building

Room Rate

AR Code Room Rate Table

Override

Default

RMSM BLDG

RRTSRRTS

RRTP


Ge

Because it would be cumbersome to define room rate tables for every room you rent, you associate room rate tables to a building/rate class combination. A rate class groups together like-style rooms. Examples of room rate classes you might use for dorm rooms include single, double, triple, or suite. Figure 82 illustrates how room rate classes relate to a building and how different buildings can have different combinations of room rate classes.

For each building/rate class combination, you can define multiple rate tables represent the rates you charge different types of individuals or organizations (Figure 83).

In the example illustrated in Figure 83, Rate A-1 represents the rates Ellucian University (EU) charges students for a single room in Brook Hall, Rate B-1 represents the employee’s rate for the same room, and Rate C-1 represents the guest’s rates for the same room. The rate tables illustrated in Figure 83 are not necessarily unique to Brook Hall. For example, EU uses the same set of rate tables for Thompson Hall’s single and double rate classes.

Each rate table includes the amount EU charges when the rental is for a day, a week, a month, a term, or a year (Figure 84).

Figure 82: Example of the Relationship Between Buildings and Room Rate Classes

Rate Class

Building

Brook Hall Thompson Hall Webb Hall

Single ? ? ?

Double ? ? ?

Triple ? ?

Suite ?

Figure 83: Example of Multiple Rate Tables for One Building

Brook Hall

Rate Class

Rate Table

Student Employee Guest

Single Rate Table A-1 Rate Table B-1 Rate Table C-1

Double Rate Table A-2 Rate Table B-2 Rate Table C-2

Triple Rate Table A-3 Rate Table B-3 Rate Table C-3

Suite Rate Table A-4 Rate Table B-4 Rate Table C-4


Ge

The example illustrated in Figure 84 shows that Colleague charges a student who rents a single room in Brook Hall on a daily basis $75 per day (rate table A-1). Colleague charges a student who rents the same room for a term $1,700 for each term. Figure 85 shows how the business office defined some of these tables in Colleague using the Room Rate Assignment (RRTS) form and the Room Rate Tables (RRTP) form.

Figure 84: Example of Rate Tables for One Building’s Room Rate Class

Brook Hall

Rate Tables

Rates Charged to Students (Amounts in Dollars)

Daily Weekly Monthly by Term

A-1 (Single) 75 n/a n/a 1,700

A-2 (Double) 50 n/a n/a 1,530

A-3 (Triple) 100 n/a n/a 1,830

A-4 (Suite) 120 n/a n/a 2,100


Ge

Figure 85: Example of Rate Tables Defined in Colleague

Components of a Room Rate

Use the Room Rate Assignment (RRTS) form and the Room Rate Tables (RRTP) form to define room rates for each building/room rate class combination (Figure 85).

The following fields and group of fields on the Room Rate Tables (RRTP) form are described below:

• Rate Period group

• End Date

Rate Period Group. Use the fields in the Rate Period group to identify the rates charged for either a daily, weekly, monthly, term, or yearly rental. You must define at least one amount for a rate table, but you do not have to have all five rates. For example, the rate table illustrated in Figure 85 indicates that students can rent a single dorm room in Brook Hall on a daily, monthly, and term basis only.


Ge

When the residence life office makes a room assignment, Colleague identifies the rate period, such as daily, weekly, monthly. Colleague uses the rate period from the assignment to identify the rate to charge the individual for the room rental. For example, if the residence life office makes a room assignment for a daily rate period, Colleague calculates the rental charge using the daily rate from the room rate table.

The Effective Date field identifies when a group of rates first becomes effective. The Brook Hall example illustrates a room rate table with two effective dates: July 1, 1996 and July 1, 1997. Colleague uses the rates effective July 1, 1996 for all room assignments for single rooms in Brook Hall made from July 1, 1996 through June 30, 1997. Colleague uses the rates effective July 1, 1997 for all room assignments for single rooms in Brook Hall made on or after July 1, 1997.

The Effective Date field lets you update one rate table each time your rates change while preserving the past rates. Even after a new rate takes effect, Colleague may use the previous rates for billing individuals when their room assignments correspond with those rates. See Using Accounts Receivable/Cash Receipts for more information about how Colleague determines which room rate to use for generating a student’s charges.

End Date. Use the End Date field when you want to discontinue the use of a room table. For example, if you enter an end date of June 30, 1997, for a room rate table, Colleague does not allow that rate table to be assigned to a building/rate class combination or to a room assignment in the Residence Life module. However, you can rebill room assignments made prior to the end date. As with any rebilling of a room assignment, Colleague determines the correct rate to charge based on the effective date of the rates and the start date of the assignment. See Using Accounts Receivable/Cash Receipts for more information about how Colleague bills room assignments.

Procedure for Defining Room Rates

Complete the following steps to define room rates and room rate tables:

1. Identify each building used in room billing.

2. Identify each rate class associated with each building you identified in Step 1.

Create a copy of the worksheet “Room Rates” on page 621 for each building/rate class combination you identify.

3. Define the ROOM.RATE.CLASSES validation code table.

Colleague stores the ROOM.RATE.CLASSES validation code table in the CORE.VALCODES file.

4. Determine the number of different rate tables you need for each building/rate class combination.

Identify the different usage types for the selected building/rate class combinations. For example, student rental, guest rental.

5. Build each rate table, using the Room Rates worksheet.

Complete the worksheet “Room Rate Tables” on page 622 for each rate table listed on the Room Rates worksheet.


Ge

You may, however, have rate tables used by more than one building/rate class combination.

6. Associate a rate class with each room in a building.

7. Access the Room Rate Tables (RRTP) form.

8. Define each rate table.

Use the information from the Room Rate Tables.

9. Access a building/rate class combination on the Room Rate Assignment (RRTS) form.

10. Associate the appropriate rate tables with the selected building/rate class combination.

11. Repeat this procedure beginning for each building/rate class combination with Step 9.

Defining Meal Plan Rates

You must associate each meal plan the residence life office defines with a unique rate table. These rate tables describe the billing rate for the meal plan as well as the credit AR code for meal plan charges and the debit AR code for meal plan cancellations.

Components of a Meal Plan Rate

Use the Meal Plan Rates (MPRS) form to define meal plan rates.

Figure 86: Example of a Meal Plan Rate


Ge

The following fields on the Meal Plan Rates (MPRS) form are described in this section:

• Rate Period

• Effective Date

Rate Period. The rate period is an informational code that describes the period of time covered by the rate being charged. Valid rate periods are:

• By the meal

• Daily

• Weekly

• Monthly

• Yearly

• Term

For example, the rate table for the meal plan indicates this meal plan’s rate of $200 is a per week rate.

Colleague does not generate charges or run any processes based on this code. However, if you define a meal plan’s rate period as “Term,” you can only assign that meal plan to an individual for one period—one term—at a time. By contrast, you can assign an individual a meal plan for multiple periods when that meal plan does not have a term rate period.

See Using Accounts Receivable/Cash Receipts for more information about how Colleague bills meal plans.

Effective Date. A meal plan rates’ effective dates indicate when Colleague uses the associated rate. If a meal plan has one rate, anyone assigned that meal plan on or after that effective date receives that rate. If a meal plan has multiple rates, Colleague determines the rate an individual is billed based on the effective date.

For example, a meal plan may have the following rates and effective dates:

Colleague bills any individual who purchases this meal plan on or after July 1, 1997 at the $500.00 rate. Colleague bills any individual who purchased this meal plan between July 1, 1996 and July 1, 1997, at the $475.00 rate.

Table 185: Example Meal Plan Rates

Effective Date Rate

07/01/97 $500.00

07/01/96 $475.00

07/01/95 $400.00

07/01/94 $350.00


Ge

Procedure for Defining Meal Plan Rates

Use the Meal Plan Rate Assignment (MPRS) form to define rates for each meal plan. Use the worksheet “Meal Plan Rates” on page 623 to record the rates for each meal plan. If you use these worksheets you should have one worksheet for each active meal plan.

You can access the Meal Plan Rate Assignment (MPRS) form from the menu or from the Rates field on the Meal Plan Setup (MPSU) form.


Ge

Setting Up Financial Aid Transmittal

In This Chapter

This chapter provides information and instruction on financial aid transmittal parameters, which control when financial data is submitted to your institution’s accounts receivable department.

Before You Begin

Before you set up the parameters for financial aid transmittal, all financial aid award periods must be defined. Refer to Using Financial Aid for information about defining financial aid award periods.

Understanding Financial Aid Transmittal Parameters

The financial aid transmittal parameters control when Colleague transmits financial aid data to accounts receivable. Colleague can transmit financial aid whenever the financial aid office modifies a student’s financial aid award package or whenever you post accounts receivable transactions to a student’s account. You set the financial aid transmittal parameters by award periods, which are the portions of an academic year in which financial aid is awarded. An award period may or may not correspond with an academic term.

Use the FA Transmittal Control (FATC) form to define the financial aid transmittal parameters

542tting Started with Colleague Student | Setting Up Financial Aid Transmittal

Ge

Figure 87: Example Financial Aid Transmittal Parameters

Posting Based on Financial Aid Activity

If you enter one or more award periods in the Award Period code of the Immediate Transmittal from FA group, Colleague transmits the financial aid awarded during those periods as soon as any financial aid activity occurs in a student’s account.

For example, Figure 87 illustrates transmittal parameters that includes the Fall 1997 award period in the Immediate Transmittal from FA group. If a student has financial aid for that period (August 15, 1997 through December 31, 1997) and the financial aid office modifies that award package, then Colleague transmits the student’s Fall 1997 financial aid to accounts receivable.

Posting Based on Accounts Receivable Activity

If you enter one or more award periods in the Award Period code of the Immediate Transmittal During Billing group, Colleague transmits the financial aid awarded during those periods as soon as any accounts receivable activity for the same time period occurs in a student’s account.

For example, Figure 87 illustrates transmittal parameters that includes the Spring 1998 award period. If a student has financial aid for that period (January 2, 1998 through May 20, 1998) and Colleague posts registration charges with a billing date of January 16, 1998, then Colleague transmits the student’s Spring 1998 financial aid to accounts receivable.


Ge

Note: You can have the same award period in both the Immediate Transmittal from FA group and the Immediate Transmittal During Billing group.

Unposted Financial Aid

If you do not include one or more award periods in either group of the FA Transmittal Control form, Colleague does not automatically transmit those awards to accounts receivable. You must run the financial aid batch transmittal process to post the aid associated with any award periods not listed on the parameter form. See Using Accounts Receivable/Cash Receipts for details on using the batch transmittal process.


Ge

Defining Administrative Fee Defaults

In This Chapter

This chapter provides information and instruction on the components of administrative and application fees and how define them for your institution in Colleague.

Before You Begin

Before you define the defaults for processing administrative fees you must define the following:

In addition, you need to be familiar with how to define rules. See “Understanding the Rules Processor” on page 309.

Understanding Administrative Fees

Colleague maintains three types of administrative fees—application fees, enrollment verification fees, and transcript request fees—that it automatically processes under the following conditions:

Table 186: Information Needed Before You Define Administrative Fee Defaults


AR codes 149

AR types 159

Table 187: When Colleague Processes Administrative Fees

Fee Type When Assessed

Application fee Colleague charges the appropriate application fees when you record the receipt of an admissions application through the Applications (APPN) form.

See Using Recruitment/Admissions Management for details on recording an admissions application.

545tting Started with Colleague Student | Defining Administrative Fee Defaults

Ge

The defaults described in this chapter determine the amount of each fee charged and the AR type and the AR code to which Colleague posts each transaction.

Components of Administrative Fee Defaults

Use the AR Fee Defaults (ARFD) form to establish the default charge Colleague assesses for each type of administrative fee and the default AR code and AR type.

Figure 88: Example of an Administrative Fee Default with Rules

Enrollment verification fee Colleague charges the appropriate enrollment verification fees when you record an verification request on the Enrollment Verification Requests (ENVR) form.

See Using Academic Records for information about recording an enrollment verification request.

Transcript request fee Colleague charges the appropriate transcript request fee when you record a transcript request on the Transcript Requests (TRRQ) form.

See Using Academic Records for information about recording a transcript request.

Table 187: When Colleague Processes Administrative Fees (continued)

Fee Type When Assessed


Ge

Note: In addition to the defaults you define on the ARFD form, you can define two additional sets of defaults for application fees: academic program application fees and academic level application fees. See “Components of Application Fee Defaults” on page 548 for details.

For each administrative fee, you can define the defaults as a single AR type, AR code, and charge that Colleague applies to all transactions associated with that fee or you can use rules to define the defaults as they apply to specific individuals. You can also use a combination of rules and defaults.

Colleague uses the default AR type, AR code, and charge you enter the Default AR Type, Default AR Code, and Default Charge fields, respectively, for all transactions associated with the fee if you do not have any rules for either the AR type or AR code. If you define rules for the AR type and one of the rules evaluates true, Colleague uses the AR type associated with that rule. Similarly, if you define rules for the AR code and one of the rules evaluates true, Colleague uses the AR code and charge associated with that rule.

For example, Ellucian University (EU) charges all students, except employees, the same amount for transcript requests. Therefore, the business office defined the defaults for transcripts requests to cover all requests except for those from employees. To cover the requests from employees the business office defined a rule that checks the student’s current student type. If the student type indicates the student is an employee, the transaction passes the rule and Colleague charges the lower transcript request fee and uses the employee receivable AR type. Figure 88 illustrates how EU defined the defaults for transcript request fees.

Figure 89 illustrates how EU charges the same amount—and uses the same AR type and Ar code—for anyone who makes an enrollment verification requests. Because there are no rules defined for this fee, Colleague charges $20.00 for all requests and posts the charge to the Student Receivable AR type and the TRANS AR code.


Ge

Figure 89: Example of an Administrative Fee Default without Rules

Using Rules for Administrative Fee Defaults

Use the following primary views to define AR type or AR code rules:

Components of Application Fee Defaults

You can define the defaults Colleague uses for charging application fees:

• As described in “Components of Administrative Fee Defaults” on page 546

• As defaults for specific academic programs

• As defaults for specific academic levels

• In any combination of the above

Table 188: Primary Views Used for Administrative Fee Defaults Rules

Rules for … Use a Primary View of …

Application fees The APPLICATIONS file

Enrollment verification fees The STUDENT.REQUEST.LOGS file

Transcript request fees The STUDENT.REQUEST.LOGS file


Ge

Application Fees Based on Academic Programs

If you charge application fees specific to one or more academic program, you may choose to define the default application program fees (Figure 90).

Figure 90: Example Application Fee Based on Academic Program

Use the Program Application Fees (PAPF) form to define one or more application fees for a specific academic program. In the example illustrated in Figure 90, Colleague assesses any applicant to the Bachelor of Science in Nursing academic program a $55.00 application fee.

Application Fees Based on Academic Levels

If you charge one or more application fees based on the academic level to which an applicant is applying, you can define those fees as academic level fees.


Ge

Figure 91: Example Application Fees Based on Academic Level

Use the Academic Level Application Fees (ALAF) form to define a set of application fees for a specific academic level. In the example illustrated in Figure 91, Colleague charges an applicant submitting an application to a graduate level program $45.00.


Ge

How Colleague Evaluates Application Fee Defaults

The following figure illustrates how Colleague determines which application fees to charge based on how you define these different defaults.

Are application fees defined for the academic

program?

Are application fees defined for the academic

level?

Are there AR type rules

defined for the

Are there AR type rules

defined for the fee defaults?

Use the default AR type

Use the application fees defined for that

academic program

Is one of the rules true?

Use the application fees defined for that academic level.

Use the AR type associated with

the true rule.

Use the AR code and charge

associated with the true rule.

Is one of the rules true?

Use the default AR code and charge.


Ge

The examples illustrated in Figure 90 and Figure 91 are one means of defining application fees that you base on either an academic program or an academic level. Alternatively, you can use the AR Fee Defaults form and define all the application fees your institution assesses.

For example, when the business office at Ellucian University (EU) set up its defaults for application fees, they determined the following:

• All undergraduates are charged a $25.00 application fee.

• All graduates are charged a $45.00 application fee, unless they are applying to one of the following programs:

• nursing—which has an additional $10.00 application fee

• law—which has an additional $15.00 application fee

• All employees—regardless of academic level—are charged a $5.00 application fee (employees applying to either the nursing or law program are charged the full application fee).

• All application fees are distributed to the same general ledger account, therefore, they all use the same AR code.

Ellucian University could have used a combination of the fee defaults with the academic program and academic level specific rules, or used just the fee defaults to define its application fee structure. Table 189 compares the two approaches for EU’s application fee structure.

Table 189: Comparing Two Approaches to Defining Application Fee Defaults

Fee Type

Using Academic Level and Academic Program Fee Defaults

Using AR Fee Defaults Only

$25.00 undergraduate application fee

Define the fee defaults on the AR Fee Defaults form to cover the undergraduates charges.

Define the fee defaults on the AR Fee Defaults form to cover the undergraduates charges.

$5.00 employee application fee, unless applying to the nursing or law program

Use a AR code rule to (1) determine that an individual is an employee not applying to either law school or the nursing program and (2) assess the $5.00 fee when the rule is true.

Use an AR code rule to (1) determine that an individual is an employee not applying to either law school or the nursing program and (2) assess the $5.00 fee when the rule is true.


Ge

Figure 92 on page 554 illustrates how Ellucian University implemented this fee structure using just the fee defaults.

$45.00 graduate application fee

Define the application fee on the Academic Level Application Fees (ALAF) form (see Figure 91).

Use an AR code rule to (1) determine that an individual is applying to a graduate program other than either law school or the nursing program and (2) assess the $45.00 fee when the rule is true.

$55.00 nursing school application fee

Define the application fee on the Program Application Fees (PAPF) form (see Figure 90).

Use an AR code rule to (1) determine that an individual is applying to the nursing program and (2) assess the $55.00 fee when the rule is true.

$50.00 law school application fee

Define the application fee on the Program Application Fees (PAPF) form (similar to the fee illustrated in Figure 90).

Use an AR code rule to (1) determine that an individual is applying to law school and (2) assess the $50.00 fee when the rule is true.

Table 189: Comparing Two Approaches to Defining Application Fee Defaults

Fee Type

Using Academic Level and Academic Program Fee Defaults

Using AR Fee Defaults Only


Ge

Figure 92: Ellucian University’s Set Up for Application Fees


Ge

Procedure for Defining Administrative Fee Defaults

Complete the following steps to define the defaults for all administrative fees.

1. Review “Components of Administrative Fee Defaults” on page 546 and determine how you need to define your fees.

Carefully review the alternative approaches to defining application fee defaults and determine which approach you will use (see “Components of Application Fee Defaults” on page 548).

2. Use the worksheet “Administrative Fee Defaults” on page 624 to map out the defaults for each type of administrative fee.

Use one worksheet each for application fees, enrollment verification fees, and transcript request fees.

3. Go to the AR Fee Defaults (ARFD) form.

The AR Fee Type LookUp prompt is displayed.

4. Enter

• APPL to define the application fee defaults.

• ENRL to define the enrollment verification fee defaults.

• TRAN to define the transcript request fee defaults.

5. Complete the ARFD form for each administrative fee.

Use the worksheets completed in Step 2.

6. Save the fee defaults.

The ARFD form redisplays with the cursor at the AR Fee Type LookUp prompt.

7. Repeat this procedure, beginning with Step 4 for each administrative fee.

8. Go to the Program Application Fees (PAPF) form.

Skip these steps if you do not have application fees that are specific to one or academic program.

Use the worksheet “Academic Program Application Fees” on page 625

9. Define each academic program specific application fee.

10. Go to the Academic Level Application Fees (ALAF) form.

Skip these steps if you do not have application fees that are specific to one or academic level.

Use the worksheet “Academic Level Application Fees” on page 626

11. Define each academic level specific application fee.


Ge

Defining Invoice Due Date Parameters

In This Chapter

This chapter provides information and instruction for calculating various invoice due dates and defining their parameters for your institution in Colleague.

Before You Begin

Before you set up the parameters for calculating an invoice due date you should read the following chapters:

Understanding Invoice Due Date Parameters

Each transaction that results in Colleague posting a charge to an individual’s accounts receivable account is represented by an invoice with an associated invoice due date. You define how Colleague determines the invoice due date through the invoice due date parameters described in this chapter.

The invoice due dates you define through the invoice due date parameter affect all invoices Colleague creates through the Accounts Receivable module, except recurring invoices.

Components of Invoice Due Date Parameters

You define how Colleague calculates an invoice’s due date by one of the following methods:

Table 190: Information You Should Understand Before Defining Invoice Due Date Parameters

Item … Reference …

An understanding of Colleague’s billing terminology


An understanding of how Colleague generates charges


556tting Started with Colleague Student | Defining Invoice Due Date Parameters

Ge

• A set number of days before the billing period start date.

• A set number of days after the billing period start date.

• Invoice due date rules associated with a specific calculation formula.

• A custom subroutine.

Each of these options is described below. Use the Invoice Due Date Parameters (IDDP) form to define the invoice due date parameters.

Figure 93: Example of an Invoice Due Date Parameter

Note: You control the due date for all types of invoices through one set of parameters. If you have different requirements for different invoice types, define those parameters with invoice due date rules or a custom subroutine. Refer to “Calculating the Invoice Due Date Based on Rules” on page 558 and “Calculating the Invoice Due Date Based on a Custom Subroutine” on page 563 for details.

Calculating the Invoice Due Date Based on the Billing Period Start Date

If you base the due date for all invoices on a set number of days either before or after the billing period start date, then you can set the invoice due date parameter as a number of days before or after the billing period start date. For example, if all invoices are due 30


Ge

days after the billing period start date, then enter 30 in the Days After Start field on the Invoice Due Date Parameters (IDDP) form.

If you use a set number of days before or after the billing period start date, keep in mind the following:

• When used alone, the invoice due date settings affect all invoices Colleague generates and serve as the default invoice due date for all miscellaneous invoices you enter manually or through a batch process.

• You can use the Days Before Start field or the Days After Start field, but not both.

• You can use the Days Before Start field or the Days After Start field and the invoice due date rules. When you use both, Colleague first checks all the rules you entered. If no rule is true for a particular invoice, then Colleague calculates the invoice due date based on how you set these fields.

• If you do not the parameters on the Invoice Due Date Parameters form, then Colleague sets the due date for all invoices as the day you enter the invoice.

• You cannot use a custom subroutine if you use either of these options.

Calculating the Invoice Due Date Based on Rules

If the invoice due date depends on specific factors, such as the type of invoice, or if you have a variety of due dates based on a different invoice dates, then you need to use invoice due date rules along with a special invoice formula to set the invoice due date.

Note: If you cannot express your invoice due date calculations using rules and the invoice due date formulas, then your system administrator must write a custom subroutine that Colleague uses to calculate the invoice due date. Refer to “Calculating the Invoice Due Date Based on a Custom Subroutine” on page 563 for details.

To determine an invoice’s due date, Colleague evaluates each rule against the invoice. When a true rule is found, Colleague calculates the invoice due date based on the formula associated with that rule. If no rules are true for that invoice, Colleague uses the information in the Days Before Start or Days After Start fields to calculate the invoices due date. If you have not entered a value in these fields, the invoice is due immediately.

For example, at Ellucian University (EU) an invoice’s due date depends on the type of charge that the invoice represents. Table 191 lists each type of charge for which Colleague calculates an invoice due date and identifies how EU calculates the due date of each.

Table 191: Ellucian University’s Invoice Due Dates

Type of Charge How Colleague Calculates the Invoice Due Date

Registration Based on the number of days before or after the term start date that the invoice is generated.


Ge

To accommodate each of these various invoice due date calculations, EU’s business office defined rules that determined the type of invoice and associated each rule with the formula that calculates the appropriate invoice due date.

Each entry in the Rule field represents a rule that the business office wrote to identify a specific type of charge. These rules determine the type of charge by looking for a unique

characteristic of that charge in the invoice record.1 For example, to determine if an invoice is for a registration charge, the business office defined a rule that looks for a value in the registration posting field of the invoice. The registration posting field (INV.REG.AR.POSTINGS) contains the ID of a record in the REG.AR.POSTINGS file, which represents an individual’s registration charges. Colleague uses this field to link an invoice with a registration charge.

Table 192 lists each type of charge and the rule that the business office wrote to identify the charge from the invoice record.

Room 30 days after the start of the room assignment start date, unless the invoice is generated after the room assignment start date, and then the invoice is due immediately.

Meal Plan 30 days after the start of the meal plan assignment, unless the invoice is generated after the meal plan assignment start date, and then the invoice is due immediately.

Sponsored Accounts 30 days after the start of the term.

Application Fees Immediately.

Miscellaneous Immediately unless it is a book store charge, in which case it is due 30 days after the charge is incurred.

1.An invoice due date formula rule must use the AR.INVOICES file as the primary file view. See “Procedure for Defining Invoice Due Date Rules” on page 560 and “Understanding the Rules Processor” on page 309 for more information about primary files and defining rules.

Table 192: Ellucian University’s Invoice Due Date Rules

Type of Charge Rule

Registration with INV.REG.AR.POSTING NE ‘ ’

Room WITH INV.ROOM.AR.POSTING NE ‘ ’

Meal Plan WITH INV.MEAL.AR.POSTING NE ‘ ’

Sponsored Accounts WITH AR.TYPE EQ ‘SPREC,’ where SPREC is the AR type that describes a sponsor receivable.

Table 191: Ellucian University’s Invoice Due Dates (continued)

Type of Charge How Colleague Calculates the Invoice Due Date


Ge

Procedure for Defining Invoice Due Date Rules

Complete the following steps to define invoice due date rules.




Note: The data elements you use must be from the AR.INVOICES file. See “Understanding the Rules Processor” on page 309 for more information about primary views.


3. Go to the Invoice Due Date Parameters (IDDP) form.

4. Go to the Rule field.

5. Enter the name of each allocation rule.


If the name of the rule displays and the cursor moves to the Due Date Formula field, continue with Step 8.

6. Define the rule.


The IDDP form is redisplayed with the cursor at the Due Date Formula field.

8. Enter the name of the invoice due date formula Colleague uses when the associate rule is true.

If you have not defined the invoice due date formula, the Invoice Due Date formula (IDDF) form is displayed.

See “Components of an Invoice Due Date Formula” on page 561.

9. Repeat this procedure beginning with Step 5 for each invoice due date rule.

Application Fees WITH INVI.AR.CODE EQ ‘APPL’, where INVI.AR.CODE is the AR code stored with the detail of the invoice in the AR.INVOICE.ITEMS file. Because the invoice and invoice item records are linked, Colleague can “find” the data in the invoice item record from the invoice.

Miscellaneous WITH INVI.AR.CODE EQ ‘BOOK’. Because book store charges are the only miscellaneous charge that EU calculates an invoice due date for, this rule only looks for those charges.

Table 192: Ellucian University’s Invoice Due Date Rules (continued)

Type of Charge Rule


Ge

10. Save the invoice due date parameters.

Components of an Invoice Due Date Formula

You associate each invoice due date rule with an invoice due date formula. Colleague uses this formula to determine an invoice’s due date. You define invoice due date formulas on the Invoice Due Date Formula (IDDF) form (Figure 94).

Figure 94: Example of an Invoice Due Date Formula

The following key components of an invoice due date formula are described below:

• Base Date

• Days Before (or After) Base group

Refer to the online help for the Invoice Due Date Formula (IDDF) form for information about the fields not described here.

Base Date. The Base Date field identifies the date Colleague uses as the basis for calculating an invoice’s due date. You indicate the date in terms of a data element from the Colleague database. The data element you use must be

• A date field

• Accessible from the AR.INVOICES file

• Defined in the runtime CDD

Examples of fields you might use as the base date include term start date, assignment start date (for room or meal plan billing), or billing period start date.

Days before base group

Days after base group


Ge

See “Understanding the Rules Processor” on page 309 for more information about primary files and the runtime CDD. You may need to work with your system administrator to ensure you select the correct data element for the invoice due date calculation.

Days Before (or After) Base Group. Figure 94 identifies the Days Before Base group and the Days After Base group. You can use either or both of these groups to define the invoice due date formula. Colleague uses formulas associated with the Days Before Base group when the invoice date is less than or equal to the base date. Colleague uses formulas in the Days After Base group when the invoice date is greater than or equal to the base date.

Note: To ensure you do not define overlapping formulas in the two groups, you cannot enter 0 (zero) as a value in the Days After Base group. If you want to define a formula for invoices that are equal to the base date, enter 0 in the Days Before Base group.

In general, Colleague calculates invoice dues dates as follows:

1. Calculates the difference between the invoice date and the base date.

2. If the invoice date is less than or equal to the base date, Colleague calculates the invoice due date using the appropriate formula from the Days Before Base group. The appropriate formula has a value in the Days Before Base field greater than or equal to the difference between the invoice date and the base date.

3. If the invoice date is greater than the base date, Colleague calculates the invoice due date using the appropriate formula from the Days After Base group. The appropriate formula has a value in the Days After Base field greater than or equal to the difference between the invoice date and the base date.

To understand how Colleague uses these fields to calculate an invoice due date, consider the example of an invoice due date formula illustrated in Figure 94. In this example, the base date is the term start date (TERM.START.DATE). Table 193 lists several different example term start dates, invoice dates, and invoice due dates that Colleague would calculate based on the invoice due date formula illustrated in Figure 94.

Table 193: Example Invoice Due Date Calculations from an Invoice Due Date Formula

Invoice DateTerm Start Date (the Base Date)

Calculated Invoice Due Date

7/3/96 8/27/96 Because 7/3/96 is 55 days before the base date, Colleague uses the formula for invoices more than 30 days before the base date.

Using the formula, Colleague calculates the invoice’s due date as the base date less 30 days; therefore, this invoice is due 7/26/96 (7/25/96—exactly 30 days before the base date—is a Sunday).


Ge

Calculating the Invoice Due Date Based on a Custom Subroutine

If you cannot use either the invoice due date formula method or rules to define an invoice due date formula, then you your system administrator must write a custom subroutine that instructs Colleague how to calculate the invoice due date. If you choose to use a custom subroutine, you should realize that:

• You cannot use either the invoice due date formula method or rules with an invoice due date formula subroutine; therefore, the subroutine must cover all invoices that have an invoice due date.

• If the subroutine does not provide an invoice due date, Colleague sets the invoice due date as the invoice date, unless the invoice date is earlier than today’s date, in which case Colleague sets the invoice due date as today’s date.

8/12/96 8/27/96 Because 08/12/96 is 15 days before the base date, Colleague uses the formula for invoices that are more than 5 days before the base date, but less than 30 days before the base date.

Using the formula, Colleague calculates the invoice’s due date as the invoice date plus 5 days; therefore, this invoice is due on 8/17/96.

8/23/96 8/27/96 Because 8/23/96 is 4 days before the base date, Colleague uses the formula for invoices that are more than zero days before the base date, but less than 5 days before the base date.

Using the formula, Colleague calculates the invoice’s due date as the invoice date plus zero; therefore, this invoice is due on 8/23/96.

9/3/96 8/27/96 Because 9/3/96 is 7 days after the base date, Colleague uses the formula for invoices that are less than 999 days after the base date.

Using the formula, Colleague calculates the invoice’s due date as invoice date plus zero; therefore, this invoice is due on 9/3/96.

Table 193: Example Invoice Due Date Calculations from an Invoice Due Date Formula (continued)

Invoice DateTerm Start Date (the Base Date)

Calculated Invoice Due Date


Ge

Enter the name of the subroutine on the IDDP form. See your system administrator for details on defining a custom subroutine for calculating invoice due dates.

Procedure for Defining Invoice Due Date Parameters

Use the Invoice Due Date Parameters (IDDP) form and the Invoice Due Date Formula (IDDF) form to define invoice due date parameters. Read “Understanding Invoice Due Date Parameters” on page 556 to understand how you define invoice due date parameters and formulas.


Ge

Setting Up Miscellaneous Invoice Defaults

In This Chapter

This chapter provides information and instruction on the components of miscellaneous invoice defaults and how to setup the parameters in Colleague.

Before You Begin

Before you can set the parameters for miscellaneous billing, you may need to define the following:

Understanding Miscellaneous Invoice Defaults

Miscellaneous invoices are invoices that you create for charges other than registration, residence hall room rental, or meal plans. The defaults described in this chapter affect all miscellaneous charge or credit invoices you enter.

Components of Miscellaneous Invoice Defaults

Use the AR Miscellaneous Invoice Defaults (ARMD) form to define the defaults for each group of miscellaneous charges and credits (Figure 95).

Table 194: Information Needed for Setting Up Miscellaneous Invoice Defaults

Information Needed1 …

1.Both the default AR types and the default location are optional parameters.

See …

Default AR types for all miscellaneous invoices

“AR Types” on page 159

Default location for all miscellaneous invoices

online help for the Locations (LOCN) form

565tting Started with Colleague Student | Setting Up Miscellaneous Invoice Defaults

Ge

Figure 95: Example AR Miscellaneous Invoice Defaults

Update AR Immediately

The Update AR Immediately field on the AR Miscellaneous Invoice Defaults (ARMD) form determines when Colleague posts miscellaneous charges and credits to accounts receivable. If you enter “Y,” Colleague posts to accounts receivable all charges and credits when you enter them through the Miscellaneous Charges/Credits Invoices (MCRG) form. If you enter “N,” Colleague does not post these charges until you reconcile and post the charges.

Defer Revenue

The Defer Revenue Code indicates how Colleague determines when to defer revenue when the an invoice’s billing period crosses multiple years. Deferred revenue is explained in detail beginning on 464.

Procedure for Setting Up Miscellaneous Billing Parameters

Use the AR Miscellaneous Invoice Defaults (ARMD) form to set your parameters for miscellaneous billing. Refer to “Components of Miscellaneous Invoice Defaults” on page 565 and online help for the ARMD for additional information.

566tting Started with Colleague Student | Setting Up Miscellaneous Invoice Defaults

Ge

Defining Payment Allocation Parameters

In This Chapter

This chapter describes how to define parameters that affect certain aspects of automatic payment allocation (system-allocation), as outlined in Table 195.

This chapter does not describe how to define refund parameters. See “Defining Refund Parameters” on page 579 for information.

Before You Begin

Before you can define these parameters, you should have a thorough understanding of how Colleague system-allocates payments. Refer to the sections in this chapter, as well as Using Accounts Receivable/Cash Receipts for information about automatic payment allocation.

Understanding Payment Allocation Parameters

When you receive and record a payment in Colleague, you have two ways of allocating that payment to charges on an AR account:

• You can manually allocate a payment to one or more specific charges at the invoice level (referred to as “manual allocation”), or at the invoice item level (referred to as “user allocation”).

Table 195: Where to Find Information About Payment Allocation Parameters

For Information About... See...

Defining how invoices are prioritized for payment

“Understanding Invoice Prioritization” on page 568

Defining how non-term payments are allocated

“Understanding Non-Term Payment Allocation” on page 569

Defining whether or not financial aid is allocated to non-term invoices

“Understanding Non-Term Financial Aid Allocation” on page 576

567tting Started with Colleague Student | Defining Payment Allocation Parameters

Ge

• You can let Colleague allocate payments automatically using a set of pre-defined priorities and parameters (referred to as “system-allocation”).

Payments which are manually or user-allocated are never reallocated by Colleague’s payment allocation processes. Payments that are system-allocated by Colleague can be reallocated by Colleague as needed.

This chapter explains certain parameters that affect automatic payment allocation, which are defined on the AR Defaults and Parameters (ARDE) form shown in Figure 96.

Figure 96: AR Defaults and Parameters for Automatic Payment Allocation

Refer to the sections in this chapter for detailed information about defining the payment allocation fields on the ARDE form.

Understanding Invoice Prioritization

When you allow Colleague to allocate payments automatically, it uses a pre-defined hierarchy to determine in which order invoice items get paid. In selecting invoice items to pay, Colleague first examines the priority of the AR code associated with an invoice item. An invoice item with a high AR code priority (for example, a “1” or a “2”) gets paid before an invoice item with a low AR code priority (such as “99”). See “AR Codes” on page 149 for information about setting up AR codes.

Once Colleague has determined which invoice items have the highest AR code priority, it prioritizes the invoice items within an AR code by invoice date order, and applies payments to the oldest invoice items first. After paying those invoice items, if there is any money remaining, Colleague selects the invoice items with the next highest AR code priority, and then pays those invoice items in oldest to newest invoice date order.


Ge

Your institution can choose to have Colleague examine the term start date associated with an invoice item before examining the invoice date. When you select this method, Colleague sorts the invoice items by AR code priority, by oldest to newest term start date (if the invoices have been associated with a term), and then by invoice date order (oldest to newest) within a term.

If your institution uses term-based billing and non-term-based receipting, and chooses to prioritize invoices by term, Colleague applies non-term payments to invoice items from the oldest terms first, provided you allow non-term payments to be allocated to term invoices (see “Understanding Non-Term Payment Allocation” on page 569 for more information). Colleague always allocates term-based payments only to those invoice items with the specified term.

Understanding Non-Term Payment Allocation

When you allow Colleague to allocate payments automatically, you need to designate how non-term payments are system-allocated. For example, you determine whether Colleague can use non-term payments to pay term charges as well as non-term charges, non-term charges only, or a restricted combination of both.

Note: Regardless of how you allow Colleague to system-allocate non-term payments, you can always manually allocate a non-term payment to any type of charge, term or non-term. Additionally, you can transfer non-term payments to individual terms if you want Colleague to system-allocate them to specific term charges. Refer to Using Accounts Receivable & Cash Receipts for information about manual payment allocation and payment term transfers.

In addition to paying individual charges on an account, non-term payments are used by Colleague to create additional payment items to offset debit and credit invoices within terms, across terms, among non-term, and between term and non-term charges, depending on how you define non-term payment allocation. For example, you have a $20 non-term parking fee, a $100 credit in your Fall term, and a $100 charge in your Spring term. If you allow non-term payments to pay all charges (both term and non-term), Colleague would use a $20 non-term payment to pay the $20 parking fee as well as to create additional payment items to offset the Fall credit against the Spring charge in an attempt to create an overall zero balance on the account. If you allow non-term payments to be allocated to non-term charges only, the Fall and Spring balances would remain outstanding, as Colleague would allow payment items to be created to offset non-term debit and credit invoices only.


Ge

Non-term payment allocation affects a number of different Colleague processes. Refer to Table 196 for where to find specific information in this chapter about non-term payment allocation.

Types of Non-Term Payment Allocation

Colleague provides three ways to handle system-allocation of non-term payments at your institution, as explained below. The setting you choose for your institution will have a direct effect on

• Aging reports

• Past due balances

• Printing AR statements

Note: Ellucian strongly recommends that when recording payments for term charges, that you always specify the term on the payment to ensure that your term balances are correctly reflected on your aging reports, past due balances, and AR statements. See Using Accounts Receivable/Cash Receipts for information about entering payments.

Term and Non-Term Allocation

You can choose to have Colleague allocate non-term payments to all charges, both term and non-term. With this method of allocation, Colleague also uses a non-term payment (both system-allocated and user-allocated) to create offsetting payment items in an attempt to balance an account’s debit and credit invoices within terms, across terms, among non-term, and between term and non-term invoices.

Table 196: Processes Affected by Non-Term Payment Allocation

For Information About How Non-Term Payment Allocation... See...

Is defined “Types of Non-Term Payment Allocation” on page 570

Affects cash receipt payments “Non-Term Payment Allocation and Cash Receipt Payments” on page 573

Affects Web payments “Non-Term Payment Allocation and Web Payments” on page 574

Affects zero dollar payments “Non-Term Payment Allocation and Zero Dollar Payments” on page 575

Affects voucher payments “Non-Term Payment Allocation and Refund Voucher Payments” on page 575


Ge

For example, Colleague would use a $20 non-term payment as outlined in Table 197.

Note: If your institution does not specify terms on cash receipt payments, and does not use aging reports, past due balances, or AR statements, you can allow non-term payments to be allocated to both term and non-term charges. This setting will not provide accurate term balances if you are a term-based institution.

Non-Term Allocation Only

You can choose to have Colleague allocate non-term payments to non-term charges only. With this method of allocation, Colleague treats non-term activity, in effect, as a “term” by itself. Colleague also uses a non-term payment (both system-allocated and user-allocated) to create offsetting payment items in an attempt to balance an account’s non-term debit and credit invoices only.

For example, Colleague would use a $20 non-term payment as outlined in Table 198.

Note: If your institution specifies terms on cash receipt payments, and is concerned with term balances, aging reports, past due balances, or AR

Table 197: Allocating Non-Term Payments to Term & Non-Term Charges

Invoice Term Invoice Amount Payment Item Balance

1 non-term 20.00 20.00 0.00

2 02/SP 100.00 100.00 0.00

3 02/FA -100.00 -100.00 0.00

4 non-term 70.00 70.00 0.00

5 non-term -70.00 -70.00 0.00

Payment Item Total 20.00

Table 198: Allocating Non-Term Payments to Non-Term Charges Only


1 non-term 20.00 20.00 0.00

2 02/SP 100.00 -- 100.00

3 02/FA -100.00 -- -100.00

4 non-term 70.00 70.00 0.00

5 non-term -70.00 -70.00 0.00



Ge

statements, Ellucian recommends that you define non-term payments to be allocated to non-term charges only. This setting will provide the most accurate term balances for term-based institutions.

Restricted Allocation

In some cases, you may have a non-term payment which is fully user-allocated at the invoice or invoice item level, and fully pays off one or more non-term invoices. For example, a $20 payment is user-allocated to a $20 invoice, or to two $10 invoices. You can choose to restrict how Colleague uses such a non-term payment, while still allowing other non-term payments to pay all charges, both term and non-term.

Restricted allocation allows a term-based institution to user-allocate such non-term payments without affecting term balances. Your institution may have certain charges, such as parking fines, application fees, transcript fees, graduation fees, etc., that are recorded as non-term charges and can only be paid by non-term payments. If you do not want Colleague to allocate this type of payment to pay term charges and affect term balances, you need to manually allocate it at the time of receipt to the specific non-term invoice(s) at the invoice or invoice-item level. Refer to Using Accounts Receivable/Cash Receipts for information about allocating payments manually.

Any payment that is not user-allocated to, and fully-paying non-term invoices would be eligible for allocation to all charges, including term invoice items and thus affecting term balances.

For example, Colleague would use a $20 non-term fully user-allocated payment as outlined in Table 199 (and would use other non-term payments as outlined in Table 200). In addition to fully paying the $20 parking fee, this attempt at balancing creates non-term payment items to offset only non-term debit and credit invoices.

Note: If your institution specifies terms on most transactions (invoices and payments), but still has a need for some non-term invoices that require non-term payments (for example, parking fines, application fees, transcript fees, graduation fees, etc.), Ellucian recommends that you use restricted non-term allocation. This setting will limit the use of restricted non-term payments to create offsetting payment items for non-term debit and credit invoices only; non-restricted non-term payments (both system-

Table 199: Allocating Restricted Non-Term Payments


1 non-term 20.00 20.00 0.00

2 02/SP 100.00 -- 100.00

3 02/FA -100.00 -- -100.00

4 non-term 70.00 70.00 0.00

5 non-term -70.00 -70.00 0.00



Ge

allocated and user-allocated) would still perform this balancing function for debit and credit invoices within terms, across terms, and between term and non-term invoices.

While restricting the allocation of fully user-allocated non-term payments, Table 200 outlines how Colleague would allocate a $50 non-term payment that is not restricted.

For more detailed information about automatic payment allocation, refer to Using Accounts Receivable & Cash Receipts.

Non-Term Payment Allocation and Cash Receipt Payments

The method of non-term payment allocation you define directly affects any cash receipt payments system-allocated by Colleague when you use the following processes:

• Cash Receipt Entry (CREN) form

• Application Fees Entry (CRAF)

• Batch Cash Receipt Entry (BCRE) form

• Batch Payment Allocation (BPMA) process

• Payment Allocation Adjustment (PAAA) form

• Payment Adjustment Detail (PAJD) form

When you record a payment on the CREN form, and do not manually allocate all of the payment to specific charges on the account, Colleague attempts to system-allocate the unallocated payment amount to outstanding charges on the account, according to how you have defined non-term payment allocation. Whether you manually allocate the payment, or allow it to be system-allocated, Colleague also uses a non-term payment to create additional payment items in an attempt to balance debit and credit invoices according to how you have defined non-term payment allocation.

When you record a payment on the CRAF form, Colleague allocates it to the fee being paid, but marks it as “user-allocated” so that it cannot be reallocated by Colleague’s

Table 200: Allocating Non-Restricted Non-Term Payments


1 non-term 70.00 50.00 20.00

2 02/SP 100.00 100.00 0.00

3 02/FA -100.00 -100.00 0.00

4 non-term 70.00 70.00 0.00

5 non-term -70.00 -70.00 0.00



Ge

payment allocation processes. However, if you use the “Restricted” method of non-term payment allocation, Colleague will use such a payment to offset non-term debit and credit invoices only. If you use either of the other two methods of non-term payment allocation, Colleague uses a CRAF payment as it would any other non-term payment to offset debit and credit invoices.

Payments recorded on BCRE cannot be manually allocated at the time you record them and, as such, are subject to system-allocation by Colleague. Colleague also uses any non-term payment recorded with BCRE to attempt to create additional payment items to balance debit and credit invoices according to how you have defined non-term payment allocation.

Note: If you record non-term payments on CREN or BCRE that were intended to pay both term and non-term charges, but have defined non-term payments to only pay non-term charges, Colleague will not allocate such payments to any outstanding term charges. This could create a non-term credit balance on an account, even though the account holder may have a term debit balance. You can, however, transfer payments to other terms or non-term as needed using Colleague’s payment term transfer processes. Refer to Using Accounts Receivable & Cash Receipts for more information.

When you record payment adjustments on the PAAA or PAJD form, Colleague attempts to system-allocate or reallocate any unallocated payment amount to outstanding charges on the account. Similarly, if you define the parameter on ARDE to allow non-term payments to pay only non-term charges, Colleague will not system-allocate a non-term payment to term charges when making payment adjustments, even though such charges may be displayed as outstanding on the PAAA or PAJD form. You can, however, manually allocate or reallocate a non-term payment to specific term charges on either the PAAA or PAJD form. Colleague also uses any non-term payment adjusted on PAAA or PAJD to create additional payment items in an attempt to balance debit and credit invoices according to how you have defined non-term payment allocation.

Refer to Using Accounts Receivable/Cash Receipts for detailed information about recording, allocating, and adjusting cash receipt payments.

Non-Term Payment Allocation and Web Payments

If your institution accepts payments using Colleague’s WebAdvisor Make a Payment form, you need to take non-term payment allocation into consideration when you set up the Financial Web Parameters (FIWP) form. On FIWP, you define whether to display charges and accept payments by term. If you choose to accept Web payments by term, Colleague assigns the appropriate term to the Web payment that corresponds with the charge or charges being paid or, in the case of paying non-term charges, creates a non-term payment.

You can also choose to have Colleague display all charges on the Make a Payment form (both term and non-term) as one amount. In this case, Colleague creates a single, non-term payment for the amount being paid via the Web. However, if you have defined non-term payments to be allocated to non-term charges only, a non-term payment received via the Web will never pay any term charges included in the Make a Payment balance.


Ge

If you set the Payments by Term parameter on the Financial Web Parameters (FIWP) form to “No” (creating only non-term payments), and you attempt to define the Apply Non-term Payments to Term Invoices on the AR Defaults and Parameters (ARDE) form to “No,” Colleague issues the following warning:

WARNING: ARDE and FIWP payment flags are in conflict.

Colleague also issues this warning if you set the flag on FIWP in conflict with the flag on ARDE. Colleague does not issue this warning if you set the FIWP flag to “No” and the ARDE flag to “Yes” or “Restricted,” both of which allow non-term payments to be allocated to term charges.

Note: Ellucian strongly recommends that if you do not accept payments by term on WebAdvisor’s Make a Payment page, that you define non-term payments to be allocated to both term and non-term charges (ARDE flag “Yes” or “Restricted”). If you ignore the warning above, you will need to transfer Web payments to the appropriate term(s) to pay term charges.

Refer to “Apply Non-Term Payments to Term Invoices” on page 577 for detailed information about the non-term payment allocation flag. See Using Accounts Receivable & Cash Receipts for information on transferring payments. Refer to WebAdvisor Installation and Administration for detailed information about defining Web parameters.

Non-Term Payment Allocation and Zero Dollar Payments

How you define non-term payment allocation has a direct effect on the need to create zero dollar payments on an account. Zero dollar payments are sometimes needed to enable system-allocation on an account, and are created using the Create Zero Dollar Payments (CZDP) process.

System-allocation cannot take place when an account does not have an eligible payment to allocate. For example, an account may have a $100 debit and a $100 credit in the Fall term that offset each other. However, the account does not have a Fall payment, or a non-term payment, that can be used for creating the necessary payment items to pay off each invoice. When this situation occurs, creating a zero dollar payment on the account enables system-allocation to create the necessary payment items to offset the debit against the credit, and reduces the past due balance.

CZDP creates either non-term or term related zero dollar payments, depending on how you define the Create Zero Dollar Payment by Term parameter when you run the CZDP process, and on how you define non-term payment allocation. Refer to Using Accounts Receivable & Cash Receipts for detailed information about running CZDP, and for information about how non-term payment allocation affects the need to create zero dollar payments.

Non-Term Payment Allocation and Refund Voucher Payments

Non-term payment allocation directly affects the way that refund voucher payments are allocated. If term balances are an important consideration at your institution, how you


Ge

define non-term payment allocation along with how you create refund vouchers will have a direct effect on your term balances.

If you are a term-based institution (most charges and payments have terms), any refund vouchers you create should include the appropriate term. Otherwise, if you have decided that non-term payments cannot be allocated to term charges, and you create a refund voucher without a term, the resulting voucher payment(s) will never be allocated to the term-related balance you want to refund. The overall account balance will be affected, but the term credit balance will not.

If your institution is not term-based or concerned with term balances, non-term payment allocation will have no effect on any refund voucher payments you create.

Refer to Using Accounts Receivable & Cash Receipts for detailed information about creating refund vouchers.

Understanding Non-Term Financial Aid Allocation

When you transmit financial aid payments to accounts receivable, you can determine whether or not financial aid award(s) for the award period(s) being transmitted can be allocated to non-term invoices that fall within the award period(s).

Colleague uses the setting you define when immediate financial aid transmittals occur, as well as when financial aid is transmitted using the Batch FA Transmittal Register (FATR/FATP) process.

If you choose not to pay non-term invoices, Colleague will only pay eligible invoices that have terms within the financial aid award period(s) being transmitted.

For example, if your award period covers the Fall academic term, any eligible non-term charges incurred between the start and end dates of the Fall term would not be paid by financial aid.

If you choose to pay non-term invoices, Colleague will allocate financial aid awards to any eligible non-term invoices with an invoice date that falls within the award period(s), as well as to any eligible term invoices.

For example, if your award period covers the Fall academic term, any eligible non-term charges incurred between the start and end dates of the Fall term would be paid by financial aid, in addition to any eligible Fall term charges.

Procedure for Setting Up Payment Allocation Parameters

Use the AR Defaults and Parameters (ARDE) form to define the parameters that affect automatic payment allocation, as shown in Figure 97.


Ge

Figure 97: Example of Payment Allocation Parameters

Prioritize Invoices by Term

The Prioritize Invoices by Term field determines how Colleague sorts invoice items for payment within an AR code. Set the flag to one of the settings described below.

• Yes. Colleague first orders the invoice items from oldest to newest term start date, and within a term, by oldest to newest invoice date within an AR code

• No. Colleague orders invoice items for payment by oldest to newest invoice date within an AR code

Apply Non-Term Payments to Term Invoices

The Apply Non-term Payments to Term Invoices field determines how non-term payments are allocated. Set this flag to one of the settings described below.

• Yes (the default value). Allows a non-term payment to be system-allocated to both term and non-term charges. Setting this flag to “Yes” will also allow Colleague to use a non-term payment to create offsetting payment items in an attempt to balance an account’s debit and credit invoices within terms, across terms, among non-term, and between term and non-term charges. This setting may not provide accurate term balances if you are a term-based institution. See “Term and Non-Term Allocation” on page 570.

• No. Allows a non-term payment to be system-allocated to non-term charges only. Setting this flag to “No” will allow Colleague to use a non-term payment to create offsetting payment items for non-term debit and credit invoices only and, in effect, treats non-term activity as a “term” by itself. This setting will provide the most accurate term balances for term-based institutions. See “Non-Term Allocation Only” on page 571.

Payment Allocation Parameters


Ge

Note: Although Colleague will not system-allocate a non-term payment to a term charge, you can still manually allocate non-term payments to term charges. Or, you can transfer a non-term payment to a specific term using Colleague’ payment term transfer processes. See Using Accounts Receivable & Cash Receipts for information about manual payment allocation and payment term transfers.

• Restricted. Allows a fully user-allocated non-term payment (where the entire payment amount is user-allocated at the invoice or invoice item level, and completely pays off one or more non-term invoices) to create offsetting payment items for non-term debit and credit invoices only. Other non-term payments are system-allocated as though this flag were set to “Yes.” This setting will limit the use of restricted non-term payments to create offsetting payment items for non-term debit and credit invoices only; non-restricted non-term payments (both system-allocated and user-allocated) would still perform this balancing function for debit and credit invoices within terms, across terms, among non-term, and between term and non-term invoices. See “Restricted Allocation” on page 572.

Apply Fin Aid to Non-term Invoices

The Apply Fin Aid to Non-term Invoices field determines whether or not financial aid is allocated to non-term charges for the award period. Set this flag to one of the settings described below.

• Yes. Colleague will allocate financial aid awards to any non-term invoices with an invoice date that falls within the award period(s), as well as to any eligible term invoices.

• No. Colleague will only pay eligible invoices that have terms within the financial aid award period(s) being transmitted.


Ge

Defining Refund Parameters

In This Chapter

This chapter describes how to define parameters that affect certain aspects of AR and deposit account refunds, as outlined in Table 201.

Note: If your institution does not accept credit card payments (either through e-commerce or using a side terminal), you will still need to define the refund parameters, as they affect the order in which payments on an account are refunded. For example, your institution may want to refund financial aid payments on an account before other types of payments are refunded, such as cash receipt payments.

This chapter does not describe how to define payment allocation parameters. See “Defining Payment Allocation Parameters” on page 567 for information.

Before You Begin

Before you can define these parameters, you should have a thorough understanding of how Colleague generates AR and deposit refunds. Refer to the sections in this chapter, as well as Using Accounts Receivable & Cash Receipts for detailed information about refunding AR and deposit accounts.

Table 201: Where to Find Information About Credit Card Refunding Parameters

For Information About... See...

Defining the order in which payments on accounts are refunded

“Understanding the Refund Hierarchy” on page 580

Defining the number of days in which

• a credit card payment is considered recent enough to refund back to the credit card

• a financial aid payment is considered to be eligible to refund before other types of payments on an account are refunded

“Understanding Days to Refund” on page 588

Defining a security key to allow AR refunds to exceed an account holder’s credit balance

“Understanding Refund Override Security” on page 590

579tting Started with Colleague Student | Defining Refund Parameters

Ge

Understanding the Refund Hierarchy

Colleague determines the method(s) of payment used to refund an account based on the Refund Hierarchy defined for your institution on the AR Defaults and Parameters (ARDE) form. For all refunds (both term and non-term), Colleague also uses the Days to Refund field on ARDE in determining the method(s) of payment used to refund an account (see “Understanding Days to Refund” on page 588 for additional information about this field).

Figure 98: Defining AR Defaults and Parameters for Refunds

Refer to Table 202 for a list of refund hierarchies your institution may define.

Table 202: Refund Hierarchies Used to Determine the Order of Refunded Payments

Refund Hierarchy Description Reference

LIFO Payments are refunded in reverse chronological order.

“LIFO Refund Hierarchy” on page 581.

FA/LIFO Financial aid payments are refunded in reverse chronological order first, followed by all other payments in reverse chronological order.

“FA/LIFO Refund Hierarchy” on page 583.

CC/LIFO Credit card payments are refunded in reverse chronological order first, followed by all other payments in reverse chronological order.

“CC/LIFO Refund Hierarchy” on page 584.

Refund Hierarchy field determines the order in which account payments are refunded

Days to Refund field helps determine the method(s) of payment used to refund an account


Ge

Depending on the Refund Hierarchy defined on ARDE, along with the payments determined eligible to be refunded for an account holder, Colleague may generate the following type(s) of voucher for a refund:

• Single check voucher

• Single check voucher and single credit card voucher

• Single check voucher and multiple credit card vouchers

• Single credit card voucher

• Multiple credit card vouchers

When Colleague generates more than one voucher for a single refund, each voucher is considered part of a related voucher group.

Refer to Using Accounts Receivable & Cash Receipts for additional information about how Colleague determines what vouchers are generated for a refund.

LIFO Refund Hierarchy

LIFO (Last In, First Out) refunds eligible payments in reverse chronological order, meaning that the most recent eligible payment (of any type) is refunded first, then the next most recent, and so on.

Note: The LIFO refund hierarchy refunds eligible AR or deposit payments in the same manner, depending on whether you are processing an AR or a deposit refund.

If the most recent payment eligible to be refunded comes from a cash receipt with one or more credit card pay methods, Colleague generates a credit card voucher for each unique

FA/CC Financial aid payments are refunded in reverse chronological order first, followed by credit card payments in reverse chronological order, followed by all other payments in reverse chronological order.

“FA/CC Refund Hierarchy” on page 585.

CC/FA Credit card payments are refunded in reverse chronological order first, followed by financial aid payments in reverse chronological order, followed by all other payments in reverse chronological order.

“CC/FA Refund Hierarchy” on page 587.

Table 202: Refund Hierarchies Used to Determine the Order of Refunded Payments

Refund Hierarchy Description Reference


Ge

credit card payment transaction that is eligible to be refunded, and/or generates a check voucher for any amount(s) on the cash receipt that cannot be refunded by credit card.

If the most recent payment eligible to be refunded cannot be refunded by credit card, Colleague includes that amount on a check voucher. If Colleague needs to refund multiple payments by check, it combines the amounts on a single check voucher.

Colleague continues this process as needed, examining eligible payments in reverse date order, and creating the appropriate type of voucher (check and/or credit card) depending on the payment being refunded, until the total refund amount is paid.

LIFO Refund Example

Using the payment history in Table 203, and 90 Days to Refund, Colleague would order the payments eligible for a $75 refund processed on December 2 as outlined in Table 204.

Note: If processing refunds on December 2, with the Days to Refund field set to 90 days, the Days to Refund would include September 4 through December 2. Payments prior to September 4 would be considered outside the Days to Refund.

Colleague would create 2 refund vouchers for the LIFO refund as follows:

• $65 check voucher combining the following:

• $50 financial aid payment from 10/1

Table 203: Payment History for LIFO Refund

Payment DatePayment Source

Cash Receipt Pay Method Amount

10/1 Financial Aid 50.00

9/10 Cash Receipt Visa 10.00

9/1 Cash Receipt MasterCard 75.00


8/1 Cash Receipt Check 50.00

Table 204: Payment Hierarchy for LIFO Refund





9/1 Cash Receipt MasterCard 1

1.The 9/1 MasterCard payment is not within the 90 Days to Refund, so the amount is refunded by check.

15.00


Ge

• $15 MasterCard payment from 9/1(leaving $60 of the $75 MasterCard payment remaining on the account)

• $10 credit card voucher for Visa payment from 9/10

FA/LIFO Refund Hierarchy

FA/LIFO (Financial Aid/Last In, First Out) refunds eligible financial aid payments in reverse chronological order first, followed by all other payments in reverse chronological order.

Note: The FA/LIFO refund hierarchy processes deposit refunds in the same manner as the LIFO Refund Hierarchy described on 581, as financial aid payments are not eligible for deposit refunds.

Colleague refunds any eligible financial aid payments on an AR account in reverse chronological order first, meaning that the most recent financial aid payment is refunded first, then the next most recent financial aid payment, and so on. Colleague continues to refund financial aid payments until either the total refund amount is paid, or until all eligible financial aid payments have been refunded but the total refund amount has not yet been paid.

If additional payments need to be refunded, Colleague generates any additional refund voucher(s) as needed using the LIFO Refund Hierarchy described on 581.

FA/LIFO Refund Example



Table 205: Payment History for FA/LIFO Refund






9/1 Financial Aid 1

1.The 9/1 financial aid payment is not within the 90 Days to Refund, and is not refunded.

75.00


Ge

Colleague would create 3 refund vouchers for the FA/LIFO refund as follows:

• $50 check voucher for the $50 financial aid payment from 10/1

• $10 credit card voucher for MasterCard payment from 9/10

• $15 credit card voucher for Visa payment from 9/1(leaving $35 of the $50 Visa payment remaining on the account)

CC/LIFO Refund Hierarchy

CC/LIFO (Credit Card/Last In, First Out) refunds eligible payments from cash receipts that were paid with one or more credit card pay methods in reverse chronological order first, followed by all other payments in reverse chronological order.

Note: The CC/LIFO refund hierarchy refunds eligible AR or deposit payments in the same manner, depending on whether you are processing an AR or a deposit account refund.

Colleague refunds any eligible credit card payment transactions from cash receipt payments in reverse chronological order first, meaning that the credit card payment transactions on the most recent cash receipt are refunded first, then the next most recent cash receipt, and so on. Colleague generates a credit card voucher for each unique credit card payment transaction that is eligible to be refunded until either the total refund amount is paid by credit card, or until all eligible credit card payment transactions have been refunded but the total refund amount has not yet been paid.

If additional payments need to be refunded, Colleague generates any additional refund voucher(s) as needed using the LIFO Refund Hierarchy described on 581.

CC/LIFO Refund Example



Table 206: Payment Hierarchy for FA/LIFO Refund







Ge

Colleague would create 2 refund vouchers for the CC/LIFO refund as follows




• $15 check payment from 9/5(leaving $60 of the $75 check payment remaining on the account)

FA/CC Refund Hierarchy

FA/CC (Financial Aid/Credit Card) refunds eligible financial aid payments in reverse chronological order first, followed by eligible payments from cash receipts that were paid with one or more credit card pay methods in reverse chronological order. All other payments are refunded in reverse chronological order.


Colleague refunds any eligible financial aid payments on an AR account in reverse chronological order first, meaning that the most recent financial aid payment is refunded

Table 207: Payment History for CC/LIFO Refund






9/1 Cash Receipt Visa 1

1.The 9/1 Visa payment is not within the 90 Days to Refund, and is not refunded.

50.00

Table 208: Payment Hierarchy for CC/LIFO Refund







Ge

first, then the next most recent financial aid payment, and so on. Colleague continues to refund financial aid payments until either the total refund amount is paid, or until all eligible financial aid payments have been refunded but the total refund amount has not yet been paid.

If additional payments need to be refunded, Colleague generates any additional refund voucher(s) as needed using the CC/LIFO Refund Hierarchy described on 584.

FA/CC Refund Example



Colleague would create 2 refund vouchers for the FA/CC refund as follows:

• $65 check voucher for the following:


• $15 cash payment from 9/10(leaving $10 of the $25 cash payment remaining on the account)

• $10 credit card voucher for Visa payment from 9/5

Table 209: Payment History for FA/CC Refund




9/10 Cash Receipt Cash 25.00


9/1 Financial Aid 1

1.The 9/1 financial aid payment is not within the 90 Days to Refund, and is not refunded.

75.00

Table 210: Payment Hierarchy for FA/CC Refund





9/10 Cash Receipt Cash 15.00


Ge

CC/FA Refund Hierarchy

CC/FA (Credit Card/Financial Aid) refunds eligible payments from cash receipts that were paid with one or more credit card pay methods in reverse chronological order first, followed by eligible financial aid payments in reverse chronological order. All other payments are refunded in reverse chronological order.

Note: The CC/FA refund hierarchy processes deposit refunds in the same manner as the CC/LIFO Refund Hierarchy described on 584, as financial aid payments are not eligible for deposit refunds.

Colleague refunds any eligible credit card payment transactions from cash receipt payments in reverse chronological order first, meaning that the credit card payment transactions on the most recent cash receipt are refunded first, then the next most recent cash receipt, and so on. Colleague generates a credit card voucher for each unique credit card payment transaction that is eligible to be refunded until either the total refund amount is paid by credit card, or until all eligible credit card payment transactions have been refunded but the total refund amount has not yet been paid.

If additional payments need to be refunded, Colleague generates any additional refund voucher(s) as needed using the FA/LIFO Refund Hierarchy described on 583.

CC/FA Refund Example

Note: Using the payment history in Table 211, and 90 Days to Refund, Colleague would order the payments eligible for a $75 refund processed on December 2 as outlined in Table 212.


Table 211: Payment History for CC/FA Refund







9/1 Cash Receipt Visa 1

1.The 9/1 Visa payment is not within the 90 Days to Refund, and is not refunded.

50.00


Ge

Colleague would create 2 refund vouchers for the CC/FA refund as follows:




• $15 check payment from 10/1 (leaving $10 of the $25 check payment remaining on the account)

Understanding Days to Refund

For all refunds (both term and non-term), Colleague uses the Days to Refund to determine which (if any) credit card payments are recent enough to be refunded back to the credit card. If a credit card payment is not recent enough to refund by credit card, Colleague simply refunds the credit card amount by check instead.

Colleague also uses the Days to Refund to determine which (if any) financial aid payments are recent enough to be refunded for the FA/LIFO and FA/CC refund hierarchies, as explained below.

Credit Card Payments

For Clients who accept credit card payments, the Days to Refund is usually established by the agreement you have with your Merchant Account Provider (MAP). For example, your MAP agreement may require that credit card payments must be refunded back to the credit card within a certain number of days. Past that number of days, you are no longer required to refund the credit card.

The Days to Refund also prevents Colleague from refunding a past credit card payment before refunding a more recent payment. For example, a student may have made a payment or deposit by credit card during the first year of enrollment. If the student has only paid by check since then, the Days to Refund would prevent that credit card from being refunded when processing a refund.

Colleague determines the eligible time period for refunding a credit card payment for a refund by subtracting the Days to Refund from the current date.

Table 212: Payment Hierarchy for CC/FA Refund







Ge

Note: Although you may define a refund date when processing a refund, Colleague will always use the current date when determining whether the payment is eligible for refunding.

Colleague then compares that date to the date of the related cash receipt. If the cash receipt date occurs within the Days to Refund date range, Colleague considers the credit card eligible to refund by credit card. For example, if the current date is October 1, and the Days to Refund is 90, a credit card payment from September 1 would be eligible to be refunded back to the credit card, but a credit card payment from April 1 would be refunded by check.

Financial Aid Payments

For Clients who select either the FA/LIFO or FA/CC refund hierarchy, the Days to Refund also affects the financial aid payments eligible to be refunded before Colleague determines if any other payments are eligible to be refunded when processing a refund.

The Days to Refund prevents Colleague from refunding an older financial aid payment before refunding another payment that is more recent. For example, a student may have a financial aid payment from the first year of enrollment. If the student has not received any additional financial aid since that first payment, and only has eligible credit card payments since then, the Days to Refund would prevent that financial aid payment from being refunded when processing a refund.

Colleague determines the eligible time period for refunding a financial aid payment for a refund by subtracting the Days to Refund from the current date.

Note: Although you may define a refund date when processing a refund, Colleague will always use the current date when determining whether the payment is eligible for refunding.

Colleague then compares that date to the transmittal date of the financial aid payment. If the financial aid transmittal date occurs within the Days to Refund date range, Colleague considers the financial aid payment eligible to refund. For example, if the current date is October 1, and the Days to Refund is 90, a financial payment transmitted on September 1 would be eligible to be refunded, but a financial aid payment transmitted on April 1 would not.

If the financial aid payments on an account are not within the Days to Refund, Colleague looks at payments in the next level of the refund hierarchy to determine the payments eligible to be refunded as follows:

• FA/LIFO - When a financial aid payment is not within the Days to Refund, Colleague determines the most recent payment(s) on the account eligible to be refunded (for example, check, cash, credit card, etc.).

• FA/CC - When a financial aid payment is not within the Days to Refund, Colleague determines the most recent credit card payment(s) on the account eligible to be refunded. If none exist or are eligible, Colleague then determines the most recent payment(s) on the account eligible to be refunded (for example, check, cash, etc.).


Ge

Understanding Refund Override Security

The refund process for AR accounts is designed to prevent creating a refund on the AR Refund (RFND) form that exceeds the credit balance on an AR account, as well as to prevent any refunds for AR accounts that do not have a credit balance.

For example, if an account has a credit balance for $500, Colleague prevents you from refunding the account for any amount over $500. If an account has a debit balance or a zero balance, Colleague prevents you from refunding the account at all.

Colleague allows you to override the credit balance restriction by implementing refund override security. When you implement refund override security, you allow all or selected staff members to refund any amount on the AR Refund (RFND) form, regardless of the account’s balance.

To set up refund override security, you must define a Refund Override Security Key on the AR Defaults and Parameters (ARDE) form. This security key is stored in encrypted format in the AR.DEFAULTS file, however, it is decrypted for viewing on the ARDE form.

Warning! Ellucian strongly recommends that you secure the AR Defaults and Parameters (ARDE) form, whether or not you define a refund override security key. Refer to the Envision Run-Time Administration manual for additional information about setting up Envision security.

After you define the security key on the ARDE form, you must also assign that security key to a security class for refund operators. You can assign the key to an existing security class, or use the security class provided by Colleague specifically for refund overrides: AR.REFUND.OVERRIDE. Authorized operators who have been assigned a security class containing the refund override security key will be able to create refunds that exceed an account holder’s credit balance, as well as to create refunds for accounts that have a debit or zero balance.

If you implement refund override security, unauthorized operators will not be able to complete any refund transaction that exceeds the account credit balance. Colleague provides a field on the RFND form, the Refund Override Login/Password field, that allows an authorized Envision operator ID and password to be entered when an unauthorized operator attempts to create a refund that exceeds the credit balance.

Procedure for Setting Up Refund Parameters

Use the AR Defaults and Parameters (ARDE) form to define the parameters that affect refund processing (Figure 99).


Ge

Figure 99: Example of Refund Parameters

Refund Hierarchy

The Refund Hierarchy field determines the method(s) of payment used to refund an account. Set the flag to one of the settings described below.

• LIFO (Last In/First Out). Payments are refunded in reverse chronological order.

• FA/LIFO (Financial Aid/Last In, First Out). Financial aid payments are refunded in reverse chronological order first, followed by all other payments in reverse chronological order.

• CC/LIFO (Credit Card/Last In, First Out). Credit card payments are refunded in reverse chronological order first, followed by all other payments in reverse chronological order.

• FA/CC (Financial Aid/Credit Card). Financial aid payments are refunded in reverse chronological order first, followed by credit card payments in reverse chronological order, followed by all other payments in reverse chronological order.

• CC/FA (Credit Card/Financial Aid). Credit card payments are refunded in reverse chronological order first, followed by financial aid payments in reverse chronological order, followed by all other payments in reverse chronological order.

Days to Refund

The Days to Refund field determines which (if any) credit card payments are recent enough to be refunded back to the credit card. Days to Refund also determines which (if any) financial aid payments are recent enough to be refunded before Colleague determines if any other payments are eligible to be refunded.

If your institution accepts credit card payments, set this field to the number of days that your Merchant Account Provider requires credit card payments be refunded back to the

Refund Parameters


Ge

credit card. The number of days that you define here will also apply to financial aid payments.

If your institution does not accept credit card payments, and you have selected the FA/LIFO refund hierarchy, set this field to the number of days in which you want financial aid payments refunded before Colleague determines if any other payments are eligible to be refunded.

Refund Override Security Key

The Refund Override Security Key determines whether or not you can process AR refunds that exceed an account holder’s credit balance.

If your institution does not want to allow any refund overrides, leave this field blank — no operators will be allowed to override the credit balance restriction on the RFND form.

If you want to allow refund overrides for some or all operators, enter up to 5 alpha-numeric characters in the Refund Override Security Key field.

Note: If you define a refund override security key, you must also assign the key to a security class used by the authorized refund operators. Refer to the Envision Run-Time Administration manual for information on defining security.


Ge

Assigning GL Posting Descriptions

In This Chapter

This chapter describes how to assign descriptions to the posting records created in the Accounts Receivable and Cash Receipts modules that are subsequently posted to the general ledger.

Note: This functionality is currently available only for invoice and cash receipt transactions, and only when using the “detail” or “no summary” methods of posting transactions to the general ledger.

Before You Begin

Before you begin, you need to determine how your institution (when posting in detail) posts the types of transactions listed in this section to your general ledger accounts. Using the options presented for each transaction type, determine the descriptions appropriate for your methods of posting these transaction types to the general ledger.

Registration Invoices

Valid descriptions for posting registration invoices to GL include:

D – AR Code DescriptionI – Account Holder IDN – Account Holder NameC – Class TitleT – TermRT – 'Registration:' and TermRC – 'Registration:' and Title

Room Assignment Invoices

Valid descriptions for posting room assignment invoices to GL include:

D – AR Code DescriptionI – Account Holder IDN – Account Holder NameH – Hall Title

593tting Started with Colleague Student | Assigning GL Posting Descriptions

Ge

RT – 'Room Assignment' & TitleDT – AR Code Description and Title

Meal Plan Invoices

Valid descriptions for posting meal plan invoices to GL include:

D - AR Code Description I - Account Holder ID N - Account Holder Name M - Meal Plan DescriptionTM - 'Meal Plan:' Plan DescriptionDP - AR code and Plan Description

Miscellaneous Invoices

Valid descriptions for posting miscellaneous invoices to GL include:

D - AR Code Description I - Account Holder ID N - Account Holder Name ID - Invoice DescriptionAD - AR Type DescriptionTD - Invoice Type Description

Sponsored Account Invoices

Valid descriptions for posting sponsor invoices to GL include:

S - Sponsor Name P - Sponsorship Name

Refund Vouchers

Valid descriptions for posting refund vouchers to GL include:

R - Refund Reason Description I - Account Holder ID N - Account Holder Name T - Term RT - 'Refund: ' and Term

Note: Detail posting descriptions are not currently used by Colleague for refund vouchers.


Ge

AR Cash Receipts

Valid descriptions for posting AR cash receipts to GL include:

IN - Account Holder ID & Name I - Account Holder ID N - Account Holder Name RD - Receipt Tender Distribution Code Description PD - Pay Method DescriptionP - PayorPT - Payor and Receipt Tender Distribution Code DescriptionPM - Payor and Payment Method

Non-AR Cash Receipts

Valid descriptions for posting Non-AR cash receipts to GL include:

D - AR Code Description RD - Receipt Tender Distribution Code Description PD - Pay Method DescriptionP - Payor

Cash Deposits

Valid descriptions for posting cash deposits to GL include:

A - Deposit Account Description I - Account Holder ID N - Account Holder Name RD - Receipt Tender Distribution Code DescriptionPD - Pay Method DescriptionP - Payor

Cash Receipt Reversals

Valid descriptions for posting cash receipt reversals to GL include:

I - Account Holder ID R - Reversal Reason P - PayorPR - Payor and Reversal Reason

Financial Aid Transmittals

Valid descriptions for posting financial aid to GL include:


Ge

T - Term FD - FA Award DescriptionFT - FA Award Description and Term

Note: Detail posting descriptions are not currently used by Colleague for financial aid.

Understanding GL Posting Descriptions

When you create transactions (invoices, cash receipts, etc.) in Colleague’s Accounts Receivable (AR) and Cash Receipts (CR) modules, you must also create posting records for those transactions which are subsequently posted to your general ledger using a series of processes outlined in Using Accounts Receivable/Cash Receipts.

Colleague assigns a description along with other types of information (GL account number, amount, etc.) to each GL posting record that you pass to the general ledger. The description that Colleague assigns is determined by the:

• Type of GL posting record being created (invoice, cash receipt, etc.).

• Posting summary method used to create the GL posting records.

If you use any of the summary methods of posting (batch, session, date, or term), Colleague uses the pre-defined GL posting descriptions described in “Using Summary GL Posting Descriptions” on page 596. If you use the “detail” or “no summary” posting summary methods, you can assign the description that Colleague uses for each type of GL posting record as described in “Assigning Detail GL Posting Descriptions” on page 598. See Using Accounts Receivable/Cash Receipts for detailed explanations of the posting summary methods.

Note: If your institution charges tax on any invoice items, Colleague uses the tax code description from the AP.TAXES file as the detail GL posting description regardless of the description assigned for that category of invoice.

Using Summary GL Posting Descriptions

When you use the summary methods of posting to the general ledger, Colleague accumulates and totals the AR or CR transactions by the method that you select (batch, session, date, or term), and creates an individual GL posting record for each total. For example, with cash receipt sessions, Colleague creates a single GL posting record for each cash receipt session selected. While a session can contain multiple cash receipt transactions with multiple types of payments, Colleague can only assign a single description to a GL posting record. Because of this, the descriptions for summarized GL posting records need to somewhat generic in describing the types of transactions.


Ge

Table outlines the posting descriptions Colleague assigns to summarized GL posting records.

Using Default Detail GL Posting Descriptions

When you use the “detail” or “no summary” methods of posting to the general ledger, Colleague creates a single GL posting record for each individual AR or CR transaction selected. For example, for invoices, Colleague creates a single GL posting record for each invoice transaction.

Additionally, Colleague categorizes the type of transaction to determine the posting description that it assigns to the GL posting record. Posting descriptions are stored in separate validation code tables for each category of transaction (registration invoices, cash receipts, financial aid transmittals, etc.). Default posting descriptions have been defined for each category, which Colleague assigns to the GL posting record depending on the type of transaction being posted. For example, if you are posting miscellaneous invoices, Colleague uses the invoice description as the default detail GL posting

Table 213: Summary GL Posting Descriptions

Transaction Type Posting Method Summary GL Posting Descriptions

Invoices Batch AR type description

AR code description(s)

Date AR type description


Term AR type description


Deposits Date AR type description

Deposit type description(s)

Financial Aid Date AR type description

Award type description(s)

Cash Receipts Session “Summary for session XXXX”

*where XXXX is the session number

Date “Summary for date MM/DD/YY”

*where MM/DD/YY is the selected date

Receipt Session Adjustments(Overages)

“Receipt Session Overage”

Receipt Session Adjustments(Shortages)

“Receipt Session Shortage”


Ge

description. You can use the default GL posting description defined for a transaction category, or assign another description from the corresponding validation code table. See “Assigning Detail GL Posting Descriptions” on page 598 for more information.

Table below outlines the default GL posting descriptions and corresponding valcodes that Colleague uses for each category of transaction.

Detail GL posting descriptions display only in Colleague’s Financial System, for example, on the List GL Postings (LPST) report, and also when you run the Post GL Transactions (PGLT) process. They do not display on the GL posting registers generated from Colleague’s AR and CR posting processes, such as Invoice GL Processing (IGLP) and Cash Receipts GL processing (CGLR/CGLP).

Assigning Detail GL Posting Descriptions

If the detail GL posting descriptions assigned as the defaults are not appropriate for your institution, Colleague provides additional descriptions for you to choose from for each transaction category. You can select the option that most closely reflects how your general ledger accounts are set up. For example, if you have separate general ledger accounts for tuition revenue for each class, you may want to select the “Class Title” option as the description assigned to your GL posting records for any registration invoices. Colleague provides different description options for each transaction category, and stores the descriptions for each category in separate validation code tables. See “Before You Begin” on page 593 for a list of the valid descriptions for each category.

Table 214: Default Detail GL Posting Descriptions

Transaction Type Default GL Posting DescriptionColleague Valcode

registration invoices ‘Registration:’ + term RT

room invoices ‘Room Assignment:’ + hall title RT

meal plan invoices ‘Meal Plan:’ + plan description TM

miscellaneous invoices invoice description ID

sponsored accounts invoices

sponsorship name P

refund vouchers refund reason description R

AR cash receipts payor + receipt tender GL distribution code description

PR

non-AR cash receipts payor P

cash deposits account holder name N

cash receipt reversals payor + reversal reason PR

financial aid transmittals FA award description + term DT


Ge

Use the Posting Desc Maintenance (PDSP) form to define the descriptions for each transaction category shown.

Note: Colleague uses the posting descriptions you assign here for both the debit and credit sides of the GL entry.

If you do not assign your own descriptions, Colleague uses the default descriptions listed in Table 214.

Figure 100: Posting Desc Maintenance (PDSP) Form

Note: The descriptions for Refund Vouchers and Financial Aid are not currently used by Colleague.

Overriding Detail GL Posting Descriptions

You can override the detail GL posting description assigned to a transaction category on the Posting Desc Parameter Override (PDPO) form when you create the GL posting records. The PDPO form is accessible as a detail form only from the Invoice GL Posting Process (IGLP) and Cash Receipt GL Register (CGLR) forms. When using the “detail” or “no summary” posting summary method, Colleague allows you to enter an override of a GL posting description by selecting another description from the corresponding validation code table. To access the PDPO form from the GL posting register forms, detail from the Posting Desc field.


Ge

Note: When you enter GL posting description overrides with IGLP, Colleague retains the override values until another operator accesses the IGLP form, or the IGLP process is run in update or immediate update mode. Once either one happens, Colleague refreshes the posting descriptions with the defaults you defined on PDSP. When you enter GL posting description overrides with CGLR, Colleague refreshes the posting descriptions with the defaults each time you access CGLR. If you need to run CGLR multiple times prior to running the Cash Receipt GL Posting (CGLP) process, you need to reenter the override values each time.

If you want to permanently change the descriptions assigned to transaction categories, you need to modify the descriptions on the Posting Desc Maintenance (PDSP) form.

Refer to Using Accounts Receivable/Cash Receipts for more information on creating GL posting records.


Ge

Figure 101: One-Time Override of GL Posting Descriptions

Procedure for Defining GL Posting Descriptions

Complete the steps listed below to define the detail GL posting descriptions used by your institution.

1. Determine the descriptions that you want posted for each category of transaction when posting in detail.


Ge

See “Before You Begin” on page 593.

2. Access the Posting Desc Maintenance (PDSP) form.

The default or previously assigned detail GL posting descriptions are displayed for each transaction category.

Colleague only uses the descriptions assigned here when using the “detail” or “no summary” posting summary methods.

Currently, Colleague uses assigned detail GL posting descriptions only for invoice and cash receipt transactions.

3. Change the description for a transaction category as needed to reflect the way that your institution posts this transaction type to the general ledger.

4. Save your work.


Ge

Accounts Receivable Worksheets

In This Chapter

This chapter provides worksheets that you can use to assist you in setting up the Accounts Receivable module.

Table 215: Worksheets for Setting Up the Accounts Receivable Module

Worksheet Procedure Reference

“Refund Formulas” on page 605 “Understanding Refund Formulas” on page 479

“Registration Refund Policies” on page 606

“Understanding Registration Refund Policies” on page 486

“Registration Charges & Refund Policies” on page 607

“Understanding Registration Refunds” on page 484

“Course & Course Section Registration Refund Policies” on page 608

“Understanding Registration Refunds” on page 484

“Registration Billing Parameters” on page 610

“Registration Billing Defaults and Parameters” on page 466

“Room Billing Parameters” on page 611 “Room Billing and Meal Plan Billing Defaults and Parameters” on page 474

“Meal Plan Billing Parameters” on page 612

“Room Billing and Meal Plan Billing Defaults and Parameters” on page 474

“Registration Rate Billing Fields” on page 613

“Defining Student Billing Characteristics” on page 495

“Tuition Rate Tables” on page 614 “Understanding Tuition Rate Tables” on page 506

“Registration Rate Tables” on page 615 “Defining a Registration Rate Table” on page 515

“Registration Term Rate Tables” on page 616

“Defining Registration Term Rates” on page 518

“AR Add/Drop/Withdraw Policies” on page 617

“Defining Add/Drop/Withdrawal Policies” on page 520

“Tuition Waiver Policies” on page 618 “Defining Tuition Waiver Policies” on page 522

“Tuition Discounts” on page 619 “Defining Tuition Discounts” on page 528

603tting Started with Colleague Student | Accounts Receivable Worksheets

Ge

“Financial Aid Transmittal Parameters” on page 620

“Understanding Financial Aid Transmittal Parameters” on page 542

“Room Rates” on page 621 “Defining Room Rates” on page 533

“Room Rate Tables” on page 622 “Defining Room Rates” on page 533

“Meal Plan Rates” on page 623 “Defining Meal Plan Rates” on page 539

“Administrative Fee Defaults” on page 624 “Understanding Administrative Fees” on page 545

“Academic Program Application Fees” on page 625

“Application Fees Based on Academic Programs” on page 549

“Academic Level Application Fees” on page 626

“Application Fees Based on Academic Levels” on page 549

“Invoice Due Date Parameters” on page 627

“Components of Invoice Due Date Parameters” on page 556

“Invoice Due Date Formulas” on page 628 “Components of an Invoice Due Date Formula” on page 561

“Miscellaneous Invoice Defaults” on page 629

“Understanding Miscellaneous Invoice Defaults” on page 565

Table 215: Worksheets for Setting Up the Accounts Receivable Module (continued)



Ge

Refund Formulas

Table 216: Refund Formulas Worksheet

Refund Formula Code:

Refund Formula Description:

Count Section Meeting:

Days Excluded:

Days Before Start Refund Percent Cancellation Charge

Days Used Refund Percent Refund Portion Cancellation Charge

Full Unused

Full Unused

Full Unused

Full Unused

Full Unused

Full Unused

Full Unused

Percent Used Refund Percent Refund Portion Cancellation Charge

Full Unused

Full Unused

Full Unused

Full Unused

Full Unused

Full Unused

Full Unused


Ge

Registration Refund Policies

Table 217: Registration Refund Policies Worksheet

Registration Refund Policy Code:

Registration Refund Policy Description:

Default Refund Formula:

Course Rate Rule Refund Formula

Term Rate Rule Refund Formula


Ge

Registration Charges & Refund Policies

Use the following worksheet to identify the registration refund policy that you will use for each type of registration charge.

Table 218: Registration Charges and Refund Policies Worksheet

Registration Charge

Drop Registration Refund Policy

Withdrawal Registration Refund Policy Form

Tuition Tuition Rate Tables (TRTB)

Section Fees Tuition Rate Tables (TRTB)

Other Charges Tuition Rate Tables (TRTB)

Registration Term Rates—default policy


Registration Term Rates—registration refund policy for each charge Registration Term Rate Tables (RTRT)

AR Code:

AR Code:

AR Code:

AR Code:

AR Code:

AR Code:

AR Code:

Registration Term Rates—registration refund policy for each rule-based charge


Rule:

Rule:

Rule:

Rule:

Rule:

Rule:

Rule:


Ge

Course & Course Section Registration Refund Policies

Use the following worksheet to identify the registration refund policies for courses and course sections that are billed based on the course. These registration refund policies are entered on the Course Billing Information (CRSB) and the Section Billing Information (SECB) forms.

Table 219: Course and Course Section Registration Refund Policies Worksheet

Course/Course Section:

Drop Reg Refund Policy

Withdrawal Reg Refund Policy























Ge



















Table 219: Course and Course Section Registration Refund Policies Worksheet


Ge

Registration Billing Parameters

Table 220: Registration Billing Parameters Worksheet

Update AR Immediately?Circle one

Yes No

Cutoff date:

Defer Revenue Codes:Circle one

Start Date End Date Part in Each Year

Wash?Circle one

Yes No

Default AR Type:

AR Type Rule AR Type

Discount Limits

Academic Level Maximum Percent Maximum Amount


Ge

Room Billing Parameters

Table 221: Room Billing Parameters Worksheet


Yes No

Cutoff date:



Default AR Type:



Refund Rule Refund Formula


Ge

Meal Plan Billing Parameters

Table 222: Meal Plan Billing Parameters Worksheet


Yes No

Cutoff date:



Default AR Type:



Refund Rule Refund Formula


Ge

Registration Rate Billing Fields

Table 223: Registration Rate Billing Fields Worksheet

Registration Rate Fields ID: Effective Date:

Field Name Required? Default Value

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No


61

4G

etting Sta

rted with C

olleague S

tudent

|A

ccounts Receivab

le Worksheets

T

red Max Cred Rule

uition Rate Tables

Table 224: Tuition Rate Tables Worksheet

Tuition Rate Table:

Description:

Tuition Drop Registration Refund Policy:

Tuition Withdrawal Registration Refund Policy:

Tuition Forfeit AR Code:

Section Fee AR Code:

Section Fee Drop Registration Refund Policy:

Section Fee Withdrawal Registration Refund Policy:

Section Fee Forfeit AR Code

Other Charges Drop Registration Refund Policy:

Other Charges Withdrawal Registration Refund Policy:

AR Code Amount CR Calc Crs/Cred Min C

Yes No A F E C S

Yes No A F E C S

Yes No A F E C S

Yes No A F E C S

Yes No A F E C S

Yes No A F E C S

Ge


Table 225: Registration Rate Tables Worksheet

Registration Rate Table: Reg Rate Fields:

Description:

Periodic Billing: End Date:

Field Name Required Value

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Yes No

Effective Date Tuition Rates Term Rates Add/Drp/Wdrw Waiver Policy


61

6G

etting Sta

rted with C

olleague S

tudent

|A

ccounts Receivab

le Worksheets

R

Min Cred Max Cred

Rule

ame Reg Refund Policy

egistration Term Rate Tables

Table 226: Registration Term Rate Tables Worksheet

Registration Term Rate Table:

Description:

Default Drop Registration Refund Policy:

Default Withdrawal Registration Refund Policy:

AR Code Amount CR Calc Forft AR Sec/Cred

Yes No A F E C S

Yes No A F E C S

Yes No A F E C S

Yes No A F E C S

Yes No A F E C S

Yes No A F E C S

Yes No A F E C S

Rule AR Code Amount CR Field N

Yes No

Yes No

Yes No

Yes No

Ge

AR Add/Drop/Withdraw Policies

Table 227: AR Add/Drop/Withdraw Policies Worksheet

AR Add/Drop/Withdraw Policy Code:

Description:

Flat Charge AR Code Amount Per Course?

Yes No

Add Charge Yes No

Drop Charge Yes No

Withdraw Charge Yes No


Use the space below to identify the registration rate tables that will use the AR Add/Drop/Withdraw policy.

Reg Rate Fields ID Reg Rate Table


Ge

Tuition Waiver Policies

Table 228: Tuition Waiver Policies Worksheet

Waiver Policy:

Description:

Waive or Charge?Circle one

Waive Charge

Tuition AR Code:

Maximum number of courses:

Maximum number of credits:

Maximum tuition:

Waived Charge AR Code Waiver AR Code Waived Percent


Ge

Tuition Discounts

Table 229: Tuition Discounts Worksheet

Discount Code:

Description

Discount Amount

Discount Percent

Discount Code:

Description

Discount Amount

Discount Percent

Discount Code:

Description

Discount Amount

Discount Percent

Discount Code:

Description

Discount Amount

Discount Percent


Ge

Financial Aid Transmittal Parameters

Table 230: Financial Aid Transmittal Parameters Worksheet

Immediate Transmittal from Financial Aid

Award Period Start Date End Date

Table 231: Financial Aid Transmittal Parameters Worksheet

Immediate Transmittal During Billing

Award Period Start Date End Date


Ge

Room Rates

Table 232: Room Rates Worksheet

Building: Rate Class:

Usage Type Room Rate Table1

1.Complete the “Room Rate Tables” worksheet for each room rate table you list here.


Ge

Room Rate Tables

Use this worksheet each time you change the rates for this table.

Table 233: Room Rates Tables Worksheet

Room Rate Table:

Description:

Effective Date

Day Rate Week Rate Month Rate Term Rate Year Rate

Default AR Code:


Ge

Meal Plan Rates

You may use this worksheet each time you change the rates of a meal plan as backup history of these changes.

Table 234: Meal Plan Rates Worksheet

Meal Plan:

Rate period (Circle one)

By the meal Daily Weekly Monthly Yearly By term

Effective Date Rate

AR Code:

Cancel Charges AR Code:


Ge

Administrative Fee Defaults

Table 235: Administrative Fee Defaults Worksheet

Application Fee Type:

Description:

Default AR Type:

Default AR Code:

Default Charge:


AR Code Rule AR Code Charge


Ge

Academic Program Application Fees

Table 236: Academic Program Application Fees Worksheet

AR Code Charge


Ge

Academic Level Application Fees

Table 237: Academic Level Application Fees Worksheet

AR Code Charge


Ge

Invoice Due Date Parameters

Table 238: Invoice Due Date Parameters Worksheet

Days Before Start:

Days After Start:

Rule Due Date Formula

Subroutine:


Ge

Invoice Due Date Formulas

Table 239: Invoice Due Date Formulas Worksheet

Due Date Formula:

Description:

Base Date:

Days Before Base Base + Days Base – Days Invoice Date + Days

Days After Base Base + Days Invoice Date + Days


Ge

Miscellaneous Invoice Defaults

Table 240: Miscellaneous Invoice Defaults Worksheet

Update AR Immediately? (Circle one) Yes No

Deferred Revenue Code:

Default AR Type:

Default Location:


Getting Started with Colleague StudentCampus Organizations

Ge

Setting Up the Campus Organizations Module

In This Chapter

This chapter provides information about the Campus Organizations module and the codes that must be defined.

The Campus Organizations module establishes your campus organizations and organizes them appropriately. With the Campus Organizations module, you can:

• enter and maintain information about organizations, clubs, fraternities, sororities, student or faculty committees, and other campus social groups.

• record the organizational structure of each group, including names of officers and advisors.

• track the purpose of each group and any restrictions on the group or its members.

• track and report on athletes.

• produce membership rosters for each group, including the start and end date for each member.

Campus Organization Codes

To set up the Campus Organizations module, you must define the codes in Table 241.

Table 241: Campus Organization Codes

Codes Needed Reference

Campus organization characteristics 168

Campus organization functions 168

Campus organization groupings 169

Campus organization member statuses

169

Campus organization types 169

Contact roles Getting Started with Colleague Core

631tting Started with Colleague Student | Setting Up the Campus Organizations Module

Ge

There is no other setup required to use the Campus Organizations module. Refer to Using Campus Organizations for information about using this module.

Directory codes Getting Started with Colleague Core

Locations Getting Started with Colleague Core

Mail Rules Getting Started with Colleague Core

Roles 263

Table 241: Campus Organization Codes


632tting Started with Colleague Student | Setting Up the Campus Organizations Module

Cash Receipts

Ge

Setting Up Cash Receipts Defaults and Parameters

In This Chapter

This chapter describes the following parameters and defaults you need to define before using the Cash Receipts module:

• Cash Receipt module parameters

• Cashier setup

• Nonsufficient funds defaults and rules

• E-Commerce defaults and parameters

Before You Begin

Before you define the defaults and parameters for the Cash Receipts module, define the following:

Table 242: Items Needed for Setting Up Cash Receipts Defaults and Parameters

Default/Parameter Items Needed Reference

Cash Receipt parameters Payment method codes See Getting Started with Colleague Core.



Cashier setup AR types “AR Types” on page 159

Deposit types “Deposit Types” on page 181

Location codes Online help for the Locations (LOCN) form

Distribution codes See Getting Started with Colleague Core.

Each cashier defined as a staff member

Use the Staff and Volunteers (SVM) form. See Using Demographics.

635tting Started with Colleague Student | Setting Up Cash Receipts Defaults and Parameters

Ge

Understanding Cash Receipts Module Parameters

Use the Cash Receipts Parameter (CRPA) form to set up the Cash Receipts module parameters.

Figure 102: Example of Cash Receipt Parameters

Controlling When Cash Receipts are Posted to Accounts Receivable

You control when Colleague posts cash receipt payments to accounts receivable with the Update AR Immediately parameter. If you set this parameter to “Yes,” Colleague immediately posts to accounts receivable all transactions you record in a cash receipt session. If you set this parameter to “No,” Colleague does not post transactions you record in a cash receipt session until you reconcile the session.

Nonsufficient funds defaults and rules

AR codes for NSF charges, change returned, and non-AR receipts

“AR Codes” on page 149



Table 242: Items Needed for Setting Up Cash Receipts Defaults and Parameters

Default/Parameter Items Needed Reference


Ge

Note: The setting of the Update AR Immediately parameter affects all cash receipt sessions and serves as the default setting for all cash receipt batches. However, if you set the default parameter to “Yes,” you can change the parameter to “No” for any given cash receipt batch.

See Using Accounts Receivable & Cash Receipts for details on how to process cash receipts.

Defining Electronic Check Processing

If you have implemented Colleague e-Commerce and process checks through your e-commerce provider, define the Use Guaranteed Checks parameter. Set this parameter to “Yes” only if you have already established the necessary accounts with your e-commerce provider and the guaranteed check processor.

Note: Guaranteed check processing is only available through TeleCheck, which requires an e-commerce account with PayPal. If Official Payments is your e-commerce provider, guaranteed check processing is not currently available.

Set this flag to “Yes” if you are implementing guaranteed check processing. Colleague sends each electronic check transaction to your e-commerce provider in the format required for guaranteed check processing.

Set this flag to “No” if you do not use guaranteed checks, or you do not have Colleague e-Commerce implemented at your institution.

Payment Method Rules

You associate each type of payment you accept—for example checks, credit cards, and travelers checks—with a payment method code. When you record a payment, you indicate which payment methods the payer used. For example, a student may pay his tuition bill with a combination of a check and a credit card. When you record that payment, you make an entry for the check and a separate entry—in the same payment transaction—for the credit card.

You can define rules to determine whether you accept that payment method from a specific payer. For example, you can have a rule that evaluates whether a payer has a specific restriction applied. If the rule is true, Colleague accepts a check from that payer.


Ge

Figure 103: Example Payment Method Rule

Procedure for Defining Payment Method Rules

Complete the following steps to define payment method rules.

1. Define your payment methods.

See the Getting Started with Colleague Core manual.

2. .Map out your rules in English-like statements.



Note: The data elements you use must be from the PERSON file. See “Understanding the Rules Processor” on page 309 for more information about primary views.


4. Go to the Cash Receipts Parameter (CRPA) form.

5. Go to the Pay Method field.

6. Enter the payment method code associated with the rule you want to enter.

7. Enter the name of the payment method rule.


Note: If the name of the rule displays, skip to Step 10.


Ge

8. Define the rule.


The CRPA form is redisplayed.

10. Repeat this procedure for each payment method rule you want to define.

11. Save the cash receipt parameters.

Understanding Cashier Parameters

You must set up each individual who processes payments made to your institution with a record in the CASHIERS file. This record defines certain processing defaults and limits that are unique to each individual.

Use the Cashier Setup (CSHS) form to define the defaults and limits for each cashier.

Figure 104: Example Cashier Setup

Processing Limits

The processing limits are optional limits you can place on the type of payment methods a particular cashier can process. The check and credit card limits are transaction-based; each limit applies to a given transaction only. For example, if a cashier has a $9,000 check limit, for one transaction he cannot accept a single check, or a group of checks, for more than $9,000. This cashier could process a $15,000 transaction if the payment method for the transaction is one or more checks totalling no more than $9,000 and cash or credit card for the balance. The same holds true for credit card limits.

Processing Limits

Processing Defaults


Ge

Currency conversion indicates whether or not a cashier can accept foreign currency. If your institution does not deal with foreign currency, accept the default value—No—for this field.

Processing Defaults

To minimize data entry, you can define several default values for each cashier. Colleague uses the defaults that you identify for a cashier whenever the cashier accesses one of the following forms:

• Cash Receipt Entry (CREN)

• Batch Cash Receipts Entry (BRCE)

• Restricted CR Batch Control (RCBC)

You can override any default value you define for an individual cashier on any of the forms where Colleague uses that default (Table 243).

Location

Certain e-commerce transactions require that the city and state in which the transaction originated be sent to the e-commerce provider. If a cashier will be processing e-commerce payments, the cashier’s cash receipt sessions must be associated with a location that has been defined with a city and state.

Note: Use the Locations (LOCN) form in Colleague Core to define city and state information for locations used by e-commerce-enabled cashiers.

If you do not define a location for the cashier here, one must be defined when the cashier opens an e-commerce-enabled session.

This field defaults into the cashier’s cash receipt sessions and any optional batches, and can be changed at the session or batch level.

Table 243: Effect of Overriding Cashier Defaults During Cash Receipts Processing

Form Override Comments

Cash Receipt Entry (CREN) Transaction-level overrides permitted. Each transaction will display the cashier’s default values, regardless of any previous overrideBatch Cash Receipts Entry

(BRCE)

Restricted CR Batch Control (RCBC)

Overrides affect all transactions processed in that batch. However, the cashier may change the defaults defined for any given transaction at the batch level.


Ge

Note: For WebAdvisor clients, you must define a valid location for the Web cashier, as Colleague automatically opens cash receipt sessions for the Web cashier. Ellucian suggests that you use the location where the Web server is physically located, as Web transactions can originate from anywhere.

E-Commerce Enabled

You must define the E-Commerce Enabled flag for all cashiers, whether or not you implement Colleague e-Commerce at your institution. If e-commerce processing is not implemented at your institution, set the E-Commerce Enabled flag on the CSHS form to No. You cannot set this flag to Yes without implementing e-commerce.

If e-commerce is being implemented at your institution, but you are not yet ready to start processing transactions, you can initially set this flag to No, and then set it to Yes after you have completed your e-commerce implementation.

If e-commerce is implemented and a cashier is enabled for e-commerce, a cashier’s cash receipt sessions (and any related batches) will automatically be enabled to process e-commerce payments. E-commerce capability can be disabled for an individual cash receipt session when you open a new session.

On occasion, you may need to enable e-commerce for additional cashiers during certain times (for example, registration), and then remove that capability when the need is over. Or, you may need to disable e-commerce for a cash receipt session, for example, to record a cash receipt necessary to reconcile Colleague payments to your e-commerce provider payments.

This section describes how to enable and disable e-commerce for a cashier or group of cashiers. Refer to Using E-Commerce for information on how to disable e-commerce for individual cash receipt sessions.

Enabling E-Commerce for an Individual Cashier

Use the Cashier Setup (CSHS) form to define e-commerce capability for an individual cashier.

If you set the E-Commerce Enabled field on CSHS to Yes, all cash receipt sessions the cashier opens will be enabled to process e-commerce payments. If you set this flag to Yes, you can still disable e-commerce processing for individual cash receipt sessions opened by the cashier.

If you set the E-Commerce Enabled field to No, the cashier will not be able to process any payments through e-commerce. The cashier will still be able to record payments with e-commerce pay methods, however, they will not be processed through e-commerce for verification.

If e-commerce is not enabled for a cashier, you cannot enable e-commerce for the cashier at the cash receipt session level.


Ge

Note: It is not necessary to define e-commerce capability for the Web cashier. Once you define the Web cashier on the Financial Web Parameters (FIWP) form, the E-Commerce Enabled flag on the CSHS form is automatically set based on what is defined in the Payment Verify Implemented field on the FIWP form, and cannot be changed on the CSHS form.

Enabling E-Commerce for a Group of Cashiers

Use the Set Cashiers' E-Commerce Flag (SCEC) process to set the cashier’s E-Commerce Enabled flag for a group of cashiers.

You may want to use the SCEC process to enable e-commerce for a group of cashiers for a limited time (for example, during registration), and then use the SCEC process again to disable e-commerce for those same cashiers.

Or, you may be in the process of implementing e-commerce and do not want to process e-commerce payments immediately. You can use the SCEC process to enable e-commerce for all or selected cashiers once you are ready to process payments through e-commerce.

Figure 105: Example of Enabling E-Commerce for Group

If you set the E-Commerce Enabled field on the SCEC form to Yes, all cash receipt sessions the cashiers open will be enabled to process e-commerce payments. If you set this flag to Yes, you can still disable e-commerce processing for individual cash receipt sessions opened by the cashiers. Refer to Using E-Commerce for information.

If you set the E-Commerce Enabled field to No, the cashiers will not be able to process any payments through e-commerce. The cashiers will still be able to record payments with


Ge

e-commerce pay methods, however, they will not be processed through e-commerce for verification.

If e-commerce is not enabled for a cashier, you cannot enable e-commerce for the cashier at the cash receipt session level.

Note: It is not necessary to define e-commerce capability for the Web cashier. Once you define the Web cashier on the Financial Web Parameters (FIWP) form, the E-Commerce Enabled flag on the CSHS form is automatically set based on what is defined in the Payment Verify Implemented field on the FIWP form, and cannot be changed with the SCEC process.

The Selection Criteria Fields

You can use the following selection fields on the SCEC form to select or limit the cashiers for which you want to enable or disable e-commerce as follows:

• Saved List Name. To enter a list of the cashiers for which you want to set the E-Commerce Enabled flag.

• Cashiers Included/Excluded. To specify individual cashiers for which you want to set the E-Commerce Enabled flag.

• Locations Included/Excluded. To specify locations of cashiers for which you want to set the E-Commerce Enabled flag.

Check Payer Present

Electronic checks that are processed through the automated clearing house must include information about whether or not the payer is present at the time the check is received as payment. This field defaults to the cashier’s cash receipt sessions and any optional batches, and can be changed at the session, batch, or transaction levels.

Note: Colleague ignores this field when processing electronic check payments through WebAdvisor, or if you have implemented guaranteed check processing.

Understanding Nonsufficient Funds Parameters

When you reverse a payment due to a returned check or credit card, Colleague can assess a charge to the individual for the returned item. This charge is associated with the nonsufficient funds code you define and can be either a flat rate assessment or a rules-based assessment.

Note: If you have implemented Colleague e-Commerce, you cannot use nonsufficient funds rules with credit card payments that were processed


Ge

through e-commerce. You can, however, use nonsufficient funds rules with electronic check payments.

Figure 106: Example Nonsufficient Funds Default and Rule-based Charges

Use the NSF Charge Rules (NSFC) form to define both the default charge and any rule-based charges for returns due to nonsufficient funds. The NSF form is also used to define default AR codes to use when an NSF transaction had change returned or a non-AR receipt.

NSF Charges and Rules

If you charge a fee for returned checks or credit card payments (non-e-commerce credit card payments only), enter the default charge in the Default NSF Charge field and the AR code in the NSF AR Code field. If there are circumstances when you do not assess the default charge, define one or more rules to describe these circumstances and the amount that Colleague charges when the rule is true.

Note: If you do not define rules, or none of the rules evaluate true, Colleague assesses the default charge.

Note: The default charge and rules you define on the NSFC form affect only the charge that Colleague assesses when a check or non-e-commerce credit card payment is returned. These defaults and rules do not determine whether you continue to accept payment from the individual. See “Payment Method Rules” on page 637 for information about how to define rules that determine whether you continue to accept a specific payment method from an individual.


Ge

Change Returned AR Code

Colleague needs to account for any change returned when reversing a cash receipt by creating an invoice on the payer’s receivable account for the amount of change that was returned. When Colleague creates the invoice for the returned change amount, it uses the AR code you define here.

Non-AR Receipt AR Code

Colleague needs to account for any non-AR receipts when reversing a cash receipt by creating an invoice on the payer’s receivable account for the non-AR amounts. When Colleague creates the invoice for the non-AR receipts, it uses the AR code you define here.

Procedure for Defining an NSF Charge Rule

Complete the following steps to define an NSF charge rule.




Note: The data elements you use must be from the PERSON file. See “Understanding the Rules Processor” on page 309 for more information about primary views.




4. Go to the NSF Charge Rules (NSFC) form.

5. Go to the Rules field.

If you have not defined the default NSF AR code and default charge amount, you can define them now.

6. Enter the name of the charge rule.


If the rule is displayed, continue with Step 10.

7. Define the rule.



8. Save the rule.


Ge

The NSFC form is redisplayed.

9. Enter the amount that Colleague charges when the associated rule is true.

10. Repeat this procedure, beginning with Step 6 for each charge rule you want to define.

11. Save the charge rules.

Procedure for Setting Up Cash Receipts Defaults and Parameters

Table 244: Forms Used to Set Up Cash Receipts Parameters

To Set Up … Use …

Cashiers Cashier Setup (CSHS) form

Cash receipt parameters Cash Receipt Parameters (CRPA) form

NSF charge rules NSF Charge Rules (NSFC) form


Ge

Cash Receipts Worksheets

In This Chapter

This chapter provides worksheets that you can use to assist you in setting up the Cash Receipts module.

Table 245: Worksheets for Setting Up the Cash Receipts Module


“Cash Receipt Parameters” on page 648 “Understanding Cash Receipts Module Parameters” on page 636

“Cashier Setup” on page 649 “Understanding Cashier Parameters” on page 639

“Nonsufficient Funds Defaults and Rules” on page 650

“Understanding Nonsufficient Funds Parameters” on page 643

647tting Started with Colleague Student | Cash Receipts Worksheets

Ge

Cash Receipt Parameters

Table 246: Cash Receipt Parameters Worksheet

Update AR Immediately: Yes No

Print Receipt: Yes No

Receipt Print Subr:

Receipt Printer:

Overage GL Account:

Shortage GL Account:

Adj to Cash GL Account:

Use Guaranteed Checks: Yes No

Pay Method Rule


Ge

Cashier Setup

Table 247: Cashier Setup Worksheet

Cashier Staff ID:

Check Limit:

Credit Card Limit:

Currency Conversion: Yes No

Defaults

AR Type:

Deposit Type:

Location:

Distribution:

E-Commerce Enabled: Yes No

Check Payer Present: Yes No

Table 248: Cashier Setup Worksheet

Cashier Staff ID:

Check Limit:

Credit Card Limit:

Currency Conversion: Yes No

Defaults

AR Type:

Deposit Type:

Location:

Distribution:

E-Commerce Enabled: Yes No

Check Payer Present: Yes No


Ge

Nonsufficient Funds Defaults and Rules

Table 249: Nonsufficient Funds Rules Worksheet

NSF AR Code:

Default NSF Charge:

Default AR Type:

Change Returned AR Code:

Non-AR Receipt AR Code:

Rule Charge Amount


Getting Started with Colleague StudentCurriculum Management

Ge

Defining Course Defaults

In This Chapter

This chapter provides information and instruction on course credits, contact hours, and instructional loads. This chapter also provides the procedures you’ll use for defining course defaults for your institution in Colleague.

Before You Begin

Before you define course defaults you should:

Defining Credits, Contact Hours and Instructional Load

Use the Course/Section Defaults (CDEF) form to define the relationship of credits, contact hours and instructional load at your institution.

Table 250: Information Needed Before You Define Course Defaults

Action Reference

Set up the communication codes Using Communications Management

Set up the instructional method codes 235

Set up the registration retake policy codes online help for the Retake Policies (RPOL) form

Set up the section status codes 269

Set up the waitlist rating codes 288

652tting Started with Colleague Student | Defining Course Defaults

Ge

Figure 107: Example of the Course Defaults (CDEF) Form

You should define every possible combination for the various number of credits offered by a single course. For example, if your institution offers one- , two- , and three-credit courses, define the number of contact hours and instructional load that equals each credit.

You can also define subroutines that calculate the course load when a particular instructional method is used. Colleague defaults the load, contact hours and other information calculated by these subroutines into any new courses created or when an instructional method is added or changed for a course. These values default to the course record and can be overridden on the Course Offering Info (COFF) form. The course field values then default to any course sections created from the course. The course section load then defaults to the faculty assignment record on the Faculty Section Assignment (FASC) form, where it can be overridden.

When deciding what the course load should be, Colleague first uses the credit hours/load relation specified in the Credits = and Instructional Load fields on the CDEF form. Next, this Instr Method/Subroutine field is checked; if an entry for a given instructional method is found, the associated subroutine is called to further refine or calculate the load. If neither a credit hours/load relation nor an entry for the instructional method exists, no course load is defaulted.

The Default Delimiter

Colleague uses the delimiter you set as the default to create course and section titles, and to search for existing course and section records. For example, if you set an asterisk (*) as the default delimiter and create a course record for ENG 100, Colleague will read the course name as ENG*100. When you retrieve the course for viewing or maintenance, Colleague will automatically retrieve ENG*100, regardless of which delimiter you use when you perform a lookup on the course ID. If you enter ENG_100, Colleague will ignore the underscore (_) and insert the asterisk as the delimiter, retrieving ENG*100.


Ge

Note: You cannot use a space, a pound sign (#), or a semicolon (;) as delimiters. The space and the pound sign are used by the Degree Audit module for subrequirement specifications and in the program evaluation process. The semicolon is reserved for lookup searches.

If you change the default delimiter once a delimiter is set and has been used, Colleague will not recognize the courses or sections you initially created with the old delimiter. Since the delimiter is stored as part of the CRS.NAME field, if you later change a delimiter, Course LookUp will not find any records created using the old delimiter. Again, regardless of which delimiter you use when you enter the course at the Course LookUp, Colleague will use the default delimiter in its search and may tell you that the course or section does not exist.

Note: You can retrieve the old courses and sections by performing a wildcard lookup. For example, to retrieve ENG*100, you can enter ENG and Colleague will retrieve all courses with English as the subject. You can then select ENG*100 from the list. Colleague will read the course as ENG-100. If you want to accept the new course ID, save the record.

Default Synonym Length

If your institution uses synonyms, you can set the default synonym length to control the synonym numbers. For example, you can enter 3 for the default synonym length. You will then be able to create synonyms from 0 to 999 for your institution’s sections. If you anticipate exceeding the number of synonyms, you can change this value to use higher synonyms.

Defining Course Defaults

When you create a course, you may want to default information into the course record to allow for easier course and section creation.

You can define course default information using the Waitlist Defaults (WLDF) form. All courses you create will inherit the information you enter on the WLDF form, however, you can change the information on each individual course and section record as needed.


Ge

Figure 108: Defining Course Defaults

Allow Course Waitlist Default

This setting determines whether course sections are waitlisted after the course enrollment capacity is reached. The value set here defaults into all courses, but can be overridden at the course and section levels.

Waitlist Rating Default

This setting can be used to enter the code of the waitlist rating criteria to use as the default for courses.

The code you enter here defaults into all courses, but can be overridden at the course and section level. If this field is blank, there is no rating code default for courses.

Required Course Subroutine

This setting can be used to enter the subroutine name to be used to determine if the course is required.

The subroutine name you enter is used by Colleague to determine if a course is required for a student. In waitlist management, you can assign a rating for a course that is required by a student. Colleague uses the subroutine name that you enter in this field to determine if the course for which the student is waiting is required for that student.

If weighting based on required courses is not needed for waitlist management, you may leave this field blank.

Enroll Number of Days Default

This setting can be used to enter the number of days a student has to accept an offer of enrollment from a waitlist.

Course Defaults


Ge

This field will be used as a default to all courses, where it will be used as a default to course restrictions by location and sections. If this field is left blank, there will be no default for courses.

Multiple Sections Default

This setting can be used to allow students to waitlist into multiple sections of the same course.

This field is used to default to courses (on the Course Restrictions [CRES] form) where it is used as a default to course restrictions by location if locations exist (displayed on the Course Restrs by Location [CLRS] form).

Even if students are not allowed to waitlist into multiple sections, a student can waitlist for multiple sections of the same course (and course locations if created for the course) if the sections are in different terms or do not overlap if there is no term.


Getting Started with Colleague StudentDegree Audit

Ge

Defining Synonyms

In This Chapter

This chapter explains how to define the synonyms used by the Degree Audit module.

Understanding Synonyms

The Degree Audit module provides a syntax consisting of keywords for you to use to define your academic programs. If you use other words, you can define the words as synonyms for the keywords using the Degree Audit Synonyms (DASY) form. You may define more than one synonym for a single keyword.

You do not need to define synonyms to use the Degree Audit module. You should, however, review the keywords to understand the terminology.

Figure 109: Example of the Degree Audit Synonyms (DASY) Form

How Colleague Handles Synonyms and Specifications

You can use either the Degree Audit keywords or the synonyms you defined for the keywords to write the specifications for requirements. After you file the specification, Colleague will store the meaning of the specification in its internal table format, not the

Multiple Synonyms for a Single Keyword

658tting Started with Colleague Student | Defining Synonyms

Ge

actual words you used. When you reaccess the subrequirement on the Subrequirement Specification (SRSP) form, Colleague will reconstruct the specifications in its standard format, using its keywords, not the synonyms you used. Although the wording has changed, the meaning of your specification has not changed.

Procedure for Defining Synonyms

Use the DA Synonyms (DASY) form to define synonyms for the keywords provided by the Degree Audit module. Refer to “Understanding Synonyms” on page 658 and online help for guidance.

659tting Started with Colleague Student | Defining Synonyms

Ge

Defining Academic Evaluation Sort Types

In This Chapter

This chapter provides information and instruction on defining sorting methods for evaluating students’ academic activity and determining what requirements they have fulfilled.

Understanding Evaluation Sort Types

You can sort a student’s academic activity for use in evaluating course requisites and academic requirements. The sort method determines the order that courses are matched to requirements. For example, you can create a sort type to apply transfer courses first, then in-house already-graded courses, in-house in-progress courses and finally, in-house preregistered courses during an evaluation. To do so, you would create separate rules for each type of activity on the Rules Definition (RLDE) form and enter each rule in the order you want them evaluated on the AEST form.

You can sort a student's activity into as many groups as you like. Each group is defined by a rule that determines the group's members. Within each group, you can specify up to two subsorts. For more information about defining rules, see “Understanding the Rules Processor” on page 309.

When you define a requirement, you can designate a sort type for the requirement. You do not, however, need to create sort types or access the AEST form to run degree audit.

Ellucian supplies a default sort type named DEFAULT that Colleague will use unless you specify another sort type. The common workflow is, however, to leave a requirement’s sort type unspecified and accept the default.

The DEFAULT sort type sorts courses in the following way:

Table 251: The DEFAULT Sort Type

Category Courses

1 In-house, graded courses.

2 In-house, ungraded courses which are nonetheless considered complete (they have no grade scheme, so they are not expected to ever get a grade).

660tting Started with Colleague Student | Defining Academic Evaluation Sort Types

Ge

If you create your own sort types, or modify the default sort type, you should do so only after you have experience with the Degree Audit module.

Note: You may modify the Ellucian-supplied sort type but you should not delete it.

Use the Academic Evaluation Sort Types (AEST) form to define the evaluation sort methods.

Figure 110: Example of the Academic Evaluation Sort Types

3 Equivalencies (transfer and non-course).

4 In-progress courses.

5 Pre-registered courses.

Table 251: The DEFAULT Sort Type (continued)

Category Courses


Ge

Procedure for Defining Academic Sort Types

Complete the steps listed below to define the academic evaluation sort types used by your institution:

1. Access the Academic Evaluation Sort Types (AEST) form.

2. Enter the sort type name you want to use.

If this is a new sort type, Colleague prompts you to (A)dd it.

3. Enter a rule used to identify the academic activity included in this sort group.

You can access the Rules Definition (RLDE) form from this field to create a new rule, or to modify an existing one.

4. If you want additional sorting within the sort group, enter one or more fields on which to sort the academic activity.

The field you enter must be from the STUDENT.ACAD.CRED file.

5. Repeat steps 3 and 4 for any additional rules.

6. Enter any additional information about this sort type in the Comments field if desired.

From this field, you can access your text editor to enter any comments.

7. Finish from the AEST form.


Ge

Defining Academic Evaluation Defaults

In This Chapter

This chapter provides information and instruction for defining academic evaluation and format default parameters for your institution.

Understanding Academic Evaluation Defaults

Use the Acad Evaluation Defaults (AEDF) form to define some of the parameters associated with the academic evaluation routines. Changing these parameters changes the behavior of the academic evaluation routines and the appearance of the evaluation report.

The AEDF form is divided into three sections. The upper section contains the field that indicates whether program evaluation data is to be stored when an evaluation is run for an include code of A. This must be set to “Yes” if WebAdvisor Smart Registration (Search and Register using Program Evaluation) is to be used.

The middle section contains parameters that can affect the results of the evaluation. Some of these parameters, such as the Extra Course Handling, Use Low Grades, and Wait Until Complete to Merge fields, can be overridden when you specify the academic requirements, and behave as defaults for the person who is defining the requirements. The Include Code and Cutoff Date fields can be overridden at the time an evaluation is requested. They are defaults for the person who is running the evaluation.

The lower section of the AEDF form contains parameters that can be overridden at the time that an evaluation is requested. They help determine the appearance of the report. These parameters are defaults for the person who is running the evaluation.

663tting Started with Colleague Student | Defining Academic Evaluation Defaults

Ge

Figure 111: The Academic Evaluation Defaults (AEDF) Form

Overriding Academic Evaluation Defaults

The academic evaluation default parameters are passed down from the hierarchy (from the defaults defined on the AEDF form to the requirement; from the requirement to the subrequirement; from the subrequirement to the group). You can override this chain of inheritance on every level of the requirement by detailing to the Additional Evaluation Params (AEVP) form. For example, if you override a default (for example, how extra courses are handled) on the subrequirement level, all groups within that subrequirement will inherit the modified value for that parameter.

See Using Degree Audit for information about overriding academic evaluation defaults for a requirement and for information about overriding academic evaluation defaults for a subrequirement and a group.

Storing Evaluations

Enter Yes in the Store Evaluations field if your institution wants to store program evaluation data to disk. Program evaluation data is only stored when using an include code of “A - All (includes planned).”

You must set this field to Yes if your institution will be using the Smart Registration workflow (Search and Register using Program Evaluation).


Ge

Defining Evaluation Parameters

You can define different types of parameters on the Acad Evaluation Defaults (AEDF) form. The parameters you define in the Evaluation Parameters group are alterable. You can override any of these defaults on the individual requirement, subrequirement, or group record. You cannot, however, override the defaults you define on the Format Parameters group for any component of a requirement. You can, however, override the format parameters when you run an evaluation.

Handling Extra Courses

You can determine how extra academic activity is handled in the Extra Course Handling field. The code you enter directs the evaluator how to handle the courses a student took above and beyond what he needed to complete the requirement. Extra course codes include:

• I – Ignore. The evaluator will not count the extra courses toward completion and will not display the extra courses with the block where it is considered extra.

• D – Display. The evaluator will display the course but not count it toward completion of the requirement (do not use the course’s credits toward that requirement’s credit total or GPA).

• S – Semi-Apply. Count the course and ignore the fact that it is “extra” but allow the course to be reused elsewhere.

• A – Apply. Apply the course fully and do not consider any course “extra.”

Note: A null value for this parameter is the same as using the Apply code.

Selecting Courses Based on Grades

When you define a requirement, you can elect to specify a minimum grade the student must achieve for the course to be counted as fulfilling the requirement. The Use Low Grades field allows a grade below the minimum grade specified to be used in calculating the student’s grade point average.

The default value for the field (“Yes”) includes any grade received by the student when calculating the GPA. If you want to include only those grades in the GPA that meet or exceed the minimum grade for the requirement, you can enter “No” in this field.

Defining Merge Methods

You can determine how Colleague merges lists of courses by entering the merge code in the Applied Courses Merging field. The merge method is associated with any academic requirement that is composed of subcomponents, where the student must select some but


Ge

not all of the subcomponents. For example, suppose you have a subrequirement that has its own minimum GPA, and is composed of three subcomponents as follows:

Minimum GPA 3.0

Take 2 of the following 3 groups:

# Take ...

# Take ...

# Take ...

After Colleague has evaluated each of the groups, it moves up to the subrequirement level and merges the list of courses applied to each group into a “list of courses applied to this subrequirement.” After removing duplicate courses, Colleague then uses this list to do the following:

• Calculate a subrequirement level GPA.

• Calculate a total course count for this subreqirement.

• Calculate a total credit count for this subrequirement.

• Serve as a “list of courses applied to me,” which the subrequirement then passes back up the hierarchy (to the requirement level) where it will in turn be merged.

Merge codes determine the answers to the questions “what happens if the student took at least one course from each of the 3 groups?” and “Which of those courses are considered applied to the subrequirement?”

The valid merge codes are:

A – Always merge everything. In this scenario, students can elect to dabble in additional options but, if they do, they risk affecting their higher level GPA.

C – Conditional merge. Merge all lists until it becomes clear which options the student has selected, at which point merge lists only from those options. In the example above, this code behaves just like code “A” until the subrequirement is complete, at which time the incomplete group is no longer merged. This option allows Colleague to calculate an interim GPA (prior to completion of the subrequirement), albeit one which, if the students dabble in options that they do not intend to complete, may not be entirely accurate.

W – Wait. Do not merge any lists until it is clear which options the student has selected. In the example above, we could not calculate a subrequirement-level GPA until two of the groups were complete (or pending). This code is used only when the student has options from among the subcomponents. If the student must complete all subcomponents, then Colleague behaves as if the code is set to “A.” If the above example had read as follows, Colleague would have ignored a code of “W” or “C” and would merge all three lists:

Minimum GPA 3.0

Take all of the following groups:

# Take ...

# Take ...

# Take ...


Ge

Including Courses Based on Completion

You can include or exclude courses from being evaluated based on their completion status. For example, You may only want to include courses that have been completed as of the date an evaluation is run. The options for this field include:

• C – Complete. Only those courses that have been completed as of the day of the evaluation.

• I – In-Progress. All completed courses, and courses currently in-progress (based on the course’s start date).

• R – Registered/Preregistered. Only activities that are complete, already in progress, or preregistered are applicable. (Planned courses are not included, because registration has not occurred for those courses.)

• A – All. Includes all completed courses, planned courses, in-progress courses, and courses in which the student is pre-registered.

• D – Day. Includes completed courses, and in-progress and pre-registered courses anticipated to be complete by a date you specify. If you use this option, you must also enter a date in the Cutoff Date field. You can enter a term in this field, and Colleague defaults term’s end date.

Defining a Cutoff Date

Enter the cutoff date used as a default when an evaluation is done using include code “D.” If the person running the evaluation chooses to include code “D,” then this becomes the default date. This date can be overridden.

If include code “D’” is used, only courses that are complete or anticipated to be complete by the cutoff date are applied to the program.

You may enter either a date or a term in this field. If you enter a term, Colleague replaces it with the term’s end date.

Defining the Preferred E-Mail Type

Use this field to determine which type of e-mail address is displayed on a student program evaluation. If more than one e-mail address is assigned to a student, then selecting a type here ensures that the preferred type is displayed on the evaluation.

If more than one e-mail type is assigned to a student, but the preferred e-mail type is not specified on the AEDF form, then the first e-mail type listed in the PERSON file is used on the evaluation.

If the student does not have an e-mail address assigned, the e-mail will not appear on the evaluation.


Ge

Defining Format Parameters

The parameters you define in the Format Parameters group apply to all evaluations. You cannot override any of these parameters for either a requirement, subrequirement or group. You can, however, override the format parameters when you run an evaluation.

Report Format

You can determine whether evaluations are displayed on the form as either a single column or a double column. If you are planning to print the evaluation, the double-column format is suggested.

Related Courses

You can define how Colleague handles related activity (including course work and noncourse work) using the Related Courses Policy field. Related activity are courses and credits that are not applied to a requirement, but are somehow related to the requirement and may be of interest to an advisor when reviewing the evaluation. For example, for the requirement

Take 10 courses ; from departments MATH, PHYSICS, BIOLOGY, CHEMISTRY ; Maximum 3 courses per department

if a student has taken five math courses, then Colleague will apply only three of the math courses to this particular component of the program. The other two math courses are classified as “related, but not applied.” The type of activity considered related includes courses that were not applied because:

• Doing so would violate a “maximum” (as in the example above).

• Doing so would violate a course-reuse rule.

• The course will not be completed by the evaluation cut-off date.

• The course has been repeated (and thus, replaced).

• The course’s status prevents it from being applied (for example, the status is equal to withdrawn, deleted, dropped or cancelled and that status is not listed in the Ignore Statuses field).

• The course failed the minimum grade check (depending upon the parameter set in the Minimum Grade Processing field).

• The course is considered “extra” and is not required to complete the block (depending on the parameter setting in the Extra Course Handling field).

The available related course codes are:

• T – Together. Display the related courses together with the applied courses.

• F – Footnote. Display the related courses at the bottom of the report in the form of a referenced footnote.

• N – Not displayed. Do not display related courses.


Ge

Ignored Statuses

Use the Ignored Statuses field to record the types of credit statuses you do not want displayed on the evaluation report. Examples of statuses include:

• Cancelled courses

• Withdrawn courses

• Dropped courses

• Deleted courses

• Transfer courses still pending approval

You may only enter statuses that either have a special processing code of 3, 4, 5, or 6, or do not have special processing codes. (Academic credit status codes are stored in the STUDENT.ACAD.CRED.STATUSES record of the ST.VALCODES file. To understand the academic status codes and special processing codes, see the description of the academic status codes in the Purpose field on the Validation Codes (VAL) form. Also, see Using Academic Records.)

This parameter affects only how the evaluation is displayed, not the evaluation. Colleague rejects these types of statuses during an evaluation but considers these types of credits as related courses (that may be of interest to an advisor) and displays them as such. By entering the codes in the Ignored Statuses field, you ensure that these credits are not displayed on the evaluation.

Colleague will not apply credit with statuses equal to deleted, cancelled, withdrawn or dropped to a student’s evaluation. If you do not enter these statuses in the Ignored Statuses field, the evaluator will consider these types of credit as related courses and print them on the evaluation report. If you do not want them printed on the report, enter the types of statuses in this field.

Procedure for Defining Academic Evaluation Defaults

Use the Acad Evaluation Defaults (AEDF) form to customize the behavior of the evaluation routine so that it better matches your institution’s policies and report format preferences. Refer to Understanding Academic Evaluation Defaults and online help for information about the fields on the AEDF form.


Ge

Restricting Additional Valid Requirement Types

In This Chapter

This chapter provides information and instruction for defining your own additional valid requirement types, which help to customize a student’s academic program at your institution.

Understanding Additional Valid Requirement Types

When customizing a student’s academic program, Colleague allows you to add additional components such as CCDs, majors, minors, and specializations. For each one of these components, you can also add standard or custom requirements. You can place restrictions on the type of standard requirements that you can add to an additional CCD, major, minor, or specialization. For example, you can restrict the standard requirements allowed for a CCD to those with a requirement type of “CCD” to avoid applying requirements for majors, minors, and specializations to additional CCDs.

If you choose not to place restrictions on the additional valid requirement types, Colleague allows you to apply any type of requirement to any type of additional component. For example, you could add a major requirement to a CCD, and vice versa.

Use the Additional Valid Requirement Types (AVRT) form to restrict the requirement types allowed for additional CCDs, majors, minors, and specializations.

Note: If you leave the AVRT form blank, as delivered by Ellucian, there are no restrictions placed on the type of requirements that you may add to additional components.

670tting Started with Colleague Student | Restricting Additional Valid Requirement Types

Ge

Figure 112: Defining Additional Valid Requirement Types

Restricting your additional valid requirement types will limit the standard requirements you can choose for an additional component on the Program Evaluation/Customization (PGEC) form.

Procedure for Defining Additional Valid Requirement Types

Complete the steps listed below to define additional valid requirement types.

1. Determine the valid requirement types for each of the following:

• CCDs

• Majors

• Minors

• Specializations

2. Access the Additional Valid Requirement Types (AVRT) form.

3. Enter the valid requirement types as determined in Step 1.

If you do not enter any requirement types, all requirement types are considered valid for CCDs, majors, minors, and specializations.

4. Finish from the AVRT form.

671tting Started with Colleague Student | Restricting Additional Valid Requirement Types

Ge

Defining Custom Paragraphs for the Evaluation Report

In This Chapter

This chapter explains how to define the synonyms used by the Degree Audit module.

Understanding the Evaluation Report Paragraphs

The Degree Audit module provides a mechanism you can use to attach customized paragraphs to the printed evaluation reports for students. Use the DA Custom Paragraphs (DACP) form to write your paragraphs. You can insert custom paragraphs at the top and the bottom of the evaluation report.

Figure 113: Example of the DA Custom Paragraphs (DACP) Form

Each window is composed of one or more PERSON-based rules that are associated to a paragraph. The custom text you insert on a student’s evaluation report is the concatenation of all paragraphs associated to the rules that the individual meets. For example, if you list five rules at the top of the window and a student passes three of those rules, Colleague will insert the three paragraphs associated with those rules at the top of the student’s printed evaluation.

672tting Started with Colleague Student | Defining Custom Paragraphs for the Evaluation Report

Ge

Defining the Custom Paragraph Rules

You may want to attach different text to evaluations of students in different programs. You will, therefore, use a rule to identify the students enrolled in a specific program. For example, you may want to attach text to the evaluations of students enrolled in the accounting program. If the rule you want to use exists, enter the rule in the Custom Block Rules field. If the rule does not exist, you can access the Rules Definition (RLDE) form to create a new rule to use for the custom paragraphs. See “Understanding the Rules Processor” on page 309 for more information about creating rules.

Writing Your Paragraph

You detail to the Define Custom Paragraphs (DPAR) form to write the text you want to print on the evaluation. If you access the DPAR form from the Beginning of Report Paragraph field, the text will print at the top of the evaluation report. Likewise, if you access the DPAR from the End of Report Paragraph field, the text will print at the bottom of the report.

Procedure for Defining Custom Paragraphs for the Evaluation Report

Use the DA Custom Paragraphs (DACP) form to define custom paragraphs to print on student evaluations. Refer to “Understanding the Evaluation Report Paragraphs” on page 672 and online help for guidance.

673tting Started with Colleague Student | Defining Custom Paragraphs for the Evaluation Report

Ge

Degree Audit Worksheets

In This Chapter

This chapter provides worksheets that can be used to assist you in using the Degree Audit module.

Academic Evaluation Defaults

Table 252: Academic Evaluation Defaults Worksheet

Default Parameters

Extra Course Handling

Use Low Grades

Wait Until Complete To Merge

Include

Cutoff Date

Preferred E-Mail Type

Fomat Parameters

Report Format

Related Courses Policy

Ignored Statuses

674tting Started with Colleague Student | Degree Audit Worksheets

Ge

Academic Evaluation Sort Types

Table 253: Academic Evaluation Sort Types Worksheet

Sort Group Rule Subsorts

1. 1

2

2. 1

2

3. 1

2

4. 1

2

5. 1

2

6. 1

2

7. 1

2

8. 1

2

9. 1

2

10. 1

2


Ge

Additional Valid Requirement Types

Table 254: Additional Valid Requirement Types Worksheet

CCDs Majors Minors Specializations


Ge

Synonyms and Keywords

Table 255: Synonyms and Keywords Worksheet

Keyword Synonym


Financial Aid

Ge

Financial Aid File Suites

In This Chapter

This chapter provides information and instructions for creating, updating, and deleting your institution’s financial aid file suites. Table 256 lists the topics covered in this chapter.

Understanding FA File Suite Processing

File Suite Files

The financial aid file suite is a set of files for holding financial aid data for a single academic year. Each file contains a particular type of financial aid data. For example, the Summary Award file contains a summary of award information for each FA applicant.

The FA file suite is delivered as a set of template files. The names of the template files have an ACYR extension; “ACYR” is an abbreviation for “academic year.” Colleague uses the template files to create or update a file suite file, replacing the ACYR extension with


Topic Page

Understanding FA File Suite Processing 680

Maintaining File Suites 685

FA File Suite Files

680tting Started with Colleague Student | Financial Aid File Suites

Ge

the academic year. For example, Colleague uses the Summary Award template file, SA.ACYR, to create a Summary Award file for the 2005/2006 academic year, SA.2005.

The template files contain no data. Financial aid data is stored in the file suite files for a given academic year. For example, Colleague stores student loan information for the 2005/2006 academic year in the Summary Loan file for that academic year, SL.2005, not the Summary Loan template file, SL.ACYR.

Note: Most of the forms in the FA module either prompt you for the academic year, or contain a required field where you enter the academic year on which you are working. This way, Colleague knows which file suite to update.

Table 257 describes the template files in the FA file suite. The record key for each file is noted following the file description.

Table 257: Financial Aid File Suite Template Files

File Name Description

APC.ACYR The Award Packaging Category file contains the award packaging category code information used in automatic packaging. Use the Award Packaging (APAC) form to assign packaging categories to awards. The APC.ACYR file stores one record per packaging category code. Record key – APC.ACYR.ID

ATP.ACYR The Attendance Pattern file contains standard attendance pattern codes for a given year. Use the Attendance Pattern Definition (ATPC) form to maintain the codes. The ATP.ACYR file stores one record per attendance pattern code. Record key – ATP.ID

CI.ACYR The Calculation Input file contains the financial aid application data for a given academic year. Use the FA Calc Input Types (FCIT) form to maintain Calculation Input types. The CI.ACYR file stores one record per student per need analysis calculation type.Record key – CI.STUDENT.ID*CI.CALC.INPUT.TYPE

COMM.ACYR This file stores the text of the comments codes from the Department of Education for a given academic year.Record key – The actual comment code from the Department of Education


Ge

CR.ACYR The Calculation Results file contains the need analysis calculation result types for a given academic year.

Use the Calculations to Execute (NACE) form to identify the calculation input types on which Colleague performs the different need analysis calculations, and to identify which results are produced.

Use the FA Default Definition (FADD) form to identify which calculation results should be used as your defaults.

The CR.ACYR file stores one record per student per need analysis result calculation type.Record key – CR.STUDENT.ID*CR.CALC.RESULT.TYPE

CS.ACYR The Calculation Summary file contains a summary of financial aid application data, calculation results, and calculation result types for a given academic year. There is one record per student. The Summary Calculation Results group on the Individual Need and Budgets (INB) form displays Calculation summary information for a student. The CS.ACYR file stores one record per student.Record key – CS.STUDENT.ID

CSS.ACYR The CSS file contains imported yearly PROFILE data, including calculation results, imported from The College Board. This file is used only by institutions that have licensed Ellucian’s CSS PROFILE Processing module.Record key – CSS.STUDENT.ID

EA.ACYR This file stores unique import fields from EDE or PHEAA input types that are not stored in Colleague input types. Data is stored as one record per student per input type.Record key – EA.ACYR.ID

FA.TERM.USER.ACYR The FA Term User file contains data stored in award-period specific user fields for a given academic year. The FA.TERM.USER.ACYR file stores one record per student per award period. Record key – FTU.KEY

FA.YEARLY.USER.ACYR The FA Yearly User file contains the data stored in year-specific user fields for a given academic year. The FA.YEARLY.USER.ACYR stores one record per student.Record key – FYU.KEY

FBC.ACYR The FA Budget Components file contains the budget components for a given academic year. Use the Budget Component Definition (SBCD) form to maintain Budget components. The FBC.ACYR file stores one record per budget component.Record key – FBC.COMPONENT.ID

Table 257: Financial Aid File Suite Template Files (continued)



Ge

FBH.ACYR The FA Budget History file contains the budget histories for a student for a given year. The FBH.ACYR form stores one record per component per student.Record key – Student ID*FBH.HISTORY.ID

FLPC.ACYR The FLPC file contains award disbursement (loan period) codes. The file is built by the Award Disbursement Code Maintenance (ADCM) form. Each award disbursement code defines award period start and end dates and information about anticipated loan disbursements. Award disbursement codes are used when Pell awards and Direct Lending and CommonLine awards are given to students. The FLPC. ACYR file stores one record per award disbursement code.Record key – FLPC.ID

FUND.OFFICE.ACYR The Fund Office file contains the award fund information for a given office for an academic year. Use the FA Budget By Office (FBBO) form to associate multiple office budgets to an award fund. Use the Office Fund Balance (OFBL) form to associate a single office budget with an award fund. The FUND.OFFICE.ACYR file stores one record per fund per office.Record key – FUNDOFC.FUND.ID*FUNDOFC.OFFICE.ID

LA.ACYR The Loan Application File contains loan application information for a student for a given loan application (Subsidized or Unsubsidized). The LA.ACYR file stores one record per student per loan. The key to this file is a sequence number.Record key – LA.APP.SEQ.NO

MRR.ACYR The Multiple Reporting Record file contains information about multiple institutions that have submitted Pell Origination and Disbursement records. This file contains information that an institution would normally see on a Potential Overpayment Report from the Department of Education.

The MRR file contains Pell Multiple Reporting Record (MRR) information that has been imported from the Department of Education (ED). The MRRs contain data on Potential Overpayment Reports (POPs) from the Department of Education. There is one record per student. Record key – MRR.ID

NSD.ACYR This file contains imported NSLDS data. This file stores only EDE input type data. Data is stored as one record per student per input type. Record key – NSD.ACYR.ID

PALT.ACYR This file stores the Alternate Pell Entitlement Information used to calculate the Alternate Pell Entitlement Schedules for low-tuition students.Record key – PALT.EFC.POSITION*PALT.COA.POSITION




Ge

PELL.ACYR This file contains the Pell disbursement plans for each student. Data is stored as one record per student.Record key – Student ID * PELL.AWARD.ID

PELL.RECON.ACYR The Pell reconciliation file is a summary disbursement file that can be imported for students. It contains the total amount of funds disbursed to the student for the academic year. Data is stored as one record per student per Pell origination ID.Record key – PELL.ORIGINATION.ID

PKA.ACYR The Packaging Award file contains the information for awards used in automatic packaging for a given academic year.Record key – PKA.AWARD.ID

PKGDEF.ACYR The Packaging Definition file contains the packaging definition information used in automatic packaging for a given academic year.Record key – PKGDEF.ID

ROF.ACYR The Return of Funds file contains data that is necessary for a Federal Return of Funds calculation for a given award period. The file contains one record for each award period for a student that has had return of funds calculated for a given award period. Record key – Student ID * Award Period (ROF.STUDENT.ID*AWARD.PERIOD)

RULE.TABLE.ACYR The Rule Table file contains the rule table information for a given academic year.Record key – RT.ID

SA.ACYR The Summary Award file contains a summary of awards for a given academic year. There is one record per student.Record key – SA.STUDENT.ID

SATP.ACYR The Student Attendance Pattern file contains the attendance patterns for each student.Record key – SATP.ID

SL.ACYR The Summary Loan file contains a summary of loans for a given academic year. There is one record per student per loan.Record key – SL.STUDENT.ID*SL.AWARD

TA.ACYR The Term Award file contains the award types for a given award period in a given academic year. There is one record per student per award per award period.Record key – TA.STUDENT.ID*TA.AW.ID*TA.TERM.ID

TC.ACYR The Term Control file contains the award period distribution weights for a given academic year. There is one record per student per award.Record key – TC.STUDENT.ID*TC.AWARD.ID




Ge

Maintaining File Suites

Use the FA File Suite Processing (FFSP) form to create, update, and delete FA file suites. Each time an action is performed, Colleague notes the date of the action and the login of the individual who performed the action.

Figure 114: The FA File Suite Processing (FFSP) Form

VS.ACYR The Verification Summary file contains a summary of verification processing information for a given academic year. There is one record per student.Record key – VS.STUDENT.ID

VSH.ACYR This file stores FA verification history information. There is one record per student.Record key – VSH.ACYR.ID

YS.ACYR The Yearly Summary file contains a summary of miscellaneous information for a given academic year. There is one record per student.Record key – YS.STUDENT.ID




Ge

Noteworthy Fields on the FFSP Form

Suite Year

Enter the academic year of the file suite that you want to process. For example, for the 2005/2006 academic year, enter 2005 in the Suite Year field.

Suite Action

Enter the action to perform on the selected year’s file suite. Select one of the following:

• C – Create a new file suite. You must create a file suite for each academic year before you can enter any financial aid data for that year. When you create a file suite, Colleague copies the files from the file suite template, replacing the ACYR extension with the academic year, and compiles the data dictionary for each file.

• U – Update an existing file suite. Software updates may include new template files, or may add new data elements to an existing template file. Software updates automatically update existing file suites. Use the Update action to copy a new template file into a file suite or to update the data dictionaries for existing files in a file suite.

• D – Delete an existing file suite. When you are certain that you no longer need to maintain financial aid data for a given year, you can delete all files and associated data dictionaries for the file suite.

Note: The Delete action does not back up or store financial aid data. To store financial aid data, please see your Colleague system administrator.

Files to Process

After you enter a year in the Suite Year field, Colleague lists the files in the current file suite template, replacing the ACYR extension with the academic year entered in the Suite Year field. This is a preview listing of the files that will exist in the file suite if you would create a new suite or if you would add new files with the update action. It is not necessarily a list of all the files currently in that year’s file suite.

The Files to Process list is for display only.

Procedure for Maintaining File Suites

Complete the following steps to create, update, or delete a file suite for a given academic year.

1. Access the FA File Suite Processing (FFSP) form.

Colleague displays a list of processed file suites, including the following:

• Suite year

• Status


Ge

• Date of last action

• Login of the user who performed the action

2. In the Suite Year field, enter the academic year of the file suite that you want to process.

In the Files to Process field, Colleague lists the files in the current file suite template. This list shows which files would be built if you create a new file suite, but does not necessarily reflect which files would be updated or deleted if you perform those actions.

For example, for the 2005/2006 academic year, enter 2005.

3. In the Suite Action field, select the action to perform on the file suite.

Enter one of the following codes:

• C – Create

• U – Update

• D – Delete

Note: For more information about these options, see “Suite Action” on page 686.

4. Finish out of the FFSP form.

Colleague displays the Process Handler form.

5. Finish out of the Process Handler form.

If you have created a new file suite:Colleague copies the files from the file suite template, replacing the ACYR extension with the academic year entered in the Suite Year field, and compiles the data dictionary for each file.

If you have updated an existing file suite:If a file does not exist, Colleague copies the file from the file suite template, replacing the ACYR extension with the academic year, and compiles the data dictionary for the file. If a file already exists, Colleague recompiles the data dictionary for the file.

If you have deleted a file suite:Colleague deletes all files and associated data dictionaries for the file suite.


Ge

Financial Aid System Parameters

In This Chapter

In this chapter you will learn how to set up parameters that define whether Financial Aid office staff can add new PERSON records to your database. Table 258 lists the topics covered in this chapter.

Forms Used

Table 259 shows an alphabetical list of the forms used in this chapter and a description of each.

Maintaining FA System Parameters

Use the FA System Parameters (FASP) form to define module-wide parameters for the Financial Aid module.


Topic Page

Maintaining FA System Parameters 688

Table 259: Forms for Processing Financial Aid File Suites

Form Purpose

FA System Parameters (FASP) Define module-wide parameters for the Financial Aid module.

688tting Started with Colleague Student | Financial Aid System Parameters

Ge

Figure 115: The FA System Parameters (FASP) Form

Noteworthy Fields on the FASP Form

Two of the fields on this form are important for initial setup of the FA module. Those fields are described below. Other fields on this form are used to set up specific functions of the module, such as importing ISIR records. Those fields are discussed elsewhere as needed.

Allow New Person Add

You can allow or deny FA office staff the ability to add new people to the Core PERSON file when they use the Financial Aid Application (FAPP) form or the Award Detail Entry (AIDE) form during their daily processing.

If you enter Y in this field, when users perform a Person LookUp on the FAPP or AIDE forms and do not find an existing record, Colleague provides the Add option at the “Record not found” prompt or the Person LookUp resolution form prompt (as shown in Figure 116, below). If you enter N in this field, Colleague does not display the Add option at these prompts.

Note: This field does not control whether the ISIR Import (ISIM) process automatically creates or updates PERSON records when your FA staff imports ISIRs. See Using Financial Aid: Need Analysis for more information about ISIR Import options.


Ge

Figure 116: The Allow New Person Add Prompts

When an FA staff member decides to Add an individual, Colleague displays the Name and Address Entry (NAE) form. After the staff member enters appropriate demographic data and finishes out of the NAE form, Colleague returns to the originating form (that is, the FAPP or AIDE form). When the staff member updates or finishes out of the originating form, then Colleague creates the new PERSON record.

Note: To allow the FA office to perform trial need analysis and awarding for individuals not in the Colleague database, without adding those people to the database, create one or more fictitious records in the PERSON file for use by the FA office. Financial aid staff can reuse these records to perform trial need analysis and awarding.

Create Prospects

Enter Y to create PROSPECT records for individuals at the same time you create new PERSON records. You can set this flag to “Yes” only if the Allow New Person Add field is also set to “Yes.”

Note: The PROSPECTS file is a logical view of prospect-related fields from the APPLICANTS file. The PROSPECTS file can be used for query reports. However, prospect-related fields on Colleague forms reference the APPLICANTS file.

Procedure for Setting Up FA System Parameters

Complete the following steps to set FA system parameters.

1. Access the FA System Parameters (FASP) form.

2. Do you want to enable FA staff members to add PERSON records to the Core system when using the Financial Aid Application (FAPP) or the Award Detail Entry (AIDE) forms?

Enter Y in the Allow New Person Add field. Continue with Step 3.

Enter N in the Allow New Person Add field. Skip to Step 4.

3. When FA staff members add a new PERSON record to the Core system, do you want Colleague to also create a PROSPECT record?

If you set the Allow New Person Add flag to “Yes,” the Add options appear at the “Record


Ge

Enter Y in the Create Prospects field.

Enter N in the Create Prospects field.

4. Save your FA system parameters.


Ge

Financial Aid Defaults

In This Chapter

This chapter provides information and instructions for setting up default values that Colleague displays at various prompts and when processing FA data.

Table 260 lists the topics covered in this chapter.

Before You Begin

Table 261 lists the tasks that must be complete before you can continue with the procedures in this chapter.

Understanding FA Defaults

FA defaults identify the values that Colleague uses at various prompts and when processing FA data, to help minimize data entry.

FA defaults should represent the most common entry for your users at the current time. When working with a particular record, users can override the default as needed. Colleague then uses the override value as the default for the rest of that user’s session.


Topic Page

Understanding FA Defaults 692

Setting Up FA Defaults 696

Table 261: Before You Begin

Task Reference

Create a Financial Aid File Suite for your first FA year.

“Maintaining File Suites” on page 685

692tting Started with Colleague Student | Financial Aid Defaults

Ge

FA defaults change from year to year, even throughout the year. For example, your “current” Award Period probably changes every few months. You can modify an FA default at any time.

Overview of the Setup Procedure

Setting up your FA Defaults consists of the following main tasks:

1. Create an initial award period. Details about this task begin on 693.

2. Enter your default values. Details about this task begin on 695.

Forms Used

Table 262 shows an alphabetical list of the forms used in this section, and a description of each.

Creating an Initial Award Period

This section covers the minimum requirements for creating your first award period. This award period must exist so you can enter it as one of your FA defaults in the next section.

You will finish setting up this award period when you complete the instructions in Using Financial Aid: Awarding and Aid Distribution.

Use the Award Period Definition (AWPD) form to create and maintain award periods.

Table 262: Forms Used in This Section

Form Purpose

Award Period Definition (AWPD) Create and maintain award periods.

FA Default Definition (FADD) Set defaults for the FA module.


Ge

Figure 117: The Award Period Definition (AWPD) Form

To create an award period, you must complete the following fields:

• Description

• Start Date

• End Date

Don’t be concerned if you aren’t sure exactly what to enter in these fields. You will have an opportunity to change these fields before you begin processing financial aid.

Even if some of the other fields on this form appear to be required fields (depending on the user interface installed at your institution), you can skip those fields for now.

Procedure for Creating the Initial Award Period

Perform the following steps to create your initial award period.

1. Access the Award Period Definition (AWPD) form.

2. Complete the following fields:

• Description

• Start Date

• End Date

3. Save your work and exit the AWPD form.


Ge

Maintaining FA Defaults

Use the FA Default Definition (FADD) form to set defaults for the FA module.

Figure 118: The FA Default Definition (FADD) Form

Noteworthy Fields on the FADD Form

Three of the fields on this form are required during initial setup of the FA module. Those fields are discussed in this section. Other fields on this form are used to set up specific functions of the module, such as importing ISIR records. Those fields are discussed elsewhere as needed.

Current Year

This year appears as the default entry whenever users are prompted for the academic year. Because most financial aid information applies to a specific year, users often must select the applicable year when they view or maintain a student’s FA information.

You can enter a year here only if the FA file suite exists for that year. See “Financial Aid File Suites” on page 680 for information and the procedure.

Current Award Period

The current award period appears as the default entry whenever users are prompted for the award period. For example, if your institution is currently in the Fall 2005 semester, you can set that as your default award period.


Ge

You must define the award period before you can enter it in this field. See “Creating an Initial Award Period” on page 693 for information.

Obsolete Fields on the FADD From

The following fields on the FADD form are obsolete as of the 2005/2006 processing year:

• Current Calc Input Type

• Result Type for FC Indicator

• Result Type for Inst FC Indicator

• Result Type for Pell Indicator

Setting Up FA Defaults

Complete the following steps to set up FA defaults.

1. Access the FA Default Definition (FADD) form.

2. In the Current Year field, enter the academic year to appear as the default entry whenever users are prompted for the academic year.

If the academic year you wish to process is not available, see “Understanding FA File Suite Processing” on page 680.

3. In the Current Award Period field, enter the award period code to appear as the default entry whenever users are prompted for the award period.

If the award period you wish to use is not available see “Creating an Initial Award Period” on page 693.

4. In the Current Calc Input Type field, enter the calculation input type code to appear as the default entry whenever users are prompted for the calculation input type.

5. Save your FA defaults.


Ge

FA Office and Location Setup

In This Chapter

In this chapter you will learn how to set up Financial Aid offices and locations.

Before You Begin

Table 264 lists the tasks that must be complete before you can continue with the procedures in this chapter.

Understanding FA Offices and Locations

When a student’s record enters the Financial Aid module (for example, Colleague receives a prospect’s ISIR, or you give a student an initial award), Colleague uses rules to assign that student to an FA location. Each FA location, in turn, is associated with an FA office.


Topic Page

Understanding FA Offices and Locations 697

Setting Up FA Offices 699

Setting Up FA Locations 705

Creating Location Rules 706

Table 264: Before You Begin

Task Reference

Create a file suite See “Maintaining File Suites” on page 685.

Define FA Defaults See “Setting Up FA Defaults” on page 696.

697tting Started with Colleague Student | FA Office and Location Setup

Ge

Every institution must set up at least one financial aid office and one financial aid location. Some multi-campus institutions may need to create multiple FA offices and locations. You must also create at least one location rule to assign students to their appropriate locations.

Your system of offices and locations should mirror the structure that you report to the Department of Education for Pell processing. Set up an FA location for each Pell Attended Campus, and an office for each Pell Reporting Campus.

Following are some of the uses for FA office and location data:

• Institutional data, such as the Reporting and Attended Campus, is included in batches of financial aid data exported from Colleague, for example, Pell and Direct Loan data sent to the Common Origination and Disbursement (COD) system.

• Award fund budgets are stored by FA office.

• Agreement letters and other correspondence with students can include contact information for a specific FA office, which can be a central office or branch campus office.

Note: The procedures in this chapter create your FA office and FA location records, and establish general information about your FA offices, such as addresses and telephone numbers. Instructions for setting up other office-related information, including Loan Defaults and COD Routing IDs, are covered in other books where you set up those specific functions.

Institutional Defaults

To simplify the setup process and help ensure that all FA office information is available when needed, the procedures in this chapter instruct you to enter default information for your institution.

Institutions that need to set up only one FA office will enter all of their information at the institutional default level and create a very basic office record.

Institutions that need to set up multiple FA offices will enter their institutional default information and then override that information as needed in each of their office records. When Colleague needs office information for a student, the process looks to the office record first, and if the specific piece of information does not exist at the office level, Colleague gets the information from the institutional defaults.

Note: The FA location record contains very little information to identify itself (just an Attended Campus Routing ID for the handful of institutions that need it). The main purpose of the FA location record is to link students with their appropriate FA office.


Ge

Forms Used

Table 265 shows an alphabetical list of the forms used in this chapter and a description of each.

Setting Up FA Offices

All institutions must create at least one FA office, their main office. Multi-campus institutions may have multiple FA offices serving branch campuses.

• To set up a main office, see “Procedure for Setting Up Your Main FA Office” on page 703.

• To set up additional FA offices, see “Procedure for Setting Up Additional FA Offices” on page 704.

You will be using the FA Institutional Defaults (FIDF) form and the FA Office Parameters (FAOP) form.

Setting up FA offices requires the following high-level steps.

1. Use the FA Institutional Defaults (FIDF) form to enter default values about your main FA office.

2. Use the FA Office Parameters (FAOP) form to create individual offices, overwriting any default information that does not apply to that office.

Maintaining Institutional Defaults

Use the FA Institutional Defaults (FIDF) form to maintain default office information for use in the Financial Aid module.

Table 265: Forms for Setting Up FA Offices and Locations

Form Purpose

FA Institutional Defaults (FIDF) Maintain institutional defaults for use in the Financial Aid module.

FA Locations Definition (FLCD) Set up FA Locations to represent various locations, such as branch campuses, at your institution.

FA Office Parameters (FAOP) Maintain Financial Aid office parameters.

Location Rule Table (LCRL) Define location rule table IDs for use in assigning locations.


Ge

FA office information appears on agreement letters and other documents. In addition, some of the information is included in data batches exported from Colleague.

Figure 119: The FA Institutional Defaults (FIDF) Form

If you have more than one FA office at your institution, use the FA Office Parameters (FAOP) form to override any of the default information for specific offices. See “Maintaining FA Office Information” on page 702 for details.

Noteworthy Fields on the FIDF Form

Most of the fields on this form contain general information about the Financial Aid operation at your institution, and probably need no further explanation. See online help for more information about any fields not discussed in this section. Keep in mind that the information you enter on this form can be overwritten at the individual office level.

Note: The following fields are not used during initial FA office setup:Loan Defaults. Used when setting up loan processing.COD Defaults. Used when setting up the COD Interface.

FA Office ID

Use this field to detail to the FA Office Parameters (FAOP) form where you will set up your main FA office. This is a required field. If you ever want to change your default FA office, you can delete the contents of this field and enter a different office code.


Ge

Health Prof Prog Type

Enter the Academic Program Type assigned to your Health Professions programs. If you want to automatically allow higher loan limits, use this field.

Verif Tolerance

Enter Y in this field to have Colleague use the original federally flagged ISIR transaction when it has a correction that is within tolerance.

Tolerance is defined on the Pell Entitlement Figures (PEF) form.

Teacher Certification Program Type

Enter the Teacher Certification code in this field.

If you want to increase loan limits (within federal limits) for students in your Teacher Certification programs, enter the Acad(emic) Program Type code for Teacher Certification in this field.

The code you enter in this field must also be entered in the Types field on the Academic Programs (PROG) form for any Academic Programs designated as Teacher Certification programs.

Entering the Teacher Certification code in this field and in the Types field on the Academic Programs for any programs designated as Teacher Certification programs field ensures that any student participating in those programs may receive the higher loan limits during packaging.

If your institution does not have any Teacher Certification programs, leave this field blank.

The Teacher Certification code must be created in the ACAD.PROGRAM.TYPES validation code table on the Validation Codes (VAL) form.

Allowing Higher Loan Limits for Health Professions Students

The Department of Education allows higher loan limits for students in specified Health Professions programs. If your institution offers specified Health Professions programs and needs to allow students in those programs higher loan limits, you must set up Colleague to do so. Colleague offers this functionality, but it is optional and requires a few setup steps. In order to allow higher loan limits for Health Professions students, you must define a Health Professions code in your ACAD.PROGRAM.TYPES validation code, enter the Health Professions code on the FIDF form, and associate the code with each of your Health Professions program. The following procedure takes you through the steps required.


Ge

Procedure for Setting Higher Loan Limits for Health Professions Students

If your institution already has a Health Professions code defined in your ACAD.PROGRAM.TYPES valcode, skip Step 1 through Step 4.

1. Access the Validation Codes (VAL) form in the Student System (ST).

2. Enter ACAD.PROGRAM.TYPES in the LookUp prompt to access the ACAD.PROGRAM.TYPES valcode.

3. Add a code for your Health Professions programs on the VAL form.

4. Save and exit the VAL form.

5. Access the FA Institutional Defaults (FIDF) form.

6. Enter your Health Professions programs code (the code created in Step 3) in the Health Prof Prog Type field.

7. Save and exit the FIDF form.

8. Access the Academic Programs (PROG) form.

9. Enter an individual Health Professions program or use the LookUp prompt.

10. Enter your Health Professions program code (the code created in Step 3) in the Type field.

11. Save and exit the PROG form.

12. Repeat Step 8 through Step 11 for each program considered a Health Professions program by your institution.

Maintaining FA Office Information

Use the FA Office Parameters (FAOP) form to create and maintain Financial Aid office records.

Other than the required Office Name field, you need to complete the fields on this form only if the information for the current office is different from the corresponding fields on the FA Institutional Defaults (FIDF) form.


Ge

Figure 120: The FA Office Parameters (FAOP) Form

When you access the FAOP form, Colleague displays an FA Office LookUp prompt. To view or maintain information for an existing office, enter the office code. To create a new FA office, enter a new, unique code—Colleague then prompts you to confirm that you want to create the new office.

Noteworthy Fields on the FAOP Form

See online help for more information about any fields not discussed in this section. Be aware that the information you are entering applies specifically to the FA office you selected or created at the LookUp prompt.

Note: The following fields are not used during initial FA office setup:Loan Defaults. Used when setting up loan processing.COD Defaults. Used when setting up the COD Interface.

Office Name

This field is required. If your institution has only one FA office, this is the only field you need to complete on this form—you can enter the rest of the information on the FA Institutional Defaults (FIDF) form.

Procedure for Setting Up Your Main FA Office

1. Access the FA Institutional Defaults (FIDF) form.

2. Complete the following fields:


Ge

• College Name

• College Address

• College CSZ

• FA Director

• Phone Number

• E-Mail Address

• Fax Number

• Title IV School Code

• OPE ID

• Destination Point

3. From the FA Office ID field, detail to the FA Office Parameters (FAOP) form.

4. At the FA Office LookUp prompt, enter a code to represent your main FA office.

The code can consist of up to five alphanumeric characters.

5. In the Office Name field, enter a name for this FA office.

6. Are you a single-campus or multi-campus institution?

Single-campus. You are done with this form. Continue with the next step.

Multi-campus. Review the rest of the fields on this form. If the information for this specific office is different from the default information you entered on the FIDF form, enter the office-specific information in the applicable fields. Then continue with the next step.

7. Finish out of the FAOP form.

8. Finish out of the FIDF form.

Procedure for Setting Up Additional FA Offices

This procedure is necessary only if your institution needs to set up multiple FA offices. Repeat the procedure as needed to create each additional FA office that you require.

Before performing this procedure, you should have already completed the “Procedure for Setting Up Your Main FA Office” on page 703.

1. Access the FA Office Parameters (FAOP) form.

2. At the FA Office LookUp prompt, enter a code to represent this FA office.

The code can consist of up to five alphanumeric characters.

3. In the Office Name field, enter a name for this FA office.

4. Update the fields on this form as needed.


Ge

Review the fields. If the information for this specific office is different from the default information you entered on the FIDF form, enter the office-specific information in the applicable fields.

5. Finish out of the FAOP form.

Setting Up FA Locations

Use the FA Locations Definition (FLCD) form to create and maintain FA locations. You create an FA location by calling up an existing campus location on the FLCD form and assigning the location to an FA office.

Note: A “campus” location, created on the Locations (LOCN) form in the Core application, must exist before you can identify it as an FA location. If a suitable campus location does not exist, contact your school’s implementation team to create one.

An FA office record must exist so that you can associate this FA location with the FA office. See “Setting Up FA Offices” on page 699 for more information.

Figure 121: The FA Locations Definition (FLCD) Form

All institutions must set up at least one FA location to represent its FA office. If you are a multi-campus institution, or are an institution that shares a single Colleague database with other schools, you can set up multiple FA locations to represent various locations, such as branch campuses, of your institution.


Ge

Typically, you would create additional FA locations only if you want to report associated students to the Department of Education with a separate Pell Attended Campus Routing ID.

For more information about how Colleague uses FA locations, see “Understanding FA Offices and Locations” on page 697.

Noteworthy Field on the FLCD Form

There is only one noteworthy field on the FLCD form—the FA Office field. The other fields are used to set up Pell processing for your institution.

FA Office

Select the FA office to associate with this FA location. Enter the FA office code if you know it, or perform a standard LookUp to locate the desired FA office.

Award fund budgets are stored by office. Colleague tracks student awards against the appropriate FA office fund balance.

FA office codes are used to indicate a Financial Aid office. You can define an FA office code on the FA Office Parameters (FAOP) form. FA office codes are stored in the FA.OFFICES file.

Creating Location Rules

Use the Location Rule Table (LCRL) form to create a rule that assigns default locations to students for whom no location has been defined. If your institution requires only one location, simply enter it as the Default Location.


Ge

Figure 122: The Location Rule Table (LCRL) Form

Each rule table you create is year-specific. When you are ready to begin using the new rule for the new year, go to the Financial Aid System Parameters (FASP) form and enter the new rule in the Location Rule ID field.

Colleague evaluates the rule whenever a CS.ACYR record is created for a student. CS.ACYR records are created in the following instances:

• When you import a student application through the ISIR Import (ISIM) process.

• When you award a student for the first time by running the Batch Awarding (BAWD) or Automatic Packaging (PKCR) processes, or using the Award Detail Entry (AIDE) form.

• When you edit a student’s attendance pattern on the Student Attendance Pattern (SATP) form.

• When you create an initial application for a student on the Financial Aid Application (FAPP) form.

Noteworthy Fields on the LCRL Form

The fields listed in this section benefit from additional explanation.

Default Location

If your institution has only one FA location, you need only enter that FA location in this field. You do not have to complete the Rule table.

If your institution has multiple FA locations, you must identify one of them as the default.


Ge

Rule / Virtual Field Name / Location

If your institution has only one FA location, you can skip this group of fields.

If your institution has multiple FA locations, detail to the Rules Definition (RLDE) form to create rules to determine the student’s FA location. If the rule is true, Colleague assigns the corresponding location to that student.

Note: Pay attention to the order of the rules in this group of fields. Colleague uses the first true rule to assign the location, and ignores the rest of the rules.

Alternately, you can create a custom subroutine to assign FA locations to students. If you use a subroutine, leave this group of fields blank and complete the Location Subroutine field instead.

Location Subroutine

Instead of using rules, you can create and use a subroutine to assign FA locations to students. If you do that, enter the subroutine name here, and leave the Rule group of fields blank.

Procedure for Creating FA Locations

Before you can create FA locations, corresponding campus locations must already exist in the system. To see a list of your institution’s existing campus location codes, perform a standard LookUp when you get to Step 2 below.

If you cannot find suitable campus locations to serve as your FA locations, see your school’s implementation team.

1. Access the FA Locations Definition (FLCD) form.

2. In the FA Office field, enter the FA office to which this FA location should be associated.

3. Finish out of the FLCD form.

4. Repeat Step 1 to Step 3 as needed to create all of the FA locations for your institution.

5. Access the Location Rule Table (LCRL) form.

6. Complete the form as necessary for your institution.

Remember, if you are an institution with only one FA location, you need only enter that FA location in the Default Location field.

7. Finish out of the LCRL form.


Faculty Information

Ge

Setting Up the Faculty Information Module

In This Chapter

This chapter provides a list of the codes that must be set up to use the Faculty Information module. The codes used by the Faculty Information module are located in both the ST and Core applications.

Setting Up Codes for the Faculty Information Module

To set up the Faculty Information module, you must define the following codes:

• Academic committee types

• Academic calendars1

• Accreditation type1

• Address route codes1

• Address relationship statuses1

• Address relationship types1

• Advisor types

• Buildings1

• Campus organization member statuses

• Campus organization types

• Communication codes1

• Classes

• Contact measures

• Contact roles1

1.This is a Core code that the Faculty Information module uses.

711tting Started with Colleague Student | Setting Up the Faculty Information Module

Ge

• Corporation statuses1

• Corporation types1

• Counselor types

• Course levels

• Course statuses

• Credit types

• Departments1

• Divisions

• EEO ranks1

• Employment statuses1

• Employment types1

• Faculty contract types

• Faculty positions

• Faculty remarks codes

• Faculty remark types

• Faculty special statuses

• Formatted name types1

• Graduation types1

• Industry classes1

• Institutional funding sources1

• Institution types1

• Instructional methods

• Interests1

• Locations1

• Mail rules1

• Other CCDs1

• Other degrees1

• Other honors1

• Other specializations1

• Person e-mail types1


Ge

• Person origin codes1

• Personnel statuses1

• Petition statuses

• Phone types1

• Positions1

• Prefixes1

• Privacy codes1

• Roles

• Room usages1

• Rooms1

• Schedule repeats1

• Schedule types

• Schools

• Session cycles

• Sources1

• States1

• Subjects

• Suffixes1

• Teaching arrangements

• Time zones1

• Transcript statuses1

• Transcript types1

• Vocations1

• Yearly cycles

Refer to “Defining Colleague Student Codes” on page 137 for information about defining these codes.


Ge

Setting Up Rules for the Faculty Information Module

If you want to assign faculty advisors based on rules, you must set up your rules for advisor assignment. See “Defining Faculty Information Rules” on page 715 for detailed instructions.

Refer to Using Faculty Information for information about using this module.


Ge

Defining Faculty Information Rules

In This Chapter

This chapter explains how to define advisor assignment rules for the Faculty Information module.

Before You Begin

Before you read this chapter and begin defining your faculty information rules you should read “Understanding the Rules Processor” on page 309 for information about the basic principles of the Colleague rules processor.

Understanding Advisor Assignment Rules

In the Faculty Information module you can define rules to control how faculty advisors are assigned to students. These rules are similar to your business rules that identify when to assign an advisor to a student, such as assignment based on the student’s major, home location, academic level, or a combination of factors.

Colleague evaluates the advisor assignment rules when you run the batch advisor assignment process.

You can assign advisors to individual students:

• Manually

• Through a batch process

• Automatically with rules

When Colleague Evaluates the Advisor Assignment Rules

Colleague evaluates your advisor assignment rules when you run the batch advisor assignment process (initiated from the Advisor Assignment [ADAS] form). Colleague does not evaluate the assignment rules when you manually assign an advisor.

715tting Started with Colleague Student | Defining Faculty Information Rules

Ge

Colleague evaluates all the rules and assigns the advisor associated with the rules that evaluate true.

How to Define Advisor Assignment Rules

Use the STUDENTS file as the primary view for the advisor assignment rule. Use the Advisor Assignment Rules (ADVR) form to associate each rule with a specific advisor.

Note: To ensure that you define all the advisor assignment rules you need, list all the advisors and identify the rules for determining when Colleague should assign a student to that advisor.

Example: Advisor Assignment Rules

Ellucian University assigns advisors based on the student’s major. However, if a student has not indicated an interest in a particular major, then Colleague assigns an advisor based on the student’s academic program. To implement this policy, Ellucian University’s faculty advisement office defined their advisor assignment rules as follows:

1. One rule for each major. These rules assign the appropriate advisor to students interested in that major.

2. One rule for each advisor’s academic program. These rules assign an advisor to students who have not yet indicated an intended major.

The faculty advisement office entered the rules on the ADVR form.

For illustration purposes, only two rules are shown on the ADVR form; however, EU would need one rule for each advisor Colleague assigns based on major and one rule for each set of advisor Colleague assigns when the student does not indicate a major.


Ge

Figure 123: Example of an Advisor Assignment Rule


Ge

Table 266 identifies three basic scenarios that Ellucian University encounters during the advisor assignment process.

Procedure for Defining Advisor Rules

Complete the following procedure to define your advisor rules.

1. Enter each advisor as a staff member using the Staff/Volunteer Maintenance (SVM) form.

Note: To associate a faculty member to a rule on the ADVR form, you must also set the Advisor flag on the FCTY form to Yes.




Note: The data elements you use must be from the STUDENTS file, or one of the subsidiary files associated with it. See “Understanding the Rules Processor” on page 309 for more information about primary views.



5. Go to the Advisor Assignment Rules (ADVR) form.

6. Enter a code to indicate the name of the advisor assignment rule.


Table 266: How Colleague Makes Advisor Assignments Based on Assignment Rules

Scenario Result

An undergraduate student registers with a major in English.

Colleague assigns an undergraduate English instructor, D. Greenwell, as the individual’s advisor. The faculty advisement office uses the Faculty Advisee Detail (FADT) form to view the details of this assignment.

An undergraduate student registers with a major in History.

Colleague assigns an undergraduate History instructor, P. Reid, as the individual’s advisor.

A student with an undeclared major registers for the B.S. in Business Administration academic program

Colleague assigns D. Myers as the individual’s advisor, since all undeclared majors who are in the B.S. in Business Administration academic program are to be assigned to Dr. Myers (who will assign advisors to these students on an individual basis).


Ge

If the rule displays on the ADVR form and the cursor moves to the Advisor field, continue with Step 10.

7. Enter A.


8. Enter the rule.

Use the information from the “Rule Construction Translation” worksheet.


9. Save the rule.

The ADVR form redisplays.

10. Enter the name or ID of the advisor Colleague will assign when this rule is true.

11. Repeat this procedure, beginning with Step 6, for each advisor assignment rule.

12. Save the assignment rules on the ADVR form.


Ge

Defining Faculty Defaults

In This Chapter

This chapter provides information about defining defaults used by the Faculty Information module.

Understanding Faculty Information Defaults

In the Faculty Information module you can define the workload calculation subroutine, which allows you to calculate and default information into faculty assignment records.

Use the Faculty Information Defaults (FIDE) form to define these subroutine defaults.

Figure 124: The Faculty Information Defaults (FIDE) Form

Workload Calculation Subroutines

Faculty workloads are usually defined by the course section instructional method workloads. But if you want to define the faculty workload using other criteria, such as

Workload Calculation Subroutines are associated with instructional methods

Contract Position Subroutine

720tting Started with Colleague Student | Defining Faculty Defaults

Ge

enrollment in the course section, you need to define workload calculation subroutines. Each instructional method you want calculated using the other criteria must be associated with a name of a cataloged subroutine that defines that workload calculation. These load calculation subroutines can affect not only load, but also the percent and course section credit.

When a faculty member is assigned to a course section for an instructional method, the section instruction method load defaults into his assignment record. If the assignment is for an instructional method that has an associated subroutine defined on the FIDE form, that subroutine is called to determine the load, percent and credits.

For example, if the subroutine named S.TEST.FACLOAD2 is associated with the instructional method GMR (Test Instructional Method). Every time a faculty assignment is made on the Faculty Section Assignment (FASC) form using the GMR instructional method, Colleague calculates the faculty workload (and percent and course credits) using the S.TEST.FACLOAD2 subroutine.

If you change the subroutine credit output after students have registered for a course, the student credits for those already registered will NOT be affected. The change will affect only future student enrollment.

If the defined workload calculation subroutines involve the number of students enrolled in the section, you must run the Faculty Load Recalculation (FLRC) form after registration. The FLRC process calls the appropriate workload calculation subroutines and recalculates the faculty workload for the selected course sections. See Using Faculty Information for more information about the FLRC process.

Contract Position Subroutine

You can define a subroutine that defines the faculty member’s contract position to use when a faculty assignment is added to a new or existing HR contract. This subroutine is called when the contract type is entered on the following forms:

• Faculty Section Assignment (FASC)

• Faculty Membership Detail (FCMD)

• Faculty Organization Asgmt (FAOA)

• Section Copy (SCOP)

See Using Faculty Information for more information about the FASC, FCMD or FAOA forms. See Using Curriculum Management for more information about the SCOP form.

721tting Started with Colleague Student | Defining Faculty Defaults

Ge

Defining Admissions Rules

In This Chapter

This chapter provides information about how to define the admissions rules which are used to control the specific processes executed during the admissions process.

Before You Begin

Before you read this chapter and begin defining your registration rules you should read “Understanding the Rules Processor” on page 309 for information about the basic principles of the Colleague rules processor.

Understanding Admissions Rules

In the Recruitment/Admissions Management module you can define rules to control specific processes. These rules are similar to your business rules that identify when to:

• Send letters or other correspondence to a prospect or applicant.

• Record the receipt of specific documents from a prospect or applicant.

• Assign an admissions representative or an alumni area representative to an applicant or an application.

• Assign a rating to prospect or an application.

• Update an applicant’s application status.

• Mark external transcript records.

• Create a STUDENTS record from an APPLICANTS record.

724tting Started with Colleague Student | Defining Admissions Rules

Ge

The specific rules that you use in the Recruitment/Admissions Management module, and when Colleague evaluates these rules is provided in Table 267.

Table 267: Overview of the Admissions Rules

These rules … Are evaluated… Reference

Admissions representative/AARS assignment

• When you update an individual’s prospect, applicant, or application information.

• When you run the batch admissions representative/AARS assignment process.

See “Admissions Representative/AARS Assignment Rules” on page 726.

Admissions tracking rules

When you update an individual’s prospect, applicant, or application information.

See “Admissions Tracking Rules” on page 729 .

Applicant rating rules When you initiate the rating calculation process from the Applications (APPN) form or run the Application Rating Assignment (APRA) process.

See “Application Rating Rules” on page 733.

Academic program admit rules

• When you update an individual’s APPLICATIONS record.

• When you run the batch admit process.

See “Academic Program Admit Rules” on page 736.

External transcript course rules

• When you update an individual’s external transcript information.

• When you run the batch that marks external transcript records.

See “External Course Rules” on page 739.

External transcript GPA selection rules

When you access an application on the Additional Application Info (ADAI) form.

See “External Transcript GPA Selection Rules” on page 742.

Prospect rating rules • when you update a prospect’s record

• when you run the batch prospect rating assignment process

See “Prospect Rating Rules” on page 746

STUDENTS creation rule

depending on the Create Student

Record Immediately flag1

• when you update an individual’s APPLICATIONS record

• when you run the STUDENTS record creation process

• when you access an individual’s APPLICATIONS record on the Student Profile (SPRO) form or the Student Academic Program (SACP) form

• when an individual first registers for class

1.See “Student Creation Rules” on page 753.

See “Student Creation Rules” on page 753


Ge

This section explains each of the rules that you will need to define for the Recruitment/Admissions Management module. Before you read this section you should read “Understanding the Rules Processor” on page 309 for a basic understanding of the rules processor.

Admissions Representative/AARS Assignment Rules

You can assign admissions representatives or alumni area representatives (collectively referred to herein as “admissions representatives”) to individual applicants or applications:

• Manually

• Through a batch process

• Automatically with rules

When Colleague Evaluates the Admissions Representative Assignment Rules

Colleague evaluates your admissions representative assignment rules each time you save an individual’s prospect, applicant, or application information or when you run the batch representative assignment process (initiated from the Batch Admissions/AARS Assignment [ARAA] form). Colleague does not evaluate the assignment rules when you manually assign an admissions representative.

Colleague evaluates all the rules and assigns the admissions representative and the AARS associated with the first rule that evaluates to true. Once Colleague assigns an admissions representative, Colleague will not automatically override the assignment unless you run the batch assignment process and you indicate that you want Colleague to override existing assignments.

Assigning Representatives to Applicants and to Applications

You choose whether Colleague assigns the admissions representatives to each applicant or to each application that an applicant has on file. For example, if you assign one representative regardless of the number of applications an individual submits, then you want Colleague to assign representatives to each applicant.

If you assign admissions representatives based on information associated with each application, such as the academic program, and one applicant may have a different representative for each application, then you want Colleague to assign representatives to each application.

Use the One Admissions Rep per Applicant parameter on the Admissions Rep/AARS Rules (ARAR) form to indicate the assignment of admissions representatives. Enter Y to have Colleague assign one admissions representative to each applicant, regardless of the


Ge

number of applications the applicant submits. Enter N to have Colleague assign one admissions representative to each application.

Note: Regardless of how you set this parameter, Colleague assigns one AARS to each applicant. Thus, an applicant who submits multiple applications always has one AARS.

How to Define Admissions Representative Assignment Rules

Use the PERSON or APPLICATIONS files as the primary view for the admissions representative/AARS assignment rule. Use the Admissions Rep/AARS Rules (ARAR) form to associate each rule with a specific representative and an alumni area representative.

Note: To ensure that you define all the representative assignment rules you need, list all the representatives and identify the rules for determining when Colleague should assign an applicant—or an application—to that representative.

Example Admissions Representative Assignment Rules

Ellucian University assigns an AARS and an admissions representative to each applicant based on the applicant’s home state. To implement this policy, Ellucian University’s admissions office defined their representative assignment rules as follows:

• One rule for each admissions representative’s geographic region. These rules assign the appropriate admissions representative and AARS to prospects and applicants based on where they live.

The admissions office set the One Admissions Rep per Applicant parameter on the ARAR form to “No” and entered the rules on the ARAR form.

EU would need one rule for each admissions representative Colleague assigns based on region.


Ge

Table 268 identifies two basic scenarios that Ellucian University encounters during the recruitment and admissions process.

Procedure for Defining Admissions Representative/AARS Rules

Complete the following procedure to define your admission representative/AARS rules.

1. Enter each AARS as an individual in Colleague using the Name and Address Entry (NAE) form.




Note: The data elements you use must be from the PERSON or APPLICATIONS file, or one of the subsidiary files associated with these. See “Understanding the Rules Processor” on page 309 for more information about primary views.




5. Go to the Admissions Rep/AARS Rules (ARAR) form.

Table 268: How Colleague Makes Admissions Representative Assignments Based on Assignment Rules

Scenario Result

An individual from Oregon submits information to the admissions office.

Colleague assigns M. Johnson as the individual’s admissions representative and Nancy Watkins as the AARS (both are assigned to the Pacific Northwest region). Colleague assigns these representatives to the individual’s applicant record. The admissions office uses the Applicant References/ Appointments (REFA) form to view this assignment.

An individual from Virginia submits an application to the accounting program.

Colleague assigns T. Whorton as the individual’s admissions representative and Paul Jefferson as the AARS (both are assigned to the Mid-Atlantic region). Colleague assigns T. Whorton to the individual’s application record and Nancy Watkins to the individual’s applicant record. The admissions office uses the Application References/ Appointments (ARFA) form to view this assignment.


Ge

6. Enter Y in the One Admissions Rep per Applicant field if you want Colleague to assign a single representative to each applicant.

The cursor moves to the Rules field.

If you want Colleague to assign representatives to an applicant and to that applicant’s individual applications, enter N.

7. Enter the name of the representative assignment rule.


If the rule displays on the ARAR form and the cursor moves to the Admissions Representative field, continue with Step 11.

8. Enter A.


9. Enter the rule.



10. Save the rule.

The ARAR form redisplays with the cursor in the Admissions Representative field.

11. Enter the name or ID of the admissions representative Colleague will assign when this rule is true.

The cursor moves to the AARS field.

12. Enter the name or ID of the AARS Colleague will assign when this rule is true.


13. Repeat this procedure, beginning with Step 7, for each admissions representative assignment rule.

14. Save the assignment rules on the ARAR form.

Admissions Tracking Rules

Admissions tracking rules let you integrate information recorded in the Recruitment/Admissions Management module with documents and tracks defined in the Communications Management module. Through this integration you can automate a number of different processes common to admissions offices.


Ge

When Colleague Evaluates the Admissions Tracking Rules

Colleague evaluates your admissions tracking rules each time you update an individual’s prospect, applicant, or application record.

When processing applications, Colleague evaluates admissions tracking rules as follows:

• Each rule is evaluated. For each rule that is found true, the corresponding communication code is assigned to the prospect, applicant, or application.

• Each communication code is assigned to a prospect, applicant, or application only once. On subsequent updates to the individual’s record, Colleague will not evaluate rules for communication codes that have already been assigned to the record.

How to Define Admissions Tracking Rules

Use the PERSON or APPLICATIONS files as the primary view for the admissions tracking rules. Use the Admissions Tracking Rules (ATRK) form to associate each tracking rule with the communications code and status Colleague assigns when a rule is true.

For example, Ellucian University requires that an applicant submit an admissions form (application), a residency certification, an application fee, test scores, a transcript, and two letters of recommendation before the admissions office considers the applicant’s application complete. The admissions office does not review an applicant’s file until they receive this information. Because this information comes to the office over time, the admissions office uses admissions tracking rules and the features of the Communications Management module to track the receipt of these items and update the applicant’s status once everything has been received.

The admissions office created communication received codes for each of the required items. The office then grouped these items together under one correspondence request code.


Ge

Figure 125: Comm Codes and Correspondence Request Codes

Next, the admissions office defined a set of admissions tracking rules. These rules let the Communications Management module know when a particular piece of information is received. For example, the APPRECVD rule identifies when the admissions office receives an admissions application by checking the APPLICATIONS file for an application date.


Ge

Figure 126: Example of an Admissions Tracking Rule

When the admissions office records an individual’s application and enters the application date, the APPRECVD rule is true and Colleague sets the associated correspondence code for that individual to “Received.”

This is just one of many ways that you can use admissions tracking rules to automate admissions processes. See Using Recruitment/Admissions Management for further details about using the Communications Management module with the Recruitment/Admissions Management module.

Procedure for Defining Admissions Tracking Rules

Complete the following procedure to define your admission tracking rules.

1. Define the communications codes you want to associate with specific rules.

See Using Recruitment/Admissions Management and Using Communications Management for information about defining codes and documents in the Communications Management module.


Ge

2. Define any necessary communications tracks and correspondence requests.








6. Go to the Admissions Tracking Rules (ATRK) form.

7. Enter the name of an assignment tracking rule.


If the rule displays on the ATRK form, continue with Step 11.

8. Enter A.


9. Enter the rule.



10. Save the rule.

The ATRK form redisplays.

11. Enter the communications code you want Colleague to update when the corresponding rule is true.

12. Enter the status code that you want Colleague to assign when the corresponding rule is true.

13. Repeat this procedure, beginning with Step 7, for each admissions tracking rule.

14. Save the tracking rules on the ATRK form.

Application Rating Rules

Application ratings let you quantify an admissions application based on specified criteria. You associate each rating rule with a number of points.


Ge

When Colleague Evaluates the Application Rating Rules

Colleague evaluates your application rating rules when you run the application rating assignment process. You can run this process for a group of applications from the Application Rating Assignment (APRA) form or for an individual from the Applications (APPN) form. Each time a true condition occurs, Colleague assigns the associated points to the application. An application’s total rating is the sum of all the points associated with each true condition. This is different from other rules where Colleague will stop evaluating a record once it finds a true condition. Colleague evaluates all application rating rules.

During the admissions process you can detail from the Rating field on the Applications (APPN) form to calculate the rating, or you can manually enter an application rating on the APPN form. When you manually enter an application rating, Colleague does not reevaluate the rating rules and override this value.

How to Define Application Rating Rules

Use the PERSON or APPLICATIONS files as the primary view for the application rating rules. Use the Application Rating Rules (ARAT) form to associate each rating rule with the points Colleague assigns when a rule is true.

For example, some of Ellucian University’s rating criteria, and the associated points, are listed below.

Figure 127 illustrates one of the applicant rating rules the admissions office defined.

Table 269: Example Application Rating Criteria

Conditions Points

SAT greater than or equal to 1100 15

SAT between 750 and 1100 10

SAT less than 750 0

high school GPA greater than or equal to 3.7 5

high school GPA between 3.0 and 3.7 5

high school GPA less than 3.0 5


Ge

Figure 127: Applicant Rating Rule

Procedure for Defining Application Rating Rules

Complete the following procedure to define your application rating rules.








4. Go to the Application Rating Rules (ARAT) form.

5. Enter the name of an application rating rule.


If the rule displays on the ARAT form, continue with Step 9.

6. Enter A.


Ge


7. Enter the rule.



8. Save the rule.

The ARAT form redisplays.

9. Enter the number of points associated with this rule.

10. Repeat this procedure, beginning with Step 5, for each application rating rule.

11. Save the application rating rules on the ARAT form.

Academic Program Admit Rules

Use academic program admit rules to define when Colleague changes an application’s status based on specified criteria. You can define a unique set of academic program admit rules for each academic program. For example, you might have an academic program admit rule instructing Colleague to automatically admit or reject applicants to the business program based on their SAT scores and high school GPA.

When Colleague Evaluates the Academic Program Admit Rules

Colleague evaluates your academic program admit rules based on the Auto Admit flag on the Admissions Parameters (ADPA) form. If you set this parameter to “Yes,” Colleague evaluates your academic program admit rules each time you update an application record from either the Prospect Summary (PRSP) form, the Applicant Summary (ASUM) form, the Applications (APPN) form, or from any of the forms where you maintain prospect, applicant, or application data (such as the Test Scores [TEST] form or the External Transcripts [EXTR] form).

If you set this parameter to “No,” Colleague evaluates your academic program admit rules only when you run the batch admissions process (from the Batch Admissions [BADM] form). In this process Colleague evaluates only those applications for a selected group of applicants.

Colleague also evaluates these rules when you assign an academic program to a student through processes in the Academic Records module or the Registration module. During these processes Colleague evaluates only those rules associated with an “accepted” application status. If any rules have been defined for “accepted” application statuses, a student being evaluated must pass at least one of those rules in order to automatically be admitted to the academic program. If the student does not pass any of the rules,


Ge

Colleague issues a warning, but will allow the failed rules to be overridden and the program assigned to the student.

For example, Ellucian University defined rules for the business program. One rule rejects an application if the applicant does not meet a minimum set of criteria. Another rule puts the application on a waitlist, another rule changes the status of the application to “needs review,” and a final rule changes the application status to “accepted.” If the registrar’s office assigns the business program to an individual, Colleague evaluates only the rule associated with the “accepted” application status. If the individual passes that rule, it assigns the academic program.

How to Define Academic Program Admit Rules

Use the PERSON or APPLICATIONS files as the primary view for the application rating rules. Use the Academic Program Admit Rules (ADMR) form to associate each academic program admit rule with the application status Colleague assigns when a rule is true.

Figure 128: Example Academic Program Admit Rule

During the admissions process you can manually enter any application status code on an application. If you do not want Colleague to override these manually entered codes when it evaluates your academic program admit rules, you will need to make sure that you define each rule to check for any manually entered status codes. For example, the academic program admit rule that Ellucian University wrote to reject an applicant from the


Ge

business program includes several statements that make sure the application status is not already set to “accepted” or “admitted” because the admissions office often manually enters these codes for individual’s who do not meet the rules for acceptance to the program but, due to special circumstances, the admissions office admits them to the program.

An alternative approach is to use miscellaneous admissions codes to indicate that an individual should be accepted or admitted to a program even if they do not meet the standard criteria for acceptance or admittance. You would write rules that assign the appropriate status code based on the existence of the miscellaneous code. For example, you might use a miscellaneous code of “OVERRIDE” to indicate that you have overridden the standard criteria for admitting an applicant. Then you would write a rule that looks for this miscellaneous code and applies the appropriate application status based on this code. See “Miscellaneous Admissions Codes” on page 241 for information about defining and using miscellaneous codes.

If you manually set the application status for waitlisted applications, you should consider writing the rules so that an applicant who might normally pass the rule would fail the rule when his application status is set to “waitlisted.”

Procedure for Defining Academic Program Admit Rules

Note: Before you define academic program admit rules, the appropriate office at your institution must define the academic programs you are defining rules for. See the Using Curriculum Management manual for details.

Complete the following procedure to define your academic program admit rules.

1. Define your application status codes.

See “Application Statuses” on page 143.








5. Go to the Academic Program Admit Rules (ADMR) form.

6. Enter the name of an academic program admit rule.


Ge


If the rule displays on the ADMR form, continue with Step 10.

7. Enter A.


8. Enter the rule.



9. Save the rule.

The ADMR form redisplays.

10. Enter the application status code associated with this rule.

11. Repeat this procedure, beginning with Step 6, for each academic program admit rule.

12. Save the academic program admit rules on the ADMR form.

External Course Rules

External transcripts are associated with an individual and an outside institution. If you want to associate those transcripts to an application and mark them to indicate such things as whether they meet an academic program requirement or can be used for general credit, you must first define external transcript course rules. You can define a unique set of external course rules for each academic program.

When Colleague Evaluates the External Course Rules

Colleague evaluates your external course rules each time you save an individual’s external transcript record from the External Transcript Summary (EXST) form or when you run the external transcript marking process (initiated from the Mark Extl Transcript Records [METR] form).

Colleague evaluates all the rules and assigns the associated indicator to the first transcript record that evaluates to true. You can define how many times Colleague can evaluate a given rule to true. For example, if an academic program required three science courses, you might define an external course rule to evaluate whether the course was science. If an external transcript passed the rule, Colleague “marks” the record with the associated indicator, such as “R” for Required. You would define the rule to be used until it evaluated to true three times to match the requirement.


Ge

How to Define External Course Rules

Use the EXTERNAL.TRANSCRIPTS file as the primary view for the external course rules. Use the Acad Program Extl Tran Rules (AETR) form to associate each external course rule with the course indicator Colleague assigns when a rules is true and the number of times Colleague can find the rule to be true.

Figure 129: The Acad Program Extl Tran Rules (AETR) Form

Sort Criteria

Because Colleague marks the first external transcript that satisfies an external course rule, it could be important for the external transcripts to be processed in a certain order. For example, external transcripts can be sorted in date order so that the oldest are used first. Or, they can be sorted in descending grade value order so the best grades are used first.

Use the Acad Level Extl Tran Sort (AETS) form to define the sort criteria for the external transcript process.


Ge

Figure 130: Forms Used to Define Transcript Sort Order

Procedure for Defining External Course Rules

Note: Before you define external course rules, the appropriate office at your institution must define the academic programs you are defining rules for. See the Using Curriculum Management manual for details.

Complete the following procedure to define your external course rules.

1. Define your course indicator codes.




Note: The data elements you use must be from the EXTERNAL.TRANSCRIPTS file. See “Understanding the Rules Processor” on page 309 for more information about primary views.




5. Go to the Acad Program Extl Tran Rules (AETR) form.


Ge

6. Enter the name of the academic program for which you want to enter external course rules.

You can only enter an academic program that has already been defined.

7. Enter the name of a required external course rule.


If the rule displays on the AETR form and the cursor moves to the Course Indicator field, continue with Step 11.

8. Enter A.


9. Enter the rule.



10. Save the rule.

The AETR form redisplays.

11. Enter the course indicator code associated with this rule.

This is the indicator code that Colleague will use to “mark” the external transcript record for an application if the associated rule evaluates to true.

12. Enter the number of times Colleague should evaluate this rule as true.

For example, if you want to “mark” up to three external transcripts as meeting a science requirement, then enter 3 here.

13. Repeat this procedure, beginning with Step 7, for each required external course rule you want to define for this academic program.

14. Go to the Other External Course Rule field.

Enter rules in this field that define external transcripts that are not required, but are otherwise used with this academic program

15. Enter the rule name, associated indicators to be assigned and the number of times the rules should be evaluated as true.

See Step 7 through Step 13 for similar actions necessary to enter this information.

16. Save the academic program external course rules on the AETR form.

External Transcript GPA Selection Rules

If you have chosen to associate your external transcripts to applications using external course rules you defined, Colleague can also calculate a variety of external transcript


Ge

GPAs for each application. The external transcript GPA selection rules identify which of the external transcripts associated with an application to use when calculating a particular external transcript GPA. For example, you may want to calculate a GPA using only those external transcripts which have been “marked” as meeting an academic program admission requirement.

When Colleague Evaluates the External Transcript GPA Selection Rules

Colleague evaluates your external transcript GPA selection rules each time you access an application using the Additional Application Info (ADAI) form.

If you do not define external transcript GPA selection rules for the academic program associated with an application, Colleague uses all external transcript records associated with the application that have a grade scheme and grade to calculate each of the GPAs.

How to Define External Transcript GPA Selection Rules

Use the APPL.EXTL.TRAN.XREF file as the primary view for the external transcript GPA selection rules. Use the Acad Program Extl Tran Rules (AETR) form to define which selection rules Colleague uses when evaluating an application with a particular academic program.

You can define up to three different external transcript GPAs and Colleague applies all three to secondary school transcripts and post-secondary school transcripts separately. For example, Ellucian University wants to define three separate GPAs based on how the transcripts were marked by the external course rules, including one for just the required external courses, one for all external courses that will be used as general credit, and, finally, a cumulative GPA which reflects all external courses. These three rules are applied to all high school transcripts associated with an application and then they are applied again to all of the post-secondary school transcripts associated with an application.


Ge

Figure 131: GPA Selection Rule Example

Procedure for Defining External Transcript GPA Selection Rules

Note: Before you define external transcript GPA selection rules, the appropriate office at your institution must define the academic programs you are defining rules for. See the Using Curriculum Management manual for details.

Complete the following procedure to define your external course rules.


Ge




Note: The data elements you use must be from the APPL.EXTL.TRAN.XREF file. See “Understanding the Rules Processor” on page 309 for more information about primary views.



4. Go to the Acad Program Extl Tran Rules (AETR) form.

5. Enter the name of the academic program for which you want to enter external transcript GPA selection rules.

You can only enter academic programs that have already been defined.

6. Go to the GPA1 Section Rule field.

7. Enter the name of an external transcript GPA1 selection rule.


If the rule displays on the AETR form and the cursor moves to the next line in the group, continue with Step 11.

8. Enter A.


9. Enter the rule.



10. Save the rule.

The AETR form redisplays.

11. Repeat this procedure, beginning with Step 7, for each GPA1 selection rule you want to define for this academic program.

12. If you want to define additional GPA selection groups for this academic program, go to the GPA2 Selection Rule field.

You can define up to three separate selection groups, GPA1-3.

If you choose not to define one (or more) of the selection groups, Colleague will use all of the external transcripts associated with an application that have a grade scheme and a grade when calculating external transcript GPAs.


Ge

13. Enter the name of the GPA selection rule.

See Step 7 through Step 11 for detail information about defining these additional GPA selection groups, except use the GPA2 or GPA3 Selection Rule field.

14. Save the external transcript GPA selection rules on the AETR form.

Prospect Rating Rules

Prospect ratings let you quantify a prospect based on specified criteria. You associate each rating rule with a number of points.

When Colleague Evaluates the Prospect Rating Rules

Colleague evaluates your prospect rating rules when you run the prospect rating assignment process. You can run this process for a group of prospects from the Prospect Rating Assignment (PRRA) form or for an individual from the Prospect Summary (PRSP) form.

During the recruitment process you may manually enter prospect rating on the Prospect Summary form. When you manually enter a prospect rating, Colleague does not reevaluate the rating rules and override this value.

How to Define Prospect Rating Rules

Use the PERSON or APPLICATIONS files as the primary view for the prospect rating rules. Use the Prospect Rating Rules (PRAT) form to define each rating rule.


Ge

Figure 132: Example Prospect Rating Admit Rule

Procedure for Defining Prospect Rating Rules

Complete the following procedure to define your application rating rules.








4. Go to the Prospect Rating Rules (PRAT) form.


Ge

5. Enter the name of a prospect rating rule.


If the rule displays on the PRAT form and the cursor moves to the Points field, continue with Step 9.

6. Enter A.


7. Enter the rule.



8. Save the rule.

The PRAT form redisplays.

9. Enter the number of points associated with this rule.

10. Repeat this procedure, beginning with Step 5, for each prospect rating rule.

11. Save the prospect rating rules on the PRAT form.

Student Creation Rules

Colleague uses your student creation rules to determine when to create a STUDENTS record from an APPLICANTS record. See “Student Record Creation Parameters” on page 752 for details.


Ge

Setting Up Admissions Parameters

In This Chapter

This chapter provides information about how to define the admissions parameters.

Before You Begin

Before you set your admissions parameters you must define the following:

Understanding Admissions Parameters

The parameters for the Recruitment/Admissions Management module let you set data entry defaults as well as define areas where specific processing will occur automatically.

Table 270: Information Needed Before Setting Up Admissions Parameters

Item Reference

The catalog that you will use as your default catalog for all applications

Using Curriculum Management

Credit type codes “Credit Types” on page 178

Prospect status codes “Prospect Status Codes” on page 252

Student creation rules

Note: You can define the these rules “on paper” and enter them when you setup your admissions parameters.

“Student Record Creation Parameters” on page 752

Address type codes1

1.Used for the Common Application defaults. If you do not use the Common Application, you do not need to have these codes defined.

Using Demographics

Phone type codes1

Address change source codes1

Application status codes “Application Statuses” on page 143

749tting Started with Colleague Student | Setting Up Admissions Parameters

Ge

Note: You can change most of the data entry defaults at the time of data entry. These defaults let you define the value that is used most often.

Use the Admissions Parameters (ADPA) form to define the defaults for processing information in the Recruitment/Admissions Management module.

Figure 133: The Admissions Parameters (ADPA) Form

There are two types of defaults that you define on the Admissions Parameters form: data processing defaults and data entry defaults. The following sections define these defaults.

Admissions Processing Parameters

Data processing defaults control how Colleague processes data in the Recruitment/Admissions Management module. These parameters affect prospect data, transfer equivalencies, and the creation of a STUDENTS record from an APPLICATION record. Each of these defaults are explained below.

Snapshot Prospect Data

Snapshot Prospect Data is a yes/no parameter that directs Colleague to take a snapshot of an individual’s application and personal data at the time their status changes from prospect to applicant. Enter Y if you want Colleague to take a point-in-time snapshot of an applicant’s file when you assign the applicant an application status with a processing code that means “Applied.” If you want to keep historical information about the individual as a prospect, then you should set this flag to “Yes.”

Admissions Processing Parameters

Applicant/ProspectDefaults

Student Record Creation Parameters

Common Application Defaults


Ge

See “Application Status Processing Codes” on page 144 for a detailed explanation of the application statuses that will direct Colleague to snapshot prospect data.

Auto Create Transfer Equivalencies

Auto Create Transfer Equivalencies is a yes/no parameter. Enter Y if you want Colleague to automatically create transfer equivalencies, for which the applicant qualifies, from a secondary or post-secondary transcript. Enter N if you want to manually evaluate each applicant’s secondary or post-secondary transcript and create the appropriate equivalencies. See “Understanding Equivalencies” on page 774 for details about defining equivalencies.

Auto Update Application Status

Auto Update Application is a yes/no parameter. Enter Y if you want Colleague to evaluate your academic program admit rules each time you update an application record (from the Prospect Summary [PRSP] form, the Applications [APPN] form, the Applicant Summary [ASUM] form, or from any other prospect or applicant form). When one of your academic program admit rules evaluates true, Colleague updates the applicant’s application status as directed by that rule.

If you enter “No,” Colleague does not evaluate your academic program admit rules when you update an application record. If you set this parameter to “No,” run the batch admissions process (initiated from the Batch Admissions [BADM] form) to admit applicants based on your rules. See Using Recruitment/Admissions Management for information about the batch admissions process.

See “Academic Program Admit Rules” on page 736 for information about defining academic program admit rules.

Use Short Application

Use Short Application is a yes/no parameter. Enter Y if you want Colleague, when detailing from the Academic Program field on the Prospect Summary [PRSP] form or the Applicant Summary [ASUM] form, to access the Short Application (SHAP) form.

Enter N to have Colleague to detail to the Applications (APPN) form.

Applicant/Prospect Data Entry Defaults

Applicant/prospect defaults let you define defaults for many common data entry tasks related to entering information about applicants and prospects. Colleague displays these defaults at various data entry points. You can override all of these defaults during data entry as needed. When you enter an application, Colleague enters the 1997-1998 catalog in the Catalog field; however, you can enter a different catalog when necessary.


Ge

Table lists each of the applicant/prospect defaults you define on the Admissions Parameters form and explains these parameters, also indicating where Colleague uses the defaults you set.

Student Record Creation Parameters

The Student Record Creation parameters identify when you want Colleague to create a STUDENTS record from an APPLICANTS record. These parameters are:

• Student creation rules

• Create STUDENT record immediately parameter

• Copy admit statuses parameter

• Copy special services parameter

Table 271: Applicant/Prospect Data Entry Defaults

Applicant/Prospect Default Where Used Explanation

Housing desired flag Prospect Summary (PRSP) form and Applicant Summary (ASUM) form

Defines the default housing intent for each new applicant. This is a yes/no value.

Catalog Applications (APPN) form Defines the default catalog for every

application entered.1

1.Colleague will assign the default catalog to applications entered as Common Applications. However, this default does not display on any of the Common Application data entry forms. Use the Applications (APPN) form to change the catalog for any applicant entered this way.

Prospect status Prospect Summary (PRSP) form

Defines the default prospect status Colleague assigns to each new prospect.

Prospect application status

Prospect Summary (PRSP) form

Defines the default application status Colleague assigns to each prospect when you enter application information in the Academic Program group on the Prospect Summary (PRSP) form.

Application status Applications (APPN) form Defines the default application status Colleague assigns to any new application you enter on the Applications (APPN) form.

Equivalency credit type

Transfer Equivalency Evaluation (TEEV) form

Defines the default status Colleague assigns to each transfer equivalency you enter on the TEEV form.


Ge

• Application status

• Default “move to students” communications code

Because these parameters are interrelated, how you set them up affects how and when Colleague creates a STUDENTS record from an APPLICANTS record. See “How the Students Record Creation Parameters Work Together” on page 759 for details.

Student Creation Rules

Enter the rules Colleague uses to determine when to create a STUDENTS record from an APPLICANTS record in the Student Creation Rules field. When you define multiple STUDENTS creation rules, an applicant must pass all the rules before Colleague creates the STUDENTS record.

Note: Colleague will not create multiple STUDENTS records for one person based on the STUDENT record creation process.

See “Create Student Record Immediately” on page 757 for information about when Colleague uses the student creation rules.

When Colleague Evaluates the Student Creation Rule. Colleague evaluates your student creation rules based on how you set the Create Student Record Immediately parameter on the Admissions Parameters (ADPA) form. If you set this parameter to “Yes,” Colleague evaluates your rules when you update an applicant’s record. If you set this parameter to “No,” Colleague evaluates your student creation rules when

• You run the student record creation batch process. See Using Recruitment/Admissions Management for more information about the student record creation batch process.

• An applicant registers for class. At that time, Colleague evaluates the applicant’s record against the rules and creates the STUDENTS record if the record passes the rules. If the applicant does not pass the rule, the individual cannot register for class. See Using Recruitment/Admissions Management for more information about this option.

• You access the applicant’s record—and the applicant has an application on file—on the Student Profile (SPRO) form or on the Student Academic Program (SACP) form.

Note: Colleague recognizes the rules you list in the Student Creation Rules field on the Admissions Parameters (ADPA) form as your STUDENTS record creation rules.

How to Define Student Creation Rules. There are a number of different ways that you can define your STUDENTS creation rules. Your rules could look for a specific application status or for a combination of items such as a specific application status and the receipt an application deposit. You can also define one rule that you use for all applicants or you can define rules that are based on different characteristics, such as academic level or academic program.

If you define rules for different characteristics such as academic level, each rule must contain a statement that identifies which criteria you are evaluating. For example, you may want one rule for undergraduates and a separate rule for graduates. The rule you define


Ge

for undergraduate applicants must include the criteria that the application is associated

with the undergraduate academic level.1

Note: If you do not explicitly state the requirement for each rule, then applicants that you do not want to pass the rule might pass it.

When you define your STUDENTS record creation rules, you need to consider when and how Colleague evaluates these rules. For example, if you only want Colleague to immediately create STUDENTS records for continuing education students and you want to control when all other applicants are moved to the STUDENTS file, you would:

1. Write one rule specifically for the continuing education students. This rule would contain the criteria that the application is associated with the continuing education academic level.

2. Write another rule, or set of rules, for the other academic levels (such as undergraduate and graduate).

3. Set the Create Student Record Immediately parameter to “Yes.”

4. Enter only the rule for continuing education applicants in the Student Creation Rules field on the Admissions Parameters (ADPA) form.

With your rules and parameters set up as described above, Colleague evaluates only the rule for moving continuing education applicants to the STUDENTS file when you update an applicant’s record. Because this rule explicitly states that the application have a continuing education academic level, Colleague does not create a STUDENTS record for non-continuing education applicants. When you want to create STUDENTS record for the other applicants, run the batch STUDENTS record creation process.

Example of a Single Student Creation Rule. Fairfax Community College uses a single rule for determining when to create a STUDENTS record. This rule is based on the following items:

• The application must be accepted

• The application fee must be either received or waived

1.An individual may be associated with several different academic levels. However, when Colleague evaluates STUDENTS creation rules, it is looking at the information that is specific to one application.


Ge

Figure 134: Example of a Single Student Creation Rule

Fairfax Community College set the Create Student Record Immediately parameter to “Y,” so that Colleague evaluates the admit rule when the admissions office enters or modifies an application. If the rule is true (if all the conditions of the rule are met) Colleague creates a STUDENTS record for that application.

Example of Multiple Student Creation Rules. Ellucian University has two the student creation rules: one rule for creating the STUDENTS record for undergraduates and one for graduates. EU’s admissions process states that all undergraduate applicants matriculate as soon as they satisfy these rules but that the admissions office must selectively matriculate graduate applications. To implement this policy, the director of admissions:

1. Defined the two student creation rules.

2. Entered the ID of the undergraduate rule in the Student Creations Rules field on the Admissions Parameters (ADPA) form.

3. Set the Create Student Record Immediately flag on the ADPA form to “Y.”

When the admissions office enters or modifies an application, Colleague evaluates the undergraduate rule and, if it is true, creates a STUDENTS record.

The admissions office runs the student creation batch process (initiated from the Student Record Creation [SRCR] form) for the university’s graduate applicants. Figure 135 illustrates how EU’s admissions office sets this form for creating STUDENTS records for the selected graduates.


Ge

Figure 135: Running the Student Record Creation Process

Procedure for Defining Student Creation Rules

Complete the following steps to define student creation rules:








4. Go to the Admissions Parameters (ADPA) form.

5. Go to the Student Creation Rules field.

The Rules LookUp prompt is displayed

6. Enter the name of the student creation rule.



Ge

If the rule displays on the ADPA form continue with Step 13.

7. Enter A.


8. Enter the rule.



9. Save the rule.

The ADPA form redisplays with the cursor at the Rules LookUp prompt.

10. Repeat this procedure beginning with Step 9 for each student creation rule.

11. Go to the Create Student Record Immediately field.

12. Enter Y.

See Create Student Record Immediately below.

13. Save the admissions parameters.

If you are defining these rules while you are defining the admissions parameters, complete the other fields as necessary.

Create Student Record Immediately

Create Student Record Immediately is a yes/no parameter that determines when Colleague uses your student creation rules to create a STUDENTS record. Enter Y if you want Colleague to evaluate your student creation rules whenever you exit most admissions processes.

Enter N if you do not want Colleague to automatically invoke the student creation rule. If you enter “N,” you can create a STUDENTS record from an APPLICATIONS record by:

• Running the student record creation batch process (see Using Recruitment/Admissions Management).

• Letting Colleague check each applicant’s record when the individual registers for class.

• Letting Colleague create the STUDENTS record when you access the person through either the Student Profile (SPRO) form or the Student Academic Program (SACP) form.

Copy Admit Status

Copy Admit Status is a yes/no parameter that determines whether Colleague copies the admit status associated with the admitted application to the student’s STUDENT.ACAD.LEVELS record. Each application has an admit status that designates

an applicant’s original enrollment status at your institution.1 Examples of admit status include first time freshman and transfer student.


Ge

Enter Y if you want Colleague to copy the admit status from the admitted application to the STUDENT.ACAD.LEVELS record associated with that academic level.

Note: Colleague does not override an existing admit status on a STUDENT.ACAD.LEVELS record when it reevaluates your STUDENTS record creation rules.

For example, Ellucian University uses the following admit status codes:

• First time freshman

• Transfer

• Returning student

Below are three scenarios for how Ellucian University uses these statuses with the Copy Admit Statuses parameter to “Y.”

Scenario One: Multiple Applications at Once. As a transfer student to EU, William Shear submitted two applications: one to the bachelor of chemistry program and one to the pre-med program. The admissions office gave each of these applications an admit status of “transfer.” William was admitted to the university in the bachelor of chemistry program. When Colleague created his STUDENT.ACAD.LEVELS record, it copied the “transfer” admit status to his undergraduate STUDENT.ACAD.LEVELS record.

Scenario Two: Undergraduate to Graduate Progression. Alicia Nathan initially applied to EU prior to beginning her senior year of high school. She was accepted to the university in the bachelor of history program as a first time freshman for the fall 1990 semester. When the admissions office recorded her admissions application, they assigned her the “first time freshman” admit status code. When Colleague created her STUDENT.ACAD.LEVELSrecord for the undergraduate level, it copied the “first time freshman” admit status to that record.

In the 1993, Alicia applied to the masters of history program. The admissions office entered her new application with a “returning student” admit status. When Alicia was admitted to this program, Colleague created a STUDENT.ACAD.LEVELS record for the graduate level that included the returning student admit status.

Scenario Three: Multiple Applications over Time. In the spring of 1995, Margaret Webster submitted an application to EU’s bachelor of arts program as a first time freshman. She was admitted to the program, but she withdrew her application when she choose to attend a different school. The following year, however, Margaret reapplied to EU for the same program. This time the admissions office set the admit status on her new application to” transfer,” reflecting her current status. She was again accepted and when she was admitted, Colleague created a STUDENT.ACAD.LEVELS record with an admit status of “transfer.”

1.The STUDENT.ACAD.LEVEL file stores one record for each student at each academic level. Therefore, a student who was both an undergraduate and a graduate at your institution would have two records in the STUDENT.ACAD.LEVEL file.


75

9G

etting Sta

rted with C

olleague S

tudent

|S

etting Up A

dmissions P

aram

eters

H

t creation rules, the create STUDENT

SCR

lleague evaluates the rules each time eates the STUDENTS record and copies

lleague evaluates the rules each time eates the STUDENTS record but does

u must run the Student Record Creation creates the record based on the ot copy the admit status to the

TUDENTS record for any applicant, with (SPRO) form or the Student Academic tatus to the STUDENT.ACAD.LEVELS

TS record for any applicant you register. ACAD.LEVELS record.

ow the Students Record Creation Parameters Work Together

Table describes how Colleague interprets the different combinations of the settings of the studenrecord immediately parameter, and the copy admit statuses parameter.

Table 272: How the Student Record Creation Parameters Work Together

tudent reation ule?

Create Immed’ly?

Copy Status? Results

Y Y Y From the Recruitment/Admissions Management module, Coyou update an application; if the rules are true, Colleague crthe admit status.

Y Y N From the Recruitment/Admissions Management module, Coyou update an application; if the rules are true, Colleague crnot copy the admit status.

N N N From the Recruitment/Admissions Management module, yo(SRCR) process to create a STUDENTS record. Colleague parameters you define on the SRCR form. Colleague does nSTUDENT.ACAD.LEVELS record.

From the Academic Records module, Colleague creates a San application, that you access on either the Student ProfileProgram (SACP) form. Colleague does not copy the admit srecord.

From the Registration module, Colleague creates a STUDENColleague does not copy the admit status to the STUDENT.

76

0G

etting Sta

rted with C

olleague S

tudent

|S

etting Up A

dmissions P

aram

eters

u must run the Student Record Creation creates the record based on the the admit status to the

TUDENTS record for any applicant, with (SPRO) form or the Student Academic the STUDENT.ACAD.LEVELS record.

TS record for any applicant you register. EVELS record.

lleague creates a STUDENTS record ation from any admissions form. EVELS record.

lleague creates a STUDENTS record n from any admissions form. Colleague ELSrecord.

SCR

N N Y From the Recruitment/Admissions Management module, yo(SRCR) process to create a STUDENTS record. Colleague parameters you define on the SRCR form. Colleague copiesSTUDENT.ACAD.LEVELS record.

From the Academic Records module, Colleague creates a San application, that you access on either the Student ProfileProgram (SACP) form. Colleague copies the admit status to

From the Registration module, Colleague creates a STUDENColleague copies the admit status to the STUDENT.ACAD.L

N Y Y From the Recruitment/Admissions Management module, Cofrom any APPLICATIONS record when you update an applicColleague copies the admit status to the STUDENT.ACAD.L

N Y N From the Recruitment/Admissions Management module, Cofrom any applications record when you update an applicatiodoes not copy the admit status to the STUDENT.ACAD.LEV

Table 272: How the Student Record Creation Parameters Work Together (continued)

tudent reation ule?

Create Immed’ly?

Copy Status? Results

Ge

Copy Special Services Parameter

If you enter any special services codes for selected applicants on the Applicant Miscellaneous (AMSC) form, you can set the Copy Special Services parameter to “Yes” to copy these special codes from the applicant record to the individual’s STUDENTS record.

Special services codes refer to special academic services, such as a private tutor, or academic alert services. Special services codes are defined on the Validation Codes (VAL) form. These codes are used with the California Community Colleges MIS Reporting functions. (These codes do not pertain to medical or emergency services.)

After being transferred to the student record, the codes are stored by Colleague but not used for processing.

If you do not use special services codes, you can set this parameter to “No.”

Application Status

The Application Status field defines the default application status Colleague assigns to any new STUDENTS record that has been created from an admitted application.

Default Move-to-Student Communication Code

You can have Colleague initiate a process in the Communications Management module when an applicant becomes a student by entering a communication code in this field.

For example, Ellucian University has a new student communication track that they place each applicant on once they have been admitted to the university. The admissions office created a welcome letter and used the letter’s communication code as the default move-to-student communication code. The welcome letter communication code includes the instruction to put the student onto the new student communication track. Refer to Using Recruitment/Admissions Management for details about using the Communications Management module with your admissions processes.

Student Program Activation from Student Records

The Move-to-Stu Application Select Rules allow you to manage the application status for students who are being made active in an academic program from Student Records, rather then from the Admissions area.

When all the rules evaluate to be true for a specific application, the Move-to-Stu Application Select Status is assigned to the application. If there are multiple applications for the same academic program, then all of the applications that pass the rules will have the move to student application select status assigned, but the first application that evaluates to true is used to create the student programs record. The status for the applications that do not pass the rules, does not change.

If none of the applications pass the rules, the status is not changed, and the first application evaluated by the rules is used to create the student programs record.

The rules must use the APPLICATIONS file as the primary view file. For example, you could write a rule that would check to make sure the application was not rejected. The


Ge

checking criteria would be as follows:WITH APPL.CURRENT.STATUS NE ‘Rejected’

If you do not enter rules, then the first application found for the academic program that has not been marked as having had the student active in the academic program is used to default student program information and has it status changed to the Move-to-Stu Application Select Status.

If the application status should never be changed, you can define a rule that will always evaluate to be false for all applications. A Move-to-Stu Application Select Status is required, but will never be assigned to an application. The status is required because Colleague does not know at this point that all applications will fail the rules.

Move-to-Stu Application Select Status

The status in the Move-to-Stu Application Select Status field is assigned to the application when all the rules are true. This status must be a status used to indicate a move to students.

You can also use the status if the Move-to-Stu Application Select Rules field is left blank. When the student is added to an academic program for which applications exist, the status in this field is assigned to the first application found for the academic program.

If both the Move-to-Stu Application Select Rules and Status fields are blank when setting the application status from Student Records, the Application Status from the Student Record Creation section of the ADPA form is assigned as the application status. If the application from the Student Record Creation section of ADPA is blank, then the first application status from the Application Statuses (APSM) form with a Special Processing Code of “MS” is assigned to the application.


Use the Common Application Parameters (CAPA) form to enter and maintain the defaults used on common applications.


Ge

Figure 136: Common Application Parameters (CAPA) Form

Setting defaults for the common application lets you simplify data entry tasks for this type of application. Colleague displays these defaults at various data entry points.


Ge

Table 273 on page 764 lists each of the common application data entry defaults and explains these parameters, indicating where Colleague uses the defaults you set.

Table 273: Common Application Defaults

Common Application Default Where Used Explanation

Mail Address Type Common App Name and Address (CNAE) form

Defines the default address type for each applicant’s mailing address.

See Using Demographics for information about address types.

Mail Phone Type Defines the default phone type for each applicant’s phone number associated with their mailing address.

See Using Demographics for information about phone types.

Main Phone Type Defines the default phone type for each applicant’s home phone number.

See Using Demographics for information about phone types.

Address Change Source Defines the default source code for any address change recorded for an applicant.

Initial Application Status Defines the default application status code for each application.

Alien Status Common App Biographic Data (CBIO) form

Defines the default alien status entered in the FPER.ALIEN.STATUS field on the FOREIGN.PERSON file when a visa type is entered

Child Relation Type (Release 18)

Defines the default relation type representing a child relationship. The relation type entered in this field is used to create a relationship between the applicant and parents.

Sibling Relation Type (Release 18)

Defines the default relation type representing a sibling relationship. The relation type entered in this field is used to create a relationship between the applicant and other children of the applicant’s parents.


Ge

Procedure for Defining Admissions Parameters

To define the default parameters for the Recruitment/Admissions Management module:

1. Access the Admissions Parameters (ADPA) form to define your parameters.

2. Complete the following types of parameters:

• Admissions Processing

• Applicant/Prospect

• Student Record Creation

• Common Application Defaults (Release 16.0 Only)

Continue to Step 6 if you are on Release 16.0

3. Access the Common Application (CAPA) form (Release 17.0 Only)

4. Complete the common application defaults are needed.

5. Save the information on CAPA by finishing from the form.

The ADPA form is displayed again.

6. Save the information of ADPA by finishing from the form.


Ge

Defining Tests and Other Noncourse Items

In This Chapter

This chapter provides information about how to define test and noncourse work.

Before You Begin

Before you can define your noncourses you must define the following:

Understanding Noncourses

Noncourses are items such as tests, portfolios, military service, and other life experiences for which you give a student academic credit or use for admissions or placement

Table 274: Information Needed Before You Can Define noncourses

Description Where to Find It

Noncourse type codes 245

Noncourse category codes 243

Correspondence received codes Using Communications Management

Grade schemes1

1.You need to define the grade schemes from each institution or organization that administered a noncourse item you want to define. See “Grades and Grade Schemes” on page 769 for complete information about the use of grade schemes with noncourses.

403

Gradesa 402

Credit type codes 178

Student academic credit status codes

274

766tting Started with Colleague Student | Defining Tests and Other Noncourse Items

Ge

purposes. Common examples of noncourse items, and how they are used, are listed in Table 275.

Components of a Noncourse

Use the Noncourses (NONC) form to define each noncourse for which your institution assigns academic credit. Use the NONC form to define both tests and other noncourse items, such as military experience.

Table 275: Example Noncourses and Their Uses

Noncourse item Commonly Used In

SAT tests • admit rules as part of your admissions criteria

• application rating rules to assign a rating based on test score

• admissions tracking rules to update a correspondence received code when the test score is recorded

Advanced placement (AP) tests

• admit rules as part of your admissions criteria

• application rating rules to assign a rating based on test score

• admissions tracking rules to update a correspondence received code when the test score is recorded

• noncourse equivalencies to assign course or general academic credit based on test score

Military experience noncourse equivalencies to assign course or general academic credit based on training received

Life experience/on-the-job training

noncourse equivalencies to assign course or general academic credit based on specific experience and on-the-job training

Portfolios • communications requests as part of an admissions requirement

• noncourse equivalencies to assign course or general academic credit based on providing samples of work done in a specific area, such as an art or writing portfolio


Ge

Figure 137: Example of a Noncourse Item

This section describes the following components of a noncourse item:

• Category (required)

• Minimum, maximum, and desired score

• Grade and grade scheme

• Grade/score to use

• Equivalencies

Refer to the online help for the NONC form for information about the other fields on this form.

Noncourse Categories

Colleague distinguishes between tests and other noncourse items and within the broad group of tests, Colleague further distinguishes between admissions, placement, and other tests. These differentiations enable Colleague to sort an individual’s test scores by admissions tests, placement tests, and other tests on the Test Summary (TSUM) form. Colleague uses the noncourse categories to make these distinctions.

Noncourse categories use processing codes to identify the different type of tests. The processing code “A” identifies admissions tests, “P” identifies placement tests, and “T” identifies other tests.


Ge

SOC Credit Type

Each noncourse record can be classified into a specific category as defined by the Servicemembers Opportunity Colleges (SOC). These credit types are used when creating the SOC Student Agreement to categorize credit hours awarded.

Note: A SOC Student Agreement is a degree plan specifically for students who serve as active duty military and their eligible family members. For more information about SOC agreements, see “Setting Up Active Military and Veteran Student Information” on page 360.

Minimum, Maximum, and Desired Score

You can define a minimum, maximum, and desired score for a noncourse item. Colleague uses the minimum and maximum score fields to validate your entries when you record an individual’s test scores. For example, EU defined the SAT noncourse item with a minimum score of 200 and a maximum score of 1600. When someone in the admissions office records an applicant’s SAT scores they cannot enter a value that is less than 200 or greater than 1600.

Colleague does not use the desired score unless you incorporate it into an admissions rule. For example, part of your application rating rules may state that the SAT score, must be greater than or equal to the desired score for that test.

Grades and Grade Schemes

You associate a noncourse item with a desired grade and a grade scheme from the institution or organization that administered the noncourse item. If you use these fields you need to:

• Define the grade scheme from the institution/organization that administered the noncourse item

• Record a desired grade for that noncourse item

Colleague uses the grade scheme to validate the grade you enter when you record an individual’s grade for that noncourse item. If the noncourse item has an equivalency, Colleague defaults the grade scheme defined for the equivalency. See “Understanding Grades and Grade Schemes” on page 402 for information about defining grades and grade schemes.

Grade/Score to Use

If an individual may have multiple occurrences of a noncourse items, you can identify which grade or score Colleague uses as the accepted occurrence of that noncourse item. For example, if you record all occurrences of an applicant’s SAT scores but only use the


Ge

best score that the applicant received, enter BEST as the score that Colleague uses. You can use one of the following indicators for any noncourse item:

Equivalencies

You can create equivalencies for any noncourse that you define and associate the equivalency with one or more courses at your institution or for general academic credit or both. See “Understanding Noncourse Equivalencies” on page 780 for information about defining noncourse equivalencies.

Example Noncourse Items

This section describes the following noncourse items and provides some suggestions for defining each:

• Standard admissions tests with composite and component scores, such as the SAT, GMAT, or GRE.

• Tests for which you give general academic credit, such as an advanced placement test.

• Tests for which you give specific course credit, such as general competency tests.

• Military or other life experience for which you give general academic credit.

Standard Admissions Tests

You need to consider how you use scores from tests such as the SAT, GMAT, and GRE with components that are graded separately. Table provides some guidelines for defining these tests based no how you might use the different combination of composite, components, and sub-components of these tests.

Table 276: Options for Indicating Which Grade or Score Colleague Uses

Grade/Score Indicator Description

Last Colleague uses the most recent grade or score the individual received on the noncourse item.

Best Colleague uses the best grade or score the individual received on the noncourse item.

Sub Colleague uses the best grade or score the individual received on any subcomponent of the noncourse item.

Table 277: Examples of How You Could Define Tests with Components

If Your Admissions Rules … Then …

for all programs …


Ge

Figure 138 is an example of an SAT noncourse item. You can choose to create a separate noncourse item for the composite test, the verbal component, and the math component or make one noncourse item for the SAT test.

Figure 138: Example of SAT Noncourse Items

Tests with Specific Course Equivalencies

Figure 139 illustrates how Ellucian University defined the advanced placement English test with a course academic credit equivalency.

are based on only the composite score define a single noncourse item for the composite test

are based on the components define a noncourse item for each component only

are based on the sub-components only define a noncourse item for each sub-component

for some programs …

are based on the composite score while others use the components

define a noncourse item for the composite and for each component

are based on the composite, while others are based on the components, and others are based on the subcomponents

define a noncourse item for the composite. each component, and sub-component

are based on the composite while others are based on the sub-components

define a noncourse item for the composite and for each sub-component

Table 277: Examples of How You Could Define Tests with Components (continued)

If Your Admissions Rules … Then …


Ge

Figure 139: Example of SAT Noncourse Items with Specific Course Sections

Tests with General Academic Credit

Figure 140 illustrates how Ellucian University defined a general competency test for which the university assigns general academic credit.

Figure 140: Example of a Noncourse Item with General Academic Credit


Ge

Military Experience

Figure 141 illustrates how Ellucian University defined a noncourse item for military experience and gave that experience general academic credit.

Figure 141: General Academic Credit Provided for Military Experience

Procedure for Defining Noncourses

Complete the following steps to define your noncourse items:

1. Complete the noncourses worksheet on 791.

2. Access the Noncourses (NONC) form.

3. Define each noncourse item.

Use the worksheets created in Step 1.

Refer to the online help if you have a question about a specific field.


Ge

Defining Equivalencies

Before You Begin

Before you define equivalencies you must define the following:

Understanding Equivalencies

You define equivalencies to give credit for work done outside of your institution to either an applicant or a student. You can define equivalencies that equate:

• Courses taken at another institution with courses or general academic credit—or both—at your institution.

• Tests such as admissions or placement tests with courses or general academic credit—or both—at your institution.

Table 278: Information and Codes Needed Before Defining Equivalencies

Requirement See …

A record for each transfer institution Using Demographics

The course(s) that equate to the transfer course

Using Curriculum Management

Each noncourse that you want to define as an equivalency

“Defining Tests and Other Noncourse Items” on page 766

Academic levels 410

Academic programs Using Curriculum Management

Course level codes 176

Credit type codes 178

Department codes online help for the Departments (DEPT) form

Grades “Defining Grades” on page 402

Grade schemes “Grade Schemes” on page 402

Student academic credit status codes 274

Subject codes 281

774tting Started with Colleague Student | Defining Equivalencies

Ge

• Any other noncourse work, such as life experience or military experience, with courses or general academic credit—or both—at your institution.

This chapter describes how to define standard course and noncourse equivalencies. Colleague uses standard equivalencies to automatically assign the appropriate credit to an individual when you record that the individual has accomplished those requirements. For example, a typical standard equivalency equates one or more courses from another institution with one or more courses at your institution. When you enter an individual’s transcript information from the other institution, Colleague evaluates each course that the individual took and assigns the appropriate credit, based on the standard equivalencies.

“When to Define a Standard Equivalency” on page 783 describes the options for defining standard equivalencies. If you choose to define equivalencies before you use the Recruitment/Admissions Management module for daily processing, follow the procedures described on 786. If you choose to define standard equivalencies as you receive external transcripts, see Using Recruitment/Admissions Management.

Colleague also lets you define individual-specific equivalencies. Colleague assigns the credit that you define for the individual’s equivalency to that individual but does not use the equivalency for anyone else who may have the same set of requirements. For example, you may define an individual-specific equivalency to grant general academic credit to an individual based on his work experience. Because you defined an individual-specific equivalency, Colleague does not grant the same equivalency to another individual with the same experience.

See Using Recruitment/Admissions Management for information about defining individual-specific equivalencies.

Understanding Standard Course Equivalencies

Use standard course equivalencies to equate one or more courses from another institution with:

• Credit for one or more courses at your institution

• General academic credit

• Both course credit and general academic credit

Components of a Standard Course Equivalency

Use the Transfer Course Equivalencies (TCEQ) form to define a standard course equivalency.


Ge

Figure 142: Example of a Transfer Course Equivalency

This section describes the following fields on the TCEQ form:

• Transfer Course Credit

• Equivalent Course Credit

• Start Date and End Date

• Grade Scheme

• Minimum Grade

• Default Status

• Academic Programs

• Transfer Credits

• Equiv Credits

Refer to online help for information about any fields on the Transfer Course Equivalencies (TCEQ) form.

Transfer Course Credit

Use the Transfer Course Credit field, in the Transfer Course group, to identify the minimum number of credits an individual typically receives from the transfer institution for this course. Colleague uses this field to determine if an individual is eligible to receive this equivalency. Colleague makes this determination based on the number of credits that the individual received from the institution—as well as the other requirement for the equivalency. If an individual received fewer credits than you set as the minimum for the equivalency, Colleague does not grant the equivalency. Colleague also uses this value to

Transfer Courses Group

General Academic Credit Group

Equivalent Courses Group


Ge

calculate the total transfer credits in this equivalency (displayed in the Transfer Credits field).

Equivalent Course Credit

Use the Equivalent Course Credit field, in the Equivalent Course group, to identify the number of credits Colleague grants for the equivalent course. Colleague also uses this field to compute the total number of credits an individual will receive for this equivalency (displayed in the Equiv Credits field).

Start Date and End Date

Use the Start Date and End Date fields to indicate when the equivalency is valid. If you have only a start date, then any individual who took the class on or after that date can qualify for the equivalency. If the equivalency has both a start date and an end date, an individual must have taken the course between those dates to qualify for the equivalency.

When anything changes about an equivalency, give the current equivalency an end date and create a new one. For example, when State University redefined its ENG 100 course in September 1995, Ellucian University reassessed its equivalency and decided to change the equivalency for this course. The admissions office entered an end date for the original equivalency and created a new equivalency for the new transfer course. The start date of the new transfer course equivalency is the same as the end date of the old equivalency. The original equivalency is still valid, and anyone who took ENG 100 between the start and end dates can receive that equivalency. However, Colleague uses the new standard equivalency to assign credit to anyone who took ENG 100 after the original equivalency’s end date.

Grade Scheme

Use the Grade Scheme field to identify the transfer institution’s grading scheme. If you require that an individual receive a minimum grade on the course (or courses) to receive the equivalency, you must identify the grade scheme that defines that minimum grade. Colleague uses this grade scheme to associate a grade with its proper grade value. If the transfer institution uses a grade scheme that is identical to one of your institution’s, you may use that grade scheme; otherwise, you must define the institution’s grade scheme and use that in your transfer equivalency.

For example, Ellucian University’s undergraduate grade scheme is similar to State University’s grade scheme, so the equivalencies defined for State’s courses use Ellucian University’s grade scheme. However, Fairfax Community College uses a different grade scheme. Therefore, the admissions office defined Fairfax Community College’s grade scheme and uses it in the equivalencies to Fairfax’s classes.

Minimum Grade

Use the Minimum Grade field to identify the minimum grade that an individual must receive for the transfer course in order to receive the equivalency.


Ge

Default Status

Use the Default Status field to identify the status Colleague gives each equivalency when Colleague assigns the equivalency to an individual. This field is validated against the student academic credit status (STUDENT.ACAD.CRED.STATUSES) table. These codes indicate how the course was placed on the student’s record.

For transfer course equivalencies, you may have different status codes to identify the way a transfer course equivalency was assigned or whether the assignment is preliminary or approved. For example, you could have one status code for automatic assignment and one for manual assignment. Ellucian University uses two student academic credit status codes for transfer course equivalencies: PR for preliminary equivalency evaluation and TR for transfer equivalency evaluation. Standard transfer course equivalencies that an admissions office does to evaluate have a default status of TR, indicating that the equivalency is approved when it is assigned. If an admissions officer must review a transfer course equivalency before it is approved, the default status is PR. The university also uses the PR status code when entering a custom transfer course equivalency for an individual.

See “Student Academic Credit Statuses” on page 274 for details on these status codes.

Transfer Credits

See “How Colleague Calculates Transfer Course Credits” on page 779.

Equiv Credits

See “How Colleague Calculates Transfer Course Credits” on page 779.

Example Standard Course Equivalencies

Figure 143 on page 779 illustrates an example of one transfer course equating to one institutional course. To qualify for this equivalency, the individual must pass the following requirements.

When an individual meets these requirements, Colleague assigns 2.01 credits for Ellucian University’s ENGL*101 course (displayed in the Equiv Credits field and the Equivalent Courses group). See “How Colleague Calculates Transfer Course Credits” on page 779 for an explanation of why Colleague assigns 2.01 credits for this 3.00 credit course.

Table 279: Example Requirements

Requirement Field Reference

taken ENG 100 at State University Transfer Course and Transfer Institution

taken the course after September 4, 1982 Start Date

received at least a C in the course Minimum Grade

received at least 3.0 credits for the course Credit field in the Transfer Course Group


Ge

Figure 143 illustrates an example of multiple transfer courses equating to general academic credit. In this example, an individual who took the three courses at Fairfax Community College receives 9 hours of general biology credit at Ellucian University. (On the TCEQ form, the Transfer Course group displays only two courses at a time. However, in this example there are three courses listed. With the cursor on one of the courses in the group, the status line at the bottom of the form identifies that there are three values in the group.)

Figure 143: Example of a Course-to-Credit Transfer Course Equivalency

An individual transferring from Fairfax Community College qualifies for this equivalency if they have met the following requirements:

How Colleague Calculates Transfer Course Credits

When you define in Colleague a record for another institution, you indicate the credits conversion. Colleague calculates the appropriate transfer credits based on the equivalencies you enter for the conversion. Although the institution’s academic calendar may be different from your calendar, Colleague will use the calculation information entered in the transfer course equivalency record to compute the proper transfer equivalency.

Table 280: Example Requirements

Took HRT 110, HRT 151, and AGR 100 at Fairfax Community College

Transfer Course group and Transfer Institution

Took the course after June 21, 1980 Start Date

received at least a C in each course Minimum Grade

received at least 3.0 credits for each course Credit field in the Transfer Course Group


Ge

For example, the transfer course equivalency illustrated indicates that State University grants 3.00 credit hours to students who successfully complete ENG 100. This course is equivalent to Ellucian University’s ENGL*101, for which EU typically grants 3.00 credit hours. However, because State University’s credits conversion factor at Ellucian University is 0.67, the total transfer credits for ENG 100 is 2.01 (0.67 x 3.00). Because Ellucian University’s admissions office did not want a transfer student to receive 3.00 hours of credit for a course that earned an equivalent of 2.01 credit hours, the admissions office set the equivalent course (ENGL*101) to 2.01 credit hours.

When you define a transfer course equivalency, you should be aware of the values displayed in the Transfer Credits and the Equiv Credits fields at the bottom of the TCEQ form. The Transfer Credits field displays the total transfer credits that the transfer institution grants for the courses listed in the Transfer Course group. The Equiv Credits field indicates the total number of transfer credits an individual will receive for the equivalency. The Equiv Credits field is the sum of all the credits listed in the Equivalent Courses group.

As you record the transfer courses in the Transfer Courses group, Colleague calculates the value for the Transfer Credit field. When you record the courses, general credit, or both, that these transfer courses are equivalent to, Colleague calculates the value for the Equiv Credits field. To ensure that transfer students receive the proper credit hours for transfer courses, these two fields should be equal after you define the equivalency

Note: Colleague lets you complete the Transfer Course Equivalencies (TCEQ) form and save the equivalency when the Transfer Credits and Equiv Credits field are not equal. However, Colleague displays a warning message indicating that these values are different.

Understanding Noncourse Equivalencies

Use noncourse equivalencies to assign academic credit to an individual for their noncourse work. Noncourse work includes items such as tests, portfolios, military service, and other life experience.

Each noncourse equivalency defines the qualifications necessary to receive the equivalency and the type and amount of credit a qualified individual receives.

Components of a Noncourse Equivalency

Use the Noncourse Equivalencies (NONE) form to define noncourse equivalencies.

Figure 144 illustrates how Ellucian University set up a placement test as a noncourse equivalency.


Ge

Figure 144: Example of Noncourse-to-Course Equivalency

Many of the important fields on the Noncourse Equivalencies (NONE) form are the same as the fields described on 775. But for noncourse equivalencies you should also be aware of the following:

• Noncourse item

• Minimum and maximum scores and grades

Noncourse Items

Before you define a noncourse equivalency you must first define the noncourse item. See “Defining Tests and Other Noncourse Items” on page 766 for information about defining noncourse items.

Minimum and Maximum Scores and Grades

When you define a noncourse equivalency for an item such as a test that is either graded or scored, you can assign specific course or general academic credit based on the score or grade that the individual received.

For example, if you grant general academic credit if an individual receives a 4 or 5 on an advanced placement test, define the equivalency to require a minimum grade of 4.


Ge

Figure 145: xample of an Equivalency Using a Minimum Grade

You can use the minimum and maximum grade in the same way when the non-test item is graded instead of scored. Note, however, that if you use the minimum and maximum grade range you must also identify the grade scheme that defines the grades used for the noncourse item. For example, Ellucian University requires instructors to grade the portfolios required for admission to specialized programs. The instructors use a different grade scheme for these portfolios than they use for standard course work. Therefore, the admissions office identified this grade scheme with the noncourse equivalency.

Considerations for Defining Equivalencies

This section provides information for you to consider when implementing the Recruitment/Admissions Management module and deciding how to define your transfer course and noncourse equivalencies.

Transfer Course Name

When you enter an individual’s transfer courses on the External Transcript (EXTR) form, Colleague checks the standard equivalencies using the course name exactly as you enter it on the EXTR form. If Colleague finds a match, it evaluates the equivalency and, if the individual qualifies, assigns the equivalency. For example, if you define an equivalency for a course and use the name “CIS 100”—capital “CIS,” with a space between the suffix and the number—as the course name, when you record that an individual took this course, you must enter cis 100—capital “CIS,” with a space between the suffix and the number—on the EXTR form or Colleague will not recognize the course as one with a standard equivalency. If you enter transfer courses from the external transcript, be sure


Ge

that when you define the equivalencies that you use the course names as they appear on the institution’s external transcript.

Advanced Placement Courses and Advanced Placement Test?

If you grant academic credit to high school students who have taken either an advanced placement (AP) course or an advanced placement test, you should understand the difference between defining a transfer course equivalency and a noncourse equivalency.

Advanced Placement Courses

Transfer course equivalencies are specific to the transfer institution. Therefore, if you grant credit to students who took an advanced placement course at their high school, you will need to define transfer course equivalencies, including grade schemes, for this course for each high school.

When you record a high school transcript you must identify the high school and then enter information about each course taken (or at least each course that you want to record). As explained in “Understanding Standard Course Equivalencies” on page 775, Colleague creates an equivalency when an individual meets the qualifications of that equivalency. These qualification include taking the course at the specified institution. If you record that an applicant took AP math at County High you will need to have an equivalency defined for AP math at County High. As explained in When to Define a Standard Equivalency below, you do have the option to create the equivalency at the time you enter the high school transcript.

Advanced Placement Tests

If you grant credit for the advanced placement tests, define a test noncourse item that is not institution-specific. Therefore, you can define one noncourse item for the math advanced placement test and define one noncourse equivalency for that test. When you record an individual’s test scores, Colleague uses the equivalency to assign the appropriate academic credit.

When to Define a Standard Equivalency

A standard equivalency, whether for a transfer course or a noncourse, is an equivalency that you define as described in this chapter and that Colleague uses to grant academic credit to all qualified individuals. There are two ways that you can define a standard equivalency: when you set up the Recruitment/Admissions Management module or when you enter an individual’s transcript.


Ge

Defining Equivalencies During Set Up

This chapter describes how to define transfer course and noncourse equivalencies when you are setting up the Recruitment/Admissions Management module for daily use. You use the Transfer Course Equivalencies (TCEQ) form to define standard transfer course equivalencies and the Noncourse Equivalencies (NONC) form to define noncourse equivalencies. When you have numerous equivalencies to set up, and the information about those equivalencies is readily available, you may want to set up equivalencies in this manner. However, depending on the number of equivalencies you need to define, you may consider the option of defining standard equivalencies as you enter individual transcripts.

Defining Equivalencies When Entering a Transcript

When you enter an individual’s transfer courses from their external transcript, you can access the Transfer Equivalency Eval (TEEV) form and define an equivalency. Typically you would use this workflow when you are defining a customized equivalency. However,

you can also use this workflow to define your standard equivalencies.1

Use the TEEV form to define an equivalency for an individual and enter Y in the Std Equiv field on the TEEV form. When you save the record, Colleague creates a standard equivalency as well as the individual’s equivalency. Colleague can then assign this standard equivalency to others.

1.The concepts described here apply to defining noncourse equivalencies as well. Use the Noncourse Work Summary (NCWS) form to enter an individual’s noncourse work. From the NCWS form you can access the Noncourse Equiv Evaluation (NEQV) form and define the noncourse equivalency. Use the Test Summary (TSUM) form to enter an individual’s test scores. You can access the NEQV form from the TSUM form.


Ge

Figure 146: Defining an Equivalency from an Individual’s Equivalency

When someone applies as a transfer student from an institution you have not dealt with in the past, you will not have standard equivalencies defined for the institution. In this case you will need to determine the equivalencies you will give to the individual and also determine which of these equivalencies you want defined as standard equivalencies. There are two ways to enter these equivalencies. You could define the standard equivalencies first and then enter the individual’s transcript, allowing Colleague to create the equivalencies for the individual. Or you could record the individual’s transcript, go to the Transfer Equivalency Eval (TEEV) form, and define the equivalency for the individual and the standard equivalency at once.

This option is also useful for recording standard equivalencies during implementation. For example, you may have more standard equivalencies than you can define before you begin using the Recruitment/Admissions Management module for daily processing. Instead of defining the equivalencies all at once, wait until you receive transcripts from each institution and define the standard equivalencies as you record transcript information for an applicant.

A third alternative is to use a combination method in which you define the most common transfer equivalencies during your implementation period and define the less common equivalencies as you receive transcripts.

See Using Recruitment/Admissions Management for additional information about defining equivalencies when you enter an individual’s external transcript and noncourse work.

Note About Default Status

When you define an equivalency for an individual, each equivalent course, or general academic credit entry, has its own status. When Colleague creates a standard


Ge

equivalency from the individual’s equivalency, it uses the first status code as the default status for the standard equivalency.

For example, suppose a transfer course equivalency is defined for an individual. Because the admissions counselor entered a “Y” in the Std Equiv field, Colleague will create a standard equivalency from this equivalency. Because the status of the general academic credit is TR (transfer equivalency), Colleague creates the standard equivalency with a TR default status.

Note: You can change the default status that Colleague records for a standard equivalency you create based on an individual’s equivalency by modifying the standard equivalency on the Transfer Course Equivalency (TCEQ) form.

Procedures for Defining Equivalencies

This section provides the procedures for defining standard transfer course equivalencies and standard noncourse equivalencies. After completing these procedures, Colleague will use these definitions to assign equivalencies to individuals when you enter an individual’s transfer courses and noncourse work.

Procedure for Defining Transfer Course Equivalencies

Use the Transfer Course Equivalency (TCEQ) form to equate one or more external (transfer) courses with one or more courses, general academic credit, or both, at your institution. See “Components of a Standard Course Equivalency” on page 775 and online help for information about the TCEQ form.

Note: You define a transfer course equivalency for the institution that offers the course. If you have not defined an institution’s record for the offering institution, you can define that record at the time you enter the equivalency. See the Using Demographics manual for information about adding an institution.

Procedures for Defining Noncourse Equivalencies

Procedure for Defining a New Noncourse Item with an Equivalency

Complete the following steps to define standard transfer noncourse equivalencies when you are defining the noncourse item.

1. Go to the Noncourses (NONC) form.

2. Enter the name of the noncourse item.


Ge

The Record not found--Enter (A)dd or RETURN to reenter prompt is displayed.

If Colleague displays the noncourse item, continue with Step 5 to define the equivalency.

3. Enter A.

The cursor moves to the Title field.

4. Complete the general description of the noncourse item.

Refer to online help and “Components of a Noncourse” on page 767.

5. Go to the Start Date field of the Equivalencies group.

The following prompt is displayed:

Detail to add a new equivalency

6. Detail to the Noncourse Equivalencies (NONE) form.

The NONE form is displayed with the cursor at the Start Date field.

7. Define the following required items:

• Academic level (in the Acad Level field)

• Credit type (in the Credit Type field)

• Default status (in the Dflt Status field)

These fields are required when you assign credit to a noncourse item.

8. Go to the Equivalency Course field.

The Course LookUp prompt is displayed.

To equate this noncourse item to general academic credit, go to the Credit field. Continue with Step 11.

9. Complete the fields in the Equivalency Courses group to define this equivalency.

See “Components of a Standard Course Equivalency” on page 775 and “Components of a Noncourse Equivalency” on page 780.

10. Continue with Step 12.

11. Complete the fields in the General Academic Credit group to define this equivalency.


12. Save the equivalency.

Procedure for Defining a Noncourse Equivalency for an Existing Noncourse Item

Complete the following steps to define standard transfer noncourse equivalencies for an existing noncourse item.


Ge

1. Go to the Noncourse Equivalency (NONE) form.

The Noncourse LookUp prompt is displayed.

2. Enter the name of the noncourse item.

The noncourse item is displayed with the cursor in the Start Date field.

If Colleague cannot find the noncourse item you selected, use the “Procedure for Defining a New Noncourse Item with an Equivalency” on page 786 to define the noncourse item with an equivalency.

3. Define the following required items:

• Academic level (in the Acad Level field)

• Credit type (in the Credit Type field)

• Default status (in the Dflt Status field)

These fields are required when you assign credit to a noncourse item.

Refer to online help for information about these fields.

4. Go to the Equivalency Course field.

The Course LookUp prompt is displayed.

To equate this noncourse item to general academic credit, go to the Credit field. Continue with Step 7.

5. Complete the fields in the Equivalency Courses group to define this equivalency.


6. Continue with Step 8.

7. Complete the fields in the General Academic Credit group to define this equivalency.


8. Save the equivalency.


Ge

Recruitment/Admissions Management Worksheets

In This Chapter

This chapter provides worksheets that you can use to assist you in setting up the Recruitment/Admissions Management module.

Table 281: Worksheets for Setting Up the Recruitment/Admissions Management Module

Worksheet Reference

“Admissions Default Parameters” on page 790

“Procedure for Defining Admissions Parameters” on page 765

“Noncourse Definition” on page 791 “Procedure for Defining Noncourses” on page 773

“Noncourse Equivalencies” on page 792 “Procedures for Defining Noncourse Equivalencies” on page 786

“Course Equivalencies” on page 794 “Procedure for Defining Transfer Course Equivalencies” on page 786

789tting Started with Colleague Student | Recruitment/Admissions Management Worksheets

Ge

Admissions Default Parameters

Table 282: Admissions Default Parameters Worksheet

Default Setting

Data Processing Defaults

Snapshot Prospect Data Circle one: Yes No

Auto Create Transfer Equivalencies

Circle one: Yes No

Auto Admit/Update Application Status

Circle one: Yes No

Student Creation Rules1

Create Student Record Immediately

Circle one: Yes No

Copy Admit Status Circle one: Yes No

Default Move-to-Students Communication Code

Data Entry Defaults

Default Housing Desired Flag Circle one: Yes No

Default Catalog

Default Prospect Status

Default Application Status for Prospects

Default Application Status

Default Equivalency General Credit Type


Mail Address Type

Mail Phone Type

Main Phone Type

Address Change Source

Initial Application Status


Ge

Noncourse Definition

Note: If this noncourse item has an equivalency, complete the worksheet “Noncourse Equivalencies” on page 792 and attach the completed worksheet to this worksheet.

1.You can have an unlimited number of student creation rules.

Table 283: Noncourse Definition Worksheet

Noncourse Item:

Field Value

Title:

Description:

Type

Category

Std Test ID

Form Name Form Number

Component Of

Minimum Score

Maximum Score

Desired Score

Grade Scheme

Desired Grade

Grade/Score to Use Circle one:LASTBESTSUB


Ge

Noncourse Equivalencies

Note: Use this worksheet in conjunction with the worksheet “Noncourse Definition” on page 791 to define a noncourse item and its equivalencies. Use the back of this worksheet to define the equivalencies for this noncourse item.

Table 284: Noncourse Equivalencies Worksheet

Noncourse Item:

Field Value

Start Date

End Date

Academic Level

Credit Type

Grade Scheme

Default Status

Description

Institution

Academic Programs


79

3G

etting Sta

rted with C

olleague S

tudent

|R

ecruitment/A

dmissions M

anagement W

orksheets

E

Grade

x. Min. Max.

C

Grade

x. Min. Max.


quivalent Course ID Credit

Score

Min. Ma


redit SubjectCourse Level Dept.

Score

Min. Ma

Ge

Course Equivalencies

Table 287: Course Equivalencies Worksheet

Transfer Institution:

Transfer Course ID:

Transfer Course Credits:

Field Value

Start Date

End Date

Academic Level

Credit Type

Grade Scheme

Minimum Grade

Transfer Credits

Equiv Credits

Default Status

Description:

Academic Programs


Ge


Equivalent Course ID/Title Credit Course Level


Credit SubjectCourse Level Dept.


Registration

Ge

Defining Registration Rules

In This Chapter

This chapter provides information about defining rules used during registration which controls which processes will be executed.

Before You Begin

Before you read this chapter and begin defining your registration rules you should read “Understanding the Rules Processor” on page 309 for information about the basic principles of the Colleague rules processor.

Because all of your registration rules are defined within your registration controls, you need to understand your registration controls before you define your rules. See “Understanding Registration Controls” on page 805 for more information about registration controls.

Understanding Registration Rules

In the Registration module you can define rules to control specific processes which occur during registration. Each of these rules must be defined for each registration control you set up. The specific rules that you define in this module are referenced in Table 290.

The following sections explain each of the rules that you can define for the Registration module.

Table 290: Rules Defined in the Registration Module

Rule Reference

Student Eligibility 799

Course Eligibility 801

Completion Eligibility 803

798tting Started with Colleague Student | Defining Registration Rules

Ge

Student Eligibility Rules

If there are criteria which you want each student to meet before you allow them to register, then you need to define student eligibility rules.

When Colleague Evaluates the Student Eligibility Rules

Colleague evaluates the student eligibility rules when attempting to register during the registration processing. If a student does not pass one of the rules, Colleague does not allow registration into any sections in the registration time period for which the rule failure occurred.

Note: Student Eligibility Rules are enforced on a Registration Time Period (PreReg, Reg, Add/Drop, Other) basis. The rules are checked if the Registration Controls record in use is enforcing Student Eligibility Rules for the registration time period matching the registration time period of the course section being processed.

How to Define Student Eligibility Rules

Use the STUDENTS file or any co-file of STUDENTS as the primary view for your student eligibility rules. For example the PERSON, APPLICANTS, PERSON.ST, and PERSON.EMER files. Use the Registration Controls (RGCT) form to define your student eligibility rules.

How to Define Student Eligibility Rules to Require Confirmation of Emergency Information

If your institution requires students to review their emergency information prior to registration and confirm that it is accurate, you can create a student eligibility rule to prevent registration until the information is confirmed.

The Student Eligibility rule that you will need to create is based on the number of days since the student last confirmed their emergency information or missing person information. If the last confirmed date is within the defined date range, the student can register for courses. If the student has not confirmed their emergency information within the time frame you indicate, then they cannot register for courses.


Ge

Figure 147: Example of the Student Eligibility Rule

The rule for the confirmation of emergency information should include the following:

• Primary File View of PERSON.EMER

• Left-hand Expression of EMER.DAYS.SINCE.CONFIRMED

• Right-hand Expression equal to the number of days

• Rule Failure Message of “You must go to the User Profile tab and confirm your emergency information.”

When the rule is evaluated, Colleague uses the EMER.DATE.SINCE.CONFIRMED computed column to calculate the number of days from the date the student's emergency information was last confirmed to today, and compares that to the number of days you entered in this rule.

Procedure for Defining Student Eligibility Rules

Complete the following procedure to define your student eligibility rules.


Use the worksheet “Student Eligibility Rules — English Statements” on page 853.


Note: The data elements you use must be from the STUDENTS file or one of the co-file files of the STUDENT file.


Ge



4. Go to the Registration Controls (RGCT) form.

5. Enter the registration control for which you want to define student eligibility rules.

6. Move to the Student Eligibility Rules field.

7. Enter the name of the student eligibility rule.


If the rule displays on the RGCT form, continue with Step 11.

8. Enter A.


9. Enter the rule.


10. Save the rule.

11. Repeat this procedure, beginning with Step 7, for each student eligibility rule for this registration control.

12. Enter Y in the appropriate fields to tell Colleague during which registration time periods to evaluate these eligibility rules.

• Prereg

• Reg

• Add/Drop

• Other

13. Save the registration control record.

Course Eligibility Rules

If there are criteria which you want each student to meet before you allow them to register for a particular course section, then you need to define course eligibility rules.

When Colleague Evaluates the Course Eligibility Rules

Colleague evaluates your course eligibility rules during the registration process after you have selected the course section. If a student does not pass one of the rules, Colleague does not allow the student to register for the course section.


Ge

How to Define Course Eligibility Rules

Use the STUDENTCOURSE.SEC file as the primary view for your course eligibility rules. Use the Registration Controls (RGCT) form to define your course eligibility rules.

Procedure for Defining Course Eligibility Rules

Complete the following procedure to define your course eligibility rules.


Use the worksheet “Course Eligibility Rules — English Statements” on page 854.


Note: The data elements you use must be from the STUDENT.COURSE.SEC file, or one of the subsidiary files associated with it.




5. Enter the registration control for which you want to define course eligibility rules.

6. In the Course Eligibility Rules field, enter the name of the course eligibility rule.



7. Enter A.


8. Enter the rule.


9. Save the rule.

10. Repeat this procedure, beginning with Step 6, for each course eligibility rule for this registration control.


• Prereg

• Reg

• Add/Drop

• Other


Ge


Completion Eligibility Rules

If there are criteria which you want each student to meet before you allow them to complete registration, then you need to define completion eligibility rules.

When Colleague Evaluates the Completion Eligibility Rules

Colleague evaluates your course eligibility rules at the end of the registration process after you have begun updating the student’s record. If a student does not pass one of the rules, Colleague cancels the student’s registration.

How to Define Completion Eligibility Rules

Use the STUDENTS file or any co-file of the STUDENTS file as the primary view for your completion eligibility rules. Use the Registration Controls (RGCT) form to define your completion eligibility rules.

Procedure for Defining Completion Eligibility Rules

Complete the following procedure to define your completion eligibility rules.


Use the worksheet “Completion Eligibility Rules — English Statements” on page 855.


Note: The data elements you use must be from the STUDENTS file or one of the co-file files of the STUDENTS file.




5. Enter the registration control for which you want to define completion eligibility rules.

6. In the Completion Eligibility Rules field, enter the name of the completion eligibility rule.



Ge


7. Enter A.


8. Enter the rule.


9. Save the rule.

10. Repeat this procedure, beginning with Step 6, for each completion eligibility rule for this registration control.


• Prereg

• Reg

• Add/Drop

• Other



Ge

Defining Registration Controls

In This Chapter

This chapter provides information about how to define registration controls, which defines the different types of registration available to students.

Before You Begin

Before you can set up registration control codes, the following information must already be set up:

Understanding Registration Controls

Registration controls are sets of parameters that define the different types of registration available to students. For example, during registration you may have you might have students registering over the internet, advisors registering students from their office, and register staff assisting students in their office. The operators working in the undergraduate registration lines would use the registration controls that limit the registration to undergraduate students. You can also use the registration controls to limit the registration offered at a satellite campus to only the courses offered at that campus while at the main campus students can register for all courses, regardless of where they are taught.

Table 291: Information Needed Before You Can Define Registration Controls

Item Reference

Academic terms “Defining Academic Terms” on page 417

Application statuses “Application Statuses” on page 143

Enrollment statuses “Enrollment Statuses” on page 190

Housing assignment statuses “Housing Codes” on page 234

Registration process periods “Registration Process Periods” on page 256

Registration defaults “Understanding Registration Defaults” on page 836

805tting Started with Colleague Student | Defining Registration Controls

Ge

After you have defined your registration control codes, you assign them to groups of staff members who register students. You can assign multiple registration control codes to one group, but each staff member must select a single control to use during a particular registration session. You can define groups of registration users with authority to override many of the checks you establish with registration control codes. For this reason, you might want to keep your registration control codes relatively general and create a wide variety of registration user groups with different levels of override authority.

When you define your registration controls, you can choose during which registration process periods Colleague should evaluate each eligibility rule and registration check. The actual dates for these time periods are defined for each academic term. The term dates default into new course sections, but can be modified, as appropriate.

If a staff member enters a registration session without an assigned registration control code, Colleague will assign her the default control code “Nameless.” Ellucian delivers this “Nameless” record with Colleague. Colleague also uses the “Nameless” record to set the initial values for any new Registration Controls records you create. See “Components of a Registration Control” on page 806 for information about defining registration control codes.

See “Understanding Registration User Groups” on page 826 for more information about assigning registration control codes to groups of registration users. See “Case Study: Setting Up Registration Control Codes and User Groups” on page 834 for an example of setting up registration control codes and registration user groups.

Components of a Registration Control

Use the Registration Controls (RGCT) form to define each registration control code.


Ge

Figure 148: Components of the Registration Controls (RGCT) Form

Each registration control code represents a unique combination of the following components:

• LookUp Restrictions. Use to place restrictions on how LookUps are performed against student and section records. For more information, see “LookUp Restrictions” on page 808.

• Registration Parameters. Use to set data entry defaults as well as define areas where specific processing will occur automatically. For more information, see “Registration Parameters” on page 809.

• Eligibility Rules. Use to define the situations under which a student can register for class. For more information, see “Eligibility Rules” on page 821.

• Checks. Use to define various checks that Colleague should evaluate before allowing a student to enroll in a course. For more information, see “Checks” on page 822.

As described in the following section, Colleague enforces any LookUp restrictions and defaults associated with a registration control code whenever that control is used. However, you choose when Colleague evaluates any eligibility rules and checks by associating these components with different registration processing periods. The registration process dates are defined for each academic term. Course sections which are not associated with an academic term are considered Other. See “Defining Academic Terms” on page 417 for more information about how these dates are defined.

LookUp Restrictions

Eligibility Rules

Registration Parameters

Checks

Registration Process Periods


Ge

LookUp Restrictions

During registration, you may not want to allow a search of all available records. For example, you may want to limit the student LookUp to undergraduate students only. For each registration control code you can place restrictions on how LookUps are performed against student and section records.

Use the Reg LookUp Restrictions (RGLR) form to specify criteria that limit the LookUp and display of course sections, as well as the LookUp of students for a particular registration control code. The restrictions defined on this form are enforced in Colleague, and WebAdvisor wherever the associated registration control code is used.

Figure 149: Components of the Reg LookUp Restrictions (RGLR) Form

Section Lookup Restrictions

Use this field to restrict a LookUp by entering a Uniquery WITH clause if you do not want to allow selection from all course sections during registration. Colleague uses this restriction whenever this registration control is used.

The restrictions are used to restrict Section LookUp, and must therefore be valid for the COURSE.SECTIONS file. For example, to set up one of your registration control codes to limit the course section LookUp and resolution to show only undergraduate course sections, you could define the section display restriction as WITH STC.ACAD.LEVEL = “UG.”

Apply Section LookUp Restrictions as Section Display Restrictions

Enter Y if you want the Section LookUp Restrictions that are defined on this form to apply to the display of active, registered sections on registration forms in Colleague and WebAdvisor. Setting this field to “Y” causes the Section LookUp Restrictions specified to also be applied to the display of active, registered course sections.


Ge

The restriction to the display of course sections is enforced on Colleague and WebAdvisor forms that permit an action to be taken on the course sections. For instance, in the Current Registrations window on the Register and Drop Sections form in WebAdvisor.

Section Display Restrictions

Use this field to restrict a LookUp by entering a Uniquery WITH clause if you do not want to allow selection from all the course sections for which a student is actively registered. The criteria you enter must be valid for the STUDENT.ACAD.CRED file.

The restriction to the display of course sections is enforced on forms that permit an action to be taken on the course sections. For instance, in the Current Registrations window on the Register and Drop Sections form in WebAdvisor. For example, to set up one of your registration control codes to limit the section display LookUp and display main campus sections on registration forms, you would define the section display LookUp restriction as WITH SCS.LOCATION = 'MAIN'.

Student LookUp Restrictions

If, during registration, you do not want to select all students, then you can restrict that LookUp by entering a Uniquery statement here. Colleague uses this restriction whenever this registration control is used.

For example, to set up one of your registration control codes to limit the student LookUp to only the students with a home location of your main campus, you would define the student LookUp restriction as WITH STU.CURRENT.HOME.LOCATION = 'MAIN'. Only students with that main location will be retrieved when a student LookUp is done on the registration forms.

Restrict LookUp by Staff Location

Each staff member has a list of locations defining his range of authority. You can limit the course sections or students that each staff member can access during registration to only those locations. See the Staff and Volunteers (SVM) form for more information about defining a staff member’s authorized locations.

Users assigned to this set of parameters cannot override these LookUp restrictions. They can further restrict the selection, using standard LookUp options, but they cannot expand the selection.

Registration Parameters

You can define additional subroutines and registration parameters for each registration control. These parameters let you set data entry defaults as well as define areas where specific processing will occur automatically. These parameters are defined on the Registration Parameters (RGPP) form which you can access from the Registration Parameters field on the Registration Control (RGCT) form, and on the Registration Print Parameters (RSPP) form, which you can access from the Print Statements field on the RGPP form.

The Registration Parameters (RGPP) form has the following main components:


Ge

• Print setup (used for printing registration statements and schedules, as well as displaying account information on WebAdvisor forms)

• Data entry defaults

• Section percent full

• Pay now

• Allow pass/fail

• Allow audit

• Registration subroutines

• Waitlist defaults

Figure 150: Components of the Registration Parameters (RGPP) Form

Each of these registration parameters are explained in this section.

Print Setup for Registration Statements & Schedules

Note: This section describes how to define registration print parameters for printed registration statements and schedules. See “Print Setup for Account Information Displayed on WebAdvisor Forms” on page 49 for information about defining these parameters for WebAdvisor.

If you want to print a billing statement or a course schedule for each student you register with this control, set the corresponding print parameter to “Y.” You can define limited

Print Setup

Data Entry Defaults

Registration Subroutines

Percent Full


Ge

specifics about printing both the statements and student schedules on the RGPP form including:

• Subroutines to run at the time of printing

• Which printer to use

• Which form image to use

To define detailed specifics about printing registration billing statements, you can access the Registration Print Parameters (RSPP) form from the Print Statements field on the RGPP form, or directly from a menu.

Figure 151: Components of Registration Print Parameters (RSPP) Form

Use the RSPP form to define specific details about registration billing statements. Colleague uses these settings each time a registration statement is printed using this registration control. You can also use the RSPP form to define the parameters used for printing student schedules with the Registration (RGN) process.

Colleague also uses the statement settings when you generate billing statements using the Registration Statement Print (RGST) process. You can override both the statement and schedule settings for individual registration users on the Registration Users Parameter (RUPM) form. See “Assigning Registration Controls to Registration Users” on page 826 for details.

If you print the registration statements using the RGST process, you can assign a specific registration user group at the time you generate the statements. See Using Accounts Receivable/Cash Receipts for more information about using the RGST process.

Registration Billing Statement Parameters

Student Schedule Parameters


Ge

Print Statements

If you set the Print Statements field to “Yes,” Colleague automatically prints a registration billing statement each time a staff member using this registration control registers a student. Colleague uses the statement parameters you define on the RSPP form when a statement is printed. If you do not define specific statement print parameters, Colleague uses the default parameter settings described below.

If you set this field to “No” and do not enter specific statement print parameters, you can still print registration billing statements using the Registration Statement Print (RGST) process as long as you specify a Registration Users group on the RGST form that has the Print Statements field set to “Yes.”

Statement Print Subroutine, Printer, and Form Image

Colleague uses these settings to determine the format of the statement (print subroutine), the printer on which the statements are printed, and the type of form on which they print. In addition to defining the statement printer, you need to set your statement printer to use the settings listed in Table 292 below.

Note: If you define your form image to use the Ellucian-delivered Moore form, you cannot print remittance slips with your statements. Define your statement form image parameter to use standard plain-paper forms or perforated paper if you want to print remittance slips with your statements. Or you can use your own customized statement print routines and forms instead.

Listed below is a brief description of each registration statement print parameter. For detailed explanations and examples of each parameter, see the chapter on printing registration statements in Using Accounts Receivable/Cash Receipts.

Summary Level

You can define the level of detail you want printed on your registration statements. Colleague offers the following summary options:

• summary level - to print one line for each invoice

• detail level - to print detail lines for each invoice

• net level - to print AR code totals for each invoice

• AR code level - to print AR code totals by term

Table 292: Printer Settings Required for Registration Statements

Parameter Value

Number of lines per page 88 lines

Number of characters per inch 15 characters


Ge

• AR category code level - to print AR category totals by term

Colleague defaults the Summary Level field to the Detail option.

Calculate Remaining FA

This field is not currently used for printed registration statements. See “Calculate Remaining FA” on page 815 for information about defining this field for displaying account information on WebAdvisor forms.

Colleague defaults this field to “No.”

Deduct Remaining FA

You can choose to deduct financial aid that has been awarded but not yet transmitted to a student’s AR account for the statement period. Colleague only includes those awards that have been defined as Destination 1, 6, or 7. Pending financial aid awards are summed and deducted from the amount owed by the student.

Colleague defaults this field to “No.” If you do not show remaining financial aid, only awards that have been transmitted and applied to the student’s AR account are reflected on the statement.

Show Section Synonym

Colleague prints the course section’s name on the registration statement, however, you can choose to override the default and print the course section synonym instead.

Show Waitlisted Courses

You can choose to show any courses for which the student is waitlisted on the registration statement. Colleague defaults this field to “No,” and does not print waitlisted courses.

Name/Address Hierarchy

You can specify what type of name and address are printed on the statements. Colleague defaults this to the preferred address, but you can enter another address type.

Produce Remittance Slip

Colleague prints a remittance slip on the top of the first page of the registration statements, however, you can choose to override the default and not to include a remittance slip. If you defined your form image to use the Ellucian-delivered Moore form, Colleague ignores what you enter here and does not print remittance slips at all. If you choose to print remittance slips with your statements, you must define your statement form image to use standard plain-paper forms or perforated paper. Or you can also use your own customized statement print routines and forms instead.


Ge

Show Balance Forward

You can choose to include any unpaid balances for students on your registration statements. Colleague calculates and prints this amount on the statement, and adds it to the total amount owed by the student. Colleague determines the balance forward date using the date range defined for the registration statement billing period.

Colleague defaults this field to “No,” and does not include a balance forward amount on the statement.

Show Other Charges

You can add a section to the registration statement which prints any other charges that have been billed to the student during the statement period for the same type of receivable. Examples include charges for rooms and meal plans, as well as miscellaneous charges.

Colleague defaults this field to “No,” and does not include a section with these types of charges on the statement.

Show Future Charges

This field is not currently used for printed registration statements. See “Show Future Charges” on page 817 for information about defining this field for displaying account information on WebAdvisor forms.

Colleague defaults this field to “No.”

Print Schedule

If you set the Print Schedule field to “Yes,” Colleague automatically prints a separate student schedule each time a staff member using this registration control registers a student. Colleague uses the parameters you define on the RSPP form when a statement is printed with the registration process. This option is primarily used by institutions that do not print registration statements, as registration statements always include a course schedule section.

If you set this field to “No,” you can still print student schedules using the Student Schedule Print (SCHD) process.

Schedule Print Subroutine, Printer, and Form Image

Colleague uses these settings to determine the format of the student schedule printed (print subroutine), the printer on which the forms are printed, and the name of the form on which they print.

Print Setup for Account Information Displayed on WebAdvisor Forms

This section describes how to define registration print parameters on the Registration Print Parameters (RSPP) form for the following WebAdvisor forms:


Ge

• Account Summary

• Account Summary by Term

• Make a Payment

See “Print Setup for Registration Statements & Schedules” on page 810 for information about defining these parameters for printed statements and schedules.

If you want to display account information for students on WebAdvisor forms, define the print parameters for the Web registration user as explained in this section.

Note: Colleague uses the parameters listed in this section to display account information on WebAdvisor forms. If you enter any other parameters on the RSPP form, Colleague ignores them for the Web registration user.

Print Statements

This field must be set to “Yes” to display accounts receivable information on WebAdvisor forms. Setting this field to “Yes” will not cause registration statements to print when a student registers through WebAdvisor — it simply enables you to define the print parameters that determine how accounts receivable information is displayed on WebAdvisor forms.

Note: Setting this field to “Yes” requires you to enter a statement print subroutine, even though it is not currently used by Colleague for Web registration.

If you set this field to “No,” Colleague clears any print parameters you may have defined on the RSPP form.

Calculate Remaining FA

This field determines whether financial aid amounts that have not yet been transmitted to the student’s account (Financial Aid Remaining) are displayed on WebAdvisor forms as estimated amounts, or as calculated amounts based on conditions of enrollment, eligible charges, and rules.

If you enter “Yes,” Colleague performs any enrollment and eligibility checks to determine the amount of financial aid that the student would receive if the funds were actually transmitted as of the end of the award period.

If you enter “No,” Colleague displays the amount of the financial aid that has not yet been transmitted to the student’s account. This amount is basically an estimate, as it does not take into account the student’s enrollment nor eligibility.

For example, a student has a $500 financial aid award, of which $300 has already been transmitted to the student’s account. Due to current enrollment conditions, the student is not eligible to receive the remaining $200.

If you enter “Yes” to calculate, Financial Aid Remaining would display as zero, as the student is not currently eligible to receive the remaining $200. If you enter “No,” Colleague


Ge

does not take the student’s eligibility into account, and Financial Aid Remaining displays the $200 that has not been transmitted (even though the student is not currently eligible to receive the remaining amount).

Note: You can define whether Colleague considers responsed amounts for electronic loans that have not yet been received and rostered when Financial Aid Remaining is calculated (when Financial Aid Remaining is estimated, Colleague always uses the full amount of the award that has not yet been transmitted). Use the Loan Award Definition (LAWD) form in the Financial Aid module to define this parameter.

Deduct Remaining FA

This field determines whether or not the Financial Aid Remaining amounts displayed on the WebAdvisor forms are deducted from the amount due, or just displayed for informational purposes.

If you enter “Yes,” Colleague deducts the Financial Aid Remaining from the amount due on the WebAdvisor forms.

If you enter “No” or leave this field blank, Colleague displays the Financial Aid Remaining, but does not deduct it from the amount due.

Note: Financial aid that has already been transmitted is included in the Financial Aid Payments amount on the My Account Summary and My Account Summary by Term forms, and in the Payments amount on the Make a Payment form. Financial aid that has already been transmitted is always deducted from the amount due.

Show Balance Forward

This field determines whether or not to display (and make payable) any balance forward amount for the account holder on the WebAdvisor forms.

Balance forward is the sum of past charges minus the sum of past payments as outlined below:

• Registration charges and payments

• Other charges and payments (if you set the Show Other Charges field on the RSPP form to “Yes”)

• Financial aid payments

• Financial aid remaining(if you set the Deduct Remaining FA field on the RSPP form to “Yes”)

• Payment plan amounts.

Note: Payment plans amounts are deducted from the balance forward, but are not payable on Make a Payment.


Ge

Refer to the WebAdvisor Installation and Administration manual for information about how Colleague determines past charges and payments.

If you enter “Yes” to Show Balance Forward, Colleague displays the following:

• My Account Summary. Displays the balance forward amount in the “Balance Forward” line at the top of the form, and includes it in the Total Charges and Total Amount Currently Due for the account holder. If the account holder does not have a past amount, Colleague displays zero as the balance forward.

• Make a Payment. Includes the balance forward amount in the balance(s) displayed for payment.

Note: My Account Summary by Term always displays all terms and/or non-term invoices with a non-zero balance, regardless of how you set the Show Balance Forward field.

If you enter “No” or leave the Show Balance Forward field blank, Colleague does not display or include the balance forward amount (if any) on the My Account Summary or Make a Payment forms.

Show Other Charges

This field determines whether or not to include other types of charges and payments (such as room and board, bookstore, etc.) in addition to registration charges and payments on the WebAdvisor forms.

If you enter “Yes” to Show Other Charges, Colleague includes other charges and payments with the registration charges and payments displayed on the WebAdvisor forms.

Note: If you set the Show Balance Forward and/or the Show Future Charges fields on RSPP to “Yes,” the balance forward and future charges amounts include other charges and payments (for example, room and board, bookstore, etc.) in addition to registration charges and payments. Otherwise, only registration charges and payments are included in Balance Forward and Future Charges.

If you enter “No” to Show Other Charges, Colleague includes only registration charges and payments on the WebAdvisor forms.

Show Future Charges

This field determines whether or not to display (and make payable) any future charges for the account holder on the WebAdvisor forms.

Future charges is the sum of future charges minus the sum of future payments as outlined below:

• Registration charges and payments

• Other charges and payments (if you set the Show Other Charges field on the RSPP form to “Yes”)


Ge

• Financial aid payments

• Financial aid remaining(if you set the Deduct Remaining FA field on the RSPP form to “Yes”)

• Payment plan amounts

Note: Payment plans amounts are deducted from future charges, but are not payable on Make a Payment.

Refer to the WebAdvisor Installation and Administration manual for information about how Colleague determines future charges and payments.

If you enter “Yes” to Show Future Charges, Colleague displays the following:

• My Account Summary. Displays the future amount in the “Amount Not Currently Due” line at the bottom of the form, but does not include the amount in the Total Amount Currently Due for the account holder. If the account holder does not have any future charges, Colleague displays zero as the amount not currently due.

• Make a Payment. Includes the future amount in the balance(s) displayed for payment.

Note: My Account Summary by Term always displays all terms with a non-zero balance, regardless of how you set the Show Future Charges field.

If you enter “No” or leave the Show Future Charges field blank, Colleague does not display nor include the future charges amount (if any) on the My Account Summary or Make a Payment forms.

Note: This field is not currently used for printed registration statements.

Data Entry Defaults

You can define some commonly entered data which Colleague defaults in automatically when a new record is created. These defaults may be overridden at the time of entry, if appropriate. Table lists the registration defaults you can define on RGPP.

Table 293: Registration Data Entry Defaults

Default Definition See...

Quick entry enroll status Enrollment status to default in during the quick entry of a student

190

Quick entry housing assign Housing assignment status to default in during the quick entry of a student

Note: Only allowed if Residence Life module is not being used

235


Ge

Section Percentage Full

During registration, you might like to know when a course section is almost full. As a course section comes close to capacity, you might want to open another section or make some other appropriate change. You can designate a percentage of the maximum enrollment and when a student causes the enrollment in that course section to go above that percentage, Colleague displays a warning on the form.

For example, Ellucian University has defined the Section Percentage Full as 80%. When the 32nd student enrolls in a course section with a maximum enrollment of 40, Colleague displays a warning on the form. The user might then decide to open another section, increase allowable enrollment, change the location of the section to a larger room or just to take note of the full enrollment.

You can also see a list of course sections which have exceeded this percentage enrollment by accessing the Registration Activity Monitor (RGAM) form during registration.

Pay Now

If you enter “Yes,” Colleague automatically presents the Cash Receipt Entry (CREN) to record payment upon completing a registration from the Registration (RGN) form. If you enter “No,” the user can override this setting prior to completing a registration, and still access the CREN form from the RGN form.

Allow Pass/Fail

If you enter “Y,” users with this registration control can register students on a pass/fail basis if the Section Restrictions (SRES) form also allows for the pass/fail option. If you enter “N,” users cannot enter a “P” in the Pass/Audit field on the Registration (RGN) form.

Quick entry application status

Application status to default in during the quick entry of a student

Use the application status that your institution has defined to mean Moved to Student

If you do not define this default, Colleague uses the application status defined on the Admissions Parameters (ADPA) form

143

Table 293: Registration Data Entry Defaults

Default Definition See...


Ge

Allow Audit

If you enter “Y,” users with this registration control can register students on an audit basis if the Section Restrictions (SRES) form also allows for an audit. If you enter “N,” users cannot enter an “A” in the Pass/Audit field on the Registration (RGN) form.

Registration Subroutines

The Before Registration Subroutine arguments are:

• STUDENT.ID - input

• WARNING.OCCURRED - output (0 - no warning, keep going; 1 - Display warning message)

• ERROR.OCCURRED - output (0 - No error, keep going; 1 - error, stop registration for this student)

• MSG - output (message ID from ST.ERROR or text of error or warning message; this means ERROR.OCCURRED = 0 can have a message)

• MSG.ARGS - output (arguments for the error message, if using a message in ST.ERROR)

The During Registration Subroutine arguments are:


• TERM - input

• COURSE.SECTIONS.ID - input

• WARNING.OCCURRED - output (0 - no error, allow student into section; 1 - Display Warning Message)

• ERROR.OCCURRED - output (0 - no error, allow student into section; 1 - error, do not allow student into section)

• MSG - output (message ID from ST.ERROR or text of error or warning message; this means ERROR.OCCURRED = 0 can have a message)

• MSG.ARGS- output (arguments for the error message, if using a message in ST.ERROR)

The After Registration Subroutine arguments:


• WARNING.OCCURRED - output (0 - no warning, update all files; 1 - display warning message)

• ERROR.OCCURRED - output (0 - No error, update all files; 1 - error, cancel registration for this student)

• MSG - output (message ID from ST.ERROR or text of error or warning message; this means ERROR.OCCURRED = 0 can have a message


Ge

• MSG.ARGS - output (arguments for the error message, if using a message in ST.ERROR)

If there are additional things you would like to check or have happen before, during or after registration, then see your system administrator for information on setting up custom subroutines tailored for your unique needs.

Waitlist Defaults

These fields are used to determine the defaults for waitlisting:

• Deactivate Student Waitlists. Used to define if, when a student is enrolled in a section of a course, any other section of that course in which the student is actively waitlisted will be deactivated. The Waitlist Availability (WLAV) form is not affected by the setting in this field. When registering students, WLAV will deactivate a student's waitlists in other sections of the course.

• Ask Deactivate Waitlist Question. Allows you to display a question on RGN that asks, when a student is enrolled in a section of a course, if the student's waitlists in all other sections of that course should be deactivated.

See on-line help for further information on these fields.

Eligibility Rules

When you have specific situations under which a student can register for class, you can define these situations as eligibility rules. There are three types of eligibility rules that you can define for use in a registration control:

• Student

• Course

• Completion

For example, Ellucian University has a student eligibility rule that identifies whether an individual has met the minimum requirements for enrollment. As described in Table 294, when a student does not pass a student eligibility rule, he is not allowed to enroll in any courses.

You can also set up eligibility rules that refer to a student’s financial aid status. In such a case, Colleague checks the student’s financial aid status to determine if awards have been made before allowing registration.


Ge

Table lists the types of eligibility rules you can define and the consequences of each.

You must decide whether various eligibility rules are evaluated during each of the four different registration process periods. For example, Ellucian University’s student eligibility rule described above, which evaluates enrollment requirements, is set to be evaluated during the preregistration, registration, and other registration processes only. There is no need for a student’s enrollment requirements to be checked as they try to drop a course. It is evident the student passed them initially.

See “Understanding Registration Rules” on page 798 for more information about defining your eligibility rules. You can assign individual registration users the authority to override any or all of these eligibility rules. See “Override Permissions” on page 833 for details.

Checks

You can define various checks for Colleague to evaluate before allowing a student to enroll in a course. There are seven types of checks that you can choose to include in your registration controls definition:

• Repeat course

• Previous requisites

• Concurrent requisites

• Previous or concurrent requisites

• Waitlisted courses

• Petitions

• Section restrictions

You must decide whether various checks, such as repeat course checking, are made during each of the four different registration process periods. Table shows the different

Table 294: Eligibility Rules and Consequences

Eligibility Rule Definition If any evaluate to “False”…

Student Eligibility Evaluates the student’s record to see if they meet the requirements for enrollment.

The student will not be allowed to enroll or waitlist in any courses.

Course Eligibility Evaluates courses to see if the student is allowed to register for this course. For example, checks to see if the student’s academic level matches the course’s academic level.

The student will not be allowed to enroll or waitlist in this course.

Completion Eligibility Evaluates after the student and the student’s schedule have passed all other edits.

The student’s registration will be cancelled without enrolling student in any courses.


Ge

types of checks, what exactly Colleague checks, and the consequence if you choose not to have Colleague make the check.

Table 295: Types of Checks and Consequences

Type If you enter “Yes”... If you enter “No”...

Repeat Course

Colleague checks the courses a student has previously taken to determine if the course in which they are currently trying to enroll is a repeated course.

If a repeat exists, Colleague will check the retake policies of the course section to see if the student is allowed to enroll in it more than once.

If no repeats are allowed, the student will not be enrolled in the course.

Colleague does not check a course’s repeat policy. Therefore

• a student can enroll in a course section regardless of how many times he has taken it.

• a student can repeat a course section even if it has a repeat policy of “No.”

Previous requisites

Colleague checks the course section in which a student is trying to enroll to see if there are requisites the student must take prior to enrolling in the current course section.

If requisites exist that the student must take prior to enrolling in the current course section, Colleague will scan the student’s academic record to see if the requirements have been met, or if the student’s status for the course section requisite matches one of the entries in the Prerequisite Statuses Allowed field. If the status is allowed, Colleague allows the student to register for the course section.

If requisites exist but have not been met, or if the student’s status for the course section requisite is not allowed, the student is not enrolled in the course section.

Colleague does not check a course section’s requisites. Therefore, the student can enroll in the course section even if it has requisites which he has not met.

Concurrent requisites

Colleague checks the course section in which the student is trying to enroll to see if there is anything else the student needs to be enrolling in at the same time.

If concurrent requisite section exist and they are all required, Colleague automatically enrolls the student in the course sections. However, if concurrent requisite sections exist and only a subset of the list is required then Colleague will not automatically enroll the student in the course section.

Colleague does not check concurrent requisites. Therefore,

• Colleague does not automatically enroll the student in concurrent requisite course sections.

• the student can enroll in a course without registering for other requisite courses or requisite course sections which should be taken concurrently.


Ge

You can assign individual registration users the authority to override any or all of these checks. See “Override Permissions” on page 833 for details.

Previous or concurrent requisites

Colleague checks the course section in which the student is trying to enroll to see if there is anything else the student must have previously taken or must be enrolling in at the same time.

Colleague does not check any requisites. Therefore, the student can enroll in the course section even if it has requisites which have not been met.

Waitlisted Courses Enrollment

Colleague allows the student to enroll in a course section with an available seat even if a waitlist has been started for that course section.

If an opening occurs in a waitlisted course section as a result of someone dropping the course:

• the next student trying to enroll in this course section will be allowed to enroll.

• the next student can enroll even if there are other students on a waitlist before him.

Colleague does not allow the student to enroll in a course section once a waitlist has been started for that course section.

If an opening occurs in a waitlisted course section as a result of someone dropping the course

• a student trying to enroll in this course will not be allowed to enroll.

• the student trying to enroll in the course is added to the waitlist.

Petitions Colleague checks the course section in which the student is trying to enroll to see if an instructor’s consent petition is required.

If consent is required, Colleague checks the student’s petition file to see if the consent has been granted.

If consent is required and the student does not have the necessary petition, the student is not allowed to register for the course.

Colleague does not check a course section’s requirement for an instructor’s consent. Therefore, the student can enroll in a course section without the required instructor’s consent.

Note: This does not deal with overload petitions which are always checked.

Section Restrictions

Colleague checks the course section in which the student is trying to enroll to see if there are any registration restrictions.

If restrictions exist, then Colleague checks the student’s record for those criteria.

If restrictions exist and the student has not met them, the student will not be allowed to enroll in the course section.

Colleague does not check the course section in which the student is trying to enroll to see if there are any registration restrictions. Therefore, the student can enroll in a course regardless of section restrictions.

Table 295: Types of Checks and Consequences (continued)

Type If you enter “Yes”... If you enter “No”...


Ge

Procedure for Defining Registration Controls

Use the Registration Controls (RGCT) form to define registration control codes for your institution. See “Understanding Registration Controls” on page 805 and online help for more information.


Ge

Assigning Registration Controls to Registration Users

In This Chapter

This chapter provides information about assigning registration controls to a group of users.

Before You Begin

Before you can set up registration users, the following information must already be set up in Colleague.

Understanding Registration User Groups

A registration user group describes a unique combination of assigned process periods, registration controls, registration dates (optional), parameters and override authority governing the registration process for each user associated with the group. Each staff member who registers students can belong to only one registration user group.

For example, Ellucian University has set up three registration user groups: Clerks, Advisors, and Faculty. The Clerks have been given a basic set of parameters, can only enroll students during the official registration process period, and have no override authority. Occasionally, Ellucian University will temporarily assign work study students to this group to assist with the heavy registration schedule. Advisors have the ability to enroll students during preregistration as well as during the registration process period. They can also register students into non-term courses using the “Other” process period. The

Table 296: Information Needed Before You Can Define Registration Users

Item Reference

Individual staff records must be on file Using Demographics

Registration controls “Understanding Registration Controls” on page 805

Registration process periods Registration Process Periods

826tting Started with Colleague Student | Assigning Registration Controls to Registration Users

Ge

Advisors group also has various print capabilities and some overrides. The Faculty group has the ability to enroll students during all process periods, including add/drop. The Faculty group also has print capabilities and all override authority.

If a staff person attempts to register students but has not been assigned to a particular registration user group, Colleague assigns that person the default control code “Nameless.” Ellucian delivers this default control code with Colleague. The “Nameless” record is also used to set the initial values for any new Registration Users records you create. See “Components of a Registration User Group” on page 827 for information about setting up registration user groups.

See “Understanding Registration Controls” on page 805 for more information about defining your registration control codes. See “Case Study: Setting Up Registration Control Codes and User Groups” on page 834 for an example of how to set up your registration controls and assign the controls to your user groups.

Components of a Registration User Group

Use the Registration Users (RGUS) form to set up registration user groups and to assign your staff members to these groups.

Figure 152: The Registration Users (RGUS) Form

The RGUS form has the following components:

• Registration process periods permitted

• Registration control codes

• Registration dates


Ge

• Print parameters

• Staff group members

• Override permissions

Each of these components is explained in this section.

Registration Functions Permitted

You must determine when each registration user group will help with student registration. Assign each group at least one of these predefined functions:

• P (preregistration). Can enroll students in course sections during preregistration

• R (registration). Can enroll students in course sections during registration

• L (delete). Can delete course sections from student schedules during preregistration

• X (delete). Can delete course sections from student schedules during registration

• A (add). Can enroll students in course sections during Add period

• D (drop). Can drop course sections from student schedules during Drop period

• O (other). Can enroll students in or remove students from course sections that do not have a term

If you want the individuals in a registration user group to be able to register students using more than one function, assign the group multiple registration function codes.

The registration process dates are defined for each academic term. Course sections which are not associated with an academic term are considered Other. See “Defining Academic Terms” on page 417 for more information about how these dates are defined.

Registration Control Codes

Registration controls represent a unique combination of registration rules and checks that determine the type of registration processes a given user can perform.

Assign each registration user group at least one control code. If a staff person is assigned to a registration user group with multiple registration control codes, Colleague displays a resolution form as the user enters a registration form. Users must select one of these controls to identify how they will operate under during that registration session.

For example, registration clerks at Ellucian University help with registration at both EU’s Main and East campuses. Therefore, the “CLERKS” registration user group is associated with two registration control codes, “MAIN” and “EAST.” At the beginning of a session, a clerk would choose one of these registration control codes depending upon the registration location.

See “Understanding Registration Controls” on page 805 for more information on these codes.


Ge

Registration Dates

Registration dates are typically set up on the Reporting Years and Terms (RYAT) form and defaulted to the Academic Terms (ACTM) form where they can be changed or expanded. These dates can then be overridden by location on the Term Location Dates (TLOC) form, and by course section on the Section Reg Date Ranges (SRGD) form. This hierarchy can be shown as:

ACTM < TLOC < SRGD

In addition, you can set up specific registration dates for a registration user group that override the dates entered on these forms. This feature allows you to have different registration dates available for a wide variety of registration user groups such as those who use Web registration or staff members who register students on campus. You may want to coordinate setting up these dates with staff members of your Registration office.

To set up registration dates for a registration user group, detail on the Reg Dates field on RGUS. The Registration User Dates (RGUD) form displays.

Figure 153: Registration User Dates (RGUD) Form

From RGUD, you can detail to enter registration dates that override:

• Term dates on ACTM. Detail on the Terms field to go to the Reg User Term Dates (RGUT) form.

• Term/locations dates on TLOC. Detail on the Term/Locations field to go to the Reg User Term Location Dates (RGUL) form.

• Section/terms dates on SRGD. Detail on the Section/Terms field to go to the Reg User Section Dates (RGUC) form.

Refer to online help for information about these forms.


Ge

For example, suppose the drop period for the Fall 2003 term, 2003/FA, is 9/15/03 through 12/01/03. However, students registering through the Web should be allowed to drop courses only up to 9/30/03. The dates on ACTM would show 9/15/03 through 12/01/03.

For the Web registration user group, detail on a blank row in Terms. Then on the RGUT form, all ACTM dates are defaulted, and the 12/01/03 can be changed to 09/30/03 for the drop end date. This means that this Web registration user group will not be able to drop classes after 9/30/03, but any other registration group whose dates have not been overridden will still use the ACTM dates.

Figure 154: Forms Used to Define Registration Dates by User Group


Ge

The Registration processes will look for registration dates in the following order, using whatever level is found first:

• Registration user course section dates (RGUC)

• Course section registration dates (SRGD)

• Registration user term/location dates (RGUL)

• Term location dates (TLOC)

• Registration user term dates (RGUT)

• Term dates (ACTM)

This hierarchy can be shown as:

ACTM < RGUT < TLOC < RGUL < SRGD < RGUC

The files associated with these forms are:

• REG.USER.SECTIONS (RGUC)

• COURSE.SECTIONS (SRGD)

• REG.USER.TERM.LOCS (RGUL)

• TERMS.LOCATIONS (TLOC)

• REG.USER.TERMS (RGUT)

• TERMS (ACTM)

When you save from a form, you create the associated file.

Once Colleague has determined which form to use, only the dates found on that form will be used. For example, suppose that Colleague determines that the REG.USER.SECTIONS file should be used (the RGUC form). However, on RGUC, you entered only the Preregistration start and end date and left all other dates blank. Colleague will use the Preregistration dates you entered, but will also use the blank dates for Registration, Add, and Drop. This means that the Registration, Add and Drop dates will have no date restrictions for this registration user group.

Therefore, Ellucian recommends that you enter dates in all fields of the form you intend to be used for the registration user group. Then if the date the student is registered falls within dates you have entered, the associated Preregistration, Registration, Add, or Drop time period is used.


Ge

However, if you leave fields blank, the following occurs:

If the date the student is registered does not fall within any start and end date that you have entered, then the blank dates will be used, in the following order:

• Preregistration

• Registration

• Add

For example, suppose you entered August 14 (start date) and August 21 (end date) for Registration and left all other dates blank. Then if a student is registered on August 22, the blank Preregistration dates will be used, even if blank dates exist for Add.

Print Parameters

If you want all of the staff members in a registration user group to have specific print options, you can define registration users print parameters. These print parameters override the print options you defined for the registration controls using the Registration Parameters (RGPP) and the Registration Print Parameters (RSPP) forms. For example, Ellucian University faculty have access to printers in the faculty office building, but these are not the printers typically used during registration. EU has defined the “FACULTY” user group with the faculty printers. When a user from the faculty group registers a student, the student’s schedule prints on the printers conveniently located in the faculty office building.

Use the Registration Users Parameters (RUPM) form to define overriding print parameters for each registration user group. Access the RUPM form by detailing from the Print Parameters field of the Registration Users (RGUS) form. From the RUPM form, you can access Registration Print Parameters (RSPP) from the Reg Controls field to view the print settings for each registration control assigned to the registration user group.

Figure 155: Forms Used to Define Registration User Groups


Ge

Colleague uses the print parameters defined for a registration user group when:

• Printing registration billing statements or student course schedules as part of the registration process.

• Printing registration billing statements using the Registration Statement Print (RGST) process.

• Displaying account information on WebAdvisor forms.

See Using Accounts Receivable/Cash Receipts for detailed information about defining your registration users and registration controls for printing registration statements. See Using Registration for detailed information about printing student course schedules. See WebAdvisor Installation and Administration for information about defining financial web parameters.

When printing a registration billing statement for a student registered by a staff member in a registration users group, Colleague examines the registration user controls assigned to the registration user group. If multiple registration control records exist for a registration user group, Colleague uses the settings defined for the first registration control record that has the “Print Statements” parameter set to “Yes.”

You can override any of the print settings for a specific registration user group on the RUPM form, which includes all of the print parameters you can define for a registration control record.

Note: When overriding parameters on the RUPM form, only enter values for print parameters that are different from the values entered on the RSPP form (leave all other fields null). See “Print Setup for Registration Statements & Schedules” on page 810 for detailed information about defining each print parameter.

Staff Group Members

Assign your staff members to the appropriate registration users group. Each group can contain one or more staff members. However, a staff member can only be part of one group at a time. If you want to change a staff member’s assigned group, enter an end date to their association with their current group and add their ID to another group with the start date of the new association.

Override Permissions

Even though the registration controls define rules regulating many of the factors during registration, you can give groups of staff members the authority to override those rules. You can set up as many unique combinations of override permissions as you need.

If a user has been set up with override authority, Colleague will display a warning message instead of an error message whenever a student fails an eligibility rule or check. The authorized user can then decide whether or not to override the rule.


Ge

See “Components of a Registration Control” on page 806 for more information on the rules and checks which you can allow registration users to override.

Case Study: Setting Up Registration Control Codes and User Groups

Ellucian University has set up two registration control codes, “MAIN” and “EAST.” Each code has different LookUp criteria and different eligibility rules. These differences were decided based upon the needs of EU’s two different campuses. For example, the LookUp criteria for each limits the courses to only those on that particular campus. Most of the eligibility rules were similar, although the “EAST” code had a slightly stricter eligibility rule regarding parking violations. This is because the EU’s East campus has a terrible problem with parking. They have found they must crack down on student parking violators or there is no parking available for EU faculty.

Both of EU’s registration control codes have most of the checks set to “YES” for most of the registration processes. Because of this setup, Colleague will check each of the rules for every student registering during each registration process period. If Colleague evaluates a rule and finds it “false” for a student, Colleague will give the registration user a message to that effect. Both schools had the “Allow Enrollment in Waitlisted Courses” set to “NO.” Therefore, no student will be allowed to enroll directly into a course section once a waitlist has been started for it. Instead, the student’s name will be added to the waitlist.

Ellucian University has set up three registration user groups: “CLERKS,” “ADVISORS,” and “FACULTY.” All three user groups have both registration control codes, “MAIN” and “EAST,” available to them and users select the control code appropriate for their location. For example, if a user is registering students on the Main campus, she selects the “MAIN” control code.

The user group “CLERKS” allows these members to help with the main registration bulk. They may enroll students in courses only during the “REGISTRATION” process period. They have no override permissions.

The user group “ADVISORS” allows staff members to help enroll students during the “PREREGISTRATION,” “REGISTRATION,” and “OTHER” process periods. They also have some override authority during those periods. EU decided that the staff members who would be in this group, would know the individual students they were registering and be qualified to make exceptions to the standard rules.

The user group “FACULTY” allows EU’s faculty members the ultimate overriding authority. Not only can they enroll students during any process period, they can override the standard rules. This means when Colleague evaluates a rule, finds it “false,” and gives the users a message indicating a problem, the “FACULTY” user can simply acknowledge the warning and override it. Faculty members alone were given the authority to add/drop students from their classes.


Ge

Procedure for Assigning Registration Controls

Use the Registration Users (RGUS) form to set up registration user groups and to assign your staff members to the appropriate registration user group.

See “Understanding Registration User Groups” on page 826 and online help for more information.


Ge

Defining Registration Defaults

In This Chapter

This chapter provides information about setting up the defaults used by the Registration module.

Before You Begin

Before you can set up your registration defaults, the following information must already be set up:

Understanding Registration Defaults

You can set defaults that Colleague will use during your registration processing. Some of these defaults will be set up once and others may need to be modified for a particular registration session. For example, you need to decide whether you want Colleague to keep a log of all of the overrides made during registration. This decision is likely to remain the same regardless of the academic term. However, some defaults may vary with each registration session, such as the default academic term.

General registration defaults, that you need to set up once before registering students, include:

• Audit credits to zero

• Log registration overrides

Table 297: Information Needed Before You Can Define Registration Controls

Item Reference

Academic levels “Defining Academic Levels” on page 410



Student program statuses “Student Program Statuses” on page 279

836tting Started with Colleague Student | Defining Registration Defaults

Ge

• Default academic program and status

• Match concurrent requisites to same location

Registration session defaults, that you may need to modify for a particular registration session, include:

• Registration transaction date

• Default registration term

Both types of registration defaults are discussed in this chapter.

General Registration Defaults

Use the Registration Defaults (RGPD) form to define your general registration defaults.

Figure 156: Example of Registration Defaults

Audit Credits

If you allow students to audit courses, you must decide whether they should receive academic credit for those courses. Set this parameter to tell Colleague whether to set all audited credits to zero. For example, EU set this parameter to Y. Therefore, every student who audits a course, will receive zero academic credits for it.


Ge

Log Registration Overrides

If you want to keep a record of each time a registration user overrides a rule or check that has been defined, Colleague can keep an overrides log. Set this parameter to tell Colleague whether to keep a log of registration overrides in the REG.OVERRIDE.LOG file.

Concurrent Requisite Location

If you want force students to register for their concurrent requisites at the same campus location, enter Yes. Enter No if location is not a consideration when satisfying this course's concurrent requisite course specification.

Registration in course sections without a defined location are not affected by this setting. Also, course sections without a defined location that otherwise satisfy a concurrent requisite course are recognized as fulfilling the requisite, even when the requiring section is defined with a location and this field is set to “Yes.”

Note: This setting affects only requisite courses defined with a timing of “Concurrent.” Requisite courses defined with a timing of “Previous” or “Previous or Concurrent” are not affected by this setting.

This setting can be overridden for individual courses on the Course Requisites (CREQ) form, and for individual sections on the Section Requisites (SREQ) form.

Default Academic Programs and Statuses

If a student registers for a course section associated with an academic level to which he does not belong, Colleague creates a student academic level record for him and that level. Each academic level record must have an associated academic program. To keep these records from getting out of sync, you can define a default academic program which Colleague will assign in this case.

Each academic program has an associated status. Colleague assigns the default status along with the default academic program to each student who registers for a course section in an academic level different from his active level.

For example, Ellucian University has defined the default academic program, MBA, for its GR academic level. Susan Doyle is an undergraduate student at EU with an academic level of UG. However, she wants to take a graduate level course in her senior year. Even though Susan has not been accepted into the graduate level yet, her advisor has approved this. When Susan registers for the graduate level course, Colleague will create a graduate level record for her with the default academic program of MBA.

You may have defined default academic programs and statuses when you set up your academic levels. If you did, Colleague displays them on the RGPD form. You can modify them, if appropriate.

See 410 for more information about defining academic levels and see Using Academic Records for more information about defining default academic programs.


Ge

Registration Session Defaults

If you want to define defaults that affect your session alone, define registration session defaults. Colleague uses these defaults for registration sessions that use your login. Use the Registration Session Defaults (RGSD) form to define your registration session defaults.

Figure 157: Example of Registration Session Defaults

The registration sessions defaults you can set up are:

• Registration transaction date

• Default registration term

Transaction Date

If you want to make the registration processor think you are actually processing registration on a day other than today, then set that date on the RGSD form. Colleague displays this date on the Registration (RGN) form instead of the current date.

Default Registration Term

If most of your students will be registering for a particular academic term during a registration session, you may want to define a default academic term. This default term will be used in the course section LookUp to limit the course sections available to only that term. You can override this default and see course sections from other academic terms by entering the desired academic term at the registration course section LookUp.


Ge

Procedure for Defining Registration Defaults

Use the Registration Defaults (RGPD) form and the Registration Session Defaults (RGSD) form to define your general registration defaults.

See “Understanding Registration Defaults” on page 836 and online help for more information about defining your registration defaults.


Ge

Defining Waitlist Defaults

In This Chapter

This chapter provides information about setting up the waitlist defaults used by the Registration module.

Before You Begin

Before you can set up your waitlist defaults, the following information must already be set up:

Understanding Waitlisting Defaults

The Waitlist Defaults (WLDF) form is used to define the default settings for the fields and parameters that affect waitlist processing. The WLDF form is also used to set up e-mail or documents that inform waitlisted students that a seat is available or that they are enrolled in a section for which they were waitlisted.

Table 298: Information Needed Before You Can Define Waitlist Defaults

Item Reference





Registration defaults “Defining Registration Defaults” on page 836

841tting Started with Colleague Student | Defining Waitlist Defaults

Ge

Figure 158: Waitlist Defaults (WLDF) Form

The waitlist defaults you can set up are:

• Allow Course Waitlist

• Waitlist Rating

• Required Course Subroutine

• Enroll Number of Days

• Multiple Sections

• E-Mail Type

• Space Available Paragraph

• Student Enrolled Paragraph

• Space Available Comm Code

• Space Available Comm Status

• Student Enrolled Comm Code

Allow Course Waitlist Default

This setting lets you set up whether you want the default setting to be that courses allow waitlists.The value set here defaults into all courses, but can be overridden at the course and section levels.


Ge

Waitlist Rating Default

This setting allows you to enter the code of the waitlist rating criteria to use as the default for courses.The code you enter here defaults into all courses, but can be overridden at the course and section levels.

Note: Waitlist rating criteria for courses are defined on the Course Waitlist Ratings (CWLR) form.

Required Course Subroutine

This setting allow you to enter the subroutine name to be used to determine if the course is required. Colleague uses the subroutine name that you enter in this field to determine if the course for which the student is waiting is required for that student.

Enroll Number of Days Default

This setting allows you to enter the number of days a student has to accept an offer of enrollment from a waitlist.

This field will be used as a default to all courses, where it will be used as a default to course restrictions by location and sections. At the section level, if a student is offered enrollment in a waitlist, and enrolls within the number of days allowed, then the student is given a seat regardless of the section capacity.

Multiple Sections Default

This setting allows you to let students waitlist into multiple sections of the same course.

This field is used to default to courses (on the Course Restrictions [CRES] form) where it will be used as a default to course restrictions by location if locations exist (displayed on the Course Restrs by Location [CLRS] form).

E-Mail Type

This setting allows you to enter the type of e-mail address to use for waitlist e-mail. The e-mail type you enter here is used when notifying students that they have permission to register or are enrolled in a section for which they were waitlisted.

If this field is left blank or if the student does not have this type, Colleague will assign a Space Available communication code or a Student Enrolled communication code if these are defined on the WLDF form.

Space Available Paragraph

This setting allows you to detail to the Define Custom Paragraph (DPAR) form. On the DPAR form you can enter the e-mail paragraph used by the waitlist management forms


Ge

and the Waitlist Availability (WLAV) form to notify students that a seat is available in the section for which they are waitlisted. For more information, see “Defining a Custom Paragraph” on page 845.

If this field is left blank, an e-mail will not be sent to notify students of seat availability. However, Colleague will assign a Space Available communication code, if one is defined in the Space Available Comm Code field on the WLDF form.

Student Enrolled Paragraph

This setting allows you to detail to the DPAR form to enter the paragraph e-mailed to students to say they have been registered. For more information, see “Defining a Custom Paragraph” on page 845.

If this field is left blank, e-mail will not be sent by the waitlist management forms or WLAV when a student is enrolled. However, Colleague will assign a Student Enrolled communication code, if one is defined in the Student Enrolled Comm Code field on the WLDF form.

Space Available Comm Code

This setting allows you to enter the communication code to be used to send availability notices.

This code is used to produce a document to be sent to inform students that seats are available in a section for which they are waitlisted. For more information, see the Using Communications Management manual.

Space Available Comm Status

This setting allows you to enter the communication code status to be set when this communications management record is created.

Student Enrolled Comm Code

This setting allows you to enter the communication code to be used to send enrolled notices.

This code is used to produce a document to be sent to inform students that they are enrolled in the section for which they were waitlisted.

For more information, see the Using Communications Management manual.

Student Enrolled Comm Status

This setting allows you to enter the communication code status to be set when this communications management record is created to notify students they have been registered.


Ge

Defining a Custom Paragraph

If you want to define a custom paragraph, detail from the Space Available Paragraph or the Student Enrolled Paragraph field.

The Define Custom Paragraphs (DPAR) form is displayed.

Figure 159: Define Custom Paragraphs (DPAR) Form

Description

Each custom paragraph must have a unique name or code associated with it. The description entered here will appear in the subject line of the e-mail sent to the student.

Office

If you enter an office code, only users who have privileges to that office can use this paragraph.

Merge File

If you want to use merge fields in your custom paragraph, enter WAIT.LIST, PERSON, or STUDENT. The merge fields in your custom paragraph must exist in this merge file. You can enter only one merge file for each custom paragraph.


Ge

Financial Aid Year

Correspondence Received codes that are year-specific and created for use by the Financial Aid office may be replicated for use in subsequent years if the FA year that applies to the code is specified in this field.

Paragraph Text

If you want to enter the text to be used in the custom paragraph, detail on the Paragraph Text field. The Comment Screen (UTEC) form is displayed.

Figure 160: Comment Screen (UTEC) Form

Enter the text for the custom paragraph. To include a merge field in the text, you’ll use a placeholder: @ followed by the field name. For example, your merge file is WAIT.LIST, and you enter:

Dear @WAIT.STU.PREF.NAME ,

When you process the document, the placeholder will be replaced with:

Dear Mr. Steve Godwin,

As shown above, you must leave a space after the field name to indicate that the field name has ended; for example:

Dear @WAIT.STU.PREF.NAME ,

If you do not leave a space, an error will occur. The extra space will not appear in the actual text sent in the e-mail.


Ge

The following computed columns are available for use in these paragraphs:

Save to return to the WLDF form.

You can modify the Sender information of the e-mail that is automatically sent to a student upon finishing from the SWLM, CWLM, CWLA, or WLAV forms. To do this, use the E-mail Registration Return Address field on the Registration Web Parameters (RGWP) form.

See on-line help for the WLDF form for further information.

Procedure for Defining Waitlist Defaults

Use the Waitlist Defaults (WLDF) form to define your waitlisting defaults.

See “Understanding Waitlisting Defaults” on page 841 and online help for more information about defining your waitlisting defaults.

Table 299: Computed Columns

Computed Columns Description

WAIT.STU.PREF.NAME Student’s preferred name

WAIT.TERM Term

WAIT.SEC.SHORT.TITLE Section’s short title

WAIT.SECTION.SORT.NAME Section’s name

WAIT.SEC.SYNONYM Section’s synonym

For use only in the Space Available Paragraph

WAIT.EXPIRE.DATE Date the student’s permission to register expires

WAIT.SEC.WAITLIST.NO.DAYS The number of days to enroll

For use only in the Student Enrolled Paragraph

WAIT.ENROLL.SEC.NAME The SORT.NAME of the enrolled section, not the originally waitlisted section

WAIT.ENROLL.SEC.SHORT.TITLE The short title of the enrolled section, not the originally waitlisted section

WAIT.ENROLL.SEC.SYNONYM The synonym of the enrolled section, not the originally waitlisted section


Ge

Initializing or Updating Waitlist Fields

In This Chapter

This chapter provides information about initializing or updating waitlist fields used by the Registration module.

Before You Begin

Before you can initialize waitlist fields, the following information must already be set up:

The Waitlist Defaults (WLDF) form must be complete before the Initialize Waitlist Fields (IWLF) process is run.

The IWLF process should be run even if you are not planning on using registration waitlists, as the data that is being populated is required on the Course Restrictions (CRES), the Course Restrs by Location (CLRS), and the Section Restrictions (SRES) forms. Set the Waitlist Multiple Sections field to “No” and leave the Waitlist Enroll No of Days field blank.

Table 300: Information Needed Before You Can Initialize or Update Waitlist Fields

Item Reference





Registration defaults “Defining Registration Defaults” on page 836

Waitlist defaults “Defining Waitlist Defaults” on page 841

848tting Started with Colleague Student | Initializing or Updating Waitlist Fields

Ge

Understanding Initializing or Updating Waitlist Fields

Warning! The IWLF process must be run on a quiet system or when no registration is taking place. Allowing students to register while running the IWLF process will cause unpredictable and inconsistent results if those students are put on a waitlist.

The Initialize Waitlist Fields (IWLF) form is used to initialize fields that have been added to the following files:

• COURSES:

• CRS.WAITLIST.NO.DAYS

• CRS.WAITLIST.MULT.SECT.FLAG

• COURSE.LOCATIONS:

• CRSL.WAITLIST.NO.DAYS

• CRSL.WAITLIST.MULT.SECT.FLAG

• COURSE.SECTIONS:

• SEC.WAITLIST.NO.DAYS

Figure 161: Initialize Waitlist Fields (IWLF) Form

Initializing these fields will:


Ge

• Define the number of days a student has to enroll from a waitlist for all courses, courses with location-specific restrictions, and sections at your institution.

• Define whether a student may be waitlisted for multiple sections of a course for all courses and courses with location-specific restrictions at your institution.

The first time you run the IWLF process, you cannot specify selection criteria or Saved List Name fields. This means that all courses, location-specific restrictions, and sections at your institution will initially be updated with whatever is entered in the Waitlist Mult Sections and the Waitlist Enroll No Days fields on WLDF.

If you need to update these settings for groups of courses or courses with location-specific restrictions, run the IWLF process again, entering selection criteria. To enter any changes needed to individual courses or courses with location-specific restrictions, use the Course Restrictions (CRES) form or the Course Restrs by Location (CLRS) form, respectively.

As sections are never selected on their own, you must make any changes to section Waitlist Enroll No Days (that need to be different from the course or course location) individually on the Section Restrictions (SRES) form, not on the IWLF form.

For further information on this form, see the on-line process help.

Waitlist Mult Sections

This setting can be used to allow waitlisting in multiple sections of a course at once, or to restrict students to waitlisting for only a single section of a course per time period, such as a term.

If this process has not previously been run, this defaults from the Multiple Sections Default field on the Waitlist Defaults (WLDF) form and can be changed as needed. On subsequent runs of the IWLF process, this field will display what was entered on the previous run done by the same user.

Waitlist Enroll No Days

This setting can be used to enter the number of days a student has to accept an offer of enrollment from a waitlist.

If you have not previously run the IWLF process, this defaults from the Enroll Number of Days Default field on the Waitlist Defaults (WLDF) form and can be changed as needed. On subsequent runs of the IWLF process, this field will display what was entered on the previous run done by the same user.

Saved List Name

This setting can be used to enter a saved list of COURSES IDs. This field must be blank the first time the IWLF process is run.


Ge

Locations

This setting can be used to enter locations of courses to be included. This field must be blank the first time the IWLF process is run.

Update Courses

This setting can be used to update courses and location-specific restrictions, or to allow only location-specific course restrictions and sections to be updated.

Academic Levels

This setting can be used to enter the academic level of the courses to be included.This field must be blank the first time the IWLF process is run.

Schools

This setting can be used to enter the schools to which a course department must belong to be included.This field must be blank the first time the IWLF process is run.

Divisions

This setting can be used to enter the divisions to which a course department must belong to be included.This field must be blank the first time the IWLF process is run.

Departments

This setting can be used to enter the departments to which a course must belong to be included.This field must be blank the first time the IWLF process is run.

Procedure for Initializing Waitlist Fields

Use the Initialize Waitlist Fields (IWLF) form to initialize or update your waitlisting fields.

See “Understanding Initializing or Updating Waitlist Fields” on page 849 and online help for more information about initializing or updating waitlist fields.


Ge

Registration Worksheets

In This Chapter

This chapter provides worksheets that you can use to assist you in setting up the Registration module.

Table 301: Registration Worksheets

Worksheet Reference Procedure Reference

Student Eligibility Rules— English Statements

853 See “Student Eligibility Rules” on page 799.

Course Eligibility Rules — English Statements

854 See “Course Eligibility Rules” on page 801.

Completion Eligibility Rules — English Statements

855 See “Completion Eligibility Rules” on page 803.

852tting Started with Colleague Student | Registration Worksheets

Ge

Student Eligibility Rules — English Statements

Table 302: Student Eligibility Rules – English Statements Worksheet

Registration Control:

Student Eligibility Criteria


Ge

Course Eligibility Rules — English Statements

Table 303: Course Eligibility Rules – English Statements Worksheet


Course Eligibility Criteria


Ge

Completion Eligibility Rules — English Statements

Table 304: Completion Eligibility Rules – English Statements Worksheet


Completion Eligibility Criteria


Residence Life

Ge

Defining Residence Life Defaults

In This Chapter

This chapter provides information about defining the defaults used by the residence module.

Before You Begin

Before you define residence life parameter defaults you should set up the following codes:

Understanding Residence Life Defaults

Use the Residence Life Parameter Def (RLPD) form to define defaults for housing assignments. When you create an assignment record, the values you define on the RLPD form will default to the assignment if you do not provide unique information.

Table 305: Information Needed for the Residence Life Module


Communications codes Using Communication Managements

Room assignment statuses 263

858tting Started with Colleague Student | Defining Residence Life Defaults

Ge

Figure 162: Example of the Residence Life Parameter Def (RLPD) Form

Defining File Types for Housing Assignments

You can define the file types that will be used to assign housing. The file types you record must be co-files of the PERSON file. For example, individuals are categorized as faculty members (FACULTY), staff (STAFF), students (STUDENTS) and other categories. You may want to limit the individuals eligible for housing assignment by defining the co-files used by the Residence Life module on the RLPD form. You could only assign rooms to individuals who are listed on the STAFF, APPLICANTS, and STUDENTS files.

Defining Notification Information

You can define the method of communication your institution uses to notify individuals of their housing assignments and status changes to the assignment using the Room Assignment Notice Comm Code field. For more information about communication codes, see Using Communications Management.

Defining Mailing and Address Information

You can define mailing address information and indicate whether Colleague will generate a new address for each new room assignment. If you enter Y in the New Box No for Each Room Assignment field, you must enter a value in the Build Box Address From field to let Colleague know how to build the new address (whether from the institution address or from the building address).

An individual may have only one address listed as their preferred address. If you enter Y in the Preferred Address field, Colleague will reverse any other indicators on the individual’s

Address and mailing information


Ge

address records (from the Name and Address Entry (NAE) form, or the Address (ADR) form) that are flagged as the preferred address. For example, an individual may have a home address on their record (accessible from the NAE form) flagged as their preferred address. If you make a room assignment to this individual and set the Preferred Address field to Y, Colleague will adhere to the latest change and not consider their home address (initially entered from the NAE form) as their preferred address.

Procedure for Defining Residence Life Defaults

Use the Residence Life Parameter Def (RLPD) form to define housing parameters. Refer to “Understanding Residence Life Defaults” and online help for information about the fields on the RLPD form.


Ge

Setting Up a Meal Plan

In This Chapter

This chapter includes information about how to set up meal plans.

Before You Begin

Before you set up a meal plan you should perform the following actions.

Understanding Meal Plans

You can set up a new meal plan or maintain data about an existing meal plan offered by your institution using the Meal Plan Set Up (MPSU) form. You can refer to these meal plans when you assign a meal plan using the Meal Plan Assignment (MPAS) form. If you

Table 306: Information Needed Before You Set Up a Meal Plan

Action Reference

Set up the meal plan rates 533

Set up the refund formulas “Procedures for Defining Refunds” on page 490

Set up the meal rate period codes 238

Set up the meal plan frequency codes 238

Set up the meal classification codes 237

Set up the meal type codes 239

Set up the codes for the days of the week

179

Set up the locations codes online help for the Locations (LOCN) form

Set up the buildings codes “Using Facilities Profile” in the appendix of Using Residence Life

Set up the AR codes 149

861tting Started with Colleague Student | Setting Up a Meal Plan

Ge

access the MPSU form from the MPAS form, you may only modify an existing meal plan; you will not be able to create a new meal plan.

Defining Restrictions for a Meal Plan

When you set up a meal plan, you can record restrictions such as the days the meal plan may be used, as well as buildings and specific dining areas. Use the fields in the Restricted To group.

If your institution has multiple campuses, you can define the campuses where a meal plan is valid. You can also define the number of meals allotted and the frequency using the meal plan frequency codes. For example, you can set up a meal plan that allots users to 3 meals per day. The restrictions you define are informational only; Colleague does not enforce the restrictions.

Recording Rate Information

You can record the rates for a meal plan on the Meal Plan Rates (MPRS) form. You can access the MPRS form by detailing from the Rates field. See 539 for more information about setting up meal plan rates.

Figure 163: Example of the Meal Plan Set-Up (MPSU) Form

Procedure for Setting Up a Meal Plan

Use the Meal Plan Setup (MPSU) form to set up a meal plan. Refer to “Understanding Meal Plans” and online help for information about the fields on the MPSU form.

Restricted to Group

862tting Started with Colleague Student | Setting Up a Meal Plan