colleague core getting started with colleague core

Colleague CoreGetting Started with Colleague Core

March 2019

Notices and Privacy

© 2006 – 2019 Ellucian.

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.

Ellucian's Privacy Statement is available at: www.ellucian.com/privacy.

Ellucian shall have the right to (a) use, store, process, modify, reproduce, distribute and display customer data, and to grant sublicenses to third parties, for the sole purposes of providing the software, performing Ellucian's obligations under its agreements with customers and complying with applicable law or legal requirements; (b) use, store, process, modify and reproduce customer data for Ellucian's internal business purposes, including development, diagnostic, forecasting, planning, analysis and corrective purposes in connection with the software, and for otherwise improving and enhancing the software; and (c) use, store, process, modify, reproduce, display, perform, distribute, disclose and otherwise exploit in any manner Aggregated Data for Ellucian's business purposes, including disclosure within its public statements and marketing materials describing or promoting Ellucian or the software. “Aggregated Data” means any data obtained or generated by Ellucian, including data pertaining to the software, Ellucian's systems and software, and the use of any of the foregoing, and includes data derived from customer data, which in all instances (i) does not identify any individual and (ii) is not attributed or attributable to a specific customer. Aggregated Data includes data that has been combined into databases which include third party data.

Ellucian2003 Edmund Halley DriveReston, VA20191United States of America

Revision History

Publication Date Summary

March 2019 Updated “Control access to UI forms that have a Person LookUp with sensitive or personal information” on page 161 as part of SU019885. Also updated Tech Doc Online to Colleague Technical Reference.

December 2018 Moved the following to the Getting Started with Colleague Student manual as part of SU019884:-Manage Vehicle Citations, (Citation) Comment, Citation Date, Citation Location, Citation Status, Citation Time, Infraction, Issuing Officer (Freeform), Issuing Officer ID, (Vehicle Infraction), Description, Vehicle Registration, License Plate Type, Vehicle Permit Period, Vehicle Permit Status, Vehicle Permit Type, Vehicle Permit Zone, Vehicle Registrant Type, Set Up Vehicle RegistrationAdded the following:-“Control access to UI forms that have a Person LookUp with sensitive or personal information” on page 161

June 2018 Added the following as part of SU018785:-““Persona” on page 96-“Source” on page 108-“Maintain consent to capture personal data ” on page 160-(Vehicle citation and registration documentation listed in December 2018 update)

March 2018 Removed archived ethnic code information.

June 2017 Updated “Prefixes” on page 98 as part of SU017515.

January 9, 2017 Added information about “Gender Identity” on page 73 and “Personal Pronouns” on page 96 as part of SU017216.

July 27, 2016 Modified as part SU016644 to add information about “Disability Categories” on page 42 and update the description of “Disability” on page 41. Also moved the Colleague Core Codes table to a separate file in the Colleague Core Documentation Library.

April 2016 Revised to update formatting throughout, remove references to wIntegrate, and fix formatting on the Colleague Core codes table.

https://www.ellucian.com/privacy

https://ellucian.force.com/clients/sfc/#version?selectedDocumentId=06916000002FIVg



Ge

Contents

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Colleague Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Colleague Core modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Colleague Core Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Codes in Colleague Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Share codes between modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Codes from Colleague Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Comprehensive list of Colleague Core codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Define Colleague Core Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Colleague Core code descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Define Colleague Core Validation Codes . . . . . . . . . . . . . . . . . . . . . . . . . 122

Before you begin to define validation codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Define validation codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Verify validation code tables and code files for the ELF process . . . . . . . . . . . . . 124

Define Colleague Core Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

International parameters and defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Dictionary date conversion (UniData environment only) . . . . . . . . . . . . . . . . . . . . 128

ID and LookUp parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Define ID and LookUp parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

3tting Started with Colleague Core | Contents - Ellucian - Confidential and Proprietary

Ge

Define address processing options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Capitalization rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Define capitalization rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Define FTP and Kermit locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Person privacy warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Define person privacy warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Reset key counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

The Rules Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Before you create and use rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Understand rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Rule evaluation results forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Work with rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

How to build rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Build rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Validate rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

A rules processor example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Set Activities and Events Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Before you set activities and events parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Budget accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Define resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Participant counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149


Ge

Set Communications Management Parameters . . . . . . . . . . . . . . . . . . . 151

Communications Management parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Define correspondence actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Rules in the Communications Management module . . . . . . . . . . . . . . . . . . . . . . . 154

Set Demographics Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Before you set demographic parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Demographics parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Define staff and volunteers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Define address security: individual mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Define address security: by office code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Maintain consent to capture personal data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Control access to UI forms that have a Person LookUp with sensitive or personal information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Define Duplication Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Duplication checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Custom duplication criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Define duplication criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Define Merge Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Merge criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Custom merge criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Define your merge criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Merge duplicate institution records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168


Ge

Define Translate Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Special processing fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Define file translate tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Determine whether translate tables are completed. . . . . . . . . . . . . . . . . . . . . . . . . 172

Set Up Facilities Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Codes needed to define buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Codes needed to define rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Set Up Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Codes used by the Scheduling Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Set Up Staff/Volunteer Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Codes used by the Staff/Volunteer Information Module . . . . . . . . . . . . . . . . . . . . . . . . 175


Ge

Introduction

This manual provides instruction for setting up the modules within Colleague Core. The instructions provided in this manual do not take into consideration your institution’s policies that can 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.

Anyone who is responsible for setting up one or more modules within Colleague Core should read this manual. If your institution has a number of individuals responsible for the setting up and implementing Colleague Core, you can choose to distribute this document among the individuals with this responsibility.

For information about using the different modules within Colleague Core, refer to the following publications:

Colleague Core

Colleague’s fully integrated applications will help your institution overcome these challenges by presenting a seamless administrative solution that can be used campus-wide. For example, an individual helping a student register can get online access to current course information, the student’s financial aid status, or even an existing accounts receivable balance. Colleague Core is at the center of this integration, providing a central location for information and processing rules used throughout Colleague. Data is entered only once, and is then shared with all authorized users. Not only does this ensure your end users have access to the most recent information available, but it saves time spent waiting on information from other departments. Everyone has immediate access to the same data, ensuring that, institution-wide, decisions are based on the same information.

Table 1: Other modules and publications

Module Publication

Activities and Events Using Activities and Events

Communications Management Using Communications Management

Demographics Using Demographics

Electronic File Transfers Using ELF

Facilities Profile Using Facilities Profile1

1.Included as an Appendix in other Using... manuals, such as Using Activities and Events.

Scheduling Using Scheduling

Staff/Volunteer Information Using Demographics

7tting Started with Colleague Core | Introduction - Ellucian - Confidential and Proprietary

Ge

Colleague Core also improves communications among departments by streamlining your institution's communications management, and centralizing activity and event planning and facility scheduling for institutional events.

Colleague Core modules

Activities and Events

The Activities and Events module automates the planning and management of activities and events for your institution’s Student, Financial, and Human Resources applications. This module automates all aspects of event and activity management, such as prospective student visits, graduation activities, award ceremonies, internal meetings, and bidders' conferences. With the Activities and Events module, you can:

• Ensure activities and events do not conflict with other events already on the institutional calendar

• Track projected vs. actual participation and cost

• Calculate expense-to-revenue projections

• Produce direct mailings for a targeted group of attendees

• Generate personalized invitations, confirmation letters, and name tags

• Assign seating based on user-defined criteria and facility set up

• Maintain information on the event’s sponsors or underwriters

• Monitor progress toward goals such as attendance or revenue

• Track single events or complex events, such as reunion week, that are made up of a series of activities

• Track volunteer and staff assignments

• Maintain a weekly or daily calendar and reminder system for event planning

Communications Management

Colleague’s Communications Management module is the leader in the industry because of its ability to track correspondence, telephone calls, personal visits, and other contacts with individuals or organizations. This module fully integrates and automates all aspects of your institution’s correspondence across all of Colleague's applications. This module ensures efficient and economical management of correspondence sent and received from heavy correspondence areas such as the Financial Aid and Recruitment/Admissions modules. With the Communications Management module, you can:

• Manage and coordinate mailings from all areas of your institution


Ge

• Maintain a complete history of correspondence and other contacts with prospects, students, employees, and vendors

• Develop customized correspondence tracks, identifying specified mailing dates, expected return correspondence, and subsequent mailings

• Monitor the success of mailing campaigns

• Process large batches of correspondence quickly and easily, with personalized salutations and other variables within letters

• Track all incoming correspondence, noting received documentation and generating reminders for missing information

• Organize and control printing on host or PC-based word processors

• Interface with word processors and list processors

• Generate mass mailing lists based on data contained in Colleague or from outside sources

• Maximize your postal budget with bulk mail features

Demographics

The Core Demographics module maintains all of the demographic information for Colleague’s applications. Colleague divides demographic information into two primary areas that can be tailored to meet the specific requirements of your institution: person demographics and organization demographics.

Person demographics includes data on applicants, students, and alumni and is used throughout Colleague’s applications. Within person demographics, your institution can enter and maintain biographical, address, academic, employment, relation, and emergency information.

Corporation demographics includes data on corporations and organizations, as well as individuals who are incorporated. Within organization demographics, your institution can enter and maintain detailed corporate profiles, including information about subsidiaries, branches, employees, addresses, industry class, and much more.

Organization demographics also allows your institution to enter and maintain information about secondary and post-secondary institutions, including institution type, primary contacts, transfer evaluations, and FICE or CEEB numbers.

Electronic File Transfers

The ELF module lets you import data to and export data from Colleague. You can import data into Colleague from legacy systems during conversion, from state systems, and from other internal or external systems with which you want to create an interface. You can export data from Colleague to state systems or other internal or external system with which you have an interface.


Ge

The ELF import process is basically two processes: import from a source area to an intermediate area, then import from the intermediate area to Colleague.

Facilities Profile

The Facilities Profile module describes every aspect of the infrastructure on your institution’s campus, including buildings, rooms, equipment within rooms, and other facilities such as playing fields or running tracks. This information is used by all of Colleague’s modules for functions such as scheduling classes, assigning residence hall rooms, developing office space plans, and calculating fixed asset depreciation. Use the Facilities Profile module to:

• Specify building codes, access codes, descriptions, and sector locations

• Track information on building ownership, age, renovation projects, size, and current condition

• Include room-by-room descriptions of each building, including location, capacity, available equipment, and usage descriptions

• Prepare inventories of facilities using Department of Education (ED) guidelines

• Assess and analyze the effectiveness of space utilization

• Calculate the percentage of building space devoted to each academic program using standard CIP codes

Scheduling

The Scheduling module gives your institution the ability to develop schedules for institutional events, as well as manually schedule and reserve facilities for classes, events, and meetings. The Scheduling module allows you to:

• Develop an academic calendar for multiple years, including terms, activities, and holidays

• Schedule and assign individual rooms and/or equipment for any purpose

• Combine course requirements, such as seating capacity, with faculty information to schedule courses in appropriate facilities


Ge

Colleague Core 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

Codes in Colleague Core

Codes are used extensively throughout Colleague Core to ensure that information listed below is consistent across your entire system.

• departments and divisions

• schools

• buildings and rooms

• locations

• ethnicities

• races

• counties, states, and countries

• handicaps and special health needs

• veteran statuses

11tting Started with Colleague Core | Colleague Core Codes - Ellucian - Confidential and Proprietary

Ge

information for completing biographical information, such as name, address, citizenship, prefixes and suffixes of names, or educational background correspondence and communications information.

Share codes between modules

Because of the integrated functionality of Colleague Core, many types of information are shared between modules within Colleague Core as well as other applications such as Colleague Student, Colleague Finance, and Colleague Human Resources. The codes provide information useful at numerous points in system processing.

In many cases a single code is used by several modules within Colleague Core and other applications. 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 Core 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 the another application.

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 Colleague Core. Some of the major types of Core information include:

• departments and divisions

• schools

• buildings and rooms

• locations

• ethnicities

• races

• counties, states, and countries


Ge

• handicaps and special health needs

• 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 other applications’ forms or from menus under those other applications.

Because of this interdependency, you should become familiar with codes used by other Colleague and Benefactor modules. When defining your institution’s codes, you should also know whom to contact to ensure that the values necessary to other office’s uses of the codes are added to the codes owned by Colleague Core.

Comprehensive list of Colleague Core codes

The Colleague Core Codes table provides an alphabetical list of all codes within Colleague Core. Mnemonics representing the names of the Core 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 file provides the following information about each code:

• the actual name by which Colleague recognizes the code (for example, ACCESS.STATUSES)

• the mnemonic of the form used to maintain the code (appears beneath each code name)

• whether 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 can 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 Core, including those pre-defined by Ellucian (and not user-maintainable).

For each code, the letters in the module columns indicate the following:

• n 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 Core.




Ge

• q indicates any modules or applications that use the code but are not primarily responsible for the code’s subject matter.

• m 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 “Define Colleague Core Codes” on page 16 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

General guidelines for different types of codes

Listed on the line following each code in the Colleague Core Codes table 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 the Core application.

• Codes whose mnemonic in the table is “VAL/Core” are stored in the CORE.VALCODES file, and can be accessed on VAL only from Colleague Core.

• 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.

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 “Define Colleague Core Validation Codes” on page 122 for more information on special processing.




Ge

Notes about the table

The column headings in the Colleague Core Codes table list Colleague Core modules and other Colleague applications where codes are used. The following legend explains the abbreviations used in the table.

The Colleague Core Codes table provides summary information only. For greater detail on any of these codes, see “Define Colleague Core Codes” on page 16, as well as online help.

Table 2: Legend for Core codes table

Mnemonic Module or Application

AE Activities and Events module

CC Communications Management module

CF Colleague Financial Application

DM Demographics module

ELF Electronic File Transfers module

FP Facilities Profile module

FR Benefactor (Fund Raising Application)

HR Colleague Human Resources

OR Organizations module

RUL Rules Processor

SC Scheduling module

ST Colleague Student

SV Staff/Volunteer Information Module






GePro

Define Colleague Core Codes

This chapter provides information for defining all of the codes in Colleague Core. The information in this chapter is provided in alphabetical order by the name of the code table. Refer to the Colleague Core Codes table for a comprehensive list of codes in Colleague Core.

Following the code descriptions is a section on defining validation codes.

Colleague Core code descriptions

Academic Calendars

Academic calendars define the method by which an institution divides its academic year, such as by quarters or by semesters. Academic calendar codes are used in the Academic Calendar field on the Institutions (INST) form. Academic calendar codes are stored in the ACADEMIC.CALENDARS record of the CORE.VALCODES file.

Access Statuses

Local, state, and federal laws and regulations require that some (if not all) buildings must have a minimum of accessible entrances and exits for the disabled. You can use access codes to identify which buildings and rooms on your campus (or elsewhere) have certain types of access. Some examples of accesses could be:

• Handicapped Access

• Wheelchair Access

• No Handicap Access

• Unknown

You can define and maintain access codes on the Validation Codes (VAL) form. Building access codes are stored in the ACCESS.STATUSES record of the CORE.VALCODES file.

ACCOMM.REQUEST.STATUS

Tracks the status of an accommodation request. The tracking of accommodation requests is optional.

An accommodation with a request status of granted, and an accommodation with no request status are both considered as being provided by the institution, subject to any start and end dates.

16tting Started with Colleague Core | Define Colleague Core Codes - Ellucian - Confidential and prietary



GePro

Accommodations

Accommodation codes are used on the Person Health Information (PHIN) form to indicate specific or special requirements associated with a particular disability. For example, you can have a disability code for wheelchair users. You can associate an accommodation code such as wheelchair access for wheelchair users.

Accommodation codes are stored in the SPECIAL.NEEDS record in the CORE.VALCODES file. Use VAL to define and maintain accommodation codes.

Accommodation codes for employment are used on the Employment Health Information (EHIN) form and stored in the HR.ACCOMMODATIONS record in the HR.VALCODES file. Use VAL to define and maintain accommodation codes.

Accounts Payable Types

AP types are defined on the AP Types Maintenance (APTF) form in the Financial application. Because these codes are used mostly in the Accounts Payable module, you should not define these codes without first consulting the Accounts Payable office at your institution.

Accreditation Type

Accreditation types identify an institutions accreditation standing, such as a regional accreditation. You can use accreditation types in the Accred field of the Accreditation group on the Institutions (INST) form. Accreditation types are stored in the ACCREDITATION.TYPE record of the CORE.VALCODES file.

Acquisition Types

Acquisition types are used to help define acquisition methods. Acquisition types are defined and delivered by Ellucian as ACQUISITION.TYPES of the CORE.VALCODES file. Acquisition methods are defined on the Acquisition Method Definition (ACQD) form and stored in ACQUISITION.METHODS file.

When defining acquisition methods, you can apply acquisition types to direct how the acquisition methods will be used. Acquisition methods are used on the Fixed Asset Maintenance (ASST) form in Colleague Finance. The acquisition type you specify for an acquisition method determines how you define your fixed asset maintenance.

For example, this table shows the actions that occur on ASST depending on the acquisition type that is applied to an acquisition method when defining a fixed asset.

Acquisition methods defined with this acquisition type... Produces this action on ASST

P (purchased) The cursor moves to the Insurance ID field.

D (donated) The cursor moves the Restrictions field.

L (leased) The cursor moves to the Lease ID field.


GePro

Active Statuses

You can use active status codes to specify whether a bank code associated with a bank account is active or inactive. Active status codes are used on the Bank Codes Maintenance (BKCM) form in Colleague Core and Colleague Finance and on the Bank Codes Definition (BANK) form in Colleague HR.

Active status codes are defined and delivered by Ellucian and stores in the ACTIVE.STATUSES record in the CORE.VALCODES file.

Activity Invitation Reasons

Use these codes in the Activities and Events module and in Benefactor to indicate the reason why a specific person or individual was invited to an event. Unlike target populations codes (TARGET.POPULATIONS) which should be used to describe the general invitation reasons, reasons for invitation codes (ACTIVITY.INVITE.REASONS) should be used for exceptions. Some example of reasons for invitation codes are:

• perspective freshman

• transfer student

• parent’s council

• major prospect

• major donor

You can define and maintain codes for activity invitation reasons on VAL. Activity reasons are stored in the ACTIVITY.INVITE.REASONS record of the CORE.VALCODES file.

Activity Types

These codes describe the levels of a campaign code tree hierarchy and the types of activities or events. These codes also categorize the entry as either a campaign or activity which is important for sorting and display purposes. Examples of activity types are:

• umbrella

• phase

• campaign

• sub-campaign

• direct mail

• event

• sub-event

• activity

Activity type codes are used in the ACTIVITY.TYPES field in the ACTIVITY file and the CAMPAIGN.TYPE field of the CAMPAIGN file. When creating an activity with sub-events


GePro

or sub-activities, you can use activity type codes to create a “hierarchy” of activities. For example, you can set up a series of activities or events such as:

15HC – 2015 Homecoming15HCALM – 2015 HC Alumni Reacquaint15HCALCT – 2015 HC Alumni Cocktail15HCPGM – 2015 HC Pregame Party15HCDNC – 2015 HC Dance

In the example above, 98HC is the “main” event, so the activity type related to an event can be applied to it. 98HCALM is a sub-event of the 98HC, so the activity type related to a sub-event can be applied to 98HCALU. 98HCALCT is a sub-event of 98HCALM, so the same sub-event activity type code can be applied to 98HCALCT. The remaining two events are sub-events of 98HC. You will learn how to create the hierarchy for such “layered” events elsewhere in this manual.

Activity Fee Types

Activity fee types are validation code tables that are not defined on VAL. These activity fee types are unique validation code tables because you define them for specific activities.

Activity fee types are defined for each individual activity using the Financial Planning (EVFP) form. Activity fee types determine the anticipated fee to charge for each person or couple attending an activity or event. When you have defined the fee structure codes and related them to this activity, you can use the codes to assign guests a fee type on the Attendance Confirmation (ATCO) form. There is no limit to the number of fee structures that you can associate with an activity.

Technical Tip: Activity fee types are stored in the ACTIVREL.FEE.TYPES table but cannot be accessed by VAL. You can only access these code using EVFP for each separate activity or event.

Activity Relation Responses

You can record responses from guests invited to activities or events by using response codes. You will need to define and set up response codes for EACH activity and event to which you want to record guest responses. Response codes are not “transferred” or shared among associated activities/events, even if you set up codes for a “main” or top level event of a hierarchy. Examples of activity relation responses are:

• accepted

• declined

• needs more information

Activity relation responses are stored in the ACTIVREL.RELATIONS validation code table. Activity relation responses are used in the Response field on the Attendee Confirmation (ATCO) form.

Use the Parameter Definition (AEPD) form to define and set up response codes for each activity/event. For more information about creating activity relation responses, see Using Activities and Events.


GePro

Activity Relation Roles

You can use activity relation roles to define the types of roles an individual might play for an activity; for example, committee leader, volunteer, coordinator, or participant. You can apply special processing codes to the codes you define for activity relation roles. For example, you can set special processing code “1” for the activity roles code you assign for coordinator. Whenever you assign the activity roles code for coordinator to a staff member, the STAFF.CAMPAIGNS.COORDINATED field in the person’s STAFF file record is updated with the ID of the activity.

Activity relation roles are defined and maintained on VAL. Activity relation roles are stored in the ACTIVREL.ROLES record of the CORE.VALCODES file.

Address Change Source

Address Change Source codes identify the source of information used when changing an individual’s address information. If this optional validation code table is activated, you must enter a source code when changing an address.

Address Change Source codes are maintained on VAL. These codes are stored in the ADDRESS.CHANGE.SOURCES record of the CORE.VALCODES file.

Address Hierarchy Types

The codes for address hierarchy types are stored in the ADDRESS.HIERARCHY.TYPES validation code table. You cannot modify this table; the table is created on-the-fly from the user-definable ADREL.TYPES validation code table and some additional hard-coded entries. To modify your institution’s user-defined address type codes for use in address hierarchies, modify the codes in the ADREL.TYPES table. The codes you modify there will be used by the ADDRESS.HIERARCHY.TYPES table. Use the Validation Code Maintenance (VAL) form to modify validation code tables.

Address hierarchy types are used on the Name and Address Hierarchy (NAHM) form and on the Address Type Definition (ADTM) form.

Address Route

Address route codes represent options for sorting and targeting mass mailings. They are built based on groups of zip codes in a specific region.

Address route codes are maintained on VAL. These codes are stored in the ADDRESS.ROUTE.CODES record of the CORE.VALCODES file.

Table 3: Activity relation roles codes

Special Processing Code Description

1 Associated role represents an activity coordinator

2 Associated role represents an activity participant


GePro

Address Status

Address status codes describe the status of an address, such as current or former. These address status codes are user-defined, but they use special processing codes to indicate how the system handles the address, as indicated below.

When you mark an address with a status that uses a special processing code of “Former,” the address is processed like a move or change of address. Address status codes are maintained on VAL. These codes are stored in the ADREL.STATUSES record of the CORE.VALCODES file.

Address Tokens

Colleague uses address token codes when indexing address lines for address LookUp to consolidate all standard long words into their appropriate abbreviation. The abbreviation is then used when creating the index. You can modify or add codes when you require certain words to index to the same values where the description is the value of the index, minimum entry and stored code are the long words. This table shows examples of address token codes.

Address token codes are stored in the ADDRESS.TOKENS record of the CORE.VALCODES file. Use the Validation Code (VAL) form to modify address token codes.

Table 4: Address status codes

Special Processing Code 1 Description

1 Current

2 Former

3 Last Known

4 Pending

Table 5: Address token codes

Code Description

northeast NE

northwest NW

south S


GePro

Address Types

Address types or address relation types identify various types of addresses, such as home or business. These codes use sequence numbers as special processing codes to determine how the addresses are handled, as listed in this table.

Address types are maintained on VAL and stored in the ADREL.TYPES record of the CORE.VALCODES file. Address type codes are used on the Address Record Security (ADRS) form and the Person Address (ADR) form.

This table lists the special processing codes that can be applied in the second special processing codes field on VAL. Special processing code 2 is used in the old virtual routines and in the query on Release 13.0-level files to translate these address types into the PEOPLE file structure. Address records in Release 14.x and higher are created with a sequentially-assigned ID which is also recorded in the PERSON record for that individual. In pre-Release 14.x software, addresses in the PEOPLE record were identified using one of the codes special processing codes field 2 plus the ID of the PEOPLE record.

Table 6: Address type codes

Special Processing Codes Field 1 Description


1 Home 8

21

1.Also used for FAC and RMA address designations. FAC is for Faculty addresses and RMA is for Room Assignment addresses.

Business 9

3 Web 10

4 11

5 12

6 13 Local address

7 Correction 14 Other



PHA Permanent Home Address

PBA Permanent Business Address

PLA Permanent Local Address

POA Other

ARA AR address

RMA1 Room assignment


GePro

Administrative Types

You can use administrative types codes to distinguish academic departments or divisions from Human Resources departments or divisions when defining departments using the Departments (DEPT) form. If you assign the appropriate administrative type to all academic and HR departments, a value is assigned, then Colleague will issue warnings if an invalid administrative type is used (for example, if an HR department is being assigned to a course).

Administrative types codes are defined and delivered by Ellucian and stored in the ADMIN.TYPES record of the CORE.VALCODES file. You can use these codes in the Type field on DEPT when defining departments in your institution.

Alien Statuses

You can define alien statuses to identify non-resident employees and students. Alien status codes are used in the Alien Status field on the Foreign Person Information (FINF) form. Examples of alien statuses are as follows:

• Alien

• Resident Alien

• Not an Alien

• Landed Immigrant

You can define and maintain alien statuses (stored in the ALIEN.STATUSES record of the CORE.VALCODES file) using VAL.

Alternate ID Types

You can define alternate ID types to categorize alternate IDs that are used in addition to a student’s Colleague ID. Alternate ID types are entered on the Additional Demographics (DADD) form, the Additional Organization Info (AORG) form, and are used in EDI transactions and in Wisconsin reporting. Examples of alternate ID types include the following:

• legacy system

• paper trail

FAC Faculty Address

WEB Web Address

1.This code can only be assigned to a single resident, and therefore does not show up on normal resolution from S.ADDRESS.UPDT. For example, when a matching address is entered for another person with the same address lines, then upon filing the address data, you will not see any RMA type addresses on the resolution form for assigning this person to an existing address.




GePro

• state Social Security number

You can define and maintain alternate ID types (stored in the ALT.ID.TYPES record of the CORE.VALCODES file) using VAL.

Association Directions

Association directions are used by ELF processes and the Rules processor to specify a sort order. These codes are primarily used by RTA.SORT.ORDER when using the Field Associations (RDSF) form to define the associations between multi-valued fields in a file.

The entries of descending left/right with nulls first is to handle the sorting of things like end dates, where a null is the most recent. This means that nulls will be first, followed by the entries with data.

Normally this isn't needed for ascending because the nulls would always be first. But this is provided in case you want nulls at the bottom.

Association directions are defined and delivered by Ellucian as ASSOCIATION.DIRECTIONS in the CORE.VALCODES file. You cannot modify these codes.

Bank Codes

Bank codes are used throughout the Accounts Payable, Purchasing, and Fixed Assets modules in Colleague Finance. You can use the Bank Codes Maintenance (BKCM) form to define the following characteristics of bank codes:

• description

• associated general ledger cash account number and description

• bank account number

• transit routing number

• last AP check number

• active status

• foreign currency code

• and currency exchange information

Bank Reconciliation Date

You can use bank reconciliation date codes to specify the date to be used as the reconciliation date during bank check reconciliation processes. Examples of bank reconciliation date codes include

• B – Bank paid date

• T – Today’s date

• I – Institution check date


GePro

You can define and maintain bank reconciliation date codes (stored in the BANK.RECON.DATES record of the CORE.VALCODES file) using VAL.

Bank Reconciliation Source

Use this field to specify the code for each Colleague module with checks to be included on this reconciliation request file. For example, depending upon your institution's procedures, the bank that you use, and the modules that currently have this capability, you could include either paychecks from the Payroll module of Colleague HR, or vendor checks from the Accounts Payable module of Colleague Finance, or both. Examples of bank reconciliation source codes include:

• PR – Payroll

• HR – Human Resources

• AP – Accounts Payable

You can define and maintain bank reconciliation source codes (stored in the BANK.RECON.SOURCE record of the CORE.VALCODES file) using VAL.

Bank Reconciliation Statuses

Bank reconciliation status codes identify the status of the bank check reconciliation batch as it transitions through the reconciliation process.

The default processes delivered with Colleague are to load the electronic media provided by the bank using the ELF set of utilities and then import the intermediate files into the Colleague database. This is accomplished through the BKRI - Bank Reconciliation Import process in the CORE application.

