Student Records Implementation Guide

Student Records

Implementation Guide

Copyright (c) 2001 Jenzabar, Inc. All rights reserved. You may print any part or the whole of this documentation to support installations of Jenzabar software. Where the documentation is available in an electronic format such as PDF or online help, you may store copies with your Jenzabar software. You may also modify the documentation to reflect your institution's usage and standards. Permission to print, store, or modify copies in no way affects ownership of the documentation; however, Jenzabar, Inc. assumes no responsibility for any changes you make. Filename: imstrc Distribution date: 07/27/1999 Contact us at www.jenzabar.com

Jenzabar CX and QuickMate are trademarks of Jenzabar, Inc. INFORMIX, PERFORM, and ACE are registered trademarks of the IBM Corporation Impromptu, PowerPlay, Scenario, and Cognos are registered trademarks of the Cognos Corporation UNIX is a registered trademark in the USA and other countries, licensed exclusively through X/Open Company Limited Windows is a registered trademark of the Microsoft Corporation All other brand and product names are trademarks of their respective companies

i

JENZABAR, INC.

STUDENT RECORDS IMPLEMENTATION GUIDE

TABLE OF CONTENTS Converting Student Records ...................................................................................................................... 1

Introduction............................................................................................................................................. 1 Course Record Fields............................................................................................................................. 1 Course Work Record Fields ................................................................................................................... 6 ID Record Fields..................................................................................................................................... 9 Profile Record Fields ............................................................................................................................ 12 Program Enrollment Record Fields ...................................................................................................... 15

Cross-Functional Issues in the Implementation of the Registrar Module ................................................ 21 Introduction........................................................................................................................................... 21 List Of Cross-Functional Issues ........................................................................................................... 21

Creating Program Enrollment Records .................................................................................................... 26 Introduction........................................................................................................................................... 26 Automated Creation of Records ........................................................................................................... 26 Manually Creating Student Records..................................................................................................... 26 Manually Creating Student Records..................................................................................................... 26

Tables Specific to the Student Records Application ................................................................................ 28 Introduction........................................................................................................................................... 28 Tables Specific to Student Records ..................................................................................................... 28

Tables and Records ................................................................................................................................. 29 Table and Record Information.............................................................................................................. 29

Maintaining the Academic Status ............................................................................................................. 30 Introduction........................................................................................................................................... 30 How to Maintain the Academic Status Record..................................................................................... 30 Updating the Academic Status ............................................................................................................. 31 Printing Academic Statuses.................................................................................................................. 31 Special Awards Maintenance ............................................................................................................... 31

Maintaining Program Degrees and/or Certifications ................................................................................ 32 Introduction........................................................................................................................................... 32 Program Enrollment Record Method.................................................................................................... 32 Education Record Method.................................................................................................................... 32 Special Awards Maintenance ............................................................................................................... 32

Student Records Reports ......................................................................................................................... 33 Introduction........................................................................................................................................... 33 Student Records Reports ..................................................................................................................... 33

Troubleshooting........................................................................................................................................ 34 Introduction........................................................................................................................................... 34 Issues ................................................................................................................................................... 34

INDEX ......................................................................................................................................................... 35

Student Management 1 Implementing Student Records

Converting Student Records

Introduction In the implementation of the CARS Solution Student Records application, you must identify and prioritize the student records for conversion. The following student records must be converted using the tpconvert tool:

• Course record (crs_rec) • Course Work record (cw_rec) • ID record (id_rec) • Profile record (profile_rec) • Program Enrollment record (prog_enr_rec)

These pages list and describe the fields of the above student records.

Course Record Fields The following lists and describes the fields of the Course record (crs_rec). The description indicates whether each field must be converted. The Schema filename precedes each field name.

accept_date Acceptance Date

Required: Yes The date that the course was formally approved for use

Note: The date should be loaded as the actual date if known; otherwise, load all as a date for conversion.

bill_code Course Bill Code

Required: No The course billing code (a second fee) for the course

cat Catalog Code - Course

Required: Yes The catalog associated with the course

Note: Use a catalog from the catalog table that is consistent with institutional implementation. If the current catalog is UG93, use a prior catalog for converted courses (e.g., UG92).

cip_no Course CIP Number

Required: No The CIP number associated with the course

clock_hrs Course Clock Hours

Required: No The number of clock hours associated with the course

cntg Counting Code

Implementing Student Records 2 Student Management

Required: Yes The type of counting codes for the course's hours

Note: Refer to the Counting table.

Use the following codes for courses that do or do not count towards a degree: E - earned N - non-earned

core Core Code

Required: No The core guideline to be used for program auditing

cr_max_rep Maximum Repeats For Credit

Required: Yes The maximum times that the course can be taken for a student to receive credit

Note: Set the field at zero (0) if you do not know the value.

cr_rep Minimum Repeats For Credit

Required: Yes The value denoting the minimum times that the course can be taken for a student to receive credit

Note: Set the field at zero (0) if you do not know the value.

crs_no Course Number

Required: Yes The course number

Note: Enter the course number, preferably without spaces (e.g., ENG100). If you use spaces, ensure that all courses have the same spacing.

dept Department Code

Required: Yes The department associated with the course

Note: Enter the department of the course as specified in the dept_table.

dir_study_allow Directed Study

Required: Yes Indicates whether directed study is allowed for the course

Example: Y (yes) or N (no)

Note: Set the field at N if you do not know the value.

fac_consent Faculty Consent

Required: Yes Indicates whether faculty consent is needed for taking the course




fac_load Faculty Load

Required: Yes Indicates whether the course is to be included in faculty load calculations



fee_code Course Fee Code

Required: No The course fee for the course

grd_rep Course Grade Repeat

Required: No Inactive at the present time