The first step of BKRI is to load the electronic media with it's layout mapped through the BANK.RECON.IMPORT file layout, into the intermediate file, INTER.BANK.RECON. Upon completion of this step, the batch control record stored in the BANK.RECON.CONTROL file (key = batch ID assigned by the operator), is updated with a status of “L” (Loaded) or “LE” (loaded with errors).

The next step of BKRI is to import the data in the intermediate file into the Colleague database's BANK.RECON file. Upon completion of this step, the batch control record is updated with a status of either “I” (Imported) or “IE” (Imported with errors).

This process imports all valid records and reports any invalid records that is could not import. It does not require the entire data set provided on the electronic media to be validated prior to loading the batch.

The next step in the process is performed by the specific application reconciling the import check information. See also the overview documentation for HR.PAYCHECK.RECONCILIATION and ELECTRONIC.RECONCILIATION for more information.

The reconciliation process of the specific application uses the data in the BANK.RECON file to reconcile the checks for a specified batch. As individual checks are reconciled, the record is removed from the BANK.RECON file. Upon completion of the reconciliation


GePro

process, the BANK.RECON.CONTROL record for the batch is again updated with a new status: “R” (reconciled) or “RE” (reconciled with errors).

Bank reconciliation status codes are defined and delivered by Ellucian and stored in the BANK.RECON.STATUSES record of the CORE.VALCODES file. You can view bank reconciliation status codes using VAL.

Box Codes

You can use box codes to identify tax forms and boxes on the tax forms. Colleague uses the box code information to accumulate paid item information into tax forms and their box numbers.

Tax forms have boxes that require entry of specific information. You can use the Tax Form Box Codes (TFBX) form to set up the tax forms’ box codes. These codes are stored in the BOX.CODES file. You can set up a box code, the description of the box, the tax form on which the box appears, and the box number.

Box codes are also used as the special processing codes when identifying tax form codes.

Buildings

You can use building codes to identify specific building location information for use in property control, scheduling activities, events, and classes, and give complete address information for use in summoning rescue vehicles, such as ambulances, police cars, or fire trucks, or for insurance purposes. Building codes are defined using the Building (BLDG) form and are stored in the BUILDINGS file.

Building Access

See “Access Statuses” on page 16.

Table 8: Bank reconciliation status codes

Bank Reconciliation Status Code Description

L Loaded to Intermediate

LE Loaded to Inter with errors

I Imported

IE Imported with errors

R Reconciled

RE Reconciled with errors


GePro

Building Condition

Use building condition codes to describe the condition of a building on your campus (or other building). Your institution may have acquired a building and you need to specify the condition of the building. Some examples of building conditions could be:

• satisfactory

• new

• occupied

• remodeling

• demolition

• termination

You can define and maintain building condition codes on VAL. Building condition codes are stored in the BUILDING.CONDITIONS record of the CORE.VALCODES file.

Building Ownership Statuses

Building ownership statuses are used on the Buildings (BLDG) form when defining a building code. Ownership statuses describe the ownership of a building. Examples of ownership statuses could be:

• owned in fee simple

• institution amortization

• corporation amortization

• leased/rented

You can define building ownership codes using VAL. These codes are stored in the BLDG.OWNERSHIP.STATUSES record of the CORE.VALCODES file.

Building Sectors

You can use building sector codes to identify the sector of the campus in which a certain building is located. Some example of sectors could be:

• north

• south

• northeast

• southeast

You can define and maintain sector codes using VAL. Sector codes are stored in the BUILDING.SECTORS record of the CORE.VALCODES file.


GePro

Building Types

Building types codes describe the type or even usage of a building on your campus (or elsewhere). Some examples of building types could be:

• dormitory

• library

• gymnasium

• hospital

• laboratories

• chapel

• classrooms/lecture halls

• auditorium

You can define and maintain building types codes on VAL. Building types codes are stored in the BUILDING.TYPES record of the CORE.VALCODES file.

Calendar Day Type

Calendar day type codes are used to indicate different types of special days that can be on a campus calendar.

The special processing code of “HO” must be put on one of the entries because that is the default entry when you create a new special day. There is also special processing invoked during scheduling that deals with holidays. Only calendar days with a special processing code of “HO” are checked for conflicts. For example, a warning is given if you attempt to schedule a class on a day marked as a holiday. You can give more than one code the special processing code of “HO”. Each type code marked that way will be treated as days when things should not be scheduled. However, the default on the Campus Calendar Special Days (CMPS) form is the first type code with the “HO” special processing code.

You can also use these calendar day types in your billing calculations. For example, Ellucian University bases its refund policy on the number of days used. However, DU does not include days defined as holidays on its main campus calendar as billable days. For more information about using calendar day types in your billing calculations, see Using Accounts Receivable and Cash Receipts.

You can now define a code in the calendar day types validation code table to identify days to exclude from registration refund calculations, regardless of whether they are holidays. You may need to distinguish between legal holidays and campus holidays (such as spring break) to exclude from (or include in) refunds. This new option essentially lets you identify holidays to exclude or include without losing the scheduling function of holidays in your academic calendar.

For example, spring break should be handled as a holiday (that is, no classes scheduled) so that it is included in the count of days for refunds. However, Labor Day, a legal holiday, would be excluded from refund calculations.


GePro

When defining calendar day type codes (CALENDAR.DAY.TYPES), the first special processing code field is used for “calendaring” or scheduling purposes. The second special processing code field is used for calculating registration refunds.

Note: Colleague’s Financial Aid module uses its own method of calculating calendar days for refunds to comply with Title IV Return of Funds policies. See Using Financial Aid: Awarding & Aid Distribution for information about calculating refunds in the Financial Aid module.

Refer to the scenarios in this table to help you specify how to enter special processing codes.

Use VAL in the Core application to define calendar day type codes. They are stored in the CALENDAR.DAY.TYPES record of the CORE.VALCODES file.

Calendar Months

Calendar month codes are used to identify each month in the year with a three-letter code, full text description, and two-digit numeric special processing value, as shown in the following examples:

• JAN - January (01)

• FEB - February (02)

• DEC - December (12)

Scenario

First Special Processing Code Field

Second Special Processing Code Field

Holiday for calendar scheduling purposes, exclude from refund days, for example, Labor Day. (No meeting day, no charge)

HO HO

Holiday for calendar scheduling purposes, include in refund days, for example, spring break. (No meeting day, charge)

HO

Not a holiday for calendar scheduling purposes, not a Saturday or Sunday (because those can be explicitly designated on REFF), but exclude from refund days anyway. (Meeting day, no charge)

HO

Not a holiday for calendar scheduling purposes and include in refund days, for example, any regularly scheduled class day (Meeting day, charge)


GePro

Calendar months are defined and delivered by Ellucian as CALENDAR.MONTHS in the CORE.VALCODES file. You cannot modify these codes.

Campus Calendar

Campus calendar codes are used to describe a specific block of time associated with campus events. Do not confuse campus calendar codes with term codes; term codes are used to describe campus calendar codes. For example, you can define a campus calendar code for holidays for the 2000 spring term. The calendar code could be 00/SP and the term can also be 00/SP. These, however, are two different entities because calendar codes are stored in the CAMPUS.CALENDAR file and terms are stored in the TERMS file.

You can define campus calendar codes using the Campus Calendars (CMPC) form. These codes are used on the Campus Calendar Special Days (CMPS) form and the Miscellaneous Scheduling (MSCH) form.

Category of Use

See “Room Category” on page 103.

CCD Grantor Codes

CCD (certificate, credential, diploma) grantor codes are used on the Other CCDs (OCCD) form to specify the agency, body, or organization that awards the certificate, credential, or diploma. Example of CCD grantors could be:

• degree-granting institution

• professional body

• both degree institution and professional

You can use VAL to define and maintain CCD grantor codes. These codes are stored in the CCD.GRANTOR.CODES record of the CORE.VALCODES file.

CCD Types

CCD (certificate, credential, diploma) types are used on the Other CCDs (OCCD) form to categorize the certificate, credential, or diploma. Examples of CCD types could be:

• certificate

• diploma

• license

• undergrad certificate

• undergrad diploma

• undergrad license


GePro

You can use VAL to define and maintain CCD type codes. These codes are stored in the CCD.TYPES record of the CORE.VALCODES file.

Certification Load Indicators

Certification load indicators specify whether the certification restricts a person to participating in a part-time role or on some other basis. These codes are used in Wisconsin state reporting but are not used otherwise in Colleague. These codes are used on the Credential Certification (CRCE) form in Colleague Core and on the WI Certification Detail (WID5) form in Colleague Student. Certification load indicators are:

• full time

• part time

• other

These codes are stored in the CERT.LOAD.INDICATORS record of the CORE.VALCODES file.

Note: Wisconsin Institutions: Do not change the values in this validation code table because the Wisconsin state reporting programs use the values (F, P, and O). Institutions not in Wisconsin can change these values as desired.

Certification Requirement Codes

You can use certificate requirement codes to specify a needed action on an associated certification requirement. These codes can denote reporting actions such as:

• add or delete

• what to send to the state

• a required action by the person trying to achieve another level of the credential

These codes are used in Wisconsin state reporting but are not used otherwise in Colleague. These codes are used on the Credential Certification (CRCE) form in Colleague Core and on the WI Certification Detail (WID5) form in Colleague Student.

You can use VAL to define and maintain certification requirement codes in the CERT.REQMT.CODES record of the CORE.VALCODES file.

Certificate Statuses

Certificate status codes reflect the status of the certification information of an academic credential. You can report if a certification which is to be deleted has been previously reported. Examples of certificate statuses are:

• new certification

• add/delete requirements

• changed certification


GePro

• terminated staff member

• delete this certification

In Colleague Student, when a faculty member is assigned to a course section, Colleague verifies if the faculty member should be teaching the course section by checking both qualifications and academic credentials. For the academic credential, the end date normally determines if that credential can be applied to the course section. However, if the credential’s certification status has a value with a special processing code of 1, then the certification has been cancelled or terminated, and the credential will not be seen as making that faculty member eligible to teach the course section regardless of the credential end date.


You can use VAL to define and maintain certification requirement codes in the CERT.STATUSES record of the CORE.VALCODES file.

Certificate Types

Certificate types designate the type of certification represented by this credential.

• provisional

• approval status

• uncertified

• emergency approval


You can use VAL to define and maintain certification requirement codes in the CERT.TYPES record of the CORE.VALCODES file.

Chapter

Chapter codes represent specific chapters of national organizations. Chapter codes are maintained on the Chapters Definition (CHP) form and are stored in the CHAPTERS file.

Classrooms

Classroom codes are defined on the Rooms (RMSM) form by combining a building code with a room number. You can only gain access to RMSM by detailing from the Building/Room Summary (BRMS) form. When you access BRMS, you are prompted to enter a building code. You can then add a room. When you enter a room number to add, RMSM is then displayed. By entering a description on RMSM for the room (and any other information), then save the information, a classroom record is created in the CLASSROOMS file.


GePro

For example, if you add room 101 to building Taylor, the classroom code for this is TAYLOR*101 in the CLASSROOMS file.

Commencement Sites

Commencement sites are used by the following forms and processes to determine the site of commencement ceremonies:

• Graduate Honors Update (GRHM)

• Graduate Adjustment (GADJ)

• Update Acad Credentials File (UACF)

• Graduate Audit Report (GDAU)

You can define and maintain commencement site codes using VAL. Commencement site codes are stored in the COMMENCEMENT.SITES record of the CORE.VALCODES file.

Communication Actions

Communication action codes are used to specify the kind of action you want taken on a group of individuals that meet certain criteria and rules. These codes initiate specific actions on their associated correspondence requests. Communication action codes are used on the Corres Request Assignment (CRA) form and the Group Track Assignment (GTA) form. Communication action codes are defined and delivered by Ellucian and stored in the CC.ACTIONS record of the CORE.VALCODES file. Valid communication action codes are:

• add

• delete

• reset

Communication Codes

Communication codes identify pieces of incoming correspondence from an individual. When your institution receives a piece of correspondence from an individual, the code representing that piece of correspondence is recorded in the system for that individual. The receipt of a piece of correspondence from an individual can trigger other actions, such as updating an individual’s status, sending a piece of outgoing correspondence, or assigning the individual to a follow-up track.

Communication codes are defined and maintained on the Communication Codes (CMC) form. See Using Communications Management for more information on defining communication codes.

Classification of Instructional Program (CIP)

The Classification of Instructional Programs (CIP) codes are a coding scheme that contains titles and descriptions of postsecondary instructional programs. It was developed by the National Center for Education Statistics (NCES) for the collection and reporting of


GePro

postsecondary degrees by field of study using standard classifications that capture the majority of academic programs.

You can specify CIP codes on the following forms using the Natl ID field:

• Courses (CRSE)

• Sections (SECT)

• Academic Programs (PROG)

• Rooms (RMSM)

• Majors (MAJR)

• Minors (MINR)

• Departments (DEPT)

Use the CIP Definition (CIPD) form to enter and maintain CIP codes.

When you enter a CIP code, Ellucian recommends that you enter the code as it is defined by NCES, including all zeros and the decimal point.

For information about the fields on CIPD, see the online help.

Consent

This is the code to indicate whether this person (or parent or guardian) has consented to the capture and processing of personal data by this institution for the specified persona and data source.

• CO - Consent

• CP - Consent (Parent/Guardian)

• DE - Decline

• DP - Decline (Parent/Guardian)

These codes are delivered as defaults but you can change them prior to using this functionality. This is the PERSONAL.DATA.CONSENT.CODES validation table and is maintained through VAL. This field is used with the Consent to Capture and Process Personal Data (CPPD) form.

Construction Types

A building can have more than one construction type associated with it. The roof can be of one type, while the walls are of another type. You can use construction types codes to specify the different types of construction material used on a building. Examples of construction types include:

• brick

• brick/steel

• wood frame


GePro

• glass steel frame

You can define and maintain construction types codes using VAL. Construction types codes are stored in the CONSTRUCTION.TYPES record of the CORE.VALCODES file.

Contact Results

Contact results are used to specify the type of actions that may have resulted from contacting a prospect. Examples of contact results are:

• gift given

• pending

• refusal

Contact results are used in the Result field on the Contact History (CON) form in the Staff/Volunteers Information module.

You can define and maintain contact results codes using VAL. Contact results codes are stored in the CONTACT.RESULTS record of the CORE.VALCODES file.

Contact Roles

Contact roles indicate the role a staff member played for a contact, such as counselor, tour guide, host, or interviewer. Contact roles codes are used in the Roles file on the Contact History (CON) form in the Staff/Volunteers Information module.

You can define and maintain contact roles codes using VAL. Contact roles codes are stored in the CONTACT.ROLES record of the CORE.VALCODES file.

Control Record Statuses

These codes are the valid statuses for a control record. A control record is used when more than one procedure are inter-related. Control record statuses are used to make sure the procedures are run in the correct sequence. Control record status codes are defined and delivered by Ellucian and stored in the CONTROL.RECORD.STATUSES record of the CORE.VALCODES file.

Convenience Fee Codes

These codes define fees to be charged to a payer for processing a payment through e-commerce (for example, a credit card or an electronic check payment). Convenience fees can be used to pass along to the payer all or part of the transaction cost associated with processing an e-commerce payment. For example, if your merchant bank charges you 2% of each credit card payment processed through e-commerce, you may want to set up a convenience fee that charges the payer 2% of the credit card payment.

You can define and maintain convenience fee codes using the Convenience Fee (CVFE) form. Convenience fee codes are stored in the CONVENIENCE.FEE file.


GePro

Conversion Types

Conversion type codes are used on the Convert Fields (CONF) utility. This table lists the valid conversion type codes and their descriptions.

You can use these codes to convert field information in a specified file. You identify the type of change or conversion you want to occur using the appropriate conversion type code. For example, if you want to change remove all spaces in a field, you could use the TRIM code.

Conversion type codes are defined and delivered by Ellucian and stored in the CONV.TYPES record of the CORE.VALCODES file. You cannot change these codes because they are hard coded in the S.CONV.RECORDS subroutine.

Corporation Name Tokens

Corporation name tokens are used by the S.XLAT.CORP.SORT.NAME subroutine to compress and standardize organization names in the Corp LookUp process. These codes are stored in the CORP.NAME.TOKENS record in the CORE.VALCODES file. You should maintain these codes only with the assistance of an Ellucian representative. Contact the Solution Center for assistance with maintaining corporation name token codes.

Corporation Statuses

Corporation statuses define the status of an organization. You can define an active status by not entering a status code for an organization because most organizations are active. Some examples of corporation statuses are:

• bankrupt

• defunct

• Chapter 9

• merged

Table 9: Conversion type codes

Code Description

UCW Convert Upper Case Word

UC Convert Upper Case

TRIM Trim All Spaces

TRIMB Trim Trailing Spaces

TRIMF Trim Leading Spaces

LC Convert Lower Case

FR Field Replace

WR Word Replace


GePro

• inactive

Corporation statuses are stored in the CORP.STATUSES record of the CORE.VALCODES file. You can define and maintain corporation statuses using VAL.

Corporation Types

Corporation type codes are used to indicate the type of business the corporation conducts. The corporation type code and its associated description display on forms and reports. Examples of corporation types are:

• insurance

• construction

• food service

• computer

Corporation types are stored in the CORP.TYPES file. You can define and maintain corporation types using the Organization Types (ORTY) form.

Correspondence Actions

You can use correspondence actions to identify specific subroutines that are called during various processes in the Communications Management module. You can set up subroutines to:

• update fields in other modules or databases

• produce special reports or documents

• send E-mail to another user on the system

• The subroutines you set up using these correspondence action codes can be used when:

• updating history through the Process Corres. Batch (PCB) process

• printing documents through the PCB process

• recording correspondence as received through the Communication Code Entry (CRI) form, the Group Communication Entry (CRG) form, or the Individual Requests (IRQ) form

• a correspondence request is completed through the Communication Code Entry (CRI) form, the Selected Group Entry (CRG) form, or the Individual Requests (IRQ) form

Correspondence action codes are stored in the CRC.ACTIONS file. You can define and maintain correspondence action codes using the Corres Actions Definition (CRAD) form.

Correspondence Received Codes

See “Communication Codes” on page 33.


GePro

Correspondence Requests

Correspondence requests are like document tracks, but they identify groups of required incoming correspondence (rather than outgoing correspondence). Correspondence requests are also called requirements tracks. A correspondence request is made up of the list of incoming correspondence (communication codes) and any special actions that should take place when all required correspondence is received.

See Using Communications Management for more information on defining correspondence requests.

Correspondence Statuses

Correspondence status codes work with communications codes (incoming correspondence) to define whether the piece of correspondence is received, waived, or incomplete for an individual. When used with correspondence request codes (requirements tracks), these status codes can trigger other actions, such as generating outgoing correspondence or updating a status flag.

Correspondence status codes are user-defined, but they use special processing codes to indicate whether the code triggers another action, as indicated below:

Correspondence status codes are maintained on VAL. These codes are stored in the CORR.STATUSES record of the CORE.VALCODES file.

Correspondence Types

Correspondence types determine who is addressed in the correspondence name, the salutation, the mail label name, and the address for this letter. Correspondence types

Table 10: Correspondence status codes

Special Processing Field 1 Description

blank If special processing field 1 is blank, the correspondence status code is considered to be incomplete. Any requirements defined in a requirements track are not met. No triggers are activated.

0 If special processing field 1 is set to 0, the correspondence status code is considered to be waived. The requirements defined in a requirements track are met, but any triggers are not activated.

1 If special processing field 1 is set to 1, the correspondence status code is considered to be received. The requirements defined in a requirements track are met, and any triggers are activated.

If you define a correspondence status code that means “received” and do not set special processing field 1 to “1,” none of your triggers will be processed.


GePro

include “I” (for individual) or “J” (for joint). Correspondence type codes are used on the Individual Pending Corres Det (IPCD) form.

Correspondence type codes are defined and delivered by Ellucian and stored in the CORRESPONDENCE.TYPES record of the CORE.VALCODES file. You cannot modify these codes.

Country

Country codes represent various countries throughout the world. They are used to specify information from countries other than your home country.

Country codes are maintained on the Countries Definition (CTRY) form. These codes are stored in the COUNTRIES file.

County

County codes represent counties or regions within states. These codes are cross-referenced to zip codes. When you enter a zip code, the system automatically finds the appropriate county code for that zip code if the link is defined.

County codes are maintained on the Counties Definition (CNTY) form. These codes are stored in the COUNTIES file.

Credit Card Types

Credit card types record the type of credit card a person uses to pay for an event. Credit card types are for informational purposes only; the system does not verify or validate the type. One way of using a credit card type is to track individuals who use your institution’s or a certain organization’s credit card. Some examples of credit card types are:

• MasterCard

• VISA

• American Express

• Diner’s Club

Credit card types are stored in the CREDIT.CARDS record of the CORE.VALCODES file. You can define and maintain credit card types using VAL.

Database Usage Types

Database usage types are used in Rules Processor to indicate the way a database element is used. You can use database usage types on such forms as the Database Element Linkages (RDEL) form. (Database usage types display on the ELF Field Mapping Detail (ELMD) form for informational purposes only.)

Example of database usage types are:

• key

• list


GePro

• associated

• data

• q pointer

• x pointer

• text

• virtual field

Database usage types are defined and delivered by Ellucian and stored in the DB.USAGE.TYPES record in the CORE.VALCODES file. You cannot modify these codes.

Data Return Types

Use these codes to specify the return type when defining virtual fields. Return types include the following:

• internal

• external

• translated

• code

You can use data return types on the Virtual Field Test and Debug (RTVF) form. Data return types are defined and delivered by Ellucian as GET.DATA.RETURN.TYPES validation code table.

Day Part

Day parts codes indicate the portion of the day in which the majority of a program is aired. If this field is used in conjunction with a program break, the code applies to the program preceding the break. This information is used in the SIP Report (SIPR).

Degree Types

Degree types are used to define degrees on the Degree Codes (DEGR) form and to define other degrees on the Other Degrees (ODEG) form. These codes are used in the Financial Aid module for FISAP report and in Texas state reporting.

You can define and modify degree type codes using VAL. Degree type codes are stored in the DEGREE.TYPES record of the CORE.VALCODES file.

Denominations

Denomination codes indicate the religious affiliation of an individual. Examples of denominations could be:

• Anglican

• Church of Christ


GePro

• Eastern Orthodox

• Roman Catholic

• Seventh-Day Adventists

Denomination codes are stored in the DENOMINATIONS file. You can define denomination codes using the Denominations (DENO) form.

Departments

Department codes correspond to all departments at your institution, including physical departments, academic departments and administrative departments. You should include any department to which a person or physical asset can be associated.

For example, departments are used in the Human Resources module on the Position Definition (POSD) form to indicate the department to which a position belongs. Another example is in the Fixed Assets module, where you would identify to which department office furniture or equipment belongs.

Department codes can also used for HR IPEDS reporting. When an institution has both medical and non-medical positions, either the department or the location is used to distinguish medical positions from non-medical positions.

You can define and maintain department codes using the Departments (DEPT) form. Department codes are stored in the DEPTS file.

Directory Codes

Directory codes are used to specify a particular directory in which an individual should belong. For example, you would not want to list a regular student in the faculty directory; however, you may want to list a student in both the student directory and the faculty directory if that student is a member of the faculty (such as a graduate assistant).

You can specify in which directory a student should belong by entering a directory code in the Directory field on the Registration Person Entry (RGPE) form and on the Biographic Information (BIO) form.

In order to automatically flag a student’s record for FERPA protection, a directory code must be set up and assigned to the student who requested FERPA protection.

For reporting purposes, directory codes are used on the Student/Faculty Directory (SFDR), Resident Directory (RESD) and NDVS Deg/CCD Student Export (NDVS) forms.

You can define and maintain directory codes using VAL. Directory codes are stored in the DIRECTORY.CODES record of the CORE.VALCODES file.

Disability

Disability codes are used to indicate any handicap or disability associated with an individual. You can use the Person Health Information (PHIN) form to assign disability codes to an individual and indicate whether those assigned disabilities can be reported to reporting agencies.


GePro

You can define and maintain disability codes using the Disabilities (DISD) form.

Disabilities related to employment are assigned on the Employment Health Information (EHIN) form. You can define and maintain HR disability codes on the HR Disabilities (HDIS) form.

Disability Categories

Disability category codes are used to track specific disabilities and group similar disabilities together for Texas state regulatory reporting. Texas CB reports require that certain disabilities be reported.

Disability categories are stored in the DISABILITY.CATEGORIES record of the CORE.VALCODES file and defined on VAL.

Disability Types

Disability type codes are used along with disability codes to identify a person’s disabilities. Use disability type codes on the Person Health Information (PHIN) form. MIS California reports require that disabilities be categorized. Use these disability type codes to meet state requirements.

Disability type codes are stored in the DISABILITY.TYPES record of the CORE.VALCODES file and defined on VAL.

Disability type codes related to employment are used on the Employment Health Information (EHIN) form. These disability type codes are stored in the HR.DISABILITY.TYPES record of the HR.VALCODES file and defined on VAL.

Distributions

Distribution codes define the debit side of a payment. When a payment is recorded in Colleague Student, the distribution code identifies the general ledger (GL) cash account to which the payment is posted.

Your institution may define unique distributions used to record payments for different operating funds, agency funds, locations, graduate levels, etc. For example, you can use one distribution for payments received for your undergraduate program, and another distribution for payments received for your Continuing Education program.

Use the Distribution (DIST) form to define and maintain distribution codes. Distribution codes are stored in the DISTRIBUTIONS file.

When you make additions or changes to the DISTRIBUTIONS file in Colleague Core, Colleague makes identical changes to the RCPT.TENDER.GL.DISTR file in Colleague Student.

Divisions

Use division codes to group departments within your institution. Division codes can be associated with department codes (that is, you can define specific departments as belonging to specific divisions) using the Departments (DEPT) form.


GePro

For example, you could group the following departments under the Humanities division:

• English

• Technical Communications

• Philosophy

• Rhetoric

• Foreign Languages

• Social Sciences

Although each are separate departments, you can group them in the Humanities division.

Use the Divisions (DIV) form to define and maintain division codes. Division codes are stored in the DIVISIONS file. You can also use division codes for sorting and reporting purposes throughout Colleague Student.

Document

Document codes are used to define the pieces of outgoing correspondence for your institution. These document codes store a profile of the document. The text of the document itself is stored as a separate file in the format used by your word processor.

See Using Communications Management for more information on creating document codes.

Document Classes

The default document file used by the system is specified in the DTYP.DOCUMENT.FILE field. You can still use the Document Classes to categorize the document. Examples of document class codes include the following:

• P, the text you enter is stored in your default filing area for personal letters, PER.LTRS.

• T, the text you enter is stored in your default filing area for template letters, TMP.LTRS.

• C, the text you enter is stored in the default filing area you have established for your code-only letters.

Your institution can choose to define other document classes, with other associated default filing areas. Contact your system administrator for more information about where text is stored in any such cases.

Document class codes are stored in the WP.DOCUMENT.TYPES record of the CORE.VALCODES file and defined on VAL.


GePro

Document History Types

Document history types are used on the Document Codes (DOC) form when defining document codes. The history type indicates whether a historical record will be kept when the document is processed.

Document history types are defined and delivered by Ellucian and stored in the DOCUMENT.HISTORY.TYPES record of the CORE.VALCODES file.

Document Print Frequency

Use document print frequency codes to specify the frequency by which to print documents. These codes are used on the Document Codes (DOC) form when defining document codes. Document print frequency codes are set up to print a document daily or on any day of the week.

Document print frequency codes are defined and delivered by Ellucian and stored in the DOC.PRINT.FREQUENCIES record of the CORE.VALCODES file. You cannot modify these codes.

Document Tracks

Document tracks, also called follow-up tracks or tracking codes, identify groups of individual pieces of outgoing correspondence. A track is made up of the list of outgoing correspondence and the dates on which the correspondence should be processed.

See Using Communications Management for more information on defining document tracks.

Document Types

Document types define the various types of documents and correspondence that the Communications Management module should create when processing correspondence. These document types also identify whether the history is updated when a particular document type is used. These document types are used when creating document codes.

Table 11: Document history type codes

Code Description

Code The document code is retained as history for the individual when processed.

Full A full history is kept on the document.

None No history is kept on the document.


GePro

Ellucian provides and supports the following standard document types.

Use the Document Type Setup (DTYS) form to create additional document types.

Duplicate Categories

The ELF process assigns a duplicate category code (stored in the DUPL.CATEGORIES validation code table) to imported records.

These categories are set by the ELF duplicate detection process. This specifies the duplicate category based on the rating as defined on the Duplicate Match Criteria (DUPC) form.

Duplicate category codes are used on the ELF Target Results/Dupl Res (TGTR) form.

E-Commerce Java Classes

These codes are used to define the software Colleague uses to interface with your e-commerce provider when sending and receiving information about payment transactions.

Table 12: Ellucian-provided and supported standard document types

Document Type OutputInitialization Subroutine

Document Merge Subroutine

ASCII ASCII format output file

S.INIT.ASCII S.ASCII

CODE Update history file only

not applicable not applicable

COQT Comma-quote output file

S.INIT.COMMA.QUOTE S.COMMA.QUOTE

DIF DIF format output file

S.INIT.DIF S.DIF

EMAIL E-mail built from document paragraph

not applicable S.EMAIL

FORM Print form processing

S.INIT.PRINT.FORM S.PRINT.FORM

LIST Saved list format

S.INIT.LIST S.LIST

WP WordPerfect merge/print

not applicable S.WP.MERGE

WPMO WordPerfect merge file only

S.INIT.WORDPERFECT S.WORDPERFECT


GePro

E-commerce Java classes are defined and delivered by Ellucian and stored in the ECOMM.JAVA.CLASSES record of the CORE.VALCODES file. You cannot modify these codes.

E-Commerce Providers

These codes define the entity with whom you process your electronic payments. Your institution may use a single e-commerce provider, or may use multiple e-commerce providers. For each e-commerce provider, you must define the host address, host port number, and number of seconds before a transaction is cancelled (transaction timeout).

Use the e-Commerce Providers (ECPR) form to define and maintain e-commerce providers. E-commerce providers are stored in the ECOMMERCE.PROVIDER file.

E-Commerce Provider Accounts

These codes define information about an account or application that you have with your e-commerce provider. Your institution must have at least one e-commerce provider account or application defined and, depending on the types of e-commerce transactions you process at your institution, you can have more than one. For each e-commerce provider account, you must define a description, e-commerce provider, account information, and Java class.

You can define and maintain e-commerce provider accounts using the e-Commerce Provider Account (ECPA) form. E-commerce provider accounts are stored in the ECOMM.PROVIDER.ACCT file.

E-Commerce Provider Account Mappings

These mappings are used to map processing for all or specific types of e-commerce payments to an e-commerce provider account or application, and to optionally charge conveniences fees on e-commerce payments.

If your institution uses Colleague e-Commerce, you must have at least one e-commerce provider account mapping and, depending on your business practices, may have multiple mappings. E-commerce mappings provide a way to route your e-commerce transactions to separate e-commerce provider accounts.

Use the e-Commerce Provider Account Mapping (EPAM) form to define and maintain e-commerce provider account mappings. E-commerce provider account mappings are stored in the PROVIDER.ACCT.DISTR file.

E-Commerce Transaction Types

These transaction types are used to define the payment transactions sent to your e-commerce provider.

E-commerce transaction types are defined and delivered by Ellucian and stored in the ECOMMERCE.TRANSACTION.TYPES record of the CORE.VALCODES file. You cannot modify these codes.


GePro

EDI Academic Credit Types

These are the valid codes for use as the academic credit type code in the SUM & CRS segments of an EDI transaction (SUM01, CRS02) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI academic credit types are defined and delivered by Ellucian and stored in the EDI.ACADEMIC.CREDIT.TYPES record of the CORE.VALCODES file. View the valid codes on VAL.

EDI Activity Codes

EDI activity codes are the valid codes for use as the EDI activity code in the ATV segment of an EDI transaction (ATV02) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI activity codes are defined and delivered by Ellucian and stored in the EDI.ACTIVITY.CODES record of the CORE.VALCODES file. View the codes on the VAL.

EDI Activity Date Types

EDI activity date codes are the valid codes for use as the activity or award date qualifier code in the DTP segment of an EDI transaction (DTP01) that follows an ATV segment in

Table 13: EDI academic credit types codes

Code Description

I Institutional

CE Continuing Education

N Non Credit

Table 14: EDI activity codes

Code Description

A01 Archery

A02 Badminton

AO3 Baseball

AO4 Basketball

AO5 Bowling


GePro

SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI activity date types are defined and delivered by Ellucian and stored in the EDI.ACTIVITY.DATE.TYPES record of the CORE.VALCODES file. View the codes on VAL.

EDI Address Types

EDI Address Types are the valid codes for use as the address location qualifier in the N4 segment of an EDI transaction (N405) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI address types are defined and delivered by Ellucian and stored in the EDI.ADDRESS.TYPES record of the CORE.VALCODES file. View the codes on VAL.

EDI Arrival Type

These are the valid codes for use as the date type qualifier for the DTP segment of an EDI transaction (DTP01) in SPEEDE transcript processing. However, this element only has

Table 15: EDI activity date types codes

Code Description

007 Effective

036 Expiration

043 Publication

050 Received

055 Confirmed

Table 16: EDI address types codes

Code Description

DT Domicile Type Code

F Current Address

H Home Address

I Home Base Address

L Local Address


GePro

these values in certain contexts, such as when the DTP segment follows the IND segment in the TS130. Examples of the delivered codes include those listed in this table.

EDI arrival types are defined and delivered by Ellucian and stored in the EDI.ARRIVAL.TYPE.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Award Codes

These are the valid codes that represent student awards for use in the ATV segment of an EDI transaction (ATV02) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI award codes are defined and delivered by Ellucian and stored in the EDI.AWARD.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Citizenship

These are the valid codes for use as the citizenship status code in the DMG segment of an EDI transaction (DMG06) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

Table 17: EDI arrival type codes

Code Description

AAA Arrival in Country

ACA Immigration Date

ABA Estimated Immigration Date

Table 18: EDI award codes

Code Description

MO1 Scholar Award with Honor

MO2 Scholar Award w/ Distinct

MO3 State Scholar Award

MO4 National Scholar Award

MO5 National & State Scholar Awd

Table 19: EDI citizenship codes

Code Description

1 US Citizen

2 Non-Resident Alien


GePro

EDI citizenship codes are defined and delivered by Ellucian and stored in the EDI.CITIZENSHIP.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Contact Function Codes

These are the valid codes for contact function in the PER segment of an EDI transaction (PER01) in SPEEDE transaction processing. Contact function codes describe the function of the contact person at an institution. Examples of the delivered codes include those listed in this table.

EDI contact function codes are defined and delivered by Ellucian and stored in the EDI.CONTACT.FUNCTION.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Countries

These are the valid codes for use as the country code in various segments of an EDI transaction (for example, DMG07, IND01, N404, etc.) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

3 Resident Alien

4 Illegal Alien

5 Alien

Table 20: EDI contact function codes

Code Description

BP School Principal

DN Dental School Adm Office

E2 Evening Programs Office

EM Emergency Contact

FA Financial Aid Office

Table 21: EDI country codes

Code Description

AD Andorra

AE United Arab Emirates

AF Afghanistan

AG Antigua and Barbuda

Table 19: EDI citizenship codes

Code Description


GePro

EDI country codes are defined and delivered by Ellucian and stored in the EDI.COUNTRIES record of the CORE.VALCODES file. View the codes on VAL.

EDI Course Level

These are the valid codes for use as the Academic Grade or Course Level Codes used in the SUM & CRS segments of an EDI transaction (SUM02,CRS08) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI course level codes are defined and delivered by Ellucian and stored in the EDI.COURSE.LEVEL.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Degree CCD Codes

These are the valid codes for use as the degree/CCD type codes in the PCL & DEG segments of an EDI transaction (PCL05,DEG01) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI course level codes are defined and delivered by Ellucian and stored in the EDI.DEGREE.CCD.CODES record of the CORE.VALCODES file. View the codes on VAL.

AI Aguilla

Table 22: EDI course level codes

Code Description

1 Remedial

2 Basic

3 Teacher’s Aide

4 General

5 Applied

Table 23: EDI degree/CCD type codes

Code Description

2.1 Post-secondary certificate/diploma (< 1 yr)

2.2 Post-secondary certificate/diploma (1-4 yr)

2.3 Associate Degree

2.4 Baccalaureate degree

2.5 Baccalaureate degree (honors)

Table 21: EDI country codes

Code Description


GePro

EDI Eligible to Return

These are the valid codes for use as the “eligible to return” status code in the SST segment of an EDI transaction (SST04) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI eligible to return codes are defined and delivered by Ellucian and stored in the EDI.ELIGLTO.RETURN.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Enroll Statuses

These are the valid codes for use as the current enrollment status code in the SST segment of an EDI transaction (SST07) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI enrollment statuses codes are defined and delivered by Ellucian and stored in the EDI.ENROLL.STATUSES record of the CORE.VALCODES file. View the valid on VAL.

EDI Entity Types

These are the valid codes for use as the entity identifier code in the IN1 segment of an EDI transaction (IN103) for SPEEDE transcript processing. The code descriptions apply to

Table 24: EDI eligible to return codes

Code Description

B27 Eligible to continue/return

B28 Suspension or Dismissal

B29 Expelled

B51 Suspension/Dismissal; can reapply

Table 25: EDI enrollment status codes

Code Description

B30 Current enrolled/IP course not included

B31 Not currently enrolled

B33 Unreported/information not available

B34 Current enrolled/IP courses included


GePro

either individuals or entities. Examples of the delivered codes include those listed in this table.

EDI entity codes are defined and delivered by Ellucian and stored in the EDI.ENTITY.TYPES record of the CORE.VALCODES file. View the codes on VAL.

EDI Ethnic Codes

These are the valid codes for use as the race or ethnicity code in the DMG segment of an EDI transaction (DMG05) for SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI ethnic codes are defined and delivered by Ellucian and stored in the EDI.ETHNIC.TYPES record of the CORE.VALCODES file. View the codes on VAL.

EDI Field of Study Types

These are the valid codes for use as the field of study type in the FOS segment of an EDI transaction (FOS01) for SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

Table 26: EDI entity codes

Code Description

6X Disciplinary Contact

E1 Entity Legally Responsible

E2 Entity Child Resides With

E3 Entity Reps and Residing w/

E4 Other Associated Entity

Table 27: EDI ethnic codes

Code Description

7 Not Provided

A Asian or Pacific Islander

B Black

C Caucasian

D Subcontinent Asian American

Table 28: EDI fields of study codes

Code Description

C Concentration


GePro

EDI field of study codes are defined and delivered by Ellucian and stored in the EDI.FIELD.OF.STUDY.TYPES record of the CORE.VALCODES file. View the codes on VAL.

EDI Honors

These are the valid codes for use as the degree honors status code in the DEG segment of an EDI transaction (DEG05) for SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI honors codes are defined and delivered by Ellucian and stored in the EDI.HONORS record of the CORE.VALCODES file. View the codes on VAL.

EDI Immunization Sources

These are the valid codes for use as the immunization report type code in the IMM segment of an EDI transaction (IMM05) for SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

E Endorsement

G Graduate Non-degree

L Licensing

M Major

Table 29: EDI honors codes

Code Description

B35 Highest honors

B36 Second highest honors

B37 Third highest honors

Table 30: EDI immunization source codes

Code Description

COUNTY County Record

HC Health Certificate

HR Health Clinic Record

IG State School Immunization Records

MG MSRTS Record

Table 28: EDI fields of study codes

Code Description


GePro

EDI immunization sources codes are defined and delivered by Ellucian and stored in the EDI.IMMUNIZATION.SOURCES record of the CORE.VALCODES file. View the codes on VAL.

EDI Immunization Statuses

These are the valid codes for use as the immunization status code in the IMM segment of an EDI transaction (IMM04) for SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI immunization status codes are defined and delivered by Ellucian and stored in the EDI.IMMUNIZATION.STATUSES record of the CORE.VALCODES file. View the codes on VAL.

EDI Immunizations

These are the valid codes for use as the immunization type codes in the IMM segment of an EDI transaction (IMM01) for SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI immunization codes are defined and delivered by Ellucian and stored in the EDI.IMMUNIZATIONS record of the CORE.VALCODES file. View the codes on VAL.

Table 31: EDI immunization status codes

Code Description

1 First Inoculation

2 Second Inoculation

3 Third Inoculation

4 Fourth Inoculation

5 Fifth Inoculation

Table 32: EDI immunization type codes

Code Description

V03.1 Vaccine Typhoid-Paratyphoid

V03.2 Vaccine Tuberculosis

V03.6 Vaccine Pertussis

V03.7 Vaccine Tetanus Toxoid

V03.8 Vaccine Bacterial Dis NEC


GePro

EDI Inst Identifier Codes

The institution identifier validation code table is used in SPEEDE transcript processing by the EIST.INST.ID.CODES parameter to determine which field is reported as the institution identifier code for EDI transactions. Examples of the delivered codes include those listed in this table.

EDI institution identifier codes are defined and delivered by Ellucian and stored in the EDI.INST.IDENTIFIER.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Institution Identifier Types

The institution identifier type codes classify EDI institution identifier codes in the N1 segment of an EDI transaction (N103) for SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI institution identifier type codes are defined and delivered by Ellucian and stored in the EDI.INST.IDENTIFIER.TYPES record of the CORE.VALCODES file. View the codes on VAL.

Table 33: EDI institution identifier validation codes

Code Description

CEEB INST.CEEB

FICE CORP.FICE

OTHER INST.OTHER.ID

LOCAL INST.LOCAL.GOVT.ID

Table 34: EDI institution identifier type codes

Code Description

71 IPEDS

72 College Board ATP

73 FICE

74 American College Testing ACT

75 State/Province Assigned No


GePro

EDI Language Indicator

EDI language indicator codes serve as the language code type qualifier in the LUI segment of an EDI transaction (LUI01) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI language indicator codes are defined and delivered by Ellucian and stored in the EDI.LANG.IND.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Language Skill

EDI language skill codes serve as the valid codes for language proficiency indicator in the LUI segment of an EDI transaction (LUI05) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI language skill codes are defined and delivered by Ellucian and stored in the EDI.LANG.SKILL.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Language Use

EDI language use codes serve as the valid codes for the use of language indicator in the LUI segment of an EDI transaction (LUI04) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

Table 35: EDI language indicator codes

Code Description

L NISO 239.53

LE ISO 639

Table 36: EDI language skill codes

Code Description

5 Status Unknown

A Excellent or Fluent

B Good

C Fair

D Poor

Table 37: EDI language use codes

Code Description

1 Language of Instruction

2 Language of Examination


GePro

EDI language use codes are defined and delivered by Ellucian and stored in the LANGUAGE.USE.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Languages

EDI languages codes serve as the valid codes for the language code in the IND segment of an EDI transaction (IND08) or in the LUI segment (LUI02) when the language qualifier (LUI01) is “LE” in SPEEDE transcript processing. These codes are the ISO 639 set of language codes. Examples of the delivered codes include those listed in this table.

EDI languages codes are defined and delivered by Ellucian and stored in the EDI.LANGUAGES record of the CORE.VALCODES file. View the codes on VAL.

EDI Major IDs

EDI major ID codes serve as the valid codes to determine the Field of Study (in Degree) in the Field of Study segment (FOS02) of the EDI transcript in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI major ID codes are defined and delivered by Ellucian and stored in the EDI.MAJOR.ID.CODES record of the CORE.VALCODES file. View the codes on VAL.

3 Language Exam Written in

4 Language Spoken in Home

5 Language Reading

Table 38: EDI languages codes

Code Description

AA Afar

AB Abkhazian

AF Afrikaans

AM Amharic

AR Arabic

Table 39: EDI major ID codes

Code Description

CIP MAJ.CIP

LOCAL MAJ.LOCAL.GOVT.CODES

Table 37: EDI language use codes

Code Description


GePro

EDI Major ID Types

EDI major ID type codes serve as the valid codes for the field of study ID qualifier in the FOS segment of an EDI transaction (FOS02) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI major ID types codes are defined and delivered by Ellucian and stored in the EDI.MAJOR.ID.TYPES record of the CORE.VALCODES file. View the codes on VAL.

EDI Marital Statuses

EDI marital statuses codes serve as the valid codes for the marital status code in the DMG segment of an EDI transaction (DMG04) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI marital statuses are defined and delivered by Ellucian and stored in the EDI.MARITAL.STATUSES record of the CORE.VALCODES file. View the codes on VAL.

Table 40: EDI major ID types codes

Code Description

81 CIP

82 HEGIS

CA Canadian SIS course codes

CC Canadian curriculum

ZZ Mutually defined

Table 41: EDI marital statuses codes

Code Description

A Common law

B Registered Domestic Partner

D Divorced

I Single

K Unknown


GePro

EDI Name Indicator Code

EDI name indicator codes serve as the valid codes for the name component qualifier in the IN2 segment of an EDI transaction (IN201) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI name indicators are defined and delivered by Ellucian and stored in the EDI.NAME.IND.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Name Type

EDI name type codes serve as the valid codes for the name type code in the IN1 segment of an EDI transaction (IN102) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI name type codes are defined and delivered by Ellucian and stored in the EDI.NAME.TYPES record of the CORE.VALCODES file. View the codes on VAL.

Table 42: EDI name indicator codes

Code Description

01 Prefix

02 First Name

03 First Middle Name

04 Second Middle Name

05 Last Name

Table 43: EDI name type codes

Code Description

01 Given Name (Birth Name)

02 Current Legal

03 Alias

04 Name of Record

05 Previous Name


GePro

EDI Phone Type

EDI phone types codes serve as the valid codes for the communication number qualifier in the PER segment of an EDI transaction (PER03,05,07) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI phone type codes are defined and delivered by Ellucian and stored in the EDI.PHONE.TYPES record of the CORE.VALCODES file. View the codes on VAL.

EDI Reference Type

EDI reference types codes serve as the valid codes for the reference number type qualifier in the REF segment of an EDI transaction (REF01) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI reference type codes are defined and delivered by Ellucian and stored in the EDI.REFERENCE.TYPES record of the CORE.VALCODES file. View the codes on VAL.

Table 44: EDI phone type codes

Code Description

AP Alternate Telephone

AS Answering Service

BN Beeper Number

CP Cellular Phone

ID EDI Access Number

Table 45: EDI reference type codes

Code Description

AS Employer ID Number

30 U.S. Government Visa Number

48 Agency’s Student Number

49 Family Unit Number

4A Personal ID Number (PIN)


GePro

EDI Secondary School Graduation Codes

EDI reference types codes serve as the valid codes for the secondary school graduation type codes in the SST segment of an EDI transaction (SST01) in SPEEDE transcript processing. Examples of the delivered codes include those listed in this table.

EDI secondary school graduation codes are defined and delivered by Ellucian and stored in the EDI.SEC.SCHOOL.GRAD.CODES record of the CORE.VALCODES file. View the codes on VAL.

EDI Transaction Versions

EDI transaction version codes serve as the valid codes for all the Electronic Data Interchange (EDI) transaction versions currently supported by Ellucian. These versions are then attached to transactions so the EDI processes can adjust the actual transaction format to correspond with the version specified. Examples of the delivered codes include those listed in this table.

EDI transaction version codes are defined and delivered by Ellucian and stored in the EDI.TRANSACTION.VERSIONS record of the CORE.VALCODES file. View the codes on VAL.

Table 46: EDI secondary school graduation codes

Code Description

B17 Did not complete secondary school

B18 Standard high school diploma

B19 Advanced/honors diploma

B20 Vocational diploma

B21 Special education diploma

Table 47: EDI transaction version codes

Code Description

004010 Version 4010

003052 Version 3052

003041 Version 3041


GePro

EDI Transactions

EDI transaction codes are the ANSI ASC X12 transactions that are supported by Colleague. Examples of the delivered codes include those listed in this table.

EDI transaction codes are defined and delivered by Ellucian and stored in the EDI.TRANSACTIONS record of the CORE.VALCODES file. View the codes on VAL.

Academic Ranks

Use academic rank codes to group employees by rank. These codes, delivered by Ellucian, are used in Colleague Human Resources and in Colleague Student. Define academic rank codes using VAL. These codes are stored in the EEO.RPT.RANKS record of the CORE.VALCODES file.

In Colleague HR, these codes are used to organize faculty positions for IPEDS reporting. For information about IPEDS reports, see the IPEDS Reporting manual.

Two different fields on the Position Definition (POSD) form in Colleague HR list information on rank. To avoid confusion, the following descriptions outline the purpose of each.

The Academic Rank field is limited normally to faculty ranks. It is used in IPEDS reporting.

The Position Rank field is completely flexible and can be used for any type of additional position classification your institution requires. For more information, see the Using Human Resources manual.

In Colleague Student, you can create different ID cards based on faculty rank using the Faculty ID Cards (FAID) form.

You can change the codes in the EEO.RPT.RANKS code table and add others that your institution might need for other reporting purposes as long as they are associated with the appropriate special processing code, which is used to facilitate IPEDS reporting, as listed below:

• Professor - 1

• Associate Professor - 2

• Assistant Professor - 3

• Instructor - 4

Table 48: EDI transaction codes

Code Description

130 Student Transcript

131 Student Record Acknowledge

146 Request for Student Record

147 Response to Request for Student Record


http://clients.datatel.com/apps/objectViewer.cfm?objectID=F5A4CC53-CC69-6CE4-C80DE68D013727BF

http://clients.datatel.com/apps/objectViewer.cfm?referrerID=647ADE24-5056-9F79-EBEA190443FAAD26&objectID=2B547D61-8FE7-434F-B64FF1D85A5FBB82

http://clients.datatel.com/apps/objectViewer.cfm?referrerID=647ADE24-5056-9F79-EBEA190443FAAD26&objectID=2B547D61-8FE7-434F-B64FF1D85A5FBB82

GePro

• Lecturer - 5

• Other Faculty - 6

For example, if your institution has more than one academic rank code that corresponds to the IPEDS rank of “Professor,” then enter 1 in the first Special Processing field for both of those academic rank codes.

Special processing code 6 corresponds to “No academic rank” for IPEDS reporting and is optional in this code table. Any academic rank codes that do not have a special processing code of 1 through 5 will be considered as having no academic rank and will be assigned a 6 in the IPEDS reporting work file.

ELF File Types

The ELF source to intermediate (STI) process needs to know what type of media the source information is coming from. This table shows a list of the predefined codes and their descriptions.

For more information about how the ELF file type codes are used ELFT, refer to Using ELF.

Use the ELF file types (stored in the ELF.FILE.TYPES validation code table) in the File Type field on the Electronic Transfer File (ELFT) form. The ELF file types codes you specify for a file determines which of the following forms you can access for a file:

• Variable File Fields (ELFV)

• Fixed File Fields (ELFF)

For more information about how these codes are used with these forms, see Using ELF.

ELF Merge Actions

ELF merge actions codes (stored in the ELF.MERGE.ACTIONS validation code table) are used by the ELF import process to determine how a field from a source file is merged with an existing Colleague record. You will use these predefined codes on the ELF Merge Criteria (MRGC) form. This table shows a list of ELF merge action codes and their descriptions.

Table 49: ELF file type codes

Code Description

C Colleague

FD Fixed Disk

FT Fixed Tape

O Other

VD Variable Disk

VT Variable Tape


GePro

For more information about how the ELF merge action codes are used on the MRGC form, see “Duplication checking” on page 163.

ELF Record Type

ELF record type codes are used by the ELectronic File (ELF) processes to determine record characteristics. Examples of the delivered codes include those listed in this table.

ELF record type codes are defined and delivered by Ellucian and stored in the RECORD.TYPE record of the CORE.VALCODES file. View the codes on VAL.

ELF Report Detail Level

These codes let you determine the level of details reported when running the Inter-to-Colleague Import (ITCI) process. Use these codes in the Report Detail field on ITCI. Examples of report detail levels could be:

Table 50: ELF merge action codes

Code Description

P Preserve existing Colleague data

PN Preserve existing data on the Colleague record unless the existing data is null; if null, use the imported record data.

R Replace existing data on the Colleague record with import record data.

RN Replace existing data on the Colleague record with the imported record data unless the data on the import record is null; if null, preserve the Colleague record data

MP Merge the imported record data with data on the Colleague record, preserving the entry on Colleague if the import data has a matching controller (or matching value, in case of a list) and no duplicate controllers are allowed. This code only applies to multi-valued fields; it cannot be specified for a single-valued field.

MR Merge the imported record data with the Colleague record data, replacing the entry on Colleague with the imported data if a match is found on the controller or the list value, and no duplicate controllers are allowed. This code only applies to multi-valued fields; it cannot be specified for a single-valued field.

Table 51: ELF record type codes

Code Description

004010 Version 4010

003052 Version 3052

003041 Version 3041


GePro

• detailed report

• unresolved duplicates only

• all duplicates

Report detail levels are stored in the ITCI.REPORT.DETAIL.LEVEL record of the CORE.VALCODES file.

ELF Run Modes

The ELF process uses ELF run modes codes (stored in the ELF.RUN.MODES validation code table) to determine whether an ELF process is in progress. There are only two predefined ELF run modes codes:

• S – ELF process is Stopped

• R – ELF process is Running

These statuses occur “under the scene” (in a field called ELFBAT.RUN.MODE) during batch processing and are not displayed on any form.

ELF Target Statuses

The ELF target statuses codes (stored in the ELF.TGT.STATUSES validation code table) indicate the results of trying to import an intermediate file record to the Colleague database. These codes are applied during the second phase [the intermediate-to-Colleague (ITC) phase] of an import.

There are two sets of possible statuses. The first set of codes is used when running the second phase of an import in update mode. The second set is used when in non-update mode, or when errors occur during update mode. Table provides a list of predefined target statuses codes.

Table 52: ELF Target Statuses Codes

Code Description

Codes used when running the second phase of an import in update mode:

E Error – an error occurred for this target record

N New – a new record was successfully added

M Merged – an existing record was successfully updated with the data from this import record

A Ambiguity – duplicate checking encountered an ambiguous situation where either

there is more than one possible duplicate, or

there is one possible duplicate, but its not certain

Codes used when in non-update mode:


GePro

The ELF target status codes appear on such forms as the ELF Target Results/Dupl Resolution (TGTR) form and the ELF Transaction Tracking (ETRK) form.

ELF Transaction Statuses

The ELF process uses ELF transaction status codes (stored in the ELF.TRANSACTION.STATUSES validation code table) to indicate the status of an ELF import. Table provides a list of predefined transaction statuses codes and their descriptions.

The ELF transaction statuses codes are used on such forms as the ELF Transaction Tracking (ETRK) form, where you can monitor an ELF transaction.

ELF Translate Actions

The ELF process uses ELF translate action codes (stored in the ELF.TRANSLATE.ACTIONS validation code table) to specify how a translate failure

A Ambiguity (same as update mode)

AN Anticipated New

AM Anticipated Merge

X The target record was not written

Table 53: ELF Transaction Statuses Codes

Code Description

N Not yet processed (ITC process has not yet been run)

NA No ambiguities found. The data in the intermediate file has been checked for duplicates but has not yet been imported into Colleague.

A Ambiguity found. The data in the intermediate files has been checked for duplicates, and duplicate checking found an ambiguity which requires you to manually resolve before the transaction can be processed.

E Errors were detected which prevented the transaction from being imported.

I Imported. The data from the intermediate files has been successfully imported into Colleague

Table 52: ELF Target Statuses Codes

Code Description


GePro

should be treated for the purposes of mapping one field to another. This table lists the predefined ELF translate action codes.

ELF translate action codes are used on the following forms in Colleague Core:

• ELF Field Mapping Detail (ELMD)

• Data Element Edits (RDEE)

ELF Value Error Actions

The ELF process uses the value error action codes (stored in the ELF.VALUE.ERROR.ACTIONS validation code table) to determine the proper action if data intended for a target record fails the target field's validation specs. This table provides a list and description of the ELF value error action codes.

ELF value error action codes are used by the underlying processes of the following Colleague Core forms:

• ELF Field Mapping (ELFM)

• ELF Field Mapping Detail (ELMD)

E-mail Subjects

E-mail subject codes are used in the Subject Line field on the E-Mail Information (EMAL) form. These codes specify the subject type of the e-mail message. For example, you can have a subject code for faculty announcements. When the recipients receive the e-mail, the description of the code appears in the subject line of the e-mail.

Define and maintain e-mail subject codes using VAL. E-mail subject codes are stored in the EMAIL.SUBJECTS record of the CORE.VALCODES file.

Table 54: ELF translate action codes

Code Description

K Keep the original (pretranslation) data

N Null – keep as blank or null for the translated value

E Error – consider this an error

Table 55: ELF value error action codes

Code Description

AN Accept/No value. The invalid value is dropped and a null value used (unless the target field has a default value specified, in which case the default value is used)

R Reject. The record is rejected and will not be written to the file.


GePro

Employable By

Employable by codes specify where a person is eligible to be employed. These codes are used in Wisconsin state reporting but are not used otherwise in Colleague. These codes are used on the Credential Certification (CRCE) form in Colleague Core and on the WI Certification Detail (WID5) form in Colleague Student.

Use VAL to define and maintain certification requirement codes in the EMPLOYABLE.BY.CODES record of the CORE.VALCODES file.

Employment Status

Use employment statuses to identify a status of an employment entry. The special processing field is used to identify employment entries which are either current or former. If Colleague encounters a status code with special processing corresponding to former, then when an employment entry is filed, the effective end date is automatically updated and all return links in the PERSON and CORP records are adjusted.