grdg Grading Code - Course

Required: Yes The type of grading that is used for the course

Note: Refer to the grade type table.

Enter the Grading Type used for the course, typically LT for letter grade.

indep_study_allow Independent Study

Required: Yes Indicates whether a student can take the course as an independent study course



last_drop_days Course Last Drop Days

Required: Yes The number of days a student has to drop the course before receiving a withdrawn grade (non-traditional courses only)

level Course Class Level

Required: No The classification course level for the course

Note: Enter 1 for 100 level courses, 2 for 200 level courses, etc.

max_days Maximum Days To Complete

Required: No The maximum number of days a student has to complete the course

Note: Use the field to define the maximum days to complete the course (for non-traditional courses only).


max_hrs Course Maximum Hours

Required: Yes The maximum number of credit hours allowed for the course

Note: Enter the maximum hours of credit allowed for the course.

max_rep Course Repeat Maximum

Required: Yes The maximum amount of times the course can be repeated for credit

Note: The crs_rep field uses the field to define the number of times a course can be repeated for credit. If you set the crs_rep field to N, the max_rep field indicates the number of times the course can be taken to improve a grade.

Enter a value to indicate the number of times a course can be taken to improve a grade (e.g., 2 for one additional time; 0 for unlimited repeats).

max_rep_hrs Course Repeat Maximum Hours

Required; Yes The maximum number of hours the course can be repeated for credit

Note: If you set the rep field to Y, the max_rep_hrs field specifies the number of credit hours the course can be taken for credit.

min_hrs Course Minimum Hours

Required: Yes The minimum number of credit hours allowed for the course

Note: Enter the minimum hours of credit allowed for the course.

pref_cl_size Preferred Class Size

Required: No The preferred number of students allowed to register for the course

prog Program Code - Course

Required: Yes The program associated with the course

Note: Enter the appropriate program codes from the Program table.

rep Course Repeatable

Required: Yes Indicates whether the course can be repeated Y (yes) or N (no)

Note: If you enter Y, the course is repeatable for credit; the course can be retaken up to and including the number in the max rep field.

If you enter N, the course cannot be retaken for credit, and the system applies normal repeat logic.

sess_offer


Session Offered Required: No The session in which the course is offered

site Site Code

Required: Yes The accredited institution responsible for the course

Note: Enter the site code of your institution.

stat Course Status

Required: Yes The status of the course

Example: A - active

B - blanked

I - inactive

Note: Enter A for all courses used to produce a schedule.

stat_date Status Date

Required: Yes The date that the course status was last updated

Note: Enter a set date for conversion purposes.

This field should be under program control only.

title1 Course Title - Line 1

Required: Yes Line one of the course title

Note: Do not leave blank.


Required: No An additional line for the course title

Note: Use if the course title exceeds one line.


Required: No An additional line for the course title

Note: Use if the course title exceeds two lines.

tuit_code Course Tuition Code

Required: No The tuition code used for the course

vo_ed


Vocational Course Required: Yes Indicates whether the course is a vocational educational course



yr_offer Years Offered

Required: No The pattern of years that the course is offered

Course Work Record Fields The following lists and describes the fields of the Course Work record (cw_rec). The description indicates whether each field is required to be converted. The schema filename precedes each field name.

absnt_hrs Absent Hours

Required: No The number of hours the student was absent for the section

Note: Use the field to compute positive attendance.

absnt_upd Absent Hours Updated

Required: No Indicates whether the absent hours have been updated


beg_date Course Work Begin Date

Required: No The beginning date of the course

Note: The field is typically used for non-traditional courses.

Enter the beginning date of the section or the date that the student started a non-traditional course.

cat Catalog Code - Course Work

Required: Yes The catalog from which the course number code is taken

Note: The value you enter must match the value entered in the crs_no field of the Course Work record and the cat field of the Course record.

clock_hrs Clock Hours - Course Work

Required: No The number of clock hours received for the course

cntg Counting Code - Course Work


Required: Yes The grade counting type for the course's grade type

Note: You can enter a value that is different from the Course record cntg field.

Use the following codes for courses that do or do not count towards a degree: • E - earned • N - non-earned

crs_no Course Number

Required: Yes The course taken for the course work record

Note: Enter the crs_no value of the Course record associated with the Course Work record. A Course record must exist for each Course Work crs_no value used.

cw_no Course Work Record Number

Required: Yes The system generated sequential number uniquely identifying this record

end_date Course Work End Date

Required: No The end date of the course

Note: Typically used for non-traditional courses.

Enter the ending date of the section or the date that the student completed a non-traditional course.

grd Final Grade - Course Work

Required: Yes The grade type for the course

Note: Enter the final grade, starting in the left-most position. The grade must also be entered in the Grade table.

grdg Grading Code - Course Work

Required: Yes The grade type for the course

Note: Enter the grading type that is entered in the Grade table.

hrs Credit Hours - Course Work

Required: Yes The number of credit hours received for the course

Note: Enter the number of hours that the student received for enrolling in the course.

id ID Number


Required: Yes The ID number of the student who took the course

midsess_grd Midsession Grade - Course Work

Required: No The midsession grade received for the course

prog Program Code- Course Work

Required: Yes The program in which the course is offered

Note: Enter the prog value that is entered in the Course record prog field.

rep Repeat Code - Course Work

Required: No The code that indicates that the course is a repeated course

Note: The system sets the value the first time that you run the transcript update.

sec Section Number - Course Work

Required: Yes The section number for the course

Note: Enter the number from the previous system, or use 01, 02, 03, etc.

sess Session Code - Course Work

Required: Yes The session during which the course was taken

Note: Enter the code from the sess_table (e.g., FA, SP, or SU).

site Course Site

Required: Yes The site associated with the course