Define and maintain employment statuses using VAL Employment statuses that are stored in the EMPLOYMT.STATUSES record in the CORE.VALCODES file.

Note: Special Processing: The special processing field is used to identify employment entries which are either current or former. If first special processing code “F” is found in the employment status, then when an entry is filed, the effective end date is automatically updated, and all return links in the PERSON and CORP records are adjusted.

Second special processing code is used by Benefactor. Employment statuses defined for retired should have the second special processing code designated as “1.” Benefactor uses this special processing when determining people eligible for matching money because some programs match retirees as well as current employees.

EPMT Providers

These codes represent supported e-commerce payment verification providers used for payment verification through WebAdvisor.

EPMT provider codes are defined and delivered by Ellucian and stored in the EPMT.PROVIDERS record of the CORE.VALCODES file.

EPMT Transaction Types

These codes represent types of transactions available from supported e-commerce providers based on the VeriSign PayFlow Pro service.

Table 56: EPMT Transaction Codes

Code Description

S Sale – charges the specified amount against the account and marks the transaction for immediate funds transfer during the next settlement period.VeriSign automatically performs settlement for each merchant daily.


GePro

EPMT transaction type codes are defined and delivered by Ellucian and stored in the EPMT.TRANSACTIONS record of the CORE.VALCODES file.

Equipment

Define codes and descriptions for equipment that is used at your institution. Use the Room Equipment (FXEQ) form to associate equipment codes with rooms. Generally, you would create equipment codes for items that do not have a fixed asset ID.

Use the Equipment (EQPM) form to define equipment codes.

Ethnics

These codes, together with the Races codes, determine the person's race/ethnicity category for regulatory reporting, such as the IPEDS survey. Specifically, these codes are used to validate the Ethnics field, which answers the question “Are you Hispanic or Latino?”

Ellucian delivers the following ethnic codes, which can be modified to meet your institution’s needs.

C Credit/Refund – returns/credits the specified amount to the cardholder. If is not necessary to have the credit card number if you have the ORIGID (Payment Network reference ID, PNREF) that was issued with the original transaction. If requesting a credit using the PNREF, and an amount is not specified, the entire amount of the original transaction is credited

A Authorize – authorizes transactions that can be processed for payment later. A delayed capture (D) type transaction must be present is to process the payment for a previously authorized transaction

D Delayed Capture – captures a previously authorized payment transaction and now processes the payment. The transaction is scheduled for settlement during the next settlement period. This used primarily for delayed order fulfillment and is used in conjunction with “A” authorization transaction.

V Void – the reversal of a sale prior to the settlement process. A void prevents a transaction from being settled.

F Voice Authorized – this code is used for transactions that have been authorized manually through the telephone. Transactions sent as type F; submit the transaction for settlement.

Table 57: Ethnic Codes

Code DescriptionSpecial Processing Code

HIS Hispanic/Latino H

Table 56: EPMT Transaction Codes (continued)

Code Description


GePro

These codes can be modified, and additional codes can be added, but each code must have one of these special processing codes.

Use VAL to define and maintain ethnic codes, which are stored in the Core code table PERSON.ETHNICS.

Event Type

The event type codes are used to categorize specific events. When used in Core scheduling, the event type is stored in the CALENDAR.EVENTS record. These codes are also used by Colleague in other modules, for example, for course scheduling, faculty scheduling, and activities and events scheduling. In those cases the code is automatically updated in the schedule records (CALENDAR.SCHEDULES) with a type code which identifies where the scheduling item originated.

This table shows valid special processing codes to enter in the first special processing field on VAL and a description of each code.

The second special processing field on VAL represents the field number for which the return link resides in the file represented by the first special processing field. The only time this is used is when purging or deleting from the calendar schedules point of view. When deleting schedules from the module where these records are used, you are already at the pointed file, therefore this field is not used. Because Colleague Student processes use this then this is the only way to get back to the return pointers.

You should not create more than one event type code with these special processing identifiers, nor should you remove any of the codes which have these identifiers in the special processing field. However, you can change the code and description to suit your needs.

NHS Non-Hispanic/Latino N

Table 58: Event type special processing codes

Special Processing Codes Description

FI Faculty Information

AE Activities and Events

CS Course Section Meetings

HO Holiday

REM Reminders and appointments [information comes from the Appointment Reminders (APPT) form]

BK Blocked out (resources are blocked out and unavailable for other bookings)

Table 57: Ethnic Codes



GePro

Use VAL to define event type codes. They are stored in the EVENT.TYPES record of the CORE.VALCODES file.

Facility Types

Use facility type codes to define the type of resource or facility being scheduled for an activity or event. For example, you may need to schedule a room for a presentation. You can define the resources needed (table, chairs, lecterns) and then apply them to the main facility for a specific event. Other examples of facility types could be:

• head table

• conference room

• hotel

• restaurant

• athletic facilities

• seminar room

Use VAL to define facility type codes. They are stored in the FACILITY.TYPES record of the CORE.VALCODES file.

Formatted Name Types

Formatted name type codes represent your name types when you create name and address hierarchies.

In the first special processing column for each formatted name type code, enter Y if you want to use soundex or indexing for this name type. Enter N or leave this field blank if you do not want to use soundex or indexing for this name type.

In the second special processing column for each formatted name type code, enter a number to indicate the length (in number of characters) to allow for this name type during data entry.

Formatted name type codes are maintained on VAL. These codes are stored in the FORMATTED.NAME.TYPES record of the CORE.VALCODES file.

See also “Name Hierarchy Types” on page 88.

Forms Processing Types

Forms processing types are used in the Workfile Key Type field on the Workfile Definition (WFD) form to identify a person or other file type.

All workfiles must be either person type or other type workfiles. If your workfile is keyed by PERSON IDs, use the code for person (P). Your workfile can then use PERSON keywords and follow PERSON-based mail rules.

Forms processing types are defined and delivered by Ellucian and stored in the FORMS.PROCESSING.TYPES record of the CORE.VALCODES file.


GePro

Gender Identity

Use this to indicate the gender identity preferred by this individual.

Define and maintain gender identity codes on the Validation Codes (VAL) form. Gender identity codes are stored in the GENDER.IDENTITY field of the PERSON file. Indicate preferred gender identity on the Addnl Bio Information (ABIO) form.

Graduation Types

Use graduation types to identify if a person has graduated from the institution attended. You can specify any number of codes to determine how a person graduated be it equivalencies or diplomas. Graduation type codes are used in the Grad Type field on the Short Application Type (SHAP) form.

Note: For Wisconsin state schools: Use graduation type codes to denote the highest grade completed. Because one person might have multiple graduation types on different records, Wisconsin schools should assign numeric values to these codes so that Colleague can determine which is “highest.” The numbers should be zero filled; that is, if the codes will be 2 positions, then 2 should be entered as 02 to keep the sort order correct.

HDR Options

HDR (header) options are used by BIOHDR.NAME and RESHDR.NAME for output editing when defining the header block of a form. Examples of HDR options are:

• ID number

• last name

• first name

• middle name

• middle initial

• full name

HDR options are defined and delivered by Ellucian and stored in the HDR.OPTIONS record of the CORE.VALCODES file.

Health Conditions

Health condition codes are used on the Emergency/Missing-Person Contacts (EMPC) form and the Emergency Information (EMER) form to designate a particular health problem of an individual. Examples of health conditions could be:

• asthma

• diabetes

• epilepsy


GePro

Use health condition codes to list only those conditions that may be pertinent in an emergency situation. Define health condition codes using VAL. Health condition codes are stored in the HEALTH.CONDITIONS record in the CORE.VALCODES file.

Immigration Status

Immigration statuses designate the status of a student or employee’s immigration. Example of immigration statuses could be:

• permanent resident

• temporary resident

• resident alien

• migrant worker

• student - no work

• student visa

Use immigration status codes on the Foreign Person Information (FINF) form. Adding an immigration status code on FINF updates the IMMIGRATION.STATUS field in that individual’s person record.

Immunizations

Track a person’s immunization record by applying immunization codes on the Person Health Information (PHIN) form to that person’s record. Examples of immunizations could be:

• polio

• mumps

• measles

Define immunization codes on VAL. Immunization codes are stored in the IMMUNIZATIONS record in the CORE.VALCODES file.

Employment records are maintained on the Employment Health Information (EHIN) form. For more information, see Using Human Resources.

Industry Classes

Define industry classes to describe the size or type of business associated with an organization or corporation. Some examples of classifications you can define are:

• large corporation

• big business

• small business

• privately owned


GePro

Use industry class codes on the Additional Organization Info (AORG) form.

Institution

Use institution codes to identify to which institution a building belongs or is used by. For example, Workman Center may be used by (or even belong to) the Department of Mineralogy and Metallurgy at the institution. Other examples of institution codes could be:

• Aerospace Institute

• State Agriculture Department

• Institute of Social Research

• Chemical Society

• Mining/Engineering

Define and maintain institution codes on VAL. Institution codes are stored in the INSTITUTION.CODES record of the CORE.VALCODES file.

Institution Funding Sources

You may need to report on the funding sources of some institutions. You can use institution funding source codes to group institutions by funding sources, such as private, public, or independent. Institution funding source codes are using the Institutions (INST) form in both Colleague Core and Colleague Student.

Define and maintain institution funding source codes using VAL. These codes are stored in the INST.FUNDING.SOURCES record of the CORE.VALCODES file.

Institution Types

Specify the type of institution by using institution type codes on the Institutions (INST) form in both Colleague Core and Colleague Student. Examples of institution types could be:

• high school

• college

• university/private

• university/public

• community college


GePro

Apply special processing codes to the codes you define for institution types:

The special processing you apply to an institution type affects which form is accessed when detailing from an institution on the Institutions Attended Summary (IASU) form.

This table shows the relationship between these special processing codes and the forms you can access by detailing from institutions listed on the IASU form.

Interests

Your institution may want to track interests that prospective students have. Such interests could include:

• biking

• skating

• bird watching

• square dancing

• genealogy

Interest codes are used on the Addnl Student Profile Info (ASPR) form and on the Applicant Honors/Activities (HACT) form when defining additional student information.

Use the Interests (INTR) form to define codes for interests. Interest codes are stored in the INTERESTS file.

Table 59: Institution types special processing codes

Special Processing Code Description

H Use this special processing code to designate the associated institution type code as a high school. Enter this code in the first special processing code field. Associated institution type codes with this special processing code will be counted as a high school when Colleague counts institutions attended.

C Use this special processing code to designate the associated institution type code as a college. Enter this code in the first special processing code field. Associated institution type codes with this special processing code will be counted as a college when Colleague counts institutions attended.

If an institution with an institution type code has this special processing applied...

...Then this form is accessed by detailing from that institution from IASU

H High Schools Attended (HSA)

C External Institution Attended (INAT)

C (institution is your institution) Home Institution Attended (HOME)


GePro

Internet Portal Department Member Roles

Internet portal department member roles codes are valid roles for the CampusCruiser interface to the department member data feed.

These codes are used by the Build Misc Members Work File (BMMW) form in the data feed for CampusCruiser to build work files for clubs, departments, and classes. This data feed allows you to add any PERSON in Colleague to be a member of a club, department, or course-section when they are transferred to CampusCruiser. Examples of the delivered codes include those listed in this table.

IP department member role codes are defined and delivered by Ellucian and stored in the IP.DEPT.MEM.ROLES record of the CORE.VALCODES file. View the codes on VAL.

Internet Portal Service Tabs

This validation code table is used for additions and deletions to the menu and menu options within the Internet portal (Campus Cruiser). Example codes include the following:

IP service codes are defined and delivered by Ellucian and stored in the EDI.ACTIVITY.CODES record of the CORE.VALCODES file. View the codes on VAL.

Table 60: IP department member role codes

Code Description

H Host

A Administrator

C Chairman

S Secretary

M Member

Table 61: IP service codes

Code Description

A Applicant Services

S Student Services

F Faculty Services

E Employee Services


GePro

Internet Portal User Types

These codes are used by the Internet portal (Campus Cruiser) interface for defining general access permission rights for the virtual campus.

Define and maintain Internet portal user type codes using VAL. These codes are stored in the IP.USER.TYPES record of the CORE.VALCODES file.

ITCI Report Detail Level

See “ELF Report Detail Level” on page 65.

Item Condition

Item condition codes are used by the Fixed Assets module in Colleague Finance to describe the condition of a fixed asset upon receipt. Enter these codes on the Other Fixed Asset Information (OFXM) form when defining other information for a fixed asset. Example of item conditions could be:

• broken

• crushed

• chipped

• damaged

• warped

• bent

Define and maintain item condition codes using VAL. These codes are stored in the ITEM.CONDITION record in the CORE.VALCODES file.

Justification Types

Justification type codes are used on or by the following forms to specify the default format field:

Table 62: IP user types

Code Description

ADM Campus-wide administrator

FAC Faculty

EMP Employee

STU Student

ALU Alumni

DRP Dropped/Deleted


GePro

• Database Element Presentation (RDEP)

• Virtual Fields (RDVF)

• Virtual Field Test and Debug (RTVF)

• Variable File Fields (ELFV)

• Fixed File Fields (ELFF)

• Data Element Definition (DELD)

This information is written into the dictionary together with the length field entered on the above forms. Data is used in the dictionary together with the length to format output for display purposes.

Justification types are defined and delivered by Ellucian and record JUSTIFICATION.TYPES record of the CORE.VALCODES file. Valid codes are “L” for left and “R” for right.

Label Destinations

Define where you want labels to be printed by using a label destination code. The common destinations are printer, terminal, and hold file for viewing and printing at a later time. This function is similar to the MODE setting in the SETPTR command.

Use label destination codes on the following forms:

• Vendor Labels (VENL)

• HR Labels (HRLB)

• HR Label Format (HRLF)

Label destination codes are defined and delivered by Ellucian and stored in the LABEL.DESTINATIONS record of the CORE.VALCODES file.

Languages

Use language codes to specify the different languages a person speaks. These codes are used to validate the person’s primary and secondary languages on demographics data entry forms in Colleague Core and in Colleague Student:

• Foreign Person Information (FINF)

• Additional Demographics (DADD)

• Addnl Student Profile Info (ASPR)

• Common Application Biographic Data (CBIO)

• Short Application Entry (SHAP)

Define and maintain language codes using VAL. Language codes are stored in the LANGUAGES record of the CORE.VALCODES file.


GePro

Letter Batch Actions

Use letter batch action codes to specify the type of action you want performed during a particular print batch process, such as the Process Corres. Batch (PCB) process. Table shows the codes, descriptions, and action taken for letter batch action codes:

These codes are defined and delivered by Ellucian and stored in the LTR.BACH.ACTIONS record of the CORE.VALCODES file.

Table 63: Letter Batch Action Codes

Code Description Action Taken

C Count Counts the letter request records in the batch and displays the number at the bottom of the form. Use this option to determine if you would like to change the parameters of the batch before selecting or processing.

S Select Selects the letter request records for the batch and reserves them for processing in this batch. When a letter request record has been selected, it cannot be selected in another batch. Use this option to freeze the records until you are ready to process them. The process (P) also selects, so the select option is most useful for reserving the letter request records in the batch.

U Unselect This essentially frees all unprocessed records so they can be processed in another batch. If you did not process any of the records, the entire batch is deleted.

T Test Processes the first 20 records from each document group in the batch. Use this option to test your printer settings, the data fields in your document, and so on.

P Process Selects the letter request records if they have not already been selected and generates the output determined by the document types of the document groups. When you select this option, the Process Correspondence Batch Process Options (PCBP) form is displayed.

H History Creates a record of the correspondence sent in the MAILING file. History can also be updated automatically when the batch is processed.

X Delete Deletes the batch (and all corresponding letter request records and associated records, including saved lists created during batch processing). If you are processing list type documents, you must perform your merge using the saved list before you delete the batch. Records that were not processed or that produced errors will not be deleted. Therefore, the batch will not be deleted if unprocessed letter request records remain.


GePro

Letter Batch Statuses

Letter batch status codes specify the status of a batch print job or to report on batch process. These codes are displayed on the Batch Process LookUp resolution form from the Process Corres Batch (PCB) form and are also displayed on the Correspondence Batch Status (CBS) form. Use these codes on the Correspondence Batch Report (CBR) form to view the status of correspondence batches. Valid status codes are:

• pending

• in progress

• cancelled

• completed

Letter batch status codes are defined and delivered by Ellucian and stored in the LTR.BACH.STATUSES record in the CORE.VALCODES file.

Letter Request Associations

Use letter request associations to specify which fields are generated on the LTREQ record for acknowledgments. Letter request association codes are used on the Specify LTREQ Associations (LTRA) form.

Letter request association codes are defined and delivered by Ellucian and stored in the LTREQ.ASSOCIATIONS record of the CORE.VALCODES file.

Letter Request Statuses

Letter request status codes are used to display the current state of the letter, whether still pending or already printed. These statuses update the LTREQ.STATUS field in the LTREQ file. Valid letter request statuses are:

• currently processing

• error

• selected

• processed

Letter request status codes are defined and delivered by Ellucian and stored in the LTREQ.STATUSES record of the CORE.VALCODES file.

List Algebra Operators

List algebra operator codes are used on the Saved List Algebra (SAAL) form. SAAL lets you perform three functions to saved lists. You can form a union, do the difference, or do an intersection between two saved lists resulting in a new saved list. Table shows the


GePro

actions that are performed on two different saved lists (List A and List B) based on the list algebra operator:

List algebra operators are defined and delivered by Ellucian and stored in the LIST.ALGEB.OPERATORS record of the CORE.VALCODES file.

Locations

Use location codes to define the different locations at your institution. Use the Locations (LOCN) form to define location codes and store them in the LOCATIONS file. Examples of locations could be:

• main campus

• downtown campus

• Fairfax campus

Use location codes throughout Colleague Core, Colleague Finance, Colleague HR, and Colleague Student to note the location of building, personnel, or asset.

Department codes can also used for HR IPEDS reporting. When an institution has both medical and non-medical positions, either the department or the location is used to distinguish medical positions from non-medical positions.

Table 64: List Algebra Operators

Code Description Action

+ union List A + List B produces one list that contains everything in List A and everything in List B.

- List A - List B produces one list that contains only those items in List A that are not in List B. For example, if List A has items a, b, c, d, e, and f, and List B has items a, c, f, g, and h, then the resulting list will have items b, d, and e.

U Union List A U List B produces one list that contains everything in List A and everything in List B.

I Intersection List A I List B produces one list that contains only those items that are both in A and B.For example, if List A has items a, b, c, d, e, and f, and List B has items a, c, f, g, and h, then the resulting list will have items a, c, and f.

D Difference List A - List B produces one list that contains only those items in List A that are not in List B. For example, if List A has items a, b, c, d, e, and f, and List B has items a, c, f, g, and h, then the resulting list will have items b, d, and e.


GePro

Location Regions

Use location region codes to group locations into a specific region. For example, you can have several locations defined by the Locations (LOCN) form in the LOCATIONS file that are located in a particular region (for example, New England).Create a location region code for New England and list the locations within that region.

Use the Location Regions (LCRG) form to create location region codes. These codes are stored in the LOCATION.REGIONS file. Use location region codes on forms that have location fields (group). If you use a location region code in a location field (group), all the locations associated with location region code are entered in the location field (group).

Location Types

Location types are used on the Locations (LOCN) form to describe the type of location defined. Examples of location types could be:

• in-district

• out-of-district

• out-of-state

• foreign country

• correctional institution

Define location types using VAL. Location types are stored in the LOCATION.TYPES record of the CORE.VALCODES file.

Location types are used in Texas State Reporting. The LOCATION.TYPES codes are translated to TXST.LOCATION.TYPES used to determine TXCRS.ZIP on Texas State Reporting.

Login Request Statuses

Login request statuses are codes that identifies which notification should be sent out to the requestor. These codes can then be used to select records from the LOGIN.REQUESTS file. This table shows the special processing codes that can be attributed to login request statuses.

Table 65: Login request status codes


1 An acknowledgement has been sent or is being sent

2 An acceptance notification has been or is being sent which should include the login ID and PIN/password.

3 A rejection notice has been or is being sent and the requestor is denied access.


GePro

Login request statuses are stored in the LOGIN.REQUEST.STATUSES record of the CORE.VALCODES file. Use VAL to define and maintain login request statuses.

Use login request statuses on the Login Request Processing (LGRP) form and the Login Requests Purge (LRPG) form.

Login Request Types

Login request types track login requests. These codes can then be used to select records from the LOGIN.REQUESTS file. This table shows the special processing codes that can be attributed to login request types.

If there is no special processing code, then the status of the request cannot be updated automatically. The status of the request must be reviewed and, once a Colleague ID is assigned, the status of the request must be set manually before an acceptance or rejection e-mail notification is sent.

If special processing exists but the person’s information doesn’t meet the criteria of the special processing code, then the request will be rejected if the person doesn't exist on the appropriate subsystem.

Login request types are stored in the LOGIN.REQUEST.TYPES record of the CORE.VALCODES file. Use VAL to define and maintain login request types.

Use login request types on the Login Request Processing (LGRP) form and the Login Requests Purge (LRPG) form.

LookUp Types

LookUp type codes are used on the ID and LookUp Parameters (PID2) form to set the default name accessing of the indexes to be soundex or partial name.

Table 66: Login request types codes


1 Ensures that a student record exists prior to acceptance of a login request.

2 Ensures that a faculty record exists prior to acceptance of a login request.

3 Ensures that an HRPER record exists before a record is accepted.

Table 67: LookUp type codes

Code Action Taken

P Uses partial-name indexing as your institution’s default. Partial indexing lets you access a person's record by entering parts of the person’s name.


GePro

Temporarily switch from one type of indexing to the other by entering a slash (/) as the first character of a LookUp prompt. For that LookUp entry only, the system uses the nondefault indexing type. For example, if your institution uses Soundex indexing as the default, you can enter a slash (/) and part of a person’s last name to use partial-name indexing for that LookUp.

LookUp types are defined and delivered by Ellucian and stored in the LOOKUP.TYPES record of the CORE.VALCODES file.

Mail Grouping Types

Mail grouping types are used on the Person Save List Creation (SLC) form to eliminate duplicate mailings to persons whose records are specified as being joint for mail purposes. This table shows the valid mail grouping type codes, their descriptions, and the action taken by the SLC process.

Mail grouping type codes are defined and delivered by Ellucian and stored in the MAIL.GROUPING.TYPES record in the CORE.VALCODES file.

Mail Rule

Mail rules identify the mailings that should either be received by or restricted from an individual or an address. Some examples of mail rules could be:

• no mail

• bad address

• no solicitations

S Uses Soundex name indexing as your institution's default. Soundex indexing indexes names based on phonics, or how the name sounds.

Table 68: Mail grouping types codes


M Joint Mail A joint mailing list is created for all selected PERSON records with a “Y” in the Joint Mail field. Any selected person records that do not have a joint mail flag set to “Y” are not affected by this entry.

S Joint Solicit A joint mailing list is created for all selected PERSON records with a “Y” in the Joint Solicit field. Any selected person records that do not have a joint solicit flag set to “Y” are not affected by this entry.

N Neither Individual mailings are sent for each selected donor record.

Table 67: LookUp type codes

Code Action Taken


GePro

• no work calls

Mail rules are maintained on VAL. These codes are stored in the MAIL.RULES record of the CORE.VALCODES file.

Mail Types

Mail types are used on the Name/Address Selection Parms (NASP) form to control how the name portion of a mail label looks. This table shows a list of codes, descriptions, and actions taken:

Table 69: Mail types codes


I Individual mailing Always creates an individual mailing label for each person, even if both if both members of a joint couple are in the workfile.

JME Joint Mail Either If the joint mail option for a couple is set to Y, the system creates one workfile record (keyed by the lower valued ID number) if either member of the joint couple is in the workfile. This one record contains a joint mailing label for this couple. If the joint mail option for a couple is set to N, the system produces individual mailing labels for the couple.

JSE Joint Solicit Either If the joint solicit option for a couple is set to Y, the system creates one workfile record (keyed by the lower valued ID number) if either member of the joint couple is in the workfile. This one record contains a joint mailing label for this couple. If the joint solicit option for a couple is set to N, the system produces individual mailing labels for the couple.

JMB Joint Mail Both If the joint mail option for a couple is set to Y, the system creates one workfile record (keyed by the lower valued ID number) if both members of the joint couple are in the workfile. This one record contains a joint mailing label for this couple. If the joint mail option for a couple is set to N, the system produces individual mailing labels for this couple.

JSB Joint Solicit Both If the joint solicit option for a couple is set to Y, the system creates one workfile record (keyed by the lower valued ID number) if either member of the joint couple is in the workfile. This one record contains a joint mailing label for this couple. If the joint solicit option for a couple is set to N, the system produces individual mailing labels for the couple.


GePro

Mail type codes are defined and delivered by Ellucian and stored in the MAIL.TYPES record of the CORE.VALCODES file.

Maintenance Specifications Process

Maintenance specifications process codes are used on the MSP Specifications Print (MSPS) form specify what part of the form is printed when running the MAINT.SPECS MSP subroutine. Maintenance specs process codes are:

• entire

• window

• page

Maintenance specs process codes are stored in the MAINT.SPEC.PRCS record of the CORE.VALCODES file but cannot be modified.

Marital Status

Marital statuses describe the marital status of an individual, such as married or divorced. These codes are used the Spouse Information (SPO) form. Apply special processing to marital status codes. This table displays a list of special processing codes and their descriptions.

Special processing for marital status codes is designed so that the Spouse Information (SPO) form does not default the incorrect values or force separation when marital status codes are used to represent married individuals other than those defined as married. For example, define a marital status code such as “M” for married, “C” for couple, or “DP” for domestic partner, and then apply special processing code “2” to indicate married.

Marital statuses are maintained on VAL. These codes are stored in the MARITAL.STATUSES record of the CORE.VALCODES file.

Meal Choices

Meal choice codes are used on the Attendee Confirmation (ATCO) and the Attend/Confirm Detail (ACFD) forms to specify the type of meal an activity or event attendee requests.

Table 70: Marital status codes

Code Description

1 Single

2 Married

3 Divorced

4 Widowed

5 Separated

7 Correction


GePro

Some attendees may require special dietary needs or request special type of meal, such as vegetarian or kosher. Use meal choice codes to note these requirements.

Define meal choice codes on VAL. Meal choice codes are stored in the MEAL.CHOICES record of the CORE.VALCODES file.

Miscellaneous Codes

Use miscellaneous codes to validate the MAIL.MISC field in the MAILING record maintained on the Communication Information (COM) form. Use the MAIL.MISC for any selection or sorting purposes on the MAILING file.

Because these are miscellaneous codes, define them according to your institution’s needs. Miscellaneous codes are stored in the MISC.CODES record in the CORE.VALCODES file.

Name Hierarchy Types

Use name hierarchy type codes to specify the name type code you want included when defining name and address hierarchy using the Name and Address Hierarchy (NAHM) form.

Name hierarchy codes are stored in the NAME.HIERARCHY.TYPES record of the CORE.VALCODES file. You cannot modify these codes. They are created “on-the-fly” from the FORMATTED.NAME.TYPES validation code table and some hard coded entries. To modify your institution’s user-defined name type codes for use in name hierarchies, modify the codes in the FORMATTED.NAME.TYPES table. The codes that you modify in FORMATTED.NAME.TYPES are included in the NAME.HIERARCHY.TYPES table. Use VAL to modify validation code tables.

New Key Functions

Use new key function codes to specify whether the key functions are subroutine-based or file-based.

Define a subroutine to return the key value (subroutine-based), or you can specify that the key is based on a value retrieved from a file (file-based).

For subroutine-based key functions, the keys are defined by a call to a previously defined subroutine. Any processing can be defined in the subroutine. For file-based key functions, the keys are derived from a field in a specified record.

These codes are used on the File Key Characteristics (RKEY) form in Colleague Core and in the Key Strategy Wizard in Colleague Studio's file Overview. New key function codes are defined and delivered by Ellucian and stored in the NEW.KEY.FUNCTIONS record of the CORE.VALCODES file.

New Key Parsing Types

See “Parsing Types” on page 93.


GePro

Occupations

Occupation codes identify different occupation types. Use occupation codes in the Occupation fields on the Additional Demographics (DADD) form in Colleague Core. These codes are defined on the Occupations (OCC) form and are stored in the OCCUPATIONS file.

Office Codes and Security

Communications Management codes can be protected so that only users in specific offices can see or use them. For example, if you work in the Admissions office, you can define and use document codes that people in other offices cannot see or use. Likewise, other offices can define and use document codes that Admissions office users cannot see or use.

When creating Communications Management codes – such as document codes, communication codes, tracking codes, and correspondence request codes – you can assign an office to each code. When setting up your account, your system administrator assigns an office (or offices) to your security record. Colleague then compares the office assigned to the code with the office on your security record each time you attempt to use or display a code. If your assigned office does not match the office associated with the code, Colleague denies you access to the code.

An office code is required when defining a document code.

Office codes are stored in the OFFICE.CODES record of the CORE.VALCODES file. Use VAL to define and maintain office codes.

Organization Types

See “Corporation Types” on page 37.

Other Academic Levels

Academic levels, such as undergraduate, graduate, continuing education, and vocational, are used when maintaining the academic credentials for a student before graduation.

Other academic levels are used on the Academic Credentials (AACR) form when maintaining the academic credentials for a student after graduation. You have an academic level defined for both “regular” academic levels (stored in the ACAD.LEVELS file) and “other” academic levels (stored in the OTHER.ACAD.LEVELS file).

Define academic level codes using the Academic Levels (ACLV) form in Colleague Student. The codes are stored in the ACAD.LEVELS file.

Define other academic level codes using the Other Academic Levels (OACD) form. These codes are stored in the OTHER.ACAD.LEVELS file.

Other CCDs

An other CCDs (certificates, credentials, degrees) record is added to the OTHER.CCDS file in Colleague Core when the same record is added to the CCDS file in Colleague Student. When students graduate, their academic program information is moved to the


GePro

ACAD.CREDENTIALS file in Colleague Core and is validated against the OTHER.CCDS file. To avoid double entry, creating CCDS records in Colleague Student automatically creates a record in the OTHER.CCDS file in Colleague Core.

However, records added to the OTHER.CCDS file do not get added to the CCDS file in Colleague Student. This allows the credentials that a person has received at another institution to be validated against CCDs that are not offered by the home institution.

Define and maintain other CCDs using the Other CCDs (OCCD) form.

Other Degrees

When a record is added to the DEGREES file in Colleague Student using the Degree Codes (DEGR) form, the same record is added to the OTHER.DEGREES file in Colleague Core. When students graduate, their academic program information is moved to the ACAD.CREDENTIALS file in Colleague Core, which validates against the OTHER.DEGREES file. To avoid double entry, creating DEGREES in Colleague Student automatically creates a record in OTHER.DEGREES in Colleague Core.

However, records added to the OTHER.DEGREES file do not get added to the DEGREES file of Colleague Student. This allows the credentials that a person has received at another institution to be validated against degrees that are not offered by the home institution.

Define and maintain other degrees using the Other Degrees (ODEG) form.

Other Divisions

When a record is added to the ST.DIVISIONS file, the same record is added to the OTHER.DIVISIONS file in Core. When students graduate, their academic program information is moved to the Core ACAD.CREDENTIALS file, which validates against the OTHER.DIVISIONS file. To avoid double entry, creating DIVISIONS in ST automatically creates a record in OTHER.DIVISIONS.

However, records added to OTHER.DIVISIONS do not get added to the DIVISIONS file of Colleague Student. This allows the credentials that a person has received at another institution to be validated against divisions that are not offered by the home institution.

Define and maintain other divisions using the Other Divisions (ODIV) form.

Other Honors

When a record is added to the ST.HONORS file, the same record is added to the OTHER.HONORS file in Core. When students graduate, their academic program information is moved to the Core ACAD.CREDENTIALS file, which validates against the OTHER.HONORS file. To avoid double entry, creating HONORS in ST automatically creates a record in OTHER.HONORS.

However, records added to OTHER.HONORS do not get added to the HONORS file of Colleague Student. This allows the credentials that a person has received at another institution to be validated against honors that are not offered by the home institution.

Define and maintain other honors using the Other Honors (OHON) form.


GePro

Other Locations

When a record is added to the ST.LOCATIONS file, the same record is added to the OTHER.LOCATIONS file in Core. When students graduate, their academic program information is moved to the Core ACAD.CREDENTIALS file, which validates against the OTHER.LOCATIONS file. To avoid double entry, creating LOCATIONS in ST automatically creates a record in OTHER.LOCATIONS.

However, records added to OTHER.LOCATIONS do not get added to the LOCATIONS file of Colleague Student. This allows the credentials that a person has received at another institution to be validated against locations that are not offered by the home institution.

Define and maintain other locations using the Other Locations (OLOC) form.

Other Majors

When a record is added to the ST.MAJORS file, the same record is added to the OTHER.MAJORS file in Core. When students graduate, their academic program information is moved to the Core ACAD.CREDENTIALS file, which validates against the OTHER.MAJORS file. To avoid double entry, creating MAJORS in ST automatically creates a record in OTHER.MAJORS.

However, records added to OTHER.MAJORS do not get added to the MAJORS file of Colleague Student. This allows the credentials that a person has received at another institution to be validated against majors that are not offered by the home institution.

Define and maintain other majors using the Other Majors (OMAJ) form.

Other Minors

When a record is added to the ST.MINORS file, the same record is added to the OTHER.MINORS file in Core. When students graduate, their academic program information is moved to the Core ACAD.CREDENTIALS file, which validates against the OTHER.MINORS file. To avoid double entry, creating MINORS in ST automatically creates a record in OTHER.MINORS.

However, records added to OTHER.MINORS do not get added to the MINORS file of Colleague Student. This allows the credentials that a person has received at another institution to be validated against minors that are not offered by the home institution.

Define and maintain other minors using the Other Minors (OMIN) form.

Other Specializations

When a record is added to the ST.SPECIALIZATIONS file, the same record is added to the OTHER.SPECIALIZATIONS file in Core. When students graduate, their academic program information is moved to the Core ACAD.CREDENTIALS file, which validates against the OTHER.SPECIALIZATIONS file. To avoid double entry, creating SPECIALIZATIONS in ST automatically creates a record in OTHER.SPECIALIZATIONS.

However, records added to OTHER.SPECIALIZATIONS do not get added to the SPECIALIZATIONS file of Colleague Student. This allows the credentials that a person


GePro

has received at another institution to be validated against specializations that are not offered by the home institution.

Define and maintain other specializations using the Other Specializations (OSPC) form.

Output Error Types

Output error type codes specify actions for processing output errors on the Data Element Output (DOUT) form. Examples of the delivered codes include those listed in this table.

Output error type codes are defined and delivered by Ellucian and stored in the OUTPUT.ERROR.TYPES record of the CORE.VALCODES file. View the codes on VAL.

Output Options

Use output option codes on the Form Production (FPR) form and the Postal Sort on File (PSRT) form to send the Mail Density Analysis Report to a printer or to a hold file. View the mail density analysis reports sent to a hold file using the Postal Sort Reports (BPSR) form.

Output option codes are defined and delivered by Ellucian and stored in the OUTPUT.OPTIONS record in the CORE.VALCODES file.

Overall Employment Status

Use overall employment statuses to define employment statuses as they apply generally to an individual, rather than to his status with a specific organization. Example of overall employment statuses are:

• retired

• full time

• part time

• consultant

Overall employment statuses are used on the Employment Information (EMPL) form. Define and modify overall employment status codes on VAL. These codes are stored in the OVERALL.EMP.STATUS record in the CORE.VALCODES file.

Table 71: Output error type codes

Code Description

R Reject invalid data

N Reject null data

I Ignore errors


GePro

Ownership Status

Ownership status codes indicate how the use of the building has been obtained. Examples of ownership status are:

• purchased

• leased

• rented

• donated

Define and maintain ownership status codes on VAL. Ownership status codes are stores as BLDG.OWNERSHIP.STATUS in the CORE.VALCODES file.

Parsing Types

Use parsing types to determine how additional characters are parsed in the new key for a file. Valid parsing type codes are shown in this table.

These codes are used on the File Key Characteristics (RKEY) form in Colleague Core and in the Key Strategy Wizard in Colleague Studio's file Overview. Parsing type codes are defined and delivered by Ellucian and stored in the NEW.KEY.PARSE.TYPES record of the CORE.VALCODES file.

Payment

Use payment codes to group payments of separate activities or events into one reconcilable payment. For example, you can have 4 or 5 different events in which a person wants to participate. Rather than sending 4 or 5 separate checks for each event, the person will probably send one check for the total amount of the checks.

By using a payment code, you can record payment for each event using the separate amount for each event, record the same check number on each payment record, and be able to associate all the payments.

Table 72: Parsing type codes

Code Description

1 The new key needs no parsing.

2 For field extraction method if the counter part of the new key is a delimited part of the key string.

3 For substring extraction method if the counter part of the new key is a substring of the key string.


GePro

For example, Larry Denger sends check number 2001 for $150. The amount of the check covers the following events:

When you record the payment for each activity, you will use the same payment code to associate each payment.

Payment codes are stored in the PAYMENT.CODES record of the CORE.VALCODES file. Use VAL to define payment codes.

Payment codes are used on the Event Payment (EVPY) form.

Payment Methods

Payment methods define each payment accepted by your institution, and indicate the type and category of tender received. Payment methods can be optionally used to determine the general ledger cash account to which a payment is posted, as well as the bank in which it is deposited.

For each payment method, you must also define whether or not it can be used for payments made through WebAdvisor, and whether or not it will be processed through e-commerce for verification.

Define and maintain payment methods using the Payment Method (PMTH) form. Payment methods are stored in the PAYMENT.METHOD file.

Payment Method Categories

Colleague uses the payment category to determine if any additional information is needed to process a payment. For example, if you define a payment method for a credit card, you would select the “credit card' category. If a credit card payment recorded is processed through e-commerce, Colleague will automatically prompt you for the information required to process the credit card payment.

Payment method categories are defined and delivered by Ellucian and stored in the PMTH.CATEGORY record of the CORE.VALCODES file. You cannot modify these categories.

Person E-mail Types

Person e-mail types define the types of different e-mail addresses used at your institution, such Internet, intranet, or Web. Maintain person e-mail types on VAL. These codes are stored in the PERSON.EMAIL.TYPES record of the CORE.VALCODES file.

Event Fee Payment Code

Registration Fee 75.00 P1

Dinner 25.00 P1

Rafting Trip 25.00 P1

Mine Tour 15.00 P1

TOTAL 140.00 P1


GePro

Person ID Options

Use person ID options to assign person identification (ID) numbers. These codes are used as a parameter setting on the ID and LookUp Parameters (PID2) form. This table shows the valid person ID option codes and their descriptions.

Person ID option codes are defined and delivered by Ellucian and stored in the PERSON.ID.OPTIONS record in the CORE.VALCODES file.

Person Origin

Person origin codes are used on the Individual History (IHS) form to indicate how an individual’s record was first acquired by the institution or how the individual first contacted the institution. Examples of origin codes are alumni, mailing list, and registrars office.

Define and maintain person origin codes on VAL. They are stored in the PERSON.ORIGIN.CODES record on the CORE.VALCODES file.

Person Record Types

Person record types are used on the Person Save List Creation (SLC) form to select records of a particular type when creating a saved list of person records.This table lists the valid person record type codes and their descriptions.

Person record type codes are defined and delivered by Ellucian and stored in the PERSON.RECORD.TYPES record in the CORE.VALCODES file.

Table 73: Person ID option codes

Code Description

A Allows the system to automatically assign sequential person IDs.

M You must manually assign all person IDs. When you choose to use this option to add a PERSON record, you are prompted for an ID number.

AM You can manually assigning Person IDs, as in option “M,” or automatically as in option “A.” When you add a new person record, you are prompted to enter an ID number or to press return to have an ID automatically assigned.

Table 74: Person record type codes

Code Description

I Selects only individuals

C Selects only corporations or organizations

B Selects both types of records


GePro

Person Relation Types

Person relation types are used on the Additional Relation Info (RELE) form to designate the type of relationship between two people. These codes are usually used to indicate a relationship other than spouse and child. Some examples of person relation types are:

• guardian

• ward

• companion

• executor

• step-parent, stepfather, stepmother

• sibling, brother, sister

• stepchild

Person relation types codes are defined and delivered by Ellucian and stored in the PERSONS.REL.TYPES record in the CORE.PARMS file.

Persona

This is the code for the type of persona for which consent to capture and process personal data will be granted or declined.

• A - Alumni

• E - Employee

• F - Faculty

• P - Parent/Guardian

• S - Student

• V - Vendor

If persona is left blank, then consent applies to all personas for this person and source.

These codes are delivered as defaults but you can change them prior to using this functionality. This is the PER.DATA.CONSENT.PERSONA.TYPES validation table and is maintained through the VAL. This field is used with the Consent to Capture and Process Personal Data (CPPD) form.

Personal Pronouns

Use this to indicate the set of personal pronouns preferred by this individual. Ellucian delivers the following codes:

• SHE - she/her/hers

• HE - he/him/his

• ZE - ze/hir/hirs


GePro

• THEY - they/them/their

• NAME - Use my name as pronoun

Define and maintain personal pronoun codes on the Validation Codes (VAL) form. Personal pronouns codes are stored in the PERSONAL.PRONOUNS field of the PERSON file. Indicate preferred personal pronouns on the Addnl Bio Information (ABIO) form.

Personal Statuses

These codes define the status of an individual in your file. Generally blank entries are assumed to be active. This save on data entry when a new person is added. Some examples of personal statuses are:

• merged

• inactive

• deceased

• lost

Define and maintain personal status codes on VAL. These codes are stored in the PERSONAL.STATUSES record of the CORE.VALCODES file.

Phone Type

Phone types define the various types of telephone numbers, such as business, fax, or home. Phone types can be associated either with a place (such as home or business) or with a person (such as a car phone or portable phone). The following types of phone type codes require special processing codes so that the appropriate phone number is displayed in header blocks, on forms, and on reports.

• a person’s or an organization’s primary business phone type code must have a special processing code of “B” (special processing field 2)

• an individual’s primary home phone type code must have a special processing code of “H” (special processing field 2)

• an individual’s primary personal phone type code must have a special processing code of “P” (special processing field 1)

The first special processing field designates the phone type as a personal phone number and therefore the phone number is stored in the PERSON record instead of the ADDRESS record for any individuals given this phone type. The second special processing field is used to extract only the home or business phone numbers on things such as the header block.

Phone types are maintained on VAL. These codes are stored in the PHONE.TYPES record of the CORE.VALCODES file. Do not use these phone type codes on the Address Change (WADR) form. The WADR form is the Web-equivalent of the Name and Address Entry (NAE) form. Use the WEB.PHONE.TYPES validation code table for phone types on WADR.


GePro

PIN Calculation Types

PIN calculation types are used by Colleague to generate personal identification numbers (PINs). PIN calculation types are used on the Assign PINS to Individuals (APIN) form in Colleague Core and on the Assign PINs to Faculty (APFI) form and the Assign PINs to Students (APTS) form in Colleague Student. PIN calculation types are listed in this table.

Positions

Use position codes to define types of positions an individual can hold with an employer or organization. A person’s job title is -form; this position code is used to classify positions for reporting purposes. For example, a person’s title may be “Vice President of Marketing,” but the code for that position may be “VPMK.”

You can also use these codes to target mailings based on an employees position within a company. These codes are used on such forms as the Employee Summary (EMSU) and Employment Detail Information (EMPD) forms in Colleague Core, and are also used on several forms in Colleague HR.

Define and maintain position codes using VAL. Position codes are stored in the POSITIONS record of the CORE.VALCODES file.

Postal Sort Types

Postal sort types are used to define the type of postal mailings such as first class. The codes are used by forms in the Communications Management module such as the Postal Presort Defaults (PPD) form, the Form Production (FPR) form, and the Postal Sort on File (PSRT) forms, and with forms processing workfiles.

Prefixes

Prefixes for individuals’ names, such as Mr. or Mrs., are defined as codes to standardize the way they are stored in the database. If a prefix code is specified to the sex entered on the Name and Address Entry (NAE) form, you can specify the sex as “M” or “F.” With this specification, the system can determine the sex of the individual when you enter a prefix (if the prefix is specific to either the “M” or “F” sex).

Table 75: PIN calculation type codes

PIN Calculation Types Code Description

R Produces a random PIN.

B Produces PINs from birthdates. This code is allowed with 4 or 6 digit PINs only and will take the month and day (in INTL format) for 4 digit PINs and month, day and year (again in INTL format) for 6 digit PINs. Delimiters (such as /, ., and -) are stripped.

S Produces PINs using the last numbers (depending on the defined PIN length) of the social security or social insurance number.


GePro

Prefixes are maintained on the Prefix and Suffix Definition (PPS) form. These codes are stored in the PREFIXES in the CORE.VALCODES record file.

Privacy

Privacy codes identify the various levels of privacy warning messages that your institution uses. These codes are linked to warning messages defined on the Person Privacy Warnings (PID5) form. You may want to define privacy codes related to specific pieces of restricted information, such as grades, addresses, telephone numbers, or inclusion in the campus telephone directory.

Privacy codes are associated to individuals on one of the following forms:

• Biographic Information (BIO)

• Student Profile (SPRO)


• Registration Person Entry (RGPE)

When a user looks up an individual, the system compares the individual’s privacy code to staff members level of privacy access to determine whether the staff member can access the individual’s record or release specific information about the individual. Examples of privacy codes are:

Privacy codes are maintained on VAL. These codes are stored in the PRIVACY.CODES record of the CORE.VALCODES file.

Procede

Procede codes are used on the Process Corres. Batch (PCB) form as part of defining the batch correspondence process. The document codes listed become document groups on PCB. The document groups include letter request records that fall within the select start and select end dates specified above.

Table 76: Privacy codes

Code Description

G Don't release grades

D Don't put in directory

P Don't release phone number

A Don't release address

E Secure everything

X Secure address/phone

Y Secure grades/phone

Z Secure grades/address


GePro

Define and maintain procede codes on the Batch Procedure Definition (BPD) form and are stored in the PROCEDE file.

Program Categories

Program category codes are used on the Program/Break Setup (PBS) form in the Activities and Events module to describe the type of program being defined, such as nature, travel, or children, when establishing a hierarchy of programs and program breaks to be used in the analysis of fund-raising efforts associated with television or radio events.

Define and maintain program category codes on VAL. These codes are stored in the PROGRAM.CATEGORIES record in the CORE.VALCODES file.

Program Sources

Program source codes are used on the Program/Break Setup (PBS) form to identify the supplier of the program, such as “PBS” for a program obtained from the Public Broadcasting System when establishing a hierarchy of programs and program breaks to be used in the analysis of fund-raising efforts associated with television or radio events.

Define and maintain program category codes on VAL. These codes are stored in the PROGRAM.SOURCES record in the CORE.VALCODES file.

Province

See “States (Province)” on page 110.

Races

These codes, together with the Ethnics codes, determine the person's race/ethnicity category for regulatory reporting, such as the IPEDS survey. Specifically, these codes are used to validate the Races field.

Ellucian delivers the following race codes, which can be modified to meet your institution’s needs.

These codes can be modified, and additional codes can be added, but each code must have one of these special processing codes.

Table 77: Race codes delivered by Ellucian


AN American/Alaska Native 1

AS Asian 2

BL Black or African American 3

HP Hawaiian/Pacific Islander 4

WH White 5


GePro

Use VAL to define and maintain race codes, which are stored in the Core code table PERSON.RACES.

Refund Reasons

Use refund reason codes to identify the reason for a refund. Refund reasons are used or displayed on one of the following forms in Colleague Student:

• Refund Voucher Register (RFVR)

• Refund Voucher Creation (RFVC)

• Deposit Refund Register (DRRG)

• Deposit Refund Voucher Create (DRVC)

Use refund reason codes to identify the reason for a cash advance created on the Cash Advance (CADV) form in Colleague Student.

Define and maintain refund reasons using VAL.

Technical Tip: Refund reasons used for cash advances must be defined with a 3 in the first special processing field on VAL. Cash advance refund reasons cannot be used for AR or deposit refunds—only for cash advances. codes are stored in the REFUND.REASONS record of the CORE.VALCODES file.

Registry Level

Registry level codes are used to give special rights to users when setting them up for Web access. Use registry level codes when building registry entries for students to access Colleague's Web-enabled forms through the Web. Registry level codes are used on the following forms:

• System Access Setup (SASU) in Colleague Core

• Build User Registry Entries (BURE) in Colleague Core

• Build Faculty Registry Entry (BFRE) in Colleague Student

• Build Student Registry Entry (BSRE) in Colleague Student

Registry level codes are defined and delivered by Ellucian and stored in the REGISTRY.LEVELS record of the CORE.VALCODES file. You cannot maintain these codes. Registry level codes are:

• 0 – No Access

• 1 – Read Only

• 2 – Read/Write


GePro

Relation Fields

Relation fields codes are used when defining the run time CDD relation files on the Database Element Linkages (RDEL) form. Each relation file pointed to by a CDD element must define which key part the field points to. If the key parts are defined by an algorithm, like the RELATION file for persons, the “L” code defines that the lower key comes first and then the higher key value second. You must have a RELATION file specified before data can be entered on this field. The RELATION file depends on this field.

This field sets up the data elements in Colleague. The data entered here is used to figure out the RELATION file key.

Relation field codes are defined and delivered by Ellucian and are stored in the RELATION.FIELDS record in the CORE.VALCODE file.

Reminder Purposes

Reminder purposes are used by the Staff/Volunteer Information module to distinguish contacts made for cultivation from those of other business contacts. Some examples of reminder purposes are:

• cultivation

• solicitation

• involvement

• personal

• placement

Reminder purposes stored in the REMINDER.PURPOSES record of the CORE.VALCODES file. Define and maintain reminder purposes using VAL.

Reminder Status

Reminder statuses are used on the Appointment Reminders (APPT) form to specify the status of the reminder of the appointment with a contact. Examples of reminder statuses could be:

• open

• closed

• postponed

• rescheduled

Reminder statuses are stored in the REMINDER.STATUS record of the CORE.VALCODES file. Define and maintain reminder statuses using VAL.


GePro

Resources

Resource codes are used in the Activities and Events module when scheduling or planning an event. Use resource codes on forms like the Resource Allocation (REAL) form and the Resource Planning/Assignment (RPAS) form.

Resources are stored in the FACILITY file. Define resources using the Resource Setup (RESU) form.

Reunion Classes

Use reunion classes to indicate the class reunion year of an individual. In most cases, the reunion class year should correspond to the individual’s year of graduation. However, an individual may consider the year when she received her Ph.D. rather than the year she received her bachelor’s degree. Also, some classes are so small that the reunion class may combine two or more years. For example, the classes of 1960, 1961, 1962, and 1963 can be categorized as reunion class 1963.

Reunion class codes are stored in the REUNION.CLASSES file. Define reunion classes using the Reunion Classes (RCLS) form.

Roles

Role codes identify positions members can 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 Access

See “Access Statuses” on page 16.

Room Category

Room category codes describe the use of rooms. Some examples of could be:

• academic instruction

• occupation and vocation instruction

• special session instruction

• institutes and research center

• individual or project research

• community education

• cooperative education

• libraries


GePro

Room category codes are stored in the ROOM.CATEGORIES record of the CORE.VALCODES file.

Room Characteristics

Use room characteristics codes to describe special features of a room. Use these codes for housing assignment based on stated preferences in Residence Life or to aid in room scheduling for events. Examples of room characteristics could be:

• non-smoking

• smoking

• bright; lots of windows

• built-in desks

• east window

Define and maintain room characteristics codes using VAL. Room characteristics codes are stored in the ROOM.CHARACTERISTICS record of the CORE.VALCODES file.

Room Choices

Room choice codes are used to indicate the type of room requested by an event attendee. Some examples of room choices could be:

• smoking room

• non smoking room

• wheel chair access

• first floor

• top floor

Room choices are used on the Attend/Confirm Detail (ACFD) form and the Attendee Confirmation (ATCO) form. Define and maintain room choice codes on the VAL form. These codes are stores in the ROOM.CHOICES record of the CORE.VALCODES file.

Room Rate Class

These are the rate classes that are associated to rooms. These are also associated to buildings so that when rooms are assigned to someone, the list of rates for that class for the building are presented to be selected from based on the assignment. Use these codes to group room rate tables by room rate class by building.

Room Type

Specify the type of room in a building by using room type codes. Some examples of room type codes are:

• classroom


GePro

• auditorium

• double

• laboratory

• lecture hall

• office

Use room type codes in the Room Type field on the Rooms (RMSM) form.

Define and maintain room types codes using the Room Types (RTYP) form.

Room Usage

Use room usage codes to describe the usage of a room. For example, you can specify a room usage code that describes a room as a laboratory (that way someone doesn’t assign the room as a bedroom for an incoming freshman). Some other examples of room usages are:

• spectator seating

• audio/visual, radio, television

• clinic, non-health professions

• demonstration service

• animal quarters

• greenhouse

• assembly

Define and maintain room usage codes on the Room Usages (RMUD) form. These codes are stored in the ROOM.USAGES file.

Room usage codes are used in the Primary Use and Secondary Use fields on the Room Maintenance (RMSM) form.

Room Wings

Use room wing codes when defining rooms to indicate what part or wing of the building the room is located. Some examples of room wings could be:

• north

• east

• lower

• upper

Use room wing codes on the following forms:

• Auto Room Assignment (ARAS)


GePro

• Resident Directory (RESD)

• Room Maintenance (RMSM)

Define and maintain room wing codes using VAL. These codes are stored in the ROOM.WINGS record of the CORE.VALCODES file.

Rooms – Miscellaneous

There are several miscellaneous room codes you can use to validate entries for the CLRM.Mx field in the CLASSROOMS file.

Define and maintain miscellaneous room codes using VAL. Miscellaneous codes are stored in the ROOM.MISCx records of the CORE.VALCODES file, where x is a number from 1 through 8.

Rules Connectives

The rules connectives validation code table stores connectives for use in building rules. Examples of the delivered codes include those listed in this table.

Table 78: Miscellaneous room codes

Code Table Field in CLASSROOMS file

ROOM.MISC1 CLRM.M1

ROOMS.MISC2 CLRM.M2

ROOMS.MISC3 CLRM.M3

ROOMS.MISC4 CLRM.M4

ROOMS.MISC5 CLRM.M5

ROOMS.MISC6 CLRM.M6

ROOMS.MISC7 CLRM.M7

ROOMS.MISC8 CLRM.M8

Table 79: Rule connective codes

Code Description

WITH Works as a parenthetical AND to start a new true/false condition.

AND Works with the previous line to determine true or false.

EVERY Works to evaluate every value within a multi-valued field and each must meet the defined condition for a true result

OR Works with the previous line to determine true or false.

OREVERY Combines the OR and EVERY conditions.


GePro

Rules connectives codes are defined and delivered by Ellucian and stored in the RULES.CONNECTIVES record of the CORE.VALCODES file. View the codes on VAL.

Schedule Repeat

Schedule repeat codes are used to define the frequency which event dates in a range should be scheduled. When you define an event end date different from the event start date, then the repeat code determines how the event is to be scheduled. For example, this code indicates whether the event should be repeated daily, monthly, or bi-weekly.

The first special processing field is the number of times to repeat the event and the second special processing field determines the period, such as daily, weekly, monthly, or yearly. The following table shows some common examples.

You can also specify consecutive bookings by entering a C in the second special processing field. If a schedule repeats code has a C, then all time is booked based on the start and end times identified in the Campus Calendar and holidays will not produce time conflicts. This allows you to specify that you are booking times starting on one day and ending on another consecutively with a start time on the first day and an end time on the last. All days in between will have start and end times derived from the start of day and end of day entries in the campus calendar.

Use VAL to define schedule repeat codes. They are stored in the SCHEDULE.REPEATS record of the CORE.VALCODES file.

ORWITH Works as a parenthetical OR to start a new true/false condition.

OWE Starts a new parenthetical condition using the EVERY function to evaluate all values within a multi-valued field, combining the functionality of both the ORWITH and the EVERY connectives.

WE The WE connector combines the WITH and EVERY conditions.

Table 80: Schedule repeat codes

1st Processing Code

2nd Processing Code Description

1 D every day

1 W every week

2 W every other week

2 Y every other year

52 W same day of the week, but one year later

3 M quarterly

Table 79: Rule connective codes

Code Description


GePro

Schools

Define school codes and descriptions using the Schools (SCHL) form. For example, you can define a code for the law school, medical school, and engineering school associated with your institution. You can also define the dean, locations, divisions, and departments associated with the school. School codes are stored in the SCHOOLS file.

Solicitation Methods

Solicit methods describe the types of methods used to solicit donations to, or participants for, an activity, event, or campaign, such as phonathon, direct mail, or door-to-door. Solicit method code are used on the Financial Planning (EVFP) form to indicate the type of solicitation method.

Define and maintain solicitation method codes using VAL. These codes are stores in the SOLICT.METHODS record of the CORE.VALCODES file.

Sort Types

Sort types are used in list algebra. These codes are used on the Savedlist Algebra (SAAL) form when performing a union, difference, or intersection between two saved lists. Valid sort type codes are:

• AL – ascending left

• AR – ascending right

• DL – descending left

• DR – descending right

Sort type codes are defined and delivered by Ellucian and stored in the SORT.TYPES record of the CORE.VALCODES file.