Note: Enter the site code of your institution.

stat Course Work Status

Required: Yes The current status of the course

Note: For conversion purposes, enter the following codes for the following statuses: • R for courses taken in residence • W for courses in residence from which the student withdrew • D for dropped sections you retained from the previous system • T for work accepted in transfer

subsess Subsession Code


Required: No The subsession during which the course was taken

yr Calender Year - Course Work

Required: Yes The year that the course was taken

Note: Enter a valid year (e.g., 199x).

ID Record Fields The following lists and describes the fields of the ID record (id_rec). The description indicates whether each field is required to be converted. The schema filename precedes each field name.

aa Address Code - ID

Required: No The type of address entered for the entity

Note: Refer to the Alternate Address table.

add_date Add Date - ID Record

Required: No The date that the ID information was added to the system

Note: The field should reflect the date you completed conversion.

addr_line1 Address Line 1

Required: Yes The first line of the entity's address

Note: An entry must be present for mailing purposes.

addr_line2 Address Line 2

Required: No The second line of the entity's address

city City

Required: Yes The city name where the entity is located

correct_addr Correct Address

Required: Yes Indicates whether the address is correct


Note: The field should be set to Y for all students.

ctry Country Code


Required: No The country in which the entity is located

Note: Refer to the Country table.

decsd Deceased

Required: Yes Indicates whether the entity is deceased


Note: The field should be set to N for all students, if known.

fullname Name

Required: Yes The name of the entity identified by the record

Note: Entries must exist for the system to function properly.

Use the following entry format: Last_Name, First_Name, and Middle_Initial.

id ID Number

Required: Yes The serial number assigned by the system to identify the record. Yes Mail indicates whether the entry should receive mailings


Note: The field should be set to Y, if known.

name_sndx Phonetic Matching Name

Required: No The code used to phonetically match the entity's name

ofc_add_by Office Added By

Required: No The office that added the entity to the system

Note: The field should be set to the "owner" office if the institution uses the CARS Solution function to limit ID/profile record updating to an owner concept (e.g., the ENABLE_FEAT_IDPERMS macro set to 'Y'.)

phone Phone Number

Required: No The area code and telephone number of the entity

Note: If desired, parenthesis and dashes should be included in the field.

phone_ext Phone Extension

Required: No The extension to the phone number of the entity

prev_name_id


ID - Previous Required: No The previous identity of the entity

prsp_no ID Number - Prospect

Required: No The entity's original lead ID number (when the entity was entered on the system as a lead)

pub Publicity Mailings

Required: No Indicates whether the individual should receive publicity notices


purge_date Date ID May Be Removed

Required: No The date that the entity is eligible to be removed from the system

sol Solicitation

Required: No Indicates whether the individual may receive solicitations


ss_no Social Security Number

Required: No The outside agency identification number of the entity

Example: Person - SS No.

Business - Fed ID

School - CEEB

st State Code

Required: Yes The state in which the entity is located

Note: Refer to the State table.

Entries must be present for mailing purposes.

suffix Suffix to Name

Required: No The suffix with which the entity should be addressed

Note: Refer to the Suffix table.

title Title Code


The title with which the entity should be addressed

Note: Refer to the Title table.

upd_date Last Update Date - ID

Required The date that the ID was last updated

valid Valid - ID

Required: Yes Indicates whether the ID is valid


Note: If the ID is valid, enter Y.

zip Zip Code

Required: Yes The zip code of the current location of the entity

Note: Entries must be present for mailing purposes.

Profile Record Fields The following lists and describes the fields of the Profile record (profile_rec). The description indicates whether each field is required to be converted. The schema filename precedes each field name.

age Age

Required: No The age of the student in years

Note: The system automatically calculates the age value.

birth_date Birthdate

Required: N/A The birthdate of the student

Note: The system uses the field to calculate age.

birthplace_city Birth City

Required: No The city where the student was born

birthplace_st Birth State

Required: No The state where the student was born

church_id ID Number - Home Church


Required: No The student's church

citz Citizen Code

Required: No The student's citizenship status

denom_code Denomination Code - Profile

Required: No The religious denomination that the student prefers

ethnic_code Ethnic Code

Required: No The ethnic background of the student

handicap_code Handicap Code

Required: No The handicap of the student

id ID Number - Profile

Required: Yes The student ID number to which the profile information refers

Note: A profile record must exist in the system.

lang Language

Required: No The primary language of the student

mrtl Marital Status

Required: No Identifies the current marital status of the student

news1_id ID Number - Newspaper 1

Required: No The primary newspaper in which to release information

news2_id ID Number - Newspaper 2

Required: No The secondary newspaper in which to release information

occ Occupation Code

Required: No The occupation of the student

password


Password Required: No The student's password to be used where appropriate

photo Photo

Required: No The individual’s photograph in .gif format. Web applications use this field.

prof_last_upd_date Last Update Date - Profile

Required: No The date that the profile of the student was last modified

prof_res_code Residence Code

Required: No The student's residence status (for fee purposes)

Note: California Community Colleges use the field.

prof_res_date Residence Date

Required: No The date that the student first moved to his or her current residence (for fee purposes)

prof_vet_chap Veteran's Chapter

Required: No The veteran's chapter with which the student is associated

prof_visa_date Visa Date

Required: No The adjustment date (either beginning or expiration date) for the visa issued to the student

prof_visa_no Visa Number

Required: No The visa number associated with the student's visa

res_ctry Resident Country Code

Required: No The country where the student resides

res_cty Resident County Code

Required: No The county where the student resides

res_st Resident State Code


Required: No The state where the student resides

sex Sex Code

Required: No The sex of the student

vet Veteran

Required: No Indicates whether the student is a veteran


visa_code Visa Code

Required: No The student’s American residential status

Program Enrollment Record Fields The following lists and describes the fields of the Program Enrollment record (prog_enr_rec). The description indicates whether each field is required to be converted. The Schema filename precedes each field name.

acad_date Academic Status Date

Required: Yes The date on which the current academic status became effective for the student

Note: Use the conversion date, if known.

acst Academic Status Code

Required: Yes The current academic status for the student

Note: Use the appropriate status from the Academic Status table.

adm_date Admission Date

Required: No The date that the student was admitted to the program

adm_sess Admission Session Code

Required: No The session for which the student was admitted

adm_stat Admission Status Code

Required: No The admitted academic status for the student

adm_yr Admission Calender Year


Required: No The calender year for which the student was admitted

adv_id ID - Student Advisor

Required: No The ID number for the student's academic advisor

apprent Apprentice Status

Required: No The student's status as a registered apprentice

Note: Enter 0 if the student is not in GAIN program; otherwise, enter 1 through 8 for the types of participation.

cl Classification Code

Required: Yes The current academic classification for the student

Note: The entry should reflect the appropriate status from the Classification table.

conc1 Concentration - First

Required: No The primary area of concentration for the student

conc2 Concentration - Second

Required: No The secondary area of concentration for the student

decl_date Program Declaration Date

Required: No The date on which the student declared the program

Note: The entry should be the conversion date, if otherwise unknown.

deg Degree Code

Required: No The type of degree the student has earned or is attempting to earn

Note: The entry should be the degree awarded by the home institution, if known.

deg_app_date Degree Application Date

Required: No The date on which the student applied for the degree

deg_grant_date Degree Granted Date


Required: No The date on which the degree was granted to the student

Note: The entry should be the date that the degree was awarded by the home institution, if known.

deg_grant_sess Degree Granted Session Code

Required: No The session in which the degree was granted


deg_grant_yr Degree Granted Calendar Year

Required: No The calendar year in which the degree was granted


enr_date Program Enrollment Date

Required: No The date of the student's first enrollment in the program

expect_grad Expected Graduation

Required: No Indicates whether the student is expected to graduate at the close of the section


gain_stat GAIN Status

Required: No The student's status in the GAIN program

Note: Enter 0 if the student is not in GAIN program; otherwise, enter 1 through 8 for the types of participation.

grd_rpt_id ID - Receive Grade Reports

Required: No The ID number of the individuals to receive the grade reports for the student

id ID Number

Required: Yes The ID number of the student associated with the program enrollment record

Note: The system assigns the ID number.

last_sess Last Session Enrolled


Required; No The most recent academic session in which the student was enrolled

major1 Major - First

Required: No The primary major declared by the student

major2 Major - Second

Required: No The secondary major declared by the student

matric_date Matriculation Date

Required: No The date that the student was matriculated in the current program

max_hrs_reg Maximum Registered Hours Allowed

Required: Yes The maximum number of course hours in which the student can register in any one session (zero means no limit on hours)

Note: Enter the load as the maximum hours allowed.

min_hrs_reg Minimum Registered Hours Allowed

Required: Yes The minimum number of course hours in which the student can register in any one session (zero means no limit on hours)

Note: Enter the load as zero if no limit is imposed.

minor1 Minor - First

Required: No The primary minor declared by the student

minor2 Minor - Second

Required: No The secondary minor declared by the student

plan_grad_yr Planned Graduation Calendar Year

Required: No The calender year in which the student plans to graduate

prog Program Code - Program Enrollment

Required: Yes The program in which the student is enrolled

Note: Enter the code from the Program table.

res_st


Resident State Code Required: No The state where the student resides

rnd Program Enrollment Random Number

Required: No The system generated random number for the student

Note: The system uses the field with anonymous grading.

rstr_schd Restricted Schedule

Required: No Indicates whether the student's schedule has been restricted


site Site Code

Required: Yes The site associated with the program

Note: Enter the institution's site code.

ss_ben Social Security Benefits

Required: No Indicates whether the student is receiving social security benefits


subprog Subprogam Code

Required: No The subprogram in which the student is enrolled

to_alum Alumni Added

Required: No Indicates whether the student has been added to the alumni file


to_alum_date Alumni Add Date

Required: No The date that the student was added to the alumni file

trans_frm_ofcl Student Official Transcript Form

Required: No The transcript form to be used on all official transcripts printed for the student

trans_frm_unofcl Student Unofficial Transcript Form


Required: No The transcript form to be used on all unofficial transcripts printed for the student

vet_ben Veteran Benefits

Required: No Indicates whether the student is receiving veterans benefits


voc_ed Vocational Education Status

Required: No The student's status as a vocational education student


Cross-Functional Issues in the Implementation of the Registrar Module

Introduction As you implement each application within the Registrar module, various policy issues will arise about which you must make decisions. However, in addition to issues affecting strictly the Registrar’s office, there are other issues that involve various offices at an institution. The next few pages list some of these issues, as well as helpful information you can use in deciding how to resolve each issue.

List Of Cross-Functional Issues The following lists each cross-functional issue, as well as a description of each, that should be addressed while implementing the Student Records application.

Use of course, section, and reference numbers To ensure that the original intent of an institution’s numbering system remains intact, answer the following questions:

• Does the meaning of the course number indicate academic year (e.g., freshman)? Does is include the credit value or some other value?

• What are the institution’s policy and procedure on reusing course numbers? How often are numbers reused? Why?

• Are section numbers or letters used? If so, is a meaning associated with them? Do they appear on transcripts?

• Are course or section numbers assigned to academic units in a centralized (e.g., Dean’s list or Registrar’s office, Curriculum Committee) or decentralized manner (e.g., each department assigns its own numbers)?

• Does the current system use a reference number for each course section? How is the reference number generated? How is it used?