Source

This is the code for the source of personal data for which consent to capture and process personal data will be granted or declined.

• ADVA - Advance

• ADVI - Advise

• COLL - Colleague

• ELEV - Elevate

• RECR - Recruit

• THIR - Third Party

If source is left blank, then Consent applies to all sources for this person and persona.

These codes are delivered as defaults but you can change them prior to using this functionality. This is the PERSONAL.DATA.SOURCES validation table and is maintained


GePro

through the VAL. This field is used with the Consent to Capture and Process Personal Data (CPPD) form.

Sources

These codes define the individual or the organization’s relationships to your institution. A person or organization can have more than one source. The source in the primary position will be the CAE (VSE) reporting source. Some examples of sources codes are:

• alumni

• friend

• parent

• trustee

• staff

• foundation

Define and maintain source codes on VAL. These codes are stored in the SOURCES record of the CORE.VALCODES file.

Associate special processing for all sources that are for alumni and require appropriate joint credit splits. Enter special processing “A” in the second special processing field when defining an alumni source code on VAL.

Sponsorship Statuses

The status of a sponsorship controls how the sponsorship can be modified and billed. Your institution can have many different sponsorship statuses, however, they must fall in the general categories listed below:

• Open. You can continue to modify the sponsorship, including adding students to the sponsorship and processing charges against the sponsorship.

• Frozen. You cannot modify the sponsorship or add students. You can, however, continue to process charges against a frozen sponsorship.

• Closed. You cannot modify the sponsorship, add students to the sponsorship, or process charges against the sponsorship.

• Archived. The sponsorship’s invoices and payment transactions have been archived using the Archive AR Transactions (ARCV) process.

Sponsorship status codes are stored in the SPONSORSHIP.STATUSES record in the ST.VALCODES file. Use VAL to define and maintain sponsorship status codes.

Staff Reminder Types

Staff reminder types are used by the Staff/Volunteers Information module to alert staff/volunteers of the type of action or contact that was made to the contact. Some example of reminder types could be:


GePro

• reception invitation

• call for appointment

• thank you

• check research

• personal visit

• phone call

Staff reminder types are used in the Type field on the Contact History (CON) form. Define and maintain staff reminder types using VAL. Staff reminder types are stored in the STAFF.REMINDER.TYPES record of the CORE.VALCODES file.

Staff Status

Staff status codes identify the status of staff members and volunteers at your institution. Typical staff statuses include current and former.

Staff status codes are maintained on VAL. These codes are stored in the STAFF.STATUSES record of the CORE.VALCODES file.

Staff Types

Staff type codes identify groups of staff members at your institution. Examples of staff types could include staff members, volunteers, consultants, counselors, and advisors.

Staff type codes are maintained on VAL. These codes are stored in the STAFF.TYPES record of the CORE.VALCODES file.

States (Province)

State and province codes are used in demographic information about an individual or organization, or any other information that pertains to the state or province location of an entity. Define and maintain state and province codes, their descriptions, and their area codes using the State/Province Definition (STPR) form. State and province codes are stored in the STATES file.

Subroutine Types

Each subroutine identified in the special actions file can be used in various places throughout the Communications Management module. This field identifies the arguments required depending on where the subroutine will be called.

For example, an instance subroutine action requires a return argument of a multivalued list of descriptions associated to each instance for that correspondence, and a document action can be called either when the document is sent, or when history is updated.


GePro

Each subroutine type code has a special processing code number (1-5) in the special processing field which is used to define the subroutine argument list. Table 81 shows the codes, descriptions, special processing code, and associated subroutine argument lists.

Use subroutine type codes on the Corres Actions Definition (CRAD) form. Subroutine type codes are defined and delivered by Ellucian and stored in the SUBROUTINE.TYPES record of the CORE.VALCODES file.

Table 81: Subroutine Type Codes

Code DescriptionSpecial Processing Argument List

CR Correspondence Received

1 CRC.ACTIONS.ID MAILING.ID CC.CODE.ID CC.DATE MAT ARGUMENTS ARGUMENT.COUNT

PA Print Action 3 CRC.ACTIONS.ID MAILING.ID LTREQ.ID DOCUMENT.ID DOCUMENT.PRINT.DATEMAT ARGUMENTS ARGUMENT.COUNT

HA History Action 4 CRC.ACTIONS.ID MAILING.ID LTREQ.ID DOCUMENT.ID DOCUMENT.PRINT.DATEMAT ARGUMENTS ARGUMENT.COUNT

IA Instance Action 5 CRC.ACTIONS.IDMAILING.ID CC.CODE CC.DATE DESCRIPTION.LIST MAT ARGUMENTS ARGUMENT.COUNT

RC Requests Completed 2 CRC.ACTIONS.ID MAILING.ID CRC.CODE.ID CRC.DATE MAT ARGUMENTS ARGUMENT.COUNT


GePro

Suffixes

Suffixes for individuals’ names, such as Jr. or III, are defined as codes to standardize the way they are stored in the database.

Suffixes are maintained on the Prefix and Suffix Definition (PPS) form. These codes are stored in the SUFFIXES file.

Summary or Detail

Several forms for reports throughout Colleague have an option in which you can specify to run the reports in summary or detail mode. A summary report gives basic information whereas a detail report offers more detailed information.

Summary or detail codes are defined and delivered by Ellucian and stored in the SUMMARY.OR.DETAIL record of the CORE.VALCODES file.

Target Populations

Use the codes to describe the target population for a particular activity, event, or campaign, for example, area business leaders, alumni, or donors who have made donations of more than $5,000, and so on. Target population codes are used when planning an event using the Event Planning (EVPL) form.

Define and maintain target population codes using VAL. These codes are stored in the TARGET.POPULATIONS record of the CORE.VALCODES file.

Tax Categories

Use tax category codes to group tax codes. Individual tax codes might have several codes for the same category because of different rebate percentages. For example, tax codes A and B might both be sales tax, but one has a rebate and one does not. However, for printing on the purchase order, you may want to see the sum of the tax amounts for tax codes A and B as a single tax entry. If so, assign the same tax category to tax codes A and B.

Any tax codes without a tax category will print as an individual item at the bottom of the purchase order. Tax category codes are used on the Tax Codes Maintenance (TXCM) form in the Colleague Finance and on the AR Tax Codes (ARTX) form in Colleague Student.

Define and maintain tax category codes using VAL. These codes are stored in the TAX.CATEGORIES record of the CORE.VALCODES file.

Special Processing: A value in the special processing column on VAL is not required to process codes. If you do enter a value, use a one-digit number for the sorting to work correctly. If a value is not entered in the special processing column, the category will appear on the purchase order after the sorted categories along with the tax codes that have no category.

The tax category information is stored and passed to the standard purchase order print routine but the routine currently does not use the information. All of the tax codes are printed separately.


GePro

Tax Form Amount Types

Tax form amount type codes control the type of source code--benefit/deduction, tax, or earnings type--that can be assigned to a box code in Colleague HR. Examples of the delivered codes include those listed in this table.

Tax form amount type codes are defined and delivered by Ellucian and stored in the TAX.FORM.AMOUNT.TYPES record of the CORE.VALCODES file. View the codes on VAL.

Tax Form Export Categories

Tax form export category codes specify, in the BOX.CODES file, the nature of the amount in the box to be used for generating totals and formatting data in the electronic file. Allows the formatting of specific data types to be independent from the box code number, which can change. Examples of the delivered codes include those listed in this table.

Tax form export category codes are defined and delivered by Ellucian and stored in the TAX.FORM.EXPORT.CATEGS record of the CORE.VALCODES file. View the codes on VAL.

Tax Form Print Categories

Tax form print category codes specify, in the BOX.CODES file, the nature of the amount in the box to be used for generating totals and formatting data on the W-2 form. Allows the

Table 82: Tax form amount type codes

Code Description

TXBD Taxable Benefits

EETP Employee Tax Paid

ERTP Employer Tax Paid

SRTP Shared Tax Paid

EETA Employee Taxable Amount

Table 83: Tax form export category codes

Code Description

FWT Federal Wages and Tips

FTH Federal Tax Withheld

SSW Social Security Wages

SST Social Security Tips

SSH Social Security Tax Withheld


GePro

formatting of specific data types to be independent from the box code number, which can change. Examples of the delivered codes include those listed in this table.

Tax form print category codes are defined and delivered by Ellucian and stored in the TAX.FORM.PRINT.CATEGS record of the CORE.VALCODES file. View the codes on VAL.

Tax Form Print Method

Tax form print method codes trigger a certain logic to be used for printing data for a box code. This code is designed to allow for different box formats, such a printing a label associated with each amount versus printing a total amount, and printing state amounts with state codes, TIN's and descriptions. Examples of the delivered codes include those listed in this table.

Tax form print method codes are defined and delivered by Ellucian and stored in the TAX.FORM.PRINT.METHODS record of the CORE.VALCODES file. View the codes on VAL.

Tax Form Processing Statuses

Tax form processing statuses identify the status of a particular tax form work record can be in. These statuses are used by 1099 tax form and T4A tax form processes in Colleague Finance, and are also used by 1098 tax form processing in Colleague Student. Table 86

Table 84: Tax form print category codes

Code Description

FWT Federal Wages and Tips

FTH Federal Tax Withheld

SSW Social Security Wages

SST Social Security Tips

SSH Social Security Tax Withheld

Table 85: Tax form print method codes


A Single Amount Accumulates the amounts for all entries and prints as a single amount in the box with no label.

L Labeled Amount Accumulates the amounts with the same label and prints each label total in the designated box.

S State/Local Taxes Lists each amount with the associated State code, Description, and TIN from the TAXCODES file.


GePro

lists the tax form processing status codes and their description.

Tax form processing status codes are defined and delivered by Ellucian as TAX.FORM.PROCESSING.CODES in the CORE.VALCODES file. You cannot modify these codes.

Tax Forms

These are the various tax forms supported by Colleague. The special processing code contains the default value for the Box field in the Form/Box/Loc line on the Voucher Item Maintenance (VOUD) form in Colleague Finance. The special processing value must be a value in the BOX.CODES file which you can maintain using the Tax Form Box Codes (TFBX) form.

Those forms that should not be entered on VOUD (such as 1098T) should not have special processing codes.

Do not change the maximum length of the code (leave the Maximum Code Size alone). Changing the length will have implications in all fields where the tax form is stored; all of whose lengths are six (6).

The code for the W-2 tax form must be defined as “W-2” with the hyphen. If it is defined any other way, such as “W2,” then the W-2 Preprocessor (W2PP) in Colleague HR will not generate W-2 data when it runs.

Terminal Types

Terminal type codes identify the type of terminal defined on the Aux Port Printing (APTR) form so that the appropriate auxiliary port commands is run. Valid terminal types are:

Table 86: Tax Form Processing Status Codes

Code Description

GEN Generated

MOD Modified

VER Verified

CER Certified

UNC Unlocked Certified

UNV Unlocked Verified

PUR Purged

SUB Submitted

FRO Frozen

REO Reopened

UNF Unfrozen


GePro

• video terminal

• WYSE Terminal

Terminal type codes are defined and delivered by Ellucian and stored in the TERMINAL.TYPE record of the CORE.VALCODES file.

Time Zones

Time zone codes identify international time zones for addresses or phone numbers. Time zone codes are maintained on VAL. These codes are stored in the TIME.ZONES record of the CORE.VALCODES file.

Time zone codes use special processing to calculate the relative difference (in hours) between your time zone and the time zone that the code identifies. Use a positive or negative number to indicate the difference between the two time zones.

Track Codes

Tracking codes consist of a list of document codes and the exact or relative date on which each document should be processed. Tracking codes, define on the Tracking Code (TRC) form, are stored in the TK.CODES file.

Assign a tracking code to any individual on your system. When you assign a track, a letter request record is created for each document on the track. The print date for each letter request is calculated from the date information entered on TRC and the Document Codes (DOC) form.

Use track codes on the Individual Tracking (ITR) form.

Transcript Statuses

Use transcript status codes to identify the status of a transcript received from another institution. It is associated to the transcript type on one of the following forms:

• External Institution Attended (INAT) in Colleague Core

• High Schools Attended (HSA) in Colleague Core

• OUAC Application Import (OUAC) in Colleague Student

Transcript status codes are used by the INSTA.TRANSCRIPT.STATUS field in the INSTITUTIONS.ATTEND file.

Define and maintain transcript status codes using VAL. These codes are stored in the TRANSCRIPT.STATUS record of the CORE.VALCODES file.

Transcript Types

Use transcript type codes to identify the type of a transcript received from another institution. It is associated to the transcript status on one of the following forms:

• External Institution Attended (INAT) in Colleague Core


GePro

• High Schools Attended (HSA) in Colleague Core

• OUAC Application Import (OUAC) in Colleague Student

Transcript type codes are used by the INSTA.TRANSCRIPT.TYPE field in the INSTITUTIONS.ATTEND file.

Define and maintain transcript type codes using VAL. These codes are stored in the TRANSCRIPT.TYPE record of the CORE.VALCODES file.

Transfer Methods

Use transfer method codes to indicate how you want PC data files transferred from a server to your PC using the Transfer PC File (TPF) process. Table 87 shows a list of valid transfer methods and how they work:

Transfer method codes are defined and delivered by Ellucian and stored in the TRANSFER.METHODS record of the CORE.VALCODES file.

Trim Types

Trim types codes are used in ELF processing on the Data Elements Edit (RDEE) form and the Data Element Write Edits (RDEW) form to indicate how Colleague should treat spaces in data after the data is read or written. Examples of the delivered codes include those listed in this table.

Table 87: Transfer methods

Method Action

FTP This method uses the standard file transfer protocol (FTP). To use FTP to transfer documents to a PC you must have an IP address and an FTP daemon loaded. FTP must also be loaded on the server and the FTP/KERMIT File Locations (PID4) form must have a parameter pointing to the object file.

KERMIT When a local PC is accessing Colleague through KERMIT, use this option to initiate a KERMIT transfer. You must then initiate a KERMIT receive at the local PC.

Table 88: Trim type codes


A All Remove all spaces, including embedded spaces.

F Front Remove only leading spaces.

B Back Remove only trailing spaces

S Standard Removes both leading and trailing spaces, and reduces embedded strings of spaces to a single space (UniData trim).


GePro

Trim type codes are defined and delivered by Ellucian and stored in the TRIM.TYPES record of the CORE.VALCODES file. View the codes on VAL.

User ID Calculation Type

User ID calculation type fields provide options for creating the prefix (first part) of the login ID field. The Build DMI Registry Users (DMIU) process and the DMI Registry User Setup (DRUS) form use the default calculation type to create user IDs for Web access. These codes are used to construct new user IDs when there is no existing entry in the PERSON.PIN file for the user ID.

All of the calculation types listed will take into account the name preference of using middle name instead of first name if the PERSON record has a code of “IM” in either the mail label name or the preferred name field. In the case of the code “NL”, if no nickname is on file, the first name is used. Examples of the delivered codes include those listed in this table.

User ID calculation type codes are defined and delivered by Ellucian and stored in the USER.ID.CALC.TYPE record of the CORE.VALCODES file. View the codes on VAL.

Valid Columns

Valid columns codes are used on the Aux Port Printing (APTR) form to define the column width of a print out. Valid columns widths are 132 columns and 80 columns. Valid columns are defined and delivered by Ellucian as VALID.COLUMNS in the CORE.VALCODES file.

Veteran Types

Use veteran types to indicate if an applicant, student, or employee is a veteran of the armed forces. Use veteran type codes on the Additional Demographic (DADD) form in Colleague Core and the Short Application Entry (SHAP) form in Colleague Student.

Define and maintain veteran type codes using VAL. These codes are stored in the VETERAN.TYPES record of the CORE.VALCODES form.

Table 89: User ID calculation type codes

Code Description

FL Full first and last names

FIL First, middle initial, last

IL first initial, last name

IIL first & middle initial, last

NL Nickname & last


GePro

Vocations

Vocation codes identify different types of vocations, professions, or jobs. These codes are defined on the Vocations (VOC) form. These codes are stored in the VOCATIONS file. Use vocation codes on demographic and employment forms.

Voucher Statuses

Use voucher statuses to indicate the current status of a voucher in the Accounts Payable module and in the Accounts Receivable module. Valid voucher statuses are as follows:

• not approved

• outstanding

• paid

• reconciled

• voided

• canceled

Voucher statuses are defined and delivered by Ellucian and stored in the VOU.STATUSES record of the CORE.VALCODES file.

Web Phone Types

Web phone types are used on the Address Change (WADR) form to specify the type of phone (home or business) associated with the person’s address information. The WADR form is the “Web equivalent” of the Name and Address Entry (NAE) form.

Web phone types are defined and delivered by Ellucian as WEB.PHONE.TYPES in the CORE.VALCODES file. Use the PHONE.TYPES validation code table when specifying phone types on NAE.

Wing

Specify the wing of a building in which a room exists by using wing codes. Use wing codes in the Wing field on the Rooms (RMSM) form. Some examples of wing codes are:

• north

• south

• northeast

• southwest

Wing codes are stored in the ROOM.WINGS record of the CORE.VALCODES file. Define and maintain wing codes on VAL.


GePro

Word Perfect Character Translate

Word Perfect character translate codes are used in Word Perfect merge process to specify non-English characters in Word Perfect text. Define and maintain Word Perfect character translate codes using VAL. These codes are stored in the WP.CHARACTER.XLAT record in the CORE.VALCODES file.

Word Perfect Document Types

The default document used by the system is specified in the DTYP.DOCUMENT.FILE field. You can still use the Word Perfect Document Types to categorize the document.

These codes are used on the Document Type Setup (DTYS) form. Table 90 shows a list of valid codes and the action that occurs.

Your institution may want to define other document types, with other associated default filing areas. These codes are defined and delivered by Ellucian and stored in WP.DOCUMENT.TYPES record of the CORE.VALCODES file. Contact the Solution Center if you need to modify these codes or add new codes.

Word Processor Printer

Word processor printer codes specify printer definitions for word processing interfaces in the Communications Management (CC) module. These codes are primarily used in document setup, document merge processing, and correspondence batch processing.

Word processor printer codes are stored in the WP.PRINTERS record of the CORE.VALCODES file. Define and maintain word processor printer codes on VAL.

Workfile Key Types

See “Forms Processing Types” on page 72.

Yes, No, Blank

Yes, no, blank codes are used for recording applicants responses to questions on a paper application. Some questions on the form had two boxes: one for Yes and the other for No. If the applicant did not check either box (that is, left the box blank), your institution may not be allowed enter either “Yes” or “No,” but is required to specify how the applicant

Table 90: WP Document Types

Code Action

P The text of the associated document is stored in your default filing area for personal letters, PER.LTRS.

T The text of the associated document is stored in your default filing area for template letters, TMP.LTRS.

C The text of the associated document is stored in the default filing area you have established for your code only letters.


GePro

responded (in this case, blank). Yes, no, blank codes are defined and delivered by Ellucian as YNB in the CORE.VALCODES file. Yes, no, blank codes are used on the Loan Application Defaults (LADF) form in Colleague Student.

ZIP and Postal Codes

Define zip and postal code cross-reference file using the Post Code Translation (PCDX) form. These codes, stored in the ZIP.CODE.XLAT file, are used by all programs that maintain address information. Whenever a postal code is entered in the city field for an address, the city, state, country, county, time zone, route code, and chapters are automatically displayed if the postal code and its associated data already exist in this file. When an unknown postal code is entered in a city field, the information can be added for that transaction. When the address record is filed, the system updates the ZIP.CODE.XLAT file.

ZIP Sort Sequence

Use zip sort sequences on the Mid Term Grade Report (MGRP) and Final Grade Report (FGRP) forms in Colleague Student to specify the how you want the reports sorted. Valid sort sequences are:

Zip sort sequence codes are defined and delivered by Ellucian and stored in the ZIP.SORT.SEQUENCE record in the CORE.VALCODES file.

Table 91: Zip Sort Sequence Codes

Code Sort Sequence

ZIPID By Zip Code By ID

ZIPNAME By Zip Code By Name

STUDENT By Student/Other Fields

NO No Sort


GeCo

Define Colleague Core Validation Codes

Use the Validation Codes (VAL) form to define validation code tables.

Before you begin to define validation codes

Before working directly with Colleague Core validation codes, Ellucian recommends a few preparatory steps.

1. Review basic codes concepts. Refer to “Colleague Core Codes” on page 11.

2. Become familiar, if you are not already, with the methods and codes your institution currently uses to track 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. Make several copies of the “Define Colleague Core Parameters” on page 127, and plan your validation codes on paper before entering any of them into Colleague Core.

Define validation codes

Use VAL to define codes for validation tables. Access VAL from any menu.

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 zeros. 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.”

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

122tting Started with Colleague Core | Define Colleague Core Validation Codes - Ellucian - nfidential and Proprietary

GeCo

properly. 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.

Warning! To define or modify Core validation code tables, you must enter CORE from the DBMS prompt (Core codes are stored in the CORE.VALCODES file). If you enter VAL from the main menu of another application, or any menu from any other application, you will access only those validation codes specific to that application (ST.VALCODES, HR.VALCODES, CF.VALCODES).

1. Complete the steps outlined in “Before you begin to define validation codes” on page 122.

2. Enter VAL at any menu prompt. Colleague displays the Validation Codes form.

3. Enter the ID of the code you want to define.

4. 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.

5. Enter the description of the associated code. The code description is displayed and the cursor moves to the Min element.

6. 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.

7. If 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 9. Space is provided for two special processing codes.

8. If you do not want to define special processing for this code table, move the cursor to the next Code group element and continue with Step 9.

9. If 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 11.

10. If you do not want to change the maximum code size for this code table, continue with Step 11.

11. Repeat Step 4 through Step 10 until all the codes you want are defined for this validation code.

When you are finished completing VAL, save the information. The menu from which you accessed VAL is displayed.


GeCo

Verify validation code tables and code files for the ELF process

In the previous section, you learned about the validation code tables that are defined by Ellucian for the ELF process. In this next section, you will learn some simple ways to check if all the validation code tables and code files that you must define have been created.

You should ensure that your validation code tables and code files are created. If some of your code table or files are not created, you could get error messages during the source-to-intermediate (STI) phase of the ELF process.

Check your mapping spreadsheets

Review your mapping data spreadsheets to determine which code tables and code files you need to define. This is one way to check the existence of required validation code tables and code files. Use VAL to verify that the validation code tables you specified on the spreadsheet do exist in Colleague Core. For information about mapping spreadsheets, see Using ELF.

Use a query sentence to verify validation code tables

Another method of checking is to search the intermediate file for fields validating against code tables. Enter the following query sentence at the colon prompt:

:SORT RT.FIELDS WITH RTFLDS.FILE.NAME EQ intermediate.file.name WITH RTFLDS.VALIDATION.TABLE RTFLDS.VALIDATION.TABLE RTFLDS.VAL.TABLE.APPLICATION

where intermediate.file.name is the name of the intermediate file you want to search.

The results of the query display the fields within the specified intermediate file that require validation against a particular code table. However, you may not have all the fields mapped (depending on your institutional needs). For example, your institution may not require a mapping to the IBIO.EMAIL.TYPES field in the INTER.BIODEMO file. Therefore, you don’t need to populate the PERSON.EMAIL.TYPES validation code table.

The validation code tables displayed as a result of the query were created by Ellucian for the intermediate file. Your institution needs to determine the codes you want to use to populate those validation code tables. This may require a team or group from your institution to determine the codes and how those codes will be used within the system. As a simple example, the codes team can specify which prefixes to define in the phone types validation code table. The codes team would determine if they want to use numeric or alpha codes, what each means, and if any special processing is needed.

Use the “Define Colleague Core Parameters” on page 127 to help you determine the codes you need to define for each validation code table. You can define most validation code tables using VAL. However, some validation code tables use other forms. For example, use the Prefix and Suffix Definition (PPS) form to define the prefixes and suffixes validation code tables.


GeCo

Use a query sentence to verify validation code files

Validation code files differ from validation code tables in that the code files are stored in their own, individual files, whereas all code tables are stored in either the VALCODES or appl.VALCODES files (where appl is the mnemonic of the application, such as CORE, CF, ST, and so on.).

To check if you have defined the validation code tables needed for your import, enter the following query sentence at the colon prompt:

:SORT RT.FIELDS WITH RTFLDS.FILE.NAME EQ intermediate.file.name WITH RTFLDS.VALIDATION.FILE RTFLDS.VALIDATION.FILE

where intermediate.file.name is the name of the intermediate file you want to search.

The results of the query display the fields within the specified intermediate file that require validation against a particular code file. However, you may not have all the fields mapped (depending on your institutional needs). For example, your institution may not require a mapping to the IBIO.DRIVER.LICENSE.STATE field in the INTER.BIODEMO file. Therefore, you do not need to populate the STATES code file for this field. However, by looking at the results, you will need to populate the STATES code file for other fields.

The validation code files displayed as a result of the query were created by Ellucian for the intermediate file. Your institution needs to determine the codes you want to use to populate those validation code tables. Just as with validation code tables, this may require a team or group from your institution to determine the codes and how those codes will be used within the system.

Because the validation code files are stored in their own individual files, each code file has a specific form you can use to define them. Most of these forms are located on the Institution Core Setup (ICS) menu in Colleague Core. Use Table 92 to determine which form you need to use to define a specific code file.

Table 92: Institution Core Setup (ICS) Forms

Mnemonic Form Name Mnemonic Form Name

DEPT Department OACD Other Academic Levels

DIV Divisions CHP Chapters

ODIV Other Divisions RCLS Reunion Classes

SCHL Schools BKCM Bank Codes Maintenance

LOCN Locations DENO Denominations

OLOC Other Locations DISD Disabilities

CNTY Counties INTR Interests

CTRY Countries VOCD Vocations

ODEG Other Degrees OCC Occupations

OMAJ Other Majors ORTY Organization Types


GeCo

OMIN Other Minors ITTL Institution Contact Titles

OCCD Other CDDs SUPL Supplies

OSPC Other Specializations EQPM Equipment

OHON Other Honors

Table 92: Institution Core Setup (ICS) Forms

Mnemonic Form Name Mnemonic Form Name


GePro

Define Colleague Core Parameters

Parameters are rules that determine various processing options and are default values that make data entry quicker. These parameters allow flexibility in our software.

There are two types of parameters: system-wide and module specific. This chapter describes the system-wide parameters used throughout Colleague. Module-specific parameters are described in the particular module part of this manual.

International parameters and defaults

Define how you want dates to display on the system and designate your country code. Use the International Parameter (INTL) form to define default settings for dates and word spellings.

For example, institutions in the U.S. use the spelling “check,” whereas institutions in Canada use the spelling “cheque.” By specifying the country code on INTL, the system will know which spelling to use. Similarly, Canadian institutions use social insurance numbers while U.S. institutions use social security numbers. By specifying the country code, the system will know which format of the numbers to use. However, you need to define the text string for social insurance or security numbers to be used on fields. Use the International Defaults (PID1) form to set the appropriate defaults for field and report labels.

If you are an international client (outside of the United States), you must set up the international parameters and dates. This setup involves completing the following forms:

Note: You need to set up your international parameters only if you are setting up a new account install. Make sure you set up international parameters in your release and main accounts.

1. Log into the account and access the Core System.

2. Access the International Parameters (INTL) form to set your date formats.

3. Complete INTL according to your site’s preferences and save the information.

4. Access the International Defaults (PID1) form to set field and report label defaults for city/state/zip or city/province/postal code, social security number or social insurance number, and so on.

5. Complete PID1 and save the information.

6. Access the Core, ST, CF, and HR systems (in the order specified) and access the Header Block Definition (PHD) form from each application to define the header block for that particular application.

7. Complete PHD in the Core, ST, CF, and HR systems.

127tting Started with Colleague Core | Define Colleague Core Parameters - Ellucian - Confidential and prietary

GePro

Dictionary date conversion (UniData environment only)

Note: Perform this procedure only if this is a UniData environment.

Use the Dictionary Date Convert (DDCV) form to change the data dictionary formats for date fields so that they are consistent with the date formats specified on the International Parameters (INTL) form.

Note: Complete the International Parameters form before you use this form.

1. Access the UT, Tool (if applicable), Core, ST, CF, and HR systems and access the Dictionary Date Convert (DDCV) form for each application to set the correct date format for dates in the dictionaries of the files for each application.

2. Complete DDCV in the UT, Tool (if applicable), Core, ST, CF, and HR applications.

Technical Tip: If you access DDCV and try to cancel, you may need to use the Cancel All icon.

3. Access the UT application.

4. Access the Dictionary Date Convert (DDCV) form to convert the date format in the HIST.LOG files from YMD format to the date format specified on INTL. You must run this process if you have specified your date format as anything other than YMD format.

ID and LookUp parameters

Use the ID and LookUp Parameters (PID2) form to define parameters for record ID assignments and LookUp processor options.

Components of the ID and LookUp parameters

Person identification numbers

One of the parameters you can define is the default for assigning person identification (ID) numbers. You can specify to let the system automatically assign sequential person IDs. For example, when you add a new person record using the Name and Address Entry (NAE) form, the system will assign a sequential person ID based on the last person record created. So, if the last person ID assigned was 100101, then Colleague will assign 100102 to the new record. This method of assigning ID numbers is the most common.


GePro

You can specify to manually assign all person IDs. When you add a new person record, Colleague will prompt you to enter the ID number. If that ID number already exists, Colleague will issue a warning then reprompt you for a new ID number.

However, you can manually assign person IDs or have the system automatically assign the number. When adding a new person record using this option, you are prompted to enter an ID number or press return to have an ID automatically assigned.

Indexing for LookUp

Specify how you want your user’s to locate names of individuals and organizations. By specify the indexing method, you can access a person’s record or organization’s record by entering parts of the name. For example, if you are looking for someone who’s last name is Anderson, you can enter one of the following to locate the record:

a...

an...

and...

ande...

ander...

...derson

...derson...

Specify a Soundex indexing method. The Soundex indexing method indexes names based on phonics, or how the name sounds. For example, using Anderson, you can enter ndrsn to locate the record.

No matter which method you specify, you can use the other method by entering a slash (/) at the LookUp prompt. For example, let’s say you specify the Soundex name indexing method on PID2. If you wanted to use partial name indexing at a LookUp prompt, you would enter the slash followed by part of the person’s name. Conversely, if you specified partial as the default, you could enter a slash and the Soundex or phonetic sound of a name at the LookUp prompt.

Subroutines for person IDs and LookUp

Specify subroutines to perform specific actions regarding person ID numbers and LookUp capabilities. Specify an Ellucian-supplied subroutine or a custom subroutine to calculate the person ID check digit.

If your system has an interface with another system such as Benefactor, or if for some reason you want to calculate ID numbers by an alternate formula, specify a custom subroutine to calculate the next available ID from the PERSON.NEXT.KEY record.

If your system has an interface with another system such as Benefactor, you may need to search dual systems for person records. For example, if a record is not found during a normal Colleague LookUp, you may want to search another database. Specify a subroutine to search the other system. For example, if your Colleague application has an interface with Benefactor, you can specify the S.BEN.PERSON.LKUP subroutine.


GePro

Subroutines for organization IDs and LookUp

Specify subroutines to perform specific actions regarding organization ID numbers and LookUp capabilities. Specify an Ellucian-supplied subroutine or a custom subroutine to calculate the organization ID check digit.

If your system has an interface with another system such as Benefactor, or if for some reason you want to calculate ID numbers by an alternate formula, you can specify a custom subroutine to calculate the next available ID from the CORP.NEXT.KEY record.

If your system has an interface with another system such as Benefactor, you may need to search dual systems for organization records. For example, if a record is not found during a normal Colleague LookUp, you may want to search another database. Specify a subroutine to search the other system. For example, if your Colleague application has an interface with Benefactor, you can specify the S.BEN.CORP.LKUP subroutine.

Specifying your institution’s host ID

Specify your institution’s ID to be used the 1099-MISC processing routines use the Corporation ID to locate your institution's name, address, and Employer ID Number (EIN) when generating 1099-MISC information. However, you must first define your institution’s ID using the Institutions (INST) form. For more information about defining your institution’s ID and INST, see Using Demographics.

Other information you can specify

Specify other default information related to your institution’s administrative offices. For example, you can specify the following information:

• the maximum width for mail labels

• whether you want to index activity list file

• specify the default campus calendar for booking purposes

• the default certificate, credential, or diploma for specifying secondary school academic credentials

• specifying to check e-mail upon entering Colleague

• the fixed length value for Personal ID Numbers

Define ID and LookUp parameters

Perform this procedure only if this is a new application environment (not upgraded from a Release 17.0 account).

From the database management system prompt in the main account that you are updating, follow these steps to set up the appropriate ID and LookUp parameters:


GePro

1. Access the ID and LookUp Parameters (PID2) form.

2. Enter the method to use when assigning new person IDs. The automatic method of assigning ID numbers is the most common.

3. Enter the method you want your users to use to locate names of individuals and organizations. Enter P to use partial-name indexing as your institution's default. Enter S to use Soundex name indexing as your institution's default.

4. Enter the maximum width your institution allows on mail labels. The width should be entered in characters and cannot be longer than 57. If you leave this field blank, the default is 30.

5. Enter Y if you want to rebuilt the index when a person is removed from the database.

6. Enter the ID of the host organization. Colleague uses this ID to locate your institution's name, address, and tax ID number when generating data for year-end tax and regulatory reporting.

7. Complete the remaining fields on the form as necessary.

8. Save the information by finishing from the form.

Define address processing options

Use the Address Processing Options (ADRO) form to specify when the address resolution form is displayed and if address householding is disabled.

1. Review your institution’s existing record address processing options. Most of these parameters were defined when your software was installed. Work with your institution’s implementation team to determine these parameters, if necessary. See the installation procedures for more information about these parameters.

2. Access the Address Processing Options (ADRO) form.

3. Enter Yes to display the address resolution form during address updates. If you enter No to not have the address resolution form displayed if a single address match is found.

4. Enter Yes to disable address householding. If you enter No or leave the field blank address householding is enabled.

5. Enter additional parameters as necessary.

6. Save the record.

Capitalization rules

You can specify certain names and addresses that you want to always appear with a particular capitalization. You can also specify word substitutions, prefixes, and delimiters.


GePro

Use the Capitalization Rules (PID3) form to specify the capitalization defaults and word substitutions.

Components of capitalization rules

About word substitution

You can use the Word Substitution fields to identify abbreviations or whole words that you want substituted for something else. For example, rather than spelling out “Parkway” in addresses, you can specify an abbreviation such as “pkwy,” then have that substituted for “Parkway.” When you enter an address such as 7100 Fairfax County Pkwy, the system displays “7100 Fairfax County Parkway.” Using the same example, you can specify “Co” to be “County.” However, make sure that what you are substituting cannot be used another way. If you specify “Co” to be substituted by “County,” someone may try to use “Co” for “Company.” Rather than displaying “Acme Computer Co.,” the system will display “Acme Computer County.”

Technical Tip: When using any form in your Ellucian application, you can override the defaults by using the equal (=) sign before entering the text. For example, if you want Ellucian to appear as “ElLuCiaN,” you would enter =ElLuCiaN. The equal sign tells the system to preserve entry just as you entered it.

About converting to upper case

There are five sets of fields in the Convert to Upper Case group on PID3.

1. Always. The words or abbreviations you enter in the Always fields will always appear in uppercase letters. Examples are “po” (for “PO” Box), “nw” (for NW), and so on. The entire word or abbreviation will be converted to uppercase.

2. Never. The words or abbreviations you enter in the Never fields will never appear in uppercase. Examples are “and,” “the,” and “by.”