Developing the annual processing calendar for catalog and schedule information The official academic calendar table (acad_cal_rec) must reflect the catalog and schedule dates. Therefore, all offices at an institution must understand and participate in developing the calendar used for catalog and schedule information.

Access to Student Records, Catalog and Schedule, Registration, Grading, and Academic History Information by Other Offices at an Institution

To ensure that individuals outside a particular office are able to access student records, catalog and schedule, registration, grading, and academic history information efficiently and cost-effectively, while guarding against misuse of this ability to access information, answer the following questions:

STUDENT RECORDS Which office is responsible for creating student ID cards? Does the card include information from admitted students’ files? How is the information produced?

CATALOG AND SCHEDULE • Is an individual other than the registrar responsible for publishing the printed course

catalog? How is the master course inventory maintained? • What information does the bookstore need for ordering books? How does the

bookstore get the information it needs? • Which offices need facility schedule information (e.g., Information Office, Campus

Security, Physical Plant)?


REGISTRATION • Which offices need student schedule information (e.g., Financial Aid office, Dean of

Students, Information office, Campus Security, Emergency contact office)? • Is an office other than the Registrar’s office responsible for reports such as enrollment and

IPEDS (e.g., Institutional Research office)? • Is an office other than the Registrar’s office responsible for or involved in facility assignment

or reporting (e.g., Academic Dean, individual academic departments, Physical Plant office)?

GRADING • Do offices other than the Registrar’s office maintain copies of grade lists turned in by

faculty? • Which offices receive a copy of student grade reports (e.g., Academic Dean, individual

academic departments, Dean of Students, Placement office)? How are the reports organized?

• Which office is responsible for grade reports (e.g., Dean, Institutional Research office)? • Which offices are responsible for determining the dean’s list? How do these offices get the

information they need? • Which offices determine which individuals are on probation or suspension? How do these

offices get the information they need? • How do the Financial Aid office and the office responsible for merit scholarships get the

information by which they assess satisfactory academic progress? • Where and how is progress determined for veterans and social security students? • How are requests for term grade information by third-party payees handled?

ACADEMIC HISTORY • Which offices expect to receive an official or unofficial transcript on a regular basis? On a

student-by-student basis? By some other grouping of students? How are such records used?

• Which offices expect to access online academic history information? For what purpose? • Are transcripts provided to another campus office ever sent off campus? For what

purpose? Who determines that a degree is to be conferred with honors? On the basis of what information?

Course and Section Fees Although the Registrar’s and Bursar’s offices usually coordinate course and section fees, sometimes fees or charges are handled manually by individual academic departments. CARS Solution supports virtually any kind of fee or charge associated with a course or section; Jenzabar, Inc. recommends an institution-wide review of such charges.

All Course or Section Requisites that Govern Enrollment To implement the CARS Solution automated requisite checking feature, complete these tasks:

• Build a requisite record for each course for which requisites exist • Review the relationships among multiple requisites as they appear in the course

catalog (e.g., review “and” and “or” logic) • Identify non-course requisites (e.g., test scores and grades) that are tracked by

CARS Solution

All Faculty or Administration Approvals Required for Students to Enroll and Sections


Students must occasionally obtain approval from a faculty member, department, or dean in order to register for a course or section, whether the requirement is course- or student-based. CARS Solution can help apply these requirements consistently. However, every office must completely understand the requirements of that the appropriate records can be created.

Decisions Made During Student Records and Catalog and Schedule Implementations Regarding Student, Course, and Section Records Used in Registration

Review the decisions made and information entered in the CARS Solution Admissions module and the Student Records and Catalog and Schedule applications of the Registrar module regarding the following registration requisites to determine their effects elsewhere during registration:

• The academic status of registering students (e.g., admitted, continuing, or returning)

• The appropriate catalog and term for courses and sections

Responsibility (e.g., office or individual) for Each of the Registration and Add/Drop Functions Occurring in CARS Solution

The Registrar’s office is usually responsible for registration and add/drop functions; however, some related registration processes often involve other offices. To improve the efficiency of the entire registration process and of the services provide to student, the offices involved in registration-related functions must do the following:

• Identify each registration-related function • Identify who is responsible for each function • Decide whether CARS Solution needs to be modified to accomplish each function

Chronological and Physical Dimensions of the Occurring With the CARS Solution Registration Process

Consider when and where registration is to occur. For example, if registration now occurs in an arena setting immediately before classes begin, the institution might consider on of these three alternatives:

• Spread the process over time, resulting in fewer disruptions to institutional operations and lower personnel costs

• Decentralized data entry to individual academic departments, in order to link academic advising and course enrollment more closely

• Implement the CARS Solution Interactive Voice Response (IVR) telephone registration, enabling student to register at a time and location of their own convenience

Staffing of the CARS Solution Registration Process Staffing considerations are significant when registration is centralized and occurs over a short period of time, whether the institution uses regular staff, temporary staff, or students. During implementation, assess efficient and cost-effective approaches to staffing during registration.

Holds Management CARS Solution enables an institution to replace manual, staff-intensive procedures for tracking academic and administrative holds with automated holds capability. During implementation, the departments at the institution should identify the following information:

• All possible holds • Who is authorized to place or remove each type of hold • The intended effect of each type of hold • Using CARS Solution, the institution can either decentralize or centralized hold

functions (e.g., placing a hold, clearing a hold). In addition, the institution can label holds as either notation or absolute.

Identification, Name, and Address Management


CARS Solution, because it is fully integrated, is able to provide the following benefits to an institution regarding identification, name, and address management:

• Each individual or entity associated with the institution is assigned a single identification number

• The social security number, an optional feature in CARS Solution, calls up an individual’s or entity’s record just as the ID number does

• CARS Solution can track prior names, salutation names, and names that reflect relationships between individuals or entities, and affords virtually unlimited capability for different addresses

• In resolving this cross-functional issue, the offices at an institution must ensure that the following tasks are completed:

• Appropriate addresses are available when needed (e.g., billing, grade reporting, third-party)

• Offices are assigned responsibility for ensuring that identification, name, and address information is available when needed, and that all offices are working cooperatively

Formatting Standards (e.g., address conventions) For consistent, professional-looking correspondence, reports, and lists, the offices at an institution must agree on the following considerations:

• How names and addresses are to be formatted • What the valid values are for various data elements in the system (e.g., the names

and abbreviations for degrees conferred, names of academic departments, majors)

Use of Records Scroll records, or collections of related information that are used as supplemental data about and individual or an entity associated with an institution, use space in CARS Solution only if data exists in a record. Some of the scroll records available in the Registrar module require coordination by several offices so that the information is usable by all offices that have access to the information contained in them. The following scroll records are example:

• Relationship scroll records identify the ways in which individuals or entities associated with an institution are related (e.g., father/son, sister/brother, husband/wife, employer/employee). Because different offices might view these relationships differently, and might use the information in unique ways, it is important to meet the needs of all offices.

• The Accomplishment, Education, and Examinations scroll records are critical to the Academic History application of the Registrar module because the information contained in these records appears on academic records and transcripts, provided certain key data are entered. The institution must decide whether these records are reserved exclusively for the registrar and, if not reserved for the registrar, what are the rules for use by other offices.

Admissions and Academic Status Coding A single status table exists in CARS Solution to identify and track prospective students’ admissions statuses and enrolled students’ academic status’s. However, there must be close coordination among the Admissions office, the Registrar’s office, and the individual academic offices in order to identify the possible admission and academic statuses.

Determining Completion of Degree Requirements; Certifying Degree Completion The offices involved in degree requirements or degree completion should organize the methods for determining when a student has met the requirements for a degree, and for certifying that a degree has been earned and/or conferred; they must understand how these processes work, because CARS Solution can support several ways to organize these processes.

Note: The transcript forms (both unofficial and official) used in the Academic History application are very flexible regarding the information about degrees earned.


Transferring Information from the Registrar’s Office to Alumni Affairs Office When a Degree has been Conferred (or at Other Times as Appropriate)

CARS Solution electronically transfers information from the Registrar module to the Alumni and Development module for individuals who have earned degrees. However, the Registrar’s and Alumni and Development offices must agree on the following related issues:

• The definition of an alumnus • The timing of the information transfer using CARS Solution • The content of the information transfer using CARS Solution

Creating the Program Enrollment Record From Admissions Information; Accessing the Program Enrollment Record For Readmitted Students

The Program Enrollment record is created when the Admission offices releases admitted students’ records to the Registrar’s office for registration; however, the Program Enrollment record must be created before a student can enroll in classes. The Admissions and Registrar’s offices must resolve the following issues:

• When to created the records for both office (because, once created, offices other than the Registrar’s office are discouraged from accessing these records)

• Accessing the Program Enrollment records of former students who are being readmitted

• Updating the Program Enrollment record when a new admissions record is created, and the Program Enrollment record already exists


Creating Program Enrollment Records

Introduction The institution must create Program Enrollment records for each student enrolled in the institution. CARS Solution, which requires Program Enrollment records for registration processing, provides two distinct methods to create a Program Enrollment record:

• Automated Program Enrollment record creation from Admission data through an SQL update statement

• Manual data entry for students who bypassed the Admission process

Automated Creation of Records The Admission or Registrar's office can automatically create a Program Enrollment record by selecting the Create Program Enrollment option, located in the Admission Session Processing menu. The Create Program Enrollment option runs the progenr SQL statement, which creates the Program Enrollment record from the Admission record data of a student.

Before creating the Program Enrollment record, the progenr SQL statement checks to ensure that a student's Program Enrollment record has not already been created for the program (e.g., UNDG, GRAD) of the Admission record.

The progenr SQL statement is located in the following directory: $CARSPATH/modules/regist/informers/.

Note: Jenzabar, Inc. recommends the following: • That the institution review the columns in the progenr SQL statement to ensure that

fields added to the Admission record during implementation are also included in the SQL statement.

• That a limited group of individuals execute the progenr SQL statement. During execution, error messages should be monitored for and investigated immediately.

Manually Creating Student Records The Registrar's office may need to create a Program Enrollment record before a corresponding Admission record exists or when the student does not require an Admission record. For the ease of use, CARS Solution provides two menu options in which to enter program enrollment information. The options are described below.

Walk-In Registration

The Registrar's office can create a Program Enrollment record through the Walk-In Registration option of the Registrar: Registration menu. With the option, the Registrar can create the ID, Profile, and Program Enrollment records, as well as any common records displayed in the Scroll Screen windows.

• If the institution uses the Walk-In Registration option, the screen default values for the Program Enrollment record should be reviewed periodically.

• The Walk-In Registration option does not concurrently create an Admission record, which is often used for statistical reporting. In addition, if the institution utilizes a code in the Academic Status table that blocks the Admissions office access to records created with the Walk-In Registration option, the Admissions office will not be able to add Admission records.

Manually Creating Student Records • Jenzabar, Inc. recommends that the institution review the use of the Walk-In Registration

option and define policy related to the following topics:


− The creation of Admission records for student’s records created with the Walk-In Registration option

− The development of internal reports to identify student’s records created with the Walk-In Registration option

Data Entry

The Registrar's office can also create a Program Enrollment record through the Data Entry menu option of the Student Management: Registrar Main Menu. The menu option accesses the Student Data Entry menu, which contains options to maintain the following student information: students, program enrollment, graduation, parents, schools, and churches. The Data Entry screen, which consists of all program enrollment options, can be used for creation and maintenance of Program Enrollment records.