3. Next Word. You may want to uppercase types of words that follow specific words or phrases. For example, you may always want the apartment number and letter (such as 3G) to be uppercase when following “Apt.” By specifying “Apt.” in the Next Word field, the system will change the word that follows “Apt.” to uppercase and preserves how you specify “Apt.” in this field. (If you enter Apt. in the Next Word field, the system displays “Apt.”. Therefore, “apt 3g” is displayed as “Apt. 3G.”

4. Prefixes. Some surnames have prefixes such as “Mc,” “Mac,” or “O’.” You can identify those prefixes so the system will recognize them and capitalize the letter that immediately follows them. For example, by specifying “Mc,” you can enter mcmorris in a name field and the system will display “McMorris.”

5. Delimiters. You can specify any delimiters such as “.” “/” or “-” to convert the letters that follow them to uppercase.


GePro

About not converting to upper case

Not only can you specify words to uppercase, but you can also specify words or phrases to not uppercase. For example, you may not want the suffixes to ordinal numbers (1st, 2nd, 3rd, and so on) to be uppercase. You can specify the letters you do not want to uppercase. When that group of letters (st, nd, and rd) follow a number without a space, they will not be converted to uppercase. For example, if you specify st, nd, and rd on PID3, and then enter 1808 21ST ST., the system will display “1808 21st St.” (the “ST.” designating “street” does not immediately follow a number.)

Earlier we discussed prefixes for names such as “Mac” and “Mc.” But what happens if you enter International Business Machines as the name of a company? The system will display “International Business MacHines.” You can specify words whose letters should not be uppercased and lowercased, thus overriding the prefix settings. You can specify words such as machine, Macon, macaroni, and so on.

Define capitalization rules

Use the Capitalization Rules (PID3) form to define capitalization and word substitution parameters.

Define FTP and Kermit locations

Specify the locations of your file transfer protocol (FTP) and kermit processes. These are the processes that your institution uses to transfer files between it and another site.

Use the FTP/Kermit File Locations (PID4) form to specify the locations to the executable code for your FTP and kermit processes.

Person privacy warnings

Set parameters on your system that will let you mark person records as private or semi-private. For example, you can mark a record so that a warning is displayed when a system user accesses that record, indicating the type of restriction, such as not to release grades or not to release phone numbers. People can request these restrictions as a right according to the Family Education Rights and Privacy Act (FERPA).

Mark a person’s record using privacy codes on one of the following forms:

• Biographic Information (BIO)

• Student Profile (SPRO)



GePro

• Registration Person Entry (RGPE)

Each of the above forms has a Privacy field in which you can enter a privacy code. (For more information about privacy codes, see “Privacy” on page 99.

When a system user accesses a record marked with a privacy code, you can specify a warning message to display when the record is accessed.

Use the Person Privacy Warnings (PID5) form to define the messages that display when a system user accesses a person’s record marked with privacy codes. You can also set a system login message for your users to view when they log into the system.

For example, you may need to send a message to all Colleague users at your institution. Rather than sending e-mail, define the message on PID5. When the system users log in, the message displays.

Components of person privacy warnings

You can define message for three separate situations.

1. User login message. Specify a message to display when users log into the system. All users on the Colleague application will see this message when they log in. You can use this for reminders or warnings.

2. Privacy code message. Specify a message for each of the privacy codes stored in the PRIVACY.CODES validation code table. For example, a person may request that his phone number not be released to anyone. By associating a message with that privacy code, users will receive the message describing the privacy code.

3. Record denial message. Set up system users to have access to records with specific privacy codes. You can also limit access to records with specific privacy codes. Use the Staff and Volunteers (SVM) form to define which privacy codes are accessible by system users. For information about SVM, see “Define staff and volunteers” on page 158 and Using Demographics. If you do not give a system user access to records with specific privacy codes, then a message displays telling the user that she cannot access that record. You can specify a one line, record denial message using PID5.

Define person privacy warnings

Use the Person Privacy Warnings (PID5) form to define person privacy warnings.

1. Access Colleague Core.

2. Access the Person Privacy Warnings (PID5) form.

3. In the System Login Message fields, enter a message you want displayed each time a system user logs into Colleague.

4. In the Privacy Warning Messages group, first enter a valid privacy code (stored in the PRIVACY.CODES validation code table) you want to associate with a message in the Privacy Code field.


GePro

5. In the Message field, enter the message you want to display to users when they access a record marked with the associated privacy code.

6. In the Record Denial Message field, enter a one-line message you want displayed if a user attempts to access a record marked with a privacy code for which the user is not authorized.

7. Save the information.

Reset key counters

You may need to reset your key counters for different files in your system. Use the Reset Key Counters (PID8) to view or set the values of all key counters in Colleague. These records are stored in the appl.PARMS file as @NEXT.KEY.file, where appl is the application (CF, CORE, HR, ST) and file is the name of the data file for which the counter is kept.

Warning! You should not modify the counter values after you start working with your system in live operation. If you feel that you need to modify any of the counter values on this form, please call Ellucian's Technical Support for assistance before changing them.


Ge

The Rules Processor

Before you create and use rules

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 “The Run-Time CDD” on page 139. 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.

Understand rules

The rules processor is a feature of Colleague Core that is used by several modules across all Ellucian products to define processing conditions and to determine whether those conditions are met. Use rules to define a set of unique criteria for selecting records and 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 142.

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 93 provides examples of how some of the modules in Colleague Student use the rules processor. This table does not provide an exhaustive or

136tting Started with Colleague Core | The Rules Processor - Ellucian - Confidential and Proprietary

Ge

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.

Colleague Core’s Communications Management module uses rules on the following forms for the purposes shown in Table 94.

• Corres Request Assignment (CRA)

• Corres Requests Definition (CRRD)

• Document Codes (DOC)

For more information about rules in the Communications Management module, see “Set Communications Management Parameters” on page 151.

Table 93: Sample Uses of the Rules Processor in Colleague Student

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

Table 94: Sample uses of the rules processor in Colleague Core

Where it is Used... How it is Used...

Communications Management • to determine who should receive a specific piece of correspondence

• to determine what correspondence should be sent next


Ge

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. Detail from RLES to the Rules Evaluation Detail (REDT) form to see a detailed list of all rules that failed processing.

Note: You cannot directly access RLES and REDT. 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.

Work with rules

Follow these four basic steps when you are working with rules.

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 RLTD, 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. Use RLDE to:

• view an existing rule to determine if it meets your needs

• create a rule


Ge

The following sections explain the concepts that you should understand before using RLDE to build rules.

The Run-Time CDD

The fields (data elements) from the files 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.

Use these forms 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:

• File Specifications (RFS)

• File Element Inquiry (RFEI)

• Database Element Presentation (RDEP)

• Database Element Linkages (RDEL)

• Virtual Fields (RDVF)

Refer to the online help for detailed information on how to use these forms.

Colleague stores files in a file named RT.FILES and fields (data elements) in the RT.FIELDS file (see Table 95). Any files and fields that you specify on RLDE must already exist in the RT.FILES or RT.FIELDS files, respectively.

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, 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

Table 95: 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

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 RLDE. 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 RLDE. 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 the next section.

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 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.

How to validate rules

The Rules Test and Debug (RLTD) form lets you test a rule against a record in the Colleague database. Through this form, you can turn on the debugger software for S.EVALUATE.RULES and S.GET.DATA and print the results to the 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.


Ge

See the procedural documentation for the appropriate module if you need more information about the specific situations in which rules are assigned and used.

Build rules

1. Read “Understand rules” on page 136.

2. Define your requirements and identify your necessary business rules.

3. Access the Rules Definition (RLDE) form. 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.

4. Add a rule. 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.

5. Complete RLDE.

6. To create a rule for use only by a specific office, enter an office code in the Office Code field.

7. 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 RLDT 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.

8. Save the record.

Validate rules

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 RLTD 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 RLTD. 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.

1. Evaluate the rule test results. If the rule contains errors, return to RLDE to correct them.


Ge

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 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 can be as simple as assigning representatives to applicants based on their state of residence, or it can 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.


Ge

You must rewrite the admissions rule for the rules processor as it appears in Table 96.

In the rule shown in Table 96, 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 96) 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

Table 96: 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”

1.See Using Admissions for complete details on assigning admissions representatives.


Geand

Set Activities and Events Parameters

This chapter explains the parameters you need to set up before using the Activities and Events module and instruct you on setting them up.

Validation code tables and validation code files are some of the parameters you need to set up. Validation code tables are discussed in “Colleague Core Codes” on page 11. Besides validation code tables, you also need other parameters within the Activities and Events module to help you use the module to its fullest.

This chapter will cover the following parameters:

• creating and maintaining a cross-reference general ledger account file

• setting up or maintaining resources for activities and events

• allowing for updating activity/event participant counters in batch

There are other parameters that you must define for activities and events; however, you must define those other parameters for every activity and event you create. Those parameters are:

• specifying the confirmation letters to be sent to guests when they confirm attendance

• setting up response codes associated with the event

• specifying if person records should be updated for participants

Because these parameters must be defined for each activity and event you create, we’ve included them in there own section closer to the chapter for creating activities and events. For information about those parameters, see Using Activities and Events.

Before you set activities and events parameters

Before you set the parameters described in this chapter, you need to coordinate with your budget office to create the budget account records needed by your institution.

Also, make sure your institution has set up facility information that will be used to define the resources for your activities and events. Use the forms in the Facilities Profile (FP) module to define such items as:

• locations

• buildings

• location regions

• room usages

• room types

144tting Started with Colleague Core | Set Activities and Events Parameters - Ellucian - Confidential Proprietary

Geand

For information on setting up facilities, see “Set Up Facilities Profile” on page 174.

Understanding parameter definitions

Define the following parameters on the Parameter Definition (AEPD) form:

• specifying the confirmation letters to be sent to guests when they confirm attendance

• setting up response codes associated with the event

• specifying if person records should be updated for participants

Note: You must define the parameters on the Parameter Definition (AEPD) form for each activity and event you create.

Because you must define these parameters for each activity and event, the procedures for defining these parameters can be found with the procedures for creating an activity or event. For information about setting these parameters, see Using Activities and Events.

Budget accounts

Use the Budget Account Definition (BGAD) form to establish and maintain a cross-reference general ledger account file or budget account file called BDGT.ACT. The budget account number and description can then be displayed on the Campaign/Event Revenue (CMR) and Campaign/Event Expense (CME) forms.

Define budget IDs for expenses and revenue associated with your activities or events. After you set these budget IDs, you can produce reports to view information about those budget IDs. For example, you can define a budget ID for Ticket Sales (revenue). Use this budget ID to identify the amount of money generated by your activities and events based on ticket sales.

Similarly, you can define a budget ID for Paper Supplies (expense). This allows you to report on the projected amount of expense versus the actual amount for a particular activity or event. Use the budget IDs to report on all activities and events to which they were applied.

Note: To get an accurate report of budget IDs, make sure that you use the same budget ID for only those activities you want them associated with. If you want to separate reports by budget IDs, create different budget IDs and apply them to the appropriate activity or event on CME or CMR.

You can also create budget IDs “on-the-fly” from CME or CMR. If you try to enter a budget ID (that has not been defined) at the Budget Account LookUp prompt, you will receive the following prompt:

Record not found -- Enter (A)dd or RETURN to Reenter:


Geand

If you enter “A” to add the new budget ID, BGAD is displayed on which you can define the budget ID. When you complete BGAD, you are returned to the form from which you began.

Define a budget account

Use the Budget Account Definition (BGAD) form to set up budget accounts as needed by institution for reporting purposes.

Resources

Some of the resources you need to set up for an activity and event may depend on whether your institution has thoroughly set up all location, buildings, rooms, and identified all equipment. If you need to set up any of this information, see Using Facilities Profile.

When you create a resource, the resource is stored in the facilities (FACILITY) file. This can get confusing, having both resources and facilities stored in the same file. You may even think that the facilities file has become too large, but after you have learned to define and manage your resources, you will realize that you can use your resources among different activities and events.

Facilities in the Activities and Events module are defined on the Resource Setup (RESU) form and are linked the Facility Profile module information. These facilities work with scheduling when assigned to an event in the Facility field on the Event Planning (EVPL) form. That is, when a facility is booked for an activity, event, or course, the time of that particular event is recorded. If a different event is booked for during that same time, a warning message is issued regarding the time conflict.

Facilities assigned as resources are also defined on RESU. These resources are linked to capacity when assigned to an activity/event in the Resource field on EVPL. As you confirm attendees to the activity/event, the Activities and Events module keeps track of the number of confirmed guests. EVPL will display the capacity of the resource and the available spaces remaining, that way you will not overbook your event. The Attendee Confirmation (ATCO) form also displays capacity as you confirm guests.

There are three categories of resources in the Activities and Events module:

• on-campus resources/facilities

• off-campus resources/facilities

• other capacity-specific resources/facilities

We’ll continue our discussion by explaining the categories of resources.


Geand

On-campus resources

On-campus resources can be a direct one-to-one relationship with a facility defined in the Facilities Profile module, or can be a room in a building or even an area on campus. To understand this definition, let’s look at how the on-campus resource can be defined and used.

For example, let’s say you have a building called Langdon Hall (LANG) defined in the Facilities Profile module. Within Langdon Hall, Cramer Lecture Hall (Room 102) is defined as an auditorium. You can create a resource called CRAMESPCH and define it for speeches in Cramer Lecture. You can create another one called CNCRTCRAME for concerts in Cramer Lecture. Each resource usage can have different characteristics (like capacity, contacts, set up) that you can define for separately for each resource need, although each occur in Cramer Lecture.

You can also define “seated” as a resource and specify how you need the room set up or arranged. Similarly, you can define “reception” as a resource with even different setup and capacity specifications.

Off-campus resources

Off-campus resources are those resources not directly associated with your institution or cannot be defined through the Facilities Profile module. For example, your institution may have arrangements made with a local motel or convention center that provide a place or services to your institution for special functions. Although you will not define these facilities in the Facilities Profile module, you can define them as resources used by your institution for activities and events. Other examples of off-campus resources are:

• municipal golf course

• city swimming pool

• recreational park

• national monument and park

• Welcome Inn conference room

Other capacity-specific resources

Resources can be created for capacity-specific activities and events. Some examples of capacity-specific resources are:

• table for 10

• table for 6

• school buses used for tours

• golf carts

• golf foursome


Geand

Set up resources

Use the Resource Setup (RESU) form to define resources for the Activities and Events module. You can create new resources using this form or maintain existing resources. When you save the information on RESU, a record is created in the FACILITY file.

Resources in this context are items that can be used for an activity or event. Examples of resources are:

• buildings

• a room (in a building)

• a table (in a room in a building)

• a lectern (in a room in a building)

• a type of usage, such a lecture, table, reception

Define your resource on a one-to-one relationship with a facility, or you can create a resource with specific characteristics or setup criteria relative to a facility. Regardless of how you define your resource, give it a unique, understandable name not to exceed ten characters.

When you define a resource and associate it to a facility, you must first make sure that the facility is defined in the Facilities Profile module. When you associate a resource with a facility by entering the building and room information in the Building/Room fields on RESU, then that resource is applied to that building and room. You would not want to enter a building and room for an off-campus resource. However, you can set up an on-campus resource and generic resource with the building and room information. That way, your activity/event can use the capacity information from the resource and the scheduling information linked to the facility. When you use Facility LookUp at any Facility LookUp prompt, the Facility Resolution form shows the building and room information for those resources that are defined with a building and resource.

The Resource Type field on RESU accepts valid codes stored in the facility types (FACILITY.TYPES) validation code table. These codes describe the type of resource you are defining.

Complete the remaining fields on RESU as you need. (None of the fields are required to complete the form, but providing more information about the resource helps you and others in planning an activity or event.)

Note: Although you can associate a building and room to a resource, none of the building or room information defined in the Facilities Profile module is defaulted or brought over to RESU. This give you the flexibility to customize the resources for your particular needs.


Geand

Define resources

Use the Resource Setup (RESU) form to define the resources your institution needs for an activity or event.

Participant counters

There are two files that you can choose to either update automatically or update in batch at different intervals. You can specify that the system update counters for the following in the activity lists (ACTLISTS) file and the activity (ACTIVITY) file automatically every time a change is made:

• invited participants

• confirmed participants

• attended participants

The activity lists (ACTLISTS) file stores the following participant information. The activity lists file’s fields are shown in parentheses:

• list of guests who attended (ACTIVITY.ATTENDED.LIST)

• list of confirmed guests (ACTIVITY.CONFIRMED.LIST)

• list of the activity’s hosts (ACTIVITY.HOST.LIST)

• list of invited guests (ACTIVITY.INVITED.LIST)

• list of all participants (ACTIVITY.PARTICIPANT.LIST)

• list of unidentified guests (ACTIVITY.UNIDENTIFIED.LIST)

Rather than storing the number of attended guests, confirmed guests, and so on, the activity lists file stores the person IDs of the participants.

The activity (ACTIVITY) file stores the number or count of the following participant information. The activity file’s fields are shown in parentheses:

• number of invited guests (ACTIVITY.INVITEE.COUNT)

• number of invited guests overall1 (ACTIVITY.COMPONENT.INVITEES)

• number of confirmed guests (ACTIVITY.CONFIRMEE.COUNT)

• number of confirmed guests overall1 (ACTIVITY.COMP.CONFIRMEES)

• number of guests who attended (ACTIVITY.ATTENDEE.COUNT)

• number of guests who attended overall1 (ACTIVITY.COMPONENT.ATTENDEES)

1.Overall means the total number for all components (sub activities/events) below the upper-level activity/event.


Geand

You can choose whether to have the system update the two files automatically (whenever a change is made to participant information, the files are updated at that time), or you can update the information in manually and in batch by using the Update Participant Counters (UPPC) process. For information about UPPC, see Using Activities and Events.

Use the ID and LookUp Parameters (PID2) form to specify how you want activity/event participant information updated. For more information about PID2, see “ID and LookUp parameters” on page 128.

Update activity counters in batch

If you want to update the activity/events counters for participants manually, enter Yes in the Update Activity Counters in Batch field on PID2. You will then be required to run the UPPC process to update all participant information.

Update activity counters automatically

If you want the system to update the activity/events counters for participants as invited, confirmed, and attended information is recorded, enter No in the Update Activity Counters in Batch field on PID2. Whenever you add or delete a guest, mark the guest as confirmed, or mark the guest’s record as attended, the system will update the ACTLISTS and ACTIVITY files automatically.


GeCo

Set Communications Management Parameters

This chapter provides information about the parameters that your institution must set up before using the Communications Management module.

Descriptions and procedures for defining the Communications Management module’s setup codes are included in the previous chapter.

Communications Management parameters

This section discusses the parameters that you must set up before using the Communications Management module.

Default word processor settings

The Communications Management module interfaces with text editors and word processors to let you compose correspondence, set up merge templates, and compose custom paragraphs. Before you can use your editor or word processor with the Communications Management module, you must define default parameters and settings on the Communications Management (PID7) parameter form.

Mail merge setup using PC-based word processors

Use Microsoft Word as your word processor for mail merge letters if you have the following system configuration:

• PC with Microsoft Word 6.0 or 6.0a connected to your host computer through a network

Correspondence actions

In the Communications Management module, you can use subroutines to create correspondence actions that do the following:

update fields in other modules or databases

produce special reports or documents

send E-mail to another user on the system

151tting Started with Colleague Core | Set Communications Management Parameters - Ellucian - nfidential and Proprietary

GeCo

Use these actions during various processes in the Communications Management module, including the following situations:

• when updating history or printing documents through the Process Corres. Batch (PCB) process.

• when recording correspondence as received through the Communication Code Entry (CRI) form, the Group Communication Entry (CRG) form, or the Individual Requests (IRQ) form.

• when a correspondence request is completed through the Communication Code Entry (CRI) form, the Selected Group Entry (CRG) form, or the Individual Requests (IRQ) form.

Correspondence actions include the following types:

• CR – Corres Received

• PA – Print Action

• HA – History Action

• IA – Instance Action

• RC – Requests Completed

The correspondence action types specify the subroutine arguments to use. Use the Corres Actions Definition (CRAD) form to create and maintain actions associated with a correspondence.

Some standard correspondence actions are supplied with your software. These standard action codes include the following:

Table 97: Standard Action Codes

Action Description Type Subroutine

COLTRANS This action code looks at an individual’s institutions attended entries. When assigned a correspondence request, it produces a requirement for communications codes of the same type for all colleges and institutions attended.

IA S.COUNT.COLTRANS

FILECMPT This action code can be used to update financial aid files with the File Complete Flag when all required or waived communication codes are entered.

CR S.UPDT.FILE.CMPT


GeCo

Staff setup

To take advantage of many of the privacy and security features available within the system, all staff members using the software must be defined within the system both with PERSON records and with STAFF records. STAFF records associate your staff members with particular offices, privacy levels, correspondence, and address security.

Staff records are created for existing PERSON records on the Staff and Volunteers (SVM) form. See Using Demographics for procedures on adding staff records.

FORMSIN This action code is used to update the Forms In field in Financial Aid with the same code as the document ID.

PA S.UPDT.FORMS.IN

FORMSOUT This action code is used to update the Forms Out field in Financial Aid with the same code as the document ID.

HA S.UPDT.FORMS.OUT

HSTRANS This action code looks at an individual’s institutions attended entries. When assigned a correspondence request, it produces a requirement for communications codes of the same type for all high schools attended.

IA S.COUNT.HSTRANS

LPTR This action code is used to print custom text fields when processing correspondence.

PA S.PRINT.LTREQ.CUSTOM

PCSMAILD This action code is used to update the DOC.PIECES.MAILED field when history is updated.

HA S.UPDT.PCSMAILD

UPDTAPPL This action code is used to update an admissions application LTREQ record with the list of applications, locations, programs, and academic levels.

CR S.UPDT.LTREQ.APPL

Table 97: Standard Action Codes (continued)

Action Description Type Subroutine


GeCo

Define correspondence actions

Use the Corres Actions Definition (CRAD) form to create correspondence actions. Use the Ellucian-provided correspondence actions as starting points to create customized actions if needed. See the online help for more information about CRAD.

Rules in the Communications Management module

This section describes how rules are used by forms and processes in the Communications Management module. For information about rules in general, see “The Rules Processor” on page 136.

Define specific rules to use on the following forms in the Communications Management module:

• Corres Request Assignment (CRA)

• Corres Requests Definition (CRRD)

• Document Codes (DOC)

Assign rules for the Corres Request Assignment (CRA)

Use rules to set conditions that each individual in your search list must meet. For example, you can have a rules ID set up so that individuals assigned with this ID must have completed an application.

CRA lets you assign to an individual a group of required documents which must be received from that individual before specific actions or events are activated. Once all documents defined on the Corres Requests Definition (CRRD) form are received or waived, then Colleague activates any action or event associated to the code.

However, before assigning the correspondence request, Colleague verifies that all individuals have satisfied the specifications of the assigned rules. Remember when defining a rules operator, using the “AND” operand requires an individual satisfies all rules before the correspondence is assigned. Using the “OR” operand requires that only one of the rules must be satisfied.

For example, let’s say you want to request specific correspondence from a group of applicants with the following criteria:

• residents of Michigan

• GPA of 3.0 or higher

• academic program of History


GeCo

Use the Rules Definition (RLDE) form to define the rules you want to list on CRA. See “The Rules Processor” on page 136 for more information on defining rules.

You can define a rule called MIAPP that selects applicants from Michigan.

Note that we used the data element “STATE” although it is not a data element in the Applicants file. However, there can be a pointer to the STATE data element in the Person file. Define the pointer using RLDT.

After you have define your rules, you can list them on CRA using a saved list of applicants that you want to select from.

Assign rules for the Corres Requests Definition (CRRD)

A correspondence request is a list of communication codes that are associated with each other as a single unit. A list of correspondence is grouped together to easily track which correspondence is required from an individual. These codes are grouped together into a single request so you can signal events based on the completion of the request.

Use the Corres Requests Definition (CRRD) form to create and maintain correspondence request codes associated to a request. You can assign limitations or rules to each correspondence received code listed for this correspondence request. Colleague will evaluate each rule and assign the code to the individual only if the individual meets the rule.

You need to define your own rules to fit the correspondence requests you want to define. You may have to define these rules on a “need to” basis, that is, you may have to define the rules you want to associate to a correspondence request at the time you create the correspondence request.

Assign rules to paragraphs

When you assign a rule to a paragraph, the individual (to whom the document with this paragraph is assigned) is evaluated using the criteria specified in the rules record. If the individual meets the criteria and satisfies the rule, Colleague inserts the paragraph into one of the custom paragraph positions within the letter request record. If the individual does not satisfy the rule, Colleague does not assign the paragraph in the document. The rules dictate which paragraph will be used. Colleague compiles the document using the appropriate paragraphs.

Again, you may have to define these rules on a “need to” basis, that is, you may have to define the rules you want to associate to a correspondence request at the time you create the correspondence request.

Use the Document Paragraphs (DOCP) form to assign the rules to paragraphs in a document.


GePro

Set Demographics Parameters

Before you set demographic parameters

The procedures in this chapter assume that you have the appropriate security access to the forms used to define demographics-related parameters. If you do not have the appropriate level of security to access the forms discussed in this chapter, see your supervisor or your system administrator.

Demographics parameters

Some of the parameters defined in Colleague Core affect the way that demographics-related data is stored, accessed, and maintained. The parameters that affect demographics include privacy warning messages for demographic information, record ID and LookUp parameters, and codes used for vocations, offices, occupations, and ethnic and race origins.

Each of the parameters is maintained on a separate form. Step-by-step procedures for maintaining these parameters are included later in this chapter. You should set up these parameters before using Colleague.

Staff setup

To take advantage of many of the privacy and security features available within the system, all staff members using the software must be defined within the system both with PERSON records and with STAFF records. STAFF records associate your staff members with particular offices, privacy levels, correspondence, and address security.

Staff records are created for existing PERSON records on the Staff and Volunteers (SVM) form.

Address security

You can elect to secure addresses from unauthorized updates based on the address type. You can set up address security for individual staff members or by office codes. For address security for individual staff members, you can list the address types that the staff member can update. For address security based on office codes, you can link address types to office codes.

156tting Started with Colleague Core | Set Demographics Parameters - Ellucian - Confidential and prietary

GePro

Address security prevents unauthorized changes to addresses, but all users can see any address type if it is used in an address hierarchy, displayed on the Address Summary (ADSU) form, appears in the header block, or is the preferred address.

Use the Address Record Security (ADRS) form to secure addresses by office codes. Use the Staff and Volunteers (SVM) form to secure addresses on an individual basis.

Privacy warning messages

Privacy warning messages work with your existing privacy settings, which use record-level security to restrict access to some or all information about individuals in your database for unauthorized users. You can define privacy messages that appear during login, reminder messages to appear when authorized users access restricted information, or a generic error message that is displayed when an unauthorized user attempts to access restricted information. Reminder messages are linked to the privacy codes defined in the PRIVACY.CODES validation code table.

Privacy warning messages are defined on the Person Privacy Warnings (PID5) form. For more information about person privacy warnings and PID5, see “Person privacy warnings” on page 133.

ID and LookUp parameters

Most of the record ID and LookUp parameters used in your system are defined during system installation and setup. Some of the most common ID and LookUp parameters include defining how IDs are assigned, defining how records are indexed, and defining length limits for individual and organization record IDs.

These parameters should be finalized before using Colleague for live processing. Record ID and LookUp parameters are defined on the ID and LookUp Parameters (PID2) form. For more information about ID and LookUp parameters and PID2, see “ID and LookUp parameters” on page 128.

Address processing options

The address processing options used in your system can be defined during system installation and setup. The parameters include when the address resolution form is displayed and if address householding is disabled.

These parameters should be finalized before using Colleague for live processing. Address processing options are defined on the Address Processing Options (ADRO) form. For more information about address processing options and ADRO, see “Define address processing options” on page 131.


GePro

Demographics-related codes

Several codes should be defined for use in the Demographics module. Before you add individual- and employment-related information, be sure to define the following codes in Colleague Core:

• vocations

• occupations

• offices

• ethnicities

• races

• privacy codes

• staff statuses

• staff types

See “Colleague Core Codes” on page 11 for step-by-step procedures for defining codes.

Define staff and volunteers

Complete the following steps to define staff members and volunteers in your system.

Note: This procedure assumes that PERSON records already exist for your staff members and volunteers. If you need to add PERSON records, see Using Demographics.

If you want to define address security for individuals and have already defined address types and decided which address types each person can update, you can enter that information when you create the staff records. See “Define address security: individual mode” on page 159 for more information.

1. Determine the following information for each staff member or volunteer that you want to define:

• Staff Code (usually initials)

• Operator ID for this person, if you defined one on the Operator Definition (SOD) form

• office(s) in which this person works

• privacy level of access for this person

Work with all of your institution’s implementation representatives to compile this information.

2. Define the following codes:


GePro

• office codes

• privacy codes

• staff type codes

• staff status codes

See “Colleague Core Codes” on page 11 for more information about defining codes.

3. Access and complete the Staff and Volunteers (SVM) form to create STAFF records for each staff member and volunteer.

• To link this person to one or more offices and take advantage of office level security, list the offices in which this staff member works in the Office Codes field.

• To restrict the information that a person can access about a student or other individual based on privacy settings, enter the privacy codes corresponding to the level of privacy that this user can access in the Privacy Access field.

If you want to define address security for individuals, you can enter that information when creating the staff record. See “Define address security: individual mode” on page 159 for more information.

4. Save the record.

Define address security: individual mode

Complete the following steps to define address security for your institution for individual staff members. You can define address security for individual staff members when you create the staff records or at a later date.

To define address security based on office codes, see “Define address security: by office code” on page 159.

1. Define the address types that you want to use at your institution. See “Colleague Core Codes” on page 11 for more information about defining codes.

2. Determine the address types that each staff member can update. Work with all of your institution’s implementation representatives to compile this information.

3. Access a staff record for which you want to define address security on the Staff and Volunteers (SVM) form. See the online help for information on a specific field.

4. List the address types that this staff member can update in the Address Security Overrides field.

5. Save the record.

Define address security: by office code

Complete the following steps to define address security based on office codes.


GePro

To define address security for individual staff members, see “Define address security: individual mode” on page 159.

1. Define the address types that you want to use at your institution. See “Colleague Core Codes” on page 11 for more information about defining codes.

2. Determine the address types that each office can update. Work with all of your institution’s implementation representatives to compile this information. All staff members associated to an office can update the address types defined for that office.

3. Access and complete the Address Record Security (ADRS) form.

• For each office code, list the address types that members of this office can update.

• If an office can update more than one address type, list the office code again and associate it with an additional address type.

4. Save the record.

Maintain consent to capture personal data

Use the Consent to Capture and Process Personal Data (CPPD) form to maintain whether a person has consented to the capture and processing of personal data by this institution for a specified persona and data source.

CPPD can be used by your institution to ensure compliance with regulations such as the European Union's General Data Protection Regulation (GDPR).

1. Access the Consent to Capture and Process Personal Data (CPPD) form and enter or look up the individual's ID number, name, or other identifying data.

2. Look up the record of a person's consent to capture and process personal data or add a new one. A person can grant or decline consent differently for each combination of persona and source, but there can be only one personal data consent record that covers any given person and persona and source combination.

3. Select the code for the type of Persona for which consent to capture and process personal data will be granted or declined. For example, a person who is both an employee and a student might grant consent for data related to the employee persona but decline for data related to the student persona. If persona is left blank, then Consent applies to all personas for this person and source.

4. Select the code for the Source of personal data for which consent to capture and process personal data will be granted or declined. For example, a person might consent to the capture and processing of personal data from Colleague but decline it for Advance. If source is left blank, then Consent applies to all sources for this person and persona.

5. Use the Consent field to select the code to indicate whether this person (or parent or guardian) has consented to the capture and processing of personal data by this institution for the specified persona and data source.

6. Enter the date when consent was granted or declined for this person, persona, and source.

7. Save your work on CPPD.


GePro

Control access to UI forms that have a Person LookUp with sensitive or personal information

Use the Demographics Access Control (DMAC) form to control access to UI forms that have a Person LookUp (such as NAE and BIO) that may contain sensitive or personal information. This functionality is disabled by default. Your institution can choose whether to enable it. If you enter the ID of a process that is not a UI form with a Person LookUp, DMAC does not restrict access to that process.

Warning! The Colleague UI person context card and the person lookup search results can often show demographic information about the person. The information shown is based on the setup for the person context on the Define User Interface Context (UICD) form and will be the same for all users. The person context card and search results can be accessed through the Person Search feature of Colleague UI apart from a UI form. Be sure to limit the information you show on the context card search results to that which is suitable for all Colleague UI users.

Colleague displays error message DM374 when a user is denied access to one of the specified forms. You can customize the message through the Custom Error Maintenance (UTER) form by entering CORE and message DM374.

1. Access the Demographics Access Control (DMAC) form.

2. Enter Yes in the Enabled field if you want to control access to certain demographic forms. If this field is set to Yes, Colleague restricts access to the controlled processes based on the security classes of the user running the process and whether the person whose data is being viewed is an employee or is a student.

3. Enter the mnemonic or process ID of the demographic forms for which you want to control access in the Controlled Process IDs fields. Any process in this list will have restricted access based on the security class of the user running the process and whether the person whose data is being viewed is an employee or is a student.

Warning! Although most do, some UI forms with a person lookup may not enforce the DMAC restriction when the form is called as a detail from another form. Because of this, you should test the forms you add to DMAC in a scenario in which they are called as a detail form.

4. Save your work on DMAC.

Note: The security classes are:

– EMP_DM_ACCESS – if the person in Colleague is an employee

– STU_DM_ACCESS – if the person in Colleague is a student

– EMP_STU_DM_ACCESS – if the person in Colleague is a student and employee

If a person in Colleague is an employee (WHERE.USED contains HRPER or FACULTY or EMPLOYES) and not a student (WHERE.USED contains STUDENTS), the user must


GePro

have the EMP_DM_ACCESS security class to use the controlled UI forms to view or maintain employee records.

If a person in Colleague is a student (WHERE.USED contains STUDENTS) and not an employee (WHERE.USED contains HRPER or FACULTY or EMPLOYES), the user must have the STU_DM_ACCESS security class to use the controlled UI forms to view or maintain student records.

If a person in Colleague is both a student and an employee, the user must have the EMP_STU_DM_ACCESS security class to use the controlled UI forms to view or maintain the person's records. Note that the EMP_STU_DM_ACCESS security class does not give the user access to people who are only students and not employees, or only employees and not students. For example a user would require both the STU_DM_ACCESS security class and the EMP_STU_DM_ACCESS security class to access all students, both those who are employees and those who are not.


GePro

Define Duplication Criteria

Duplication checking

During the “intermediate-to-Colleague” (ITCI) procedure, ELF compares the intermediate records to records in your Colleague database. Using defined duplication criteria, ELF identifies new records that are duplicates of existing ones. These duplicate records are merged into the existing Colleague file. ELF also identifies intermediate records that are possible duplicates. There are records which are similar to existing Colleague records, but with enough differences that verification is required before merging the records.

Note: Ellucian supplies standard duplication checking criteria that you can copy and modify as needed.

For example, you might use last name, first name, and SSN to determine if a record is for a person who already exists on your database. Colleague compares the first and last name and SSN of the new record against names and SSNs that already exist in your database when checking for duplicates.

Each criterion can contribute a different amount in determining whether a record is a duplicate.You can give each of these criterion a different weight or penalty.

• If the values in the fields of the two records are the same, the rating is increased by the weight.

• If the values in the two records are different, the rating is decreased by the penalty.

• If either value is null, the rating is neither increased nor decreased.

The rating is then compared to the Duplicate and Possible Duplicate Rating numbers you define. The records are then marked “duplicate” or “possible duplicate” and are listed on Duplication Report after the ITCI process is run.

Table 98 illustrates how the criteria is used to determine the duplication rating of a particular record in the intermediate file with a similar record in the Colleague database.

Table 98: Example of Duplication Rating Determination

Field Weight PenaltyIntermediateValue

ColleagueValue Rating

SSN 10 10 123-45-6789 123-45-6789 +10

Last Name 10 10 Jones Jones +10

First Name 8 8 Ann Susan -8

Total Rating 12

163tting Started with Colleague Core | Define Duplication Criteria - Ellucian - Confidential and prietary

GePro

In this example, notice that the SSN numbers and the last names are the same for both records, but that the first names are different. For the values that are the same, the rating uses the “weight” number, but for values that are different, the rating uses the “penalty” number. The sum of these ratings is 12 (10 for SSN, plus 10 for the last name, and minus 8 for the first name discrepancy.) If the Duplicate Rating for this file was 15, the record would not be considered a duplicate.

Table 99 provides another example in which the SSN is not found in Colleague.

In this example, notice that again the last names are the same for both records, but that the first names are different. For the values that are the same, the rating uses the “weight” number, but for values that are different, the rating uses the “penalty” number. Because a value for the SSN was not found, the rating uses the penalty. The sum of these ratings is -8 (minus 10 for SSN, plus 10 for the last name, and minus 8 for the first name discrepancy.) If the Duplicate Rating for this file was 15, the record would not be considered a duplicate.

Custom duplication criteria

You can customize your own duplication criteria if the standard duplication checking criteria supplied by Ellucian does not meet your needs. Use the Duplicate Match Criteria (DUPC) form to define custom duplication criteria you want ELF to use when evaluating the intermediate file for duplicate records.

Duplicate detection/resolution for the Person file

The following limitations are made during the duplicate detection process on the PERSON file information:

• Uses social security/insurance number if available on record being imported.

• If no social security/insurance number or no social security/insurance number match is found, then the process uses Name LookUp and alternate ID.

Table 99: Second Example of Duplication Rating Determination

Field Weight PenaltyIntermediateValue

ColleagueValue Rating

SSN 10 10 123-45-6789 --- -10

Last Name 10 10 Jones Jones +10

First Name 8 8 Ann Susan -8

Total Rating -8


GePro

For more information, see Colleague Technical Reference for S.LIMIT.PERSON.DUPLICATES in the For Our Clients section of Ellucian’s web site (http://clients.datatel.com/index.cfm).

After a list of PERSON records is pre-selected using the limitations above, the following comparisons are made during the duplicate detection process on the PERSON file information:

• Social security/insurance number scores are really high and if matched, the person must differ by gender, birthdate or name (combination of two) to fail duplicate detection.

• Name, gender, birthdate, social security/insurance number, and address information (preferred address) are compared.

• If no social security/insurance number exists, then a person must match more of the other criteria to find a duplicate.

For more information, use the Duplicate Match Criteria (DUPC) form to view the IBIO.PERSON record.

Note that are three subroutine fields on DUPC:

• Field/Subroutine

• Limiting Field/Subroutine

• Dupl Subroutine

If you enter a subroutine in the Field/Subroutine field or the Limiting Subroutine field, then the subroutine governs how the duplicate detection will determine the values of the fields. For example, a subroutine (S.COMPARE.SSN) exists in the subroutine field of the Field/Subroutine field for IBIO.SSN. Although the weight and penalty are defined, the subroutine (depending on its coding) may not necessarily use the weight and penalty to determine the duplicate criteria.

The Dupl Subroutine field works differently in that you can enter a subroutine that will “override” any of the settings on this form. For example, if you have a subroutine written with specific duplication criteria, you can enter that subroutine in the Dupl Subroutine field to supersede the settings on DUPC. Refer to online help for more information about these subroutine fields.

Define duplication criteria

Complete the following steps to define your duplication criteria:

1. Familiarize yourself with the process of defining duplication criteria. See “Duplication checking” on page 163.

2. Use the Duplicate Match Criteria (DUPC) form to modify or create a new duplication criteria record.

3. Make the appropriate modifications on DUPC. See “Custom duplication criteria” on page 164 and DUPC online help.


GePro

4. Save from DUPC.


Ge

Define Merge Criteria

Merge criteria

After ELF has checked the importing records and if it has found a duplication, the information in the intermediate file record is merged with your existing record in Colleague. ELF uses the defined merge criteria to determine how to handle the information in the two records and merge them into one record.

Note: Ellucian supplies standard merge criteria for each file that you can copy and modify as needed.

Possible merge actions

When ELF finds two records that are duplicates, it attempts to merge the two records into one. You must select either P, PN, or RN to be the default for each field in the file. You can define separate merge actions for each field, if appropriate.

Select from P, PN, or RN as the default merge action that you do not overwrite valid Colleague record information with incorrect or null record information. For example, you can import immunization information from the INTER.PERSON.HEALTH file. This information may only contain the immunization information for a person, with the remaining fields (last name, first name, address, and so on) left blank. Using a merge action of R could possibly overwrite a valid name field in the person’s record with a null (or blank) value. Using P (preserve), PN (preserve unless null), or RN (replace unless null) will prevent overwriting valid information.

Table 100 shows the various types of merge actions you can specify for a single-valued field. These merge actions are stored in the ELF.MERGE.ACTION validation code table. Use these codes on the ELF Merge Criteria (MRGC) form.

Table 100: Merge Actions for Single-Valued Fields

Code Merge Action Description

P Preserve Preserve the existing data on the Colleague record.

PN Preserve unless null

Preserve the existing data on the Colleague record, unless the existing data is null. In that case, use the data on the new record.

R Replace Replace the existing data on the Colleague record with the data on the new record.

167tting Started with Colleague Core | Define Merge Criteria - Ellucian - Confidential and Proprietary

Ge

Table 101 shows the merge actions you can specify for a multi-valued field or an association.

Note that both Merge/Preserve and Merge/Replace add entries if the controller is new (that is, it did not previously exist in the Colleague set of values).

If you have a field that contains a multi-valued list but is not an association, there is no difference between Merge/Preserve and Merge/Replace. Both add a new value and leave an existing value unchanged.

RN Replace unless null

Replace the existing data on the Colleague record with the data on the new record, unless the data on the new record is null. In that case, preserve the existing data.

Table 101: Merge Actions for an Association

Code

Association Merge Actions

Are Duplicate Controllers Allowed? Description

MP Merge/Preserve

No Merge the data on the new record with the data on the Colleague record. If a controller on the new record already exists on the Colleague record, preserve that instance of the association on the Colleague record.

Yes Add the new data as a new entry in the list, because there is no way to know which value is to be preserved.

MR Merge/Replace

No Merge the data on the new record with the data on the Colleague record. If a controller on the new record already exists on the Colleague record, replace that instance of the association with the data on the new record.

Yes Add the new data as a new entry in the list, because there is no way to know which value is to be replaced.

Table 100: Merge Actions for Single-Valued Fields

Code Merge Action Description


Ge

Table 102 shows some additional information about merge actions on the PERSON and ADDRESS files. You must decide how appropriate the information is for your particular needs.

Custom merge criteria

You can customize your own merge criteria if the standard merge criteria supplied by Ellucian does not meet your needs. Use the ELF Merge Criteria (MRGC) form to define custom merge criteria you want ELF to use when merging the intermediate files with your Colleague files.

Define your merge criteria

Complete the following steps to define your merge criteria.

1. Familiarize yourself with the file merge process. See “Duplication checking” on page 163.

2. Use the ELF Merge Criteria (MRGC) form to define your merge criteria.

3. Determine the merge action you want to default if no specific merge action is defined for a field. Enter the corresponding code for that merge action into the Default Action field. See “Possible merge actions” on page 167.

4. Make the appropriate modifications on MRGC. See “Custom merge criteria” on page 169 and the online help for MRGC.

5. Save the record.

Merge duplicate institution records

Use the Institutions Merge (INMG) process to remove duplicate Institution records from the database. The information for the Merge From Institution is moved to the Merge To Institution by changing the Institution ID wherever it is found in the system.

Table 102: Merge Actions on the PERSON and ADDRESS Files

PERSON ADDRESS

Most fields are of action PN All fields are of action PN

Associations are of action MP Associations are of action MP

For more details, see the IBIO.PERSON file using MRGC.

For more details, see the IBIO.ADDRESS file using MRGC.


Ge

The following files are merged:

• INSTITUTIONS.ATTEND

• PERSON (pointer to INSTITUTIONS.ATTEND)

• ACAD.CREDENTIALS

• APPLICATIONS

• COURSE.EQUIVS

• STUDENT.NON.COURSES

• STUDENT.EQUIV.EVALS

• STUDENT.HIATUS

• STUDENT

• EXTERNAL.TRANSCRIPTS

• SECSCH.TRANSCRIPTS

If there are no errors when you run this process, Colleague deletes the INSTITUTIONS record for the Merge From Institution after merging the records.

Use the following steps to merge Institution Duplicates.

1. Access the institutions Merge (INMG) form.

2. Use the Institution to merge from field to enter the ID of the institution that you want to merge into another institution.

3. Use the Institution to Merge to field to enter the ID of the Institution into which another institution is being merged.

4. Enter Yes in the Merge Institution Attend... field if you want to merge the information for an institution when a conflict is found.

5. Enter Yes in the Update field if you want the Merge From Institution ID merged into the Merge To Institution ID.

6. Save and update from INMG to create a report of the records that were merged (if you chose No on the Update field, the report shows the records that would have been merged, but the records will not actually be merged).

0


GePro

Define Translate Tables

The source data you are importing does not necessarily contain the codes used by your institution. You can define how you want ELF to translate each code in the source data. ELF uses the translate tables you define for each code and converts the original source code into a “new” code recognizable by your institution.

You must define a translate table for each code used by the source data. For delivered imports, refer to the online help for the particular source-to-intermediate import you will use for a list of translate tables you need to define. Refer to the documentation that you received with the source data to determine a list of values used by the source for each code.

Use the File Translation Table (FLTT) form to define a translation for every code referenced in the source data. List the values used by the source on FLTT in the Original Code column. In the New Code column list the appropriate Colleague code used by your institution.

Note: If you do not define a new code for a particular original code, ELF puts nothing (null) into the corresponding intermediate file.

To define the translate table for the ethnic codes in the example above, Ellucian University used a worksheet like Table 103. The list of the original code values and their descriptions came from the source data documentation. The new code value list is the appropriate translation of each original value into EU’s ethnic code values. Note that the last three code values do not have corresponding new values. Therefore, if a source file contains one of those code values, the corresponding intermediate file will not have a value for that code.

Table 103: Example of a Translate Table Worksheet

Original Code Values (from Source) Description

New Code Values(Colleague)

1. African-American/Black 02

2. American Indian/Alaskan Native 05

3. Caucasian-American/White 01

4. Mexican-American/Chicano 08

5. Asian-American/Pacific Islander 04

6. Puerto Rican/Cuban/other Hispanic origin 03

7. Other --

8. Multiracial --

9. Not Specified --

171tting Started with Colleague Core | Define Translate Tables - Ellucian - Confidential and prietary

GePro

The ELF translate tables are only maintained through FLTT. You could build your own utility to populate the table, especially if you have hundreds of entries and would rather not enter each entry by hand. A translate table is one record in the ELF.TRANSLATE.TABLES file and the values in the table are stored in a multi-valued association. Check the dictionary of the file for the appropriate positions.

If you have a source code that needs to be defined into two or more different codes, Ellucian recommends that you build separate tables for each new code using the source code, rather than trying to use the special processing fields on FLTT. For example, if you have source codes A1, B2, C3, D4, and so on, and you want to separate each into two codes, you can build the following:

Special processing fields

The specific delivered source to intermediate import (STI) procedure you use may have optional special processing that further defines how the source data is translated. In these cases, the translate table must also include information in the Special Processing Fields. See the Comments field for a particular translate table for more information.

Define file translate tables

Complete the following steps to define your file translate tables.

1. Familiarize yourself with the procedure for defining file translate tables.

2. Determine which “source-to-intermediate” (STI) procedure you need to use for this import. See Using ELF for a partial list of available STI procedures.

3. Determine which translate tables you must define. Refer to the online process help for the STI procedure to identify the necessary translate tables.

4. Refer to the documentation that came with your source data to determine what values the source uses for each code.

5. Prepare each file translate table you must define. See “Set Up Facilities Profile” on page 174.

6. Access the File Translation Table (FLTT) form.

Table 104: Example of “Splitting” a Source Code

Source New Source New

A1 A A1 1

B2 B B2 2

C3 C C3 3

D4 D D4 4


GePro

7. Complete FLTT for one of your translate tables.

8. Save the record.

9. Repeat the procedure for each file translate table you identified in Step 4.

Determine whether translate tables are completed

Ellucian strongly recommends that you use your mapping spreadsheet to determine if you have specified all the translate tables needed for your ELF process. However, you can use the following query sentence to determine the translate tables required for your ELF process. Enter the following query sentence at the colon prompt:

:LIST ELF.MAPS WITH @ID EQ import.name WITH ELFMAP.TRANSLATE.TABLE ELFMAP.SRC.FIELD ELFMAP.TGT.FIELD ELFMAP.TRANSLATE.TABLE

where import.name is the name of your ELF import

:LIST RT.FIELDS WITH RTFLDS.FILE.NAME EQ ELF_import_file_name WITH RTFLDS.READ.TRANSLATE.TABLE RTFLDS.READ.TRANSLATE.TABLE

where ELF_import_file_name is the name of the import file.


Ge

Set Up Facilities Profile

This chapter tells you which code you must define before you can define your buildings, rooms, and equipment.

Codes needed to define buildings

• building condition codes

• building access codes

• building type codes

• construction type codes

• country codes

• institution codes

• ownership status codes

• sector codes

Codes needed to define rooms

• category of use codes

• room access codes

• room characteristics codes

• room rate class codes

• room type codes

• room usage codes

• usage codes

• wing codes

For information on defining these codes, see “Colleague Core Codes” on page 11.

174tting Started with Colleague Core | Set Up Facilities Profile - Ellucian - Confidential and Proprietary

Ge

Set Up Scheduling

This chapter tells you which code you must define before you can define the Scheduling module.

Codes used by the Scheduling Module

Before you can use the Scheduling module, you must set up the following codes:

• calendar day types

• event types

• schedule repeat codes

• facilities

• buildings

• rooms


175tting Started with Colleague Core | Set Up Scheduling - Ellucian - Confidential and Proprietary

GePro

Set Up Staff/Volunteer Information

This chapter tells you which code you must define before using the Staff/Volunteer Information module.

Codes used by the Staff/Volunteer Information Module

Before you can use the Staff/Volunteer Information module, you must set up the following codes:

• address relation types

• communications codes

• contact results

• contact roles

• locations

• office codes

• privacy codes

• proceed

• reminder purposes

• reminder status

• staff reminder types

• staff status

• staff types


176tting Started with Colleague Core | Set Up Staff/Volunteer Information - Ellucian - Confidential and prietary

colleague core getting started with colleague core

Documents