Tables Specific to the Student Records Application

Introduction Tables specific to the Student Records application are accessed only by the Student Records application. Any modifications you make to the Student Records tables should not affect how other CARS Solution applications run.

Tables Specific to Student Records The following lists each table that is specific to the Student Records application.. Review and update (if necessary) these tables in the order listed below. Both the title and the filename of each table are provided below.

acad_stat_table Academic Status table

cert_table Certificate table

cl_table Classification table

cont_table Concentration table

degree_table Degree table

major_table Major table

minor_table Minor table

prog_table Program table

progreg_table Program Registration table

subprog_table Subprogram table


Tables and Records

Table and Record Information The following list identifies the tables and records that originate from the Accelerated Degree product. The list includes the filenames, location, purpose, and association of each table and record with programs, products, and other tables and records.

Note: The Program interrelationships in the list are included in the Accelerated Degree product. The Product interrelationships in the list are not included in the Accelerated Degree product.

Academic Record Tracks detail information such as hours attended, points earned, and grade information. CARS Solution creates one Academic record per program for each session the student atrtends.

UNIX filename: stuacad

Informix filename: stu_acad_rec

Schema location: $CARSPATH/schema/student

Program interrelationships: billing, grading, grdrpt, regist, reglist, trans

Product interrelationships: Registration, Grading, Transcript

Table/record interrelationships: None

Program Enrollment Record Stores specific program information, such as major, minor, degree, and date of graduation for each student.

UNIX filename: progenr

Informix filename: prog_enr_rec

Schema location: $CARSPATH/schema/student

Program interrelationships: billing, faentry, grading, grdrpt, regist, reglist, trans

Product interrelationships: Registration, Grading, Transcript

Table/record interrelationships: None


Maintaining the Academic Status

Introduction The Program Enrollment record contains the sum of a student's program information. CARS Solution allows you to take snapshots of the Program Enrollment record by transferring specific session information to the Academic Status table. The transferred information, which becomes the Student Academic record (stu_acad_rec), comes from the Academic Status column of the Program Enrollment record. CARS Solution uses the Student Academic record to maintain the snapshot of a student's status, which is driven by the Academic Status table.

Through use of the Academic Status table, the institution can also limit registration through warning messages or completely block the ability to register the student.

Note: If the institution uses the Jenzabar, Inc.-provided SQL statement to create Program Enrollment records from Admission data, the system creates the Academic Status column based on the admission decision code in the Admission record.

Example: Admission Status Academic Status FULL Full Admission REG Allowed to Register

How to Maintain the Academic Status Record The regent program creates the Academic Status record when the student registers for the first time. The system automatically creates the fields of the Academic Status record when the system processes the student's first registration.

Subsequent changes to the Program Enrollment record, following the first registration, can be transferred to the Academic Status record with an SQL statement. CARS Solution provides the updstuac SQL statement, a sample SQL statement that must be reviewed by the institution's data processing center. The updstuac SQL statement is located in the following directory: $CARSPATH/modules/regist/informers/.

The following lists and describes the steps to maintain the Academic Status record.

1. Define the fields you want to maintain in the Student Academic record, then add corresponding rows to the database.

Note: The field names in the Student academic record must match the names in the Program Enrollment record.

2. Modify the following includes located in $CARSPATH/include/regent:

include 1: #define STUAC_AUD_FIELDS { \ {"cl", "cl"}, \

{"subprog", "subprog"} \

! !

Prog_enr Stu_acad

include 2: #define STUAC_AUD_LEN 2

Note: In this step, you should consider all data that the institution may need to report on in a session year basis.


The base CARS Solution system provides the above includes. Jenzabar, Inc. recommends that you enhance your system with further custom includes.

3. Perform a reinstall of the following files: • include/custom/applic • src/regist/regent

Updating the Academic Status With CARS Solution, you can maintain the academic status on individual students on a manual basis, or you can perform maintenance on the student body through the use of SQL update statements.

• You perform manual entry for individual students in the Data Entry screens. • CARS Solution provides sample SQL statements to report on and update the statuses of

the student body. The data processing administrator must define the processing requirements and create the needed SQL statements. The sample SQL statements are as follows:

− modules/regist/informers/deanaccomp − modules/regist/informers/deanctc − modules/regist/informers/probctc

Printing Academic Statuses The Transcript program provides the ability to print academic statuses. At the institution's discretion, transcripts can be printed containing overall or session academic statuses.

Special Awards Maintenance Special awards (e.g., cum laude) are not associated with the academic status. You should enter special awards in the Accomplishment record for the session, year, and program in which the awards were earned.


Maintaining Program Degrees and/or Certifications

Introduction CARS Solution provides two distinct methods to perform program degree and/or certifications maintenance. The methods are as follows:

• Modifying the Program Enrollment record • Modifying the Education record

You perform the maintenance of program degree and/or certifications in the Student Data Entry screen.

Program Enrollment Record Method This method of maintaining program degree and/or certifications involves modifying the degree fields of the Program Enrollment record. Select the Program Enrollment option from the Student Data Entry menu. If you use this method, consider the following issues:

• The standard CARS Solution system comes with only one set of degree fields. • The institution is limited to the number of degree fields that it chooses to add to the

Program Enrollment record. • Degree information appears only in the header of transcripts.

The following lists and describes the steps to maintain program degrees and/or certifications by modifying the Program Enrollment record.

1. Check the fields in the Program Enrollment record for additional field requirements.

2. Add fields from the Program Enrollment record to the schema/student/progenr.

3. Add fields from the Program Enrollment record to the modules/regist/progscr/stuentry.

4. Add fields from the Program Enrollment record to the modules/regist/progscr/trans.

Education Record Method This method of maintaining program degree and/or certifications involves modifying the degree fields of the Education record (ed_rec). Select the Student option from the Student Data Entry menu, access the scroll screen of the Data Entry screen, and select the Education option. If you use this method, consider the following issues:

• You enter degree/certifications information one at a time, and complete the session, year, and program fields to link this record to the transcript programs.

• The institution has no limit to the number of degrees/certifications it can offer. • Degree information appears only in the body of the transcript in the session and year from

the Education record.

Special Awards Maintenance Special awards (e.g., cum laude) are not associated with degrees and certifications. You should enter special awards in the Accomplishment record for the session, year, and program in which the awards were earned


Student Records Reports

Introduction A report is a paper copy of the information contained in one or more tables. After you review or update tables in CARS Solution, it is good practice to print the corresponding report. The printed copy of the report allows you to verify that the information you added or updated in the table was changed in the database, and that the information is set up correctly on the report.

Student Records Reports The following lists and describes the steps to access the reports corresponding to the Student Records application by using the procedure that follows.

1. Select Student Management.

The Student Management: Main Menu appears.

2. Select Registrar.

The Student Management: Registrar Main Menu appears.

3. Select Reports.

The Registrar: Reports menu appears.

4. Select the Registrar: Reports menu option to access a specific report menu (e.g., Enrollment).

The specific report menu appears, depending on the option you selected.

5. Select the specific report that you would like to have printed (e.g., New Students).

A window containing information related to the report you selected appears.

6. Complete the required fields in the window, then select Finish.

The Output Parameters window appears.

7. Complete the fields in the Output Parameters window, then select Finish.

The report you selected is printed.


Troubleshooting

Introduction When running the Student Records application, you may encounter problems that have previously documented solutions. These pages are included to minimize your research time and problem solving efforts.

Issues The following lists a problem that can occur as well as the possible solution to the problem.

Students Have Majors, Ethnic Codes, or Other Student Data Missing on their Records Run the Missing Student Data option from the Registrar: Enrollment Reports menu. The system produces a report that indicates those students that have missing data from their records.

• You can specify items to be checked as missing by modifying the report generator located in $CARSPATH/modules/regist/reports/missdata.

• For each student record flagged in the report, you must manually add any missing data.

Index 35 Implementing Student Records

INDEX A academic status

maintaining, 30 printing, 31 updating, 31

academic status coding, 24 Academic Status table, 28 access to academic history information, 21 access to catalog, 21 access to grading, 21 access to registration, 21 access to schedule, 21 access to student records, 21 accessing the Program Enrollment record, 25 administration approval, 22 admissions coding, 24 automated creation of records, 26

C Certificate table, 28 certifying degree completion, 24 chronological requirements, 23 Classification table, 28 Concentration table, 28 converting student records, 1 course fees, 22

transferring information, 25 Course record

fields, 1 Course records

implementation, 23 Course Work record

fields, 6 creating Program Enrollment records, 26 creating the Program Enrollment record, 25 cross-functional issues

academic status coding, 24 access to academic history information, 21 access to catalog, 21 access to grading, 21 access to registration, 21 access to schedule, 21 access to student records, 21 accessing the Program Enrollment record, 25 admissions coding, 24 approvals, 22 certifying degree completion, 24 chronological requirements, 23 course fees, 22

transferring information, 25 creating the Program Enrollment record, 25 determining degree completion, 24

drop/add functions, 23 formatting standards, 24 holds management, 23 identification management, 23 implementations

Course records, 23 Section records, 23 Student records, 23

name and address management, 23 physical requirements, 23 registration functions, 23 requisites for enrollment, 22 section fees, 22 staffing registration, 23 use of records, 24

cross-functional issues, 21 implementing the Registrar module, 21 processing calendar, 21 use of course numbers, 21 use of reference numbers, 21 use of section numbers, 21

D Degree table, 28 determining degree completion, 24 developing the processing calendar, 21 drop/add functions, 23

E Education Enrollment record method, 32 Education record, 32

F faculty approval, 22 fields

Course record, 1 ID records, 9 Program Enrollment records, 15

formatting standards, 24

H holds management, 23

I ID record

fields, 9 identification

management, 23 implementation

Course records, 23 Section records, 23 Student records, 23


implementing the registrar module cross-functional issues, 21

M maintaining

academic status, 30 certifications, 32 program degrees, 32

maintenance certifications, 32 methods

Education record, 32 Program Enrollment record, 32

program degrees, 32 special awards, 31, 32

Major table, 28 manually creating, 26 Minor table, 28

N name and address management, 23

P physical requirements, 23 printing academic statuses, 31 Profile record

fields, 12 Program Enrollment record, 32

creating, 26 fields, 15 method, 32

Program Registration table, 28 Program table, 28

R records, 29

automated, 26 Course Work records, 6 creating automated records, 26 manually creating Student records, 26 Profile records, 12 Program Enrollment record, 26

registration functions, 23 reports

Student records, 33

S section fees, 22 Section records

implementation, 23 special awards maintenance, 31, 32 staffing registration, 23 Student records

Application tables, 28 converting, 1 implementation, 23 reports, 33

Subprogram table, 28

T tables, 29

Academic Status table, 28 Certificate table, 28 Classification table, 28 Concentration table, 28 Degree table, 28 Major table, 28 Minor table, 28 Program Registration table, 28 Program table, 28 specific to student records application, 28 Subprogram table, 28

troubleshooting, 34 missing record information, 34

U updating the academic status, 31 using course numbers, 21 using records, 24 using reference numbers, 21 using section numbers, 21

Index 37 Implementing Student Records

Documents

Student Records Implementation Guide