ohiosisfit-gapanalysis

i

PeopleSoft Student Administration

Fit/Gap Analysis

ii

REVISION CONTROL

Document Title: Ohio University Fit/Gap Analysis

Date By Action

3/19/2008 Eric Baker Initial Outline of document

3/30/2008 Leslie Roe / Byron Gibbs / Eric Baker

Append with Academic Structure

4/4/2008

Dewey Holleman / Micah Marin / Eric Baker

Append with Campus Community

4/28/2008 Julie Simpson / Micah Marin / Eric Baker

Append with Financial Aid

5/13/2008

Dewey Holleman / Micah Marin / Eric Baker

Append with Recruiting and Admissions

5/13/2008 Susan Kretz / Eric Baker

Append with Academic Advisement

5/13/2008 Chris Couture Append with Portal

5/27/2008 Reed Kofoed / Eric Baker

Append with Student Financials

6/4/2008

Leslie Roe / Susan Kretz / Karen King / Eric Baker/ Bruce Moore

Append with Student Records

6/4/2008 Colleen Egan Append with Business Intelligence

6/16/2008 Team / Eric Baker

Append with Final Team revisions for AS, CC, SF and FA

11/10/2008 Shelley Ruff Append with Non-Credit, Independent Distance Learning and AIMS (submitted by Debra Benton)

iii

Review/Approval History – Academic Structure

By Action Approved

Debra Benton Final Review Academic Structure Yes

Review/Approval History – Campus Community

By Action Approved

Steve Flaherty Final Review Campus Community Yes

Review/Approval History – Recruiting and Admissions

By Action Approved

Jean Lewis Final Review Recruiting and Admissions Yes

Review/Approval History – Financial Aid

By Action Approved

Jill Lallier Final Review Financial Aid Yes

Review/Approval History – Student Records

By Action Approved

Debra Benton Final Review Student Records Yes

Review/Approval History – Academic Advising

By Action Approved

Debra Benton Final Review Student Records Yes

Review/Approval History – Student Financials

By Action Approved

Kim Trout Final Review Student Financials Yes

iv

Table of Contents

Section 1 Fit/Gap Summary .................................................................................................................... 12

Section 2 Scope ...................................................................................................................................... 13

Section 3 Project Team........................................................................................................................... 14

Section 4 Academic Structure ................................................................................................................ 15

Installation Table .................................................................................................................................. 15

Tableset IDs/Set IDs/Table Set Control ............................................................................................... 15

Record Groups ..................................................................................................................................... 16

Business Unit / Business Unit Options Default .................................................................................... 16

Company .............................................................................................................................................. 17

Establishment ...................................................................................................................................... 18

Regulatory Region ............................................................................................................................... 18

Department Table ................................................................................................................................ 19

Holiday Schedule ................................................................................................................................. 20

Market Rates ........................................................................................................................................ 21

Academic Institution ............................................................................................................................. 21

Grading Scheme .................................................................................................................................. 22

Load/Level Rules ................................................................................................................................. 23

Campus ................................................................................................................................................ 25

Academic Career ................................................................................................................................. 25

Career Pointer Exceptions ................................................................................................................... 26

Degree Table ....................................................................................................................................... 26

Academic Group Table ........................................................................................................................ 27

Academic Organization Table .............................................................................................................. 27

Academic Program Table .................................................................................................................... 28

Academic Plan Table ........................................................................................................................... 28

Academic Sub-Plan Table ................................................................................................................... 29

Academic Subject Table ...................................................................................................................... 29

Field of Study Table ............................................................................................................................. 29

CIP Code Table ................................................................................................................................... 29

Reporting Codes - HEGIS Code Table ................................................................................................ 29

Term Values Table............................................................................................................................... 30

Term Setup - Term/Session Table ....................................................................................................... 30

Academic Calendar.............................................................................................................................. 31

Building Table ...................................................................................................................................... 31

Facility Table ........................................................................................................................................ 31

Room Characteristics Table ................................................................................................................ 31

Table Loading Sequence ..................................................................................................................... 32

Section 5 Campus Community ............................................................................................................... 34

The Person Record / National ID length .............................................................................................. 34

Campus Community Steering Committee ........................................................................................... 34

v

EmplID Length / Numbering Scheme .................................................................................................. 34

Data Mapping for Conversion .............................................................................................................. 35

Organization Table Build ..................................................................................................................... 35

Minimum Standards for Person Record Creation ................................................................................ 35

Identify any major systems that may be retained and will need student data feeds ........................... 36

Shared Tables with HR ........................................................................................................................ 36

Personal Information / Biographical ..................................................................................................... 42

Health Information................................................................................................................................ 44

Identification ......................................................................................................................................... 45

Participation ......................................................................................................................................... 48

Service Indicators / Holds .................................................................................................................... 49

Committees .......................................................................................................................................... 51

Row Level Security .............................................................................................................................. 52

3Cs – Communications, Checklists and Comments ............................................................................ 52

Administrative Functions ...................................................................................................................... 52

Communication Categories ................................................................................................................. 52

Communication Contexts ..................................................................................................................... 53

Standard Letters .................................................................................................................................. 53

3C Groups ............................................................................................................................................ 53

Communication Speed Keys ............................................................................................................... 53

Communication Management .............................................................................................................. 53

Checklist Table, Items, Function Items, Managing Checklists ............................................................ 54

Checklist Item Update .......................................................................................................................... 54

Comment, Categories, 3C Groups ...................................................................................................... 55

Comment Management ....................................................................................................................... 56

Communication Generation ................................................................................................................. 56

Mass Communication .......................................................................................................................... 56

Events 56

Event Type Table ................................................................................................................................. 57

Resource Code Table .......................................................................................................................... 57

Staff Code Table .................................................................................................................................. 57

Event Template .................................................................................................................................... 57

Meetings .............................................................................................................................................. 57

Overview of Organizations ................................................................................................................... 57

Identify Source Data ............................................................................................................................ 58

Conversion Issues ............................................................................................................................... 58

FERPA 59

3C Security .......................................................................................................................................... 60

Student Service Center ........................................................................................................................ 60

SEVIS 61


Section 6 Recruiting and Admissions ..................................................................................................... 66

vi

Setting up Prospects ............................................................................................................................ 66

Recruitment Territories ........................................................................................................................ 66

Referral Sources .................................................................................................................................. 66

Recruitment .......................................................................................................................................... 67

Prospect Record .................................................................................................................................. 67

Test Score Setup ................................................................................................................................. 69

Processing External Test Scores ......................................................................................................... 70

Undergraduate and Graduate Business Processes ............................................................................ 71

Com Business Process ........................................................................................................................ 72

Continuing Ed Business Process ......................................................................................................... 72

Transfer Business Process .................................................................................................................. 72

No Shows ............................................................................................................................................. 73

HS Students Taking College Courses ................................................................................................. 73

Distance Learning (Continuing Ed) ...................................................................................................... 74

Summer Transition Program ................................................................................................................ 74

Sixty Plus Program .............................................................................................................................. 74

Adding New Applications Manually ...................................................................................................... 74

Checklist Items ..................................................................................................................................... 76

Auto-Decision ....................................................................................................................................... 76

External Education ............................................................................................................................... 76

Test Results ......................................................................................................................................... 77

Basis of Admission............................................................................................................................... 77

Application Student Response ............................................................................................................. 77

Quick Admit / Quick Enroll ................................................................................................................... 77

Admitting Students ............................................................................................................................... 77

State Transfer Initiatives in OH ............................................................................................................ 79

Transfer Processing ............................................................................................................................. 80

Set up Transfer Credit Processing: ...................................................................................................... 80

Processing Transfer Credit .................................................................................................................. 80

Deleting a prospect/applicant record ................................................................................................... 81

Viewing Summary ................................................................................................................................ 81

Communication Generation ................................................................................................................. 82

Process Flow - Freshman and Transfer Process with OnBase ........................................................... 83


Section 7 Financial Aid ........................................................................................................................... 87

Aid Year ............................................................................................................................................... 87

Financial Aid Terms ............................................................................................................................. 87

Institutional Student Information Record (ISIR) Processing ................................................................ 88

Verification ........................................................................................................................................... 89

Student Budgets .................................................................................................................................. 90

Item Types/Fund Management ............................................................................................................ 91

Awarding/Mass Packaging .................................................................................................................. 91

vii

Authorization/Disbursement ................................................................................................................. 93

Assigning & Tracking Holds ................................................................................................................. 94

Pell Payment Processing ..................................................................................................................... 94

Loan Processing .................................................................................................................................. 95

Perkins 96

Satisfactory Academic Progress (SAP) ............................................................................................... 97

Return of Title IV Aid ............................................................................................................................ 97

Student Employment ........................................................................................................................... 98


Section 8 Student Records ................................................................................................................... 105

Review / Define Student Records Installation settings ...................................................................... 105

Define Class Notes ............................................................................................................................ 105

Define Global Notes ........................................................................................................................... 106

Define Course Attributes .................................................................................................................... 106

Define Exam Codes ........................................................................................................................... 107

Review Buildings................................................................................................................................ 107

Review Room Characteristics ............................................................................................................ 107

Define Facilities and Rooms .............................................................................................................. 107

Review Facility Components ............................................................................................................. 108

Review Facility Characteristics .......................................................................................................... 109

Designate Approved Instructor and Advisors .................................................................................... 109

Requirement Designation .................................................................................................................. 109

Set Up Unit Conversions ................................................................................................................... 109

Define Standard Meeting Patterns..................................................................................................... 110

Define Modes of Instruction ............................................................................................................... 110

Repeat Schemes and Repeat Codes ................................................................................................ 110

Define Repeat Rules .......................................................................................................................... 112

Set up Repeat Checking for Academic Careers ................................................................................ 113

Set up Repeat Checking for Academic Programs ............................................................................. 113

Define Course Catalog Data .............................................................................................................. 113

Define Course Offerings .................................................................................................................... 113

Define Course Components .............................................................................................................. 113

Create Course Equivalency Groups .................................................................................................. 114

View Course Catalog Summary Information ..................................................................................... 114

Print the Course Catalog ................................................................................................................... 114

Define Enrollment Course List ........................................................................................................... 115

Define Enrollment Requirements ....................................................................................................... 115

Define Enrollment Requirement Groups ............................................................................................ 116

View Enrollment Requisite Summary Information ............................................................................. 116

Process the Enrollment Advisement Report ...................................................................................... 116

Set up Attendance Tracking .............................................................................................................. 117

Define Academic Standing Action Codes .......................................................................................... 118

viii

Create Academic Standing Rules ...................................................................................................... 118

Link Academic Standing, Honors and Awards Rules to Academic Programs .................................. 121

Set up Honors and Awards ................................................................................................................ 121

Set up Special Grade Point Averages ............................................................................................... 122

Set up Milestones .............................................................................................................................. 122

Set up Extracurricular Activities ......................................................................................................... 122

Set up Student Groups ...................................................................................................................... 123

Set up Student Attributes ................................................................................................................... 123

Define Grading Schemes ................................................................................................................... 123

Define Grading Basis Exception Rules .............................................................................................. 126

Create Grade Rosters for a Single Class .......................................................................................... 127

Create Grade Rosters for Multiple Classes ....................................................................................... 128

Define Degrees .................................................................................................................................. 129

Attach Degrees to Academic Plans ................................................................................................... 129

Define Degree Honors ....................................................................................................................... 129

Transcript Levels................................................................................................................................ 129

Define Transcript Type Security ........................................................................................................ 130

Create Transcript Notes ..................................................................................................................... 130

Create Transcript Text ....................................................................................................................... 130

Review Transcript Print Areas ........................................................................................................... 131

Define Transcript Types ..................................................................................................................... 131

Schedule a New Class ....................................................................................................................... 131

Modify Scheduled Classes ................................................................................................................ 132

Modify Scheduled Class Meetings..................................................................................................... 133

View and Update Class Sections ....................................................................................................... 133

Roll Data from Course Catalog to the Schedule of Classes .............................................................. 133

Define Class Associations ................................................................................................................. 133

Define Class Permissions .................................................................................................................. 134

Create Combined Sections ................................................................................................................ 134

Schedule Examinations ..................................................................................................................... 135

Modify Course Events ........................................................................................................................ 135

View Instructor Schedules ................................................................................................................. 135

Search for an Available Facility Usage .............................................................................................. 135

View and Update Class Sections ....................................................................................................... 135

Search for Available Facility .............................................................................................................. 135

Search for Classes............................................................................................................................. 136

Print the Schedule of Classes Report ................................................................................................ 137

Copy Classes from one Term to Another .......................................................................................... 137

Understand Academic Program and Plan Activation ......................................................................... 138

Understand Program Action and Statuses ........................................................................................ 138

Understand Program Actions Where Future Enrollments Exist ........................................................ 139

Maintain Student Program Information .............................................................................................. 140

ix

Student Records – Part 3 .......................................................................................................................... 141

Non-Credit Unique Issues .................................................................................................................. 141

Independent and Distance Learning Programs ................................................................................. 143

College of Arts and Sciences AIMS Unique Issues ........................................................................... 149

Table Loading Sequence ................................................................................................................... 151

Section 9 Academic Advising ............................................................................................................... 154

Effective Dating in Advisement .......................................................................................................... 154

Academic Structure and Academic Advisement ................................................................................ 154

Requirement Terms ........................................................................................................................... 155

Capturing Graduation Requirements ................................................................................................. 155

Creating Course Lists ........................................................................................................................ 156

Establishing Requirements ................................................................................................................ 156

Establishing Requirement Groups ..................................................................................................... 157

Requirement Functionality ................................................................................................................. 157

Transfer Coursework ......................................................................................................................... 158

Course Share Sets............................................................................................................................. 158

Requirement Usage ........................................................................................................................... 159

Entity Groups ..................................................................................................................................... 159

Dynamic Conditions ........................................................................................................................... 159

Condition Processes .......................................................................................................................... 160

Course Substitution............................................................................................................................ 160

Authorize Student Exceptions ............................................................................................................ 160

Setting Up an Advisement Report ..................................................................................................... 161

Printing the Advisement Transcript/Degree Audit Report .................................................................. 162

In-Progress Credit .............................................................................................................................. 162

What-If Report .................................................................................................................................... 163

Course Applicability System (CAS) ................................................................................................... 164

Analysis Table .................................................................................................................................... 164

Documenting Institutional Rules ........................................................................................................ 164

Section 10 Student Financials ................................................................................................................ 166

General Student Financials Settings: SF Business Units ................................................................ 166

General Student Financials Settings: Account Types ....................................................................... 166

General Student Financials Settings: Item Types ............................................................................. 166

General Student Financials Settings: Item Type Tree ....................................................................... 167

General Student Financials Settings: Payment Application Rules .................................................... 167

General Student Financials Settings: Student Waiver/Permission Forms ........................................ 167

General Student Financials Settings: SF Term Default ................................................................... 168

Calculating Tuition, Fees, & Waivers: Due Date Calendars .............................................................. 168

Calculating Tuition, Fees, & Waivers: Adjustment Calendars ........................................................... 168

Calculating Tuition, Fees, & Waivers: Application & Deposit Fees ................................................... 169

Calculating Tuition, Fees, & Waivers: Criteria & Equations............................................................... 169

Calculating Tuition, Fees, & Waivers: Tuition Groups ....................................................................... 169

x

Calculating Tuition, Fees, & Waivers: Term Fees ............................................................................. 170

Calculating Tuition, Fees, & Waivers: Waivers .................................................................................. 170

Calculating Tuition, Fees, & Waivers: Course/Class Fees ................................................................ 170

Calculating Tuition, Fees, & Waivers: Optional Fees ........................................................................ 170

Calculating Tuition, Fees, & Waivers: Transaction Fees ................................................................... 171

Calculating Tuition, Fees, & Waivers: Tuition Calculation Controls .................................................. 171

Calculating Tuition, Fees, & Waivers: Processing Enrollment Cancellation...................................... 172

Student & Third Party Receipts: Online Payments & Cashiering .................................................. 175

Student & Third Party Receipts: Departmental Receipts................................................................... 176

Student & Third Party Receipts: Lockbox Payments ........................................................................ 176

Student & Third Party Receipts: Third Party Payments............................................................... 176

Student & Third Party Billing: Student Billing .............................................................................. 176

Student & Third Party Billing: Third Party Billing ..................................................................... 177

Student Payment Plans: Installment Payment Plans ........................................................ 177

Student Payment Plans: Payment Plan Late Fees ............................................................. 177

Third Party Contracts: Third Party Contracts ............................................................. 177

Third Party Contracts: Third Party Contract Rollover ...................................................... 178

Student Financials Interfaces ............................................................................................................ 179

Processing GL Accounting Entries .................................................................................................... 180

Student Financials Conversions ........................................................................................................ 180

Tax Reporting .................................................................................................................................... 180

Campus Community for SF ............................................................................................................... 181

Service Indicators for SF ................................................................................................................... 181

3C‘s for SF ......................................................................................................................................... 181

Self-Service for SF ............................................................................................................................. 181

Query/Reporting Tools for SF ............................................................................................................ 182

Security for SF ................................................................................................................................... 182

SF Integration Points with AD ............................................................................................................ 182

SF Integration Points with SR ............................................................................................................ 183

SF Integration Points with FA ............................................................................................................ 183

Table Loading Sequence ................................................................................................................... 184

Section 11 Portal ..................................................................................................................................... 190

General Considerations ..................................................................................................................... 191

Portal Requirements .......................................................................................................................... 191

IDMS Replacement ............................................................................................................................ 192

Section 12 Business Intelligence ............................................................................................................ 198

Business Intelligence Summary ......................................................................................................... 198

Current State ...................................................................................................................................... 198

Future Vision ...................................................................................................................................... 201

Approaches ........................................................................................................................................ 202

Architectural Approach 1 ................................................................................................................... 202

Architectural Approach 2 ................................................................................................................... 203

xi

Functional Approach .......................................................................................................................... 204

Functional Approach 1 ....................................................................................................................... 204

Functional Approach 2 ....................................................................................................................... 204

Section 13 Interfaces .............................................................................................................................. 206

Section 14 Modifications ......................................................................................................................... 212

Gap Descriptions ............................................................................................................................... 212

Gap Effort Estimates .......................................................................................................................... 224

Section 15 Conversion Issues identified during Fit/Gap ......................................................................... 230

Section 16 Appendices ........................................................................................................................... 234

18.1 Reporting ................................................................................................................................... 235

18.2 Support Document for Converting Holds ................................................................................... 236

18.3 Complete Table Loading Sequence .......................................................................................... 247

SCOPE

12

Section 1 Fit/Gap Summary This Fit/Gap Analysis represents a comprehensive review of the current business requirements for Student Administration at Ohio University. These business requirements were evaluated and compared to the delivered functionality of the PeopleSoft Campus Solutions modules. The results are presented in this analysis and grouped in the following categories:

Detailed Analysis –We describe the findings for each functional area and detail the anticipated Fit or Gap of the delivered PeopleSoft module with the existing business practices. If Gaps are identified, recommended solutions are presented in most cases. To facilitate a review of the Gaps they have been highlighted in RED.

Interfaces – This section details interfaces that will be needed to support the implementation. Interfaces, whether new or replacement for a legacy interface, are not considered a Gap unless they result in significant business change to accommodate an interface process. To facilitate a review of the new Interfaces they have been highlighted in GREEN within the detailed analysis.

Modifications – This section summarizes recommendations for areas where PeopleSoft needs to be modified to accommodate OHIO business processes and/or requirements.

Effort estimates were made for the modifications. These estimates are preliminary and were built on the following assumptions:

1. Resources assigned to the team are knowledgeable and experienced with the

PeopleSoft product and tools. 2. Sufficient training has been received on all suggested applications and tools. 3. The resources are dedicated full-time to the project effort. 4. Resources are knowledgeable about the legacy system and operations.

Conversion – This section discusses the legacy data and issues related to conversion. To facilitate a review of Conversion issues they have been highlighted in BLUE in the detailed analysis.

SCOPE

13

Section 2 Scope

Prototype 1 – Discovery Resulting Deliverables

Project Charter Sessions

Project Charter including Readiness Assessment

Project Team Kickoff Meeting

Preliminary Project Plan

Fit/Gap Schedule

Conversion Strategy

Interface Strategy

Reporting Strategy

Security Strategy

Project Management Controls

A shared vision for project goals, scope, roles and responsibilities and project strategies – Team Building

Project Team – Pre-Fit/Gap Training

Four day overview per module for:

Recruiting and Admissions

Student Records and Academic Advisement

Financial Aid

Student Financials

Fit/Gap Analysis Workshops, including technical and BI interviews

Fit/Gap Sessions

Fit/Gap Analysis Document

Revised scope if necessary

Readiness Assessment

BI Strategy

Detailed Project Plan


Deliverables Approval and Signoff Process

Discovery Prototype Acceptance Signoff for:

Project Charter

Fit/Gap Analysis Document


Presentation of Materials Presentation of Charter, Fit/Gap Document and Initial Project Plan to Project Executives and Team

Assistance with preparation of Board Update Documents for May 31.

PROJECT TEAM

14

Section 3 Project Team

Ohio University Core Team

Project Manager - Technical Shelley Ruff

Project Manager - Functional Steve Flaherty

Recruiting and Admissions Lead

Jean Lewis

Student Financials Lead Kim Trout

Financial Aid Lead Jill Lallier

Student Records Lead Debra Benton

CIBER Active Participants

Vice President Henry Tran

Program Manager Bruce Moore

Project Manager Eric Baker

Technical Consultant Mark Sanderson

Consultant (Academic Structure, Student Records)

Leslie Roe

Consultant (Campus Community, Admissions)

Dewey Holleman

Consultant (Financial Aid) Julie Simpson

Consultant (Academic Advising)

Susan Kretz

Consultant (Business Intelligence)

Colleen Egan

Consultant (Student Financials)

Reed Kofoed

Consultant (Portal) Chris Couture

Consultant Byron Gibbs

Consultant Micah Marin

Technical Consultant Jesus Chanlatte

Security Consultant Carolyn Ryll

ACADEMIC STRUCTURE

15

Section 4 Academic Structure

CIBER Leads: Leslie Roe and Byron Gibbs OHIO Leads: Steve Flaherty, Shelley Ruff, Debra Benton, Kim Trout, Jean Lewis, Jill Lallier Fit/Gap Sessions were held from March 17 to 20. Faculty and Staff attended an overview on March 17 and a validation session on March 20.

Installation Table FIT: YES

This component is used to specify which PS applications are installed at OHIO.

Products: Select which PS applications and application parameters are installed on the system. Ensure that the settings on this page are accurate before using the Campus Solutions system.

Product Specific: Set up product-specific values for Campus Solutions.

Last ID Assigned: Set up ID assignment numbers for Campus Solutions.

CIBER Comments:

CONVERSION: Once the production environment is established, the Last ID Assigned will need to be reset when conversion occurs.

CIBER checked the following products in the Sandbox environment: Student Administration, Campus Self-Service

Tableset IDs/Set IDs/Table Set Control FIT: YES

You define tableset IDs for the purpose of administering certain control tables, such as the Department table, in a decentralized way. When you define a tableset ID, consider how to categorize a subset of the control table data. If you want to use multiple tableset IDs to set up tableset sharing for the first business unit that you create—before you have created any additional business units—create tableset IDs on the TableSetID page before defining the business unit.

You can create tableset IDs as you set up the business units. If the default setID that you enter creates a new business unit that does not exist, the system automatically creates it; however, you can also create tableset IDs independent of business unit creation by using the TableSetID page.

ACADEMIC STRUCTURE

16

To define tableset sharing for the organization, you complete the steps for each of these tasks.

1. Set up business units.

2. Define record groups. You can add new record groups.

3. Define tableset IDs for the organization, to reflect the organization‘s structure. This step is sometimes optional. It is required; however, for Contributor Relations if a setID matching the Contributor Relations business unit does not exist.

4. Update all of the tableset record group controls.

To link tableset sharing and system defaults to permission lists or business units, you:

1. Set up Primary Permission List Preference Defaulting options.

2. (Optional) Set up all Business Unit HR Defaulting (business unit human resources defaulting) options.

CIBER Comments:

CIBER created the SETID ―OHIOU‖ in the Sandbox environment. o SetID: OHIOU o Description: Ohio University o Short Description: OHIO UNIV o Comments: (Left blank)

The team discussed whether the description should be ―The Ohio University‖ or ―Ohio University.‖ After discussion the issue was sent to David Descutner for resolution. David Descutner decided we should use ―The Ohio University.‖ Note that the diploma uses ―The Ohio University‖ but most other documents use only ―Ohio University.‖

Record Groups FIT: YES

In the record group table, group the record definitions for the tables that you want to share, as well as any dependent record definitions. If you are adding a table to a PS application, an appropriate record group may already be defined. If you are adding new functionality, you may need to add a new record group for the tables that you define.

Record group definitions and the assignment of the individual tables and views to specific groups are provided to ensure complete and accurate tableset sharing within each functional area. You should NOT change these record group assignments.

CIBER Comments:

CIBER used delivered PS values from this setup in the Sandbox.

Business Unit / Business Unit Options Default

FIT: YES

ACADEMIC STRUCTURE

17

When you define a business unit, you can specify that the system establish default tableset IDs for the business unit by using the Default Record Group SetIDs group box. This indicates to the system which tableset ID is associated with the business unit. The tableset ID determines the preliminary tableset sharing for the business unit by associating the business unit with a record group.

For optimal system performance business units must be five characters. Significant performance degradation occurs if the business units have fewer than five characters.

CIBER Comments:

The OHIO Team created this Business Unit in the Sandbox environment: o Business Unit: OHIOU o Status: Active o Description: Ohio University o Short Description: OHIO UNIV

OHIO Team created Business Unit Options Default record for OHIOU in the Sandbox environment.

o SetID: OHIOU o Company: OU Ohio University o Country: USA United States o To Currency: USD US Dollar

Company FIT: YES

Used to define and describe companies. For a single-company environment, you set up this table only once; for multiple-company environments, you set up a company code for each company.

CIBER Comments:

OHIO Team created this Company in the Sandbox environment. Company Location page: o Company: OU o Effective Date: 01/01/1901 o Status: Active o Description: Ohio University o Short Description: OHIO UNIV o Location Set ID: OHIOU o Location: ATHENS o Default SetID OHIOU o Country: USA o Address: Athens, OH 45701 Default Settings page:

ACADEMIC STRUCTURE

18

o Regulatory Region: USA o Currency Code: USD US Dollar

Establishment FIT: YES

Use the establishment component to define distinct physical places of business (establishments) within your company, to enter address information, and to enter regulatory reporting information. In PS Human Resources, you define establishments that are consistent with the regulatory requirements of your business operations.

CIBER Comments:

OHIO Team created Establishment in the Sandbox environment. Establish Address page: o Establishment ID: OHIOU o Effective Date: 01/01/1901 o Status: Active o Description: Ohio University o Short Description: OHIO UNIV o Reg Region: USA o Headquarters Unit: checked the checkbox o Company: OU o Country: USA o Address: Athens, OH 45701 Phone Numbers page: o Phone Type: MAIN o Phone: 740/593-1000

Regulatory Region FIT: YES

Define or review regulatory region descriptions and security access. The system is delivered with regulatory regions predefined for Canada, the United States, Canadian provinces, and other areas. Use this page to set up additional regulatory regions.

CIBER Comments:

CIBER recommends using ―USA‖ (the delivered value).

ACADEMIC STRUCTURE

19

Number: Location FIT: YES

Location is a separate physical administrative unit associated within an institution. Uses the Institution‘s course catalog. One transcript for all campuses. Students are assigned to a home campus. An institution may have one or many campuses. Campuses may have one or many locations where classes are taught. Campuses all use one course catalog. Locations as they pertain to international and high school locations will be built as separate locations. One location will be defined for online courses. Capture highest level of detail for all locations and make a determination to what campus to tie to. Location: where the instruction takes place. Each campus will have a location of online. CIBER Comments:

CIBER configured the following values in the Sandbox: o SetID: OHIOU o Location Code: ATHENS o Effective Date: 01/01/1901 o Status: Active o Description: Ohio University – Athens o Short Description: OU-Athens o Country: USA o Address: Athens, OH 45701 o o SetID: OHIOU o Location Code: THE PLAINS o Effective Date: 01/01/1901 o Status: Active o Description: The Plains Elementary School o Short Description: The Plains Elementary School o Country: USA

OHIO must consider the following questions during implementation: What is the best practice for a class that is delivered from one location to many other locations, i.e. Ohio University Learning Network (OULN)? Can a single class be set to identify the instructor‘s campus and location, but also permit students at other locations to be identified appropriately? If separate sections/classes are created what is the impact for BlackBoard, class rosters, and grade rosters?

Department Table FIT: YES

The department table is used to define the internal business organizations/offices within the institution or departments with a specific organization. For instance, HR, Financial Aid,

ACADEMIC STRUCTURE

20

Admissions, etc. These departments can be used with Service Indicator Reasons and Organization Communications.

CIBER Comments:

The OHIO team built the following Department: o SetID: OHIOU o Department: FINAID o Effective Date: 01/01/1901 o Status: Active o Description: Financial Aid Office o Short Description: Fin Aid o Location SetID: OHIOU o Location: ATHENS o Company: OU

CONVERSION: Departments may need to include Parking and other internal organizations within the University to populate the interfaces with Student Financials.

Holiday Schedule FIT: YES

Use this component to designate holidays for each year used in processing.

CIBER Comments:

The OHIO Team created the following Holiday Schedule and Holidays in the Sandbox environment.

o Holiday Schedule: OHIOU o Effective Date: 01/01/1901 o Status: Active o Description: Ohio University Holiday Schedule o Short Description: OU Holiday o Holiday: 11/27/2008 Holiday: 12/25/2008 o Description: Thanksgiving Day Description: Christmas

Day o Number of Hours: 24.00 Number of Hours: 24.00 o Holiday Type: Standard Holiday Type: Standard

The first year that OHIO sets up for the holiday schedule should be the go-live year that OHIO will be using PS.

A separate Holiday schedule is able to be scheduled for various careers and regional campuses. However, the College of Osteopathic Medicine and the regional campuses operate under the same holiday schedule.

ACADEMIC STRUCTURE

21

Market Rates FIT: YES

Maintain and view market rates. The fields available on the page vary depending on the rate category. The data you enter on this page is stored in the RT_RATE_TBL table, which is the common repository for all types of market rates including exchange rates and interest rates.

This page is not editable if all of the following are true - the rate is triangulated, the primary visual rate is the cross rate, and Allow Override option is clear for the exchange rate‘s quotation method on the Currency Quotation Method page.

CIBER Comments:

CIBER recommends using the delivered values from PS.

Any translate value that OHIO wishes not to display in a drop-down or search, will need to be inactivated. Page views are controlled by security.

Academic Institution FIT: YES

An Academic Institution is a separate university or college that operates independently. It maintains own course catalog and timetable/schedule, and is recognized as separate entity for Financial Aid purposes. Each Academic Institution maintains separate academic statistics and it‘s course work appears on a single transcript, and in unique reports to Department of Education (DOE). CIBER Comments:

CIBER recommends that OHIO use all 5 characters for the Academic Institution code. The team decided on the single institution code of OHIOU. Setup will need to be completed once other setup tables are established. The following setup values were established in Sandbox environment:

o Academic Institution: OHIOU o Eff. Date: 01/01/1901 o Status: Active o Residency Required: Checked o Description: Ohio University o Formal Desc: Ohio University o Country: USA o Address: Athens, OH 45701

The Process on Enrollment field may be set to No or Yes. Repeat checking is used at OHIO when processing enrollment and when grades are posted.

If process is to be run during enrollment, will need to add the repeat checking process to the load testing scenarios.

ACADEMIC STRUCTURE

22

The setup under Academic Structure is used for enrollment/records reporting to the Canadian Government. Documentation setup information is in PeopleBooks-Student Financials for the setup of tax reporting for Canadian students.

Residency Required checkbox should be checked in order to require a residency value for the student when he/she is term activated. Verified the admissions business process will remain the same and a report will need to be created to identify students with missing residency information so that residency values may be entered in advance of term activation.

The College of Osteopathic Medicine processes its own FAFSA using a separate federal school code but in processing aid they use the OHIO main campus code. The regional campuses may use either the main campus code or regional campus codes. The regional campuses do not do any reporting. The main campus Office of Student Financial Aid and Scholarships currently processes the FISAP for main campus and regional campus students. College of Osteopathic Medicine FISAP reporting will most likely be done by the Office of Student Financial Aid and Scholarships.

Grading Scheme FIT: Undecided

Creation of the grades that will be assigned as a result of enrollment in courses. Each course must have a grade basis. All grades that could be awarded must be included. CIBER Comments:

OHIO uses the following values for grading: A, A-, B+, B, B-, C+, C, C-, D+, D, D-, F,W, PR (Progress), CR (Credit), WP (Withdrawn Passing), WF (Withdrawn Failing), FN (Failure Never Attended), FS (Failure, Stopped Attending), AU (Audit), I (Incomplete), I* (Administrative Incomplete – Inactive), NC (No Credit), S (Satisfactory – Inactive), and P (Pass). Note: AU and P are not assigned by the instructor

Ohio University currently has seven grading systems 01 – Eligible 1 A-F, W, WP, WF. FN, FS, AU, I and P 02 – Eligible 2 A-F, PR, W, WP, WF, FN, FS, AU, I, and P 03 – Eligible 3 A-F, PR, W, WP, WF, FN, FS, AU, I, and P 04 – Eligible 4 A-F, PR, W, WP, WF, FN, FS, AU, I, and P 05 – Eligible 5 CR, PR, F 06 – Eligible 6 CR, F 07 – Eligible 7 CR, NC,

The grading schemes are not career specific. The grading system is assigned to course by the University Curriculum Council, which determines the eligible grades. Regardless

ACADEMIC STRUCTURE

23

of grading system, a student can take course for Audit or Pass/Fail. When the student is approved to take the course pass/fail, the instructor does not know the student is taking the class for P/F but assigns a regular grade that will convert to a P or may remain an F based on the original grade assigned by the instructor. The College of Osteopathic Medicine typically does not assign letter grades.

When an FS grade is assigned, a last date of attendance must be entered by the faculty member assigning the FS grade.

In the current transfer credit grading basis for Admissions, courses that have various grade basis we can associate multiple grading basis AUD & GRD to a course or a class- SR Fit/Gap.

If Instructor does not assign grade, PS will not default to a grade. This was identified as a gap during Student Records discussions.

Load/Level Rules FIT: YES

Load/Level Rules establish the limits for (academic) level such as freshman, sophomore, junior, senior and for load, e.g., full time, half time, etc. The load/level rules for National Student Clearinghouse and Direct Loan for financial aid are setup here. CIBER Comments:

Academic Load Requirements at OHIO o At the undergraduate level a student is considered full-time if registered for 11 or

more hours excluding classes registered for Audit. Half-time is 6.0 to 10.99 and less than half-time is 0.01 to 5.99.

o At the graduate level a student is considered full-time if registered for 9 or more hours. Half-time is 5.0 to 8.99 and less than half-time is 0.01 to 4.99.

o Athletes, veterans, financial aid recipients, etc. are required to be registered in at least 12 hours.

o Some scholarships and other student groups require minimum hours. o Some students are reported as full-time if they are in full-time academic study but

not necessarily registered in the credit hours that would automatically report them as full-time. For example, students completing thesis or dissertation are reported as full-time even though they may be registered in only 1 credit hour.

The following setup values were configured in the Sandbox: Academic Level Undergraduate: U 01 Freshman 0.00 – 44.99 U 02 Sophomore 45.00 – 89.99 U 03 Junior 90.00 – 134.99 U 04 Senior 135.00 – 999.99 Graduate:

ACADEMIC STRUCTURE

24

G 01 POST BAC <51 GRADUATE POST BAC/NON-DEG <51 G 02 POST BAC 51> GRADUATE POST BAC/NON-DEG 51> G 03 MASTERS <51 GRADUATE MASTERS <51 G 04 MASTERS 51> GRADUATE MASTERS 51> G 05 PHD <51 GRADUATE PHD <51 G 06 PHD 51> GRADUATE PHD 51> Medical M 01 PHASE I MEDICAL, PHASE I M 02 PHASE II MEDICAL, PHASE II M 03 PHASE III MEDICAL, PHASE III M 04 PHASE IV MEDICAL, PHASE IV Translate Values for Academic Level – Added the following values effective dated 01/01/1901 U 01 Freshman U 02 Sophomore U 03 Junior U 04 Senior G 01 Grad PBac/NonDeg <51 G 02 Grad PBac/NonDeg >51 G 03 Grad Masters <51 G 04 Grad Masters >51 G 05 Grad PhD <51 G 06 Grad PhD >51 M 01 Medical Phase 1 M 02 Medical Phase 2 M 03 Medical Phase 3 M 04 Medical Phase 4

A PS Query needs to be written to identify students within specified student groups who are enrolled less than full time. Then those student‘s Enrollment Limits will be manually set to the required minimum hours.

Ohio University will need to make minor modification to Academic Level Translates to reflect various Graduate levels. Translate value changes are not considered gaps. These were modeled in the sandbox under Academic Institution of OHIOU for MASTR (Masters), MED (Medical), PBACC (Graduate Post Bacc/Non Degree), PHD (Graduate PhD) and UGRD (Undergraduate).

Note: For Audit and OPIE (Ohio Program of Intensive English) courses - If courses are not counted toward academic progress, they will not be counted toward financial aid.

Athletes, veterans, financial aid recipients, etc. are required to be registered for at least 12 hours.

Financial Aid Recipients - FA Eligibility is for any hours enrolled. If 12 hours is considered full-time, then on the Academic Load Table, the Financial Aid Load for 12 units would have to be set to be full-time.

ACADEMIC STRUCTURE

25

Athletes and Veterans – Students can be assigned to a Student Group; a query can be written to check those individuals and their enrolled hours and list any student that is not enrolled full-time. Then their individual Enrollment Limit record can be set to the minimum required.

For Financial Aid, the identified students would have to report as enrolled, but for those athletic aid funds or veterans benefits, they can set those disbursement rules to not disburse unless they are in 12 hours of courses.

Some scholarships and other student groups require minimum hours. These can be set up on the disbursement rules by item type (fund ID in Sigma SAM) so that to disburse those funds the student must be in defined amount of 12 hours.

Some students are reported as full-time if they are in full-time academic study but not necessarily registered in the credit hours that would automatically report them as full-time. For example, students completing thesis or dissertation are reported as full-time even though they may be registered in only one credit hour. For these students, their Academic Load can be adjusted on their Term Activation record under the Student Term Information component.

Campus FIT: YES

A Campus is a separate physical administrative unit associated within an institution. It uses the Institution‘s course catalog, and there is one transcript for all campuses at an institution. Students are assigned to a home campus. An institution may have one or many campuses. Campuses may have one or many locations where classes are taught. CIBER Comments:

These values were set up in the Sandbox: o Athens, Chillicothe, Eastern, Lancaster, Southern and Zanesville o Campus: ATHN 4 digit codes from legacy used o Description: Athens o Short Description: ATHENS o Checkbox selected for: Use SR Class Schedule Facility Conflict Checking

Academic Career FIT: YES

The Academic Career represents a student‘s academic work with one set of academic statistics. Single rule of handling repeated course work. Common term structure (e.g., quarter or semester). Usually a common set of valid grades and grade points. People can be in more than one career. Repeat rules can be set at the career level. CIBER Comments:

OHIO‘s values include: Undergraduate, Graduate, Medical, Non-Credit o Non Credit – used for non credit course of study that can possibly be used to

earn CEU credits.

ACADEMIC STRUCTURE

26

o Students can earn a certificate. A non-credit transcript will need to be produced. Non-credit coursework should not appear on an official registrar transcript.

OHIO can define where to edit the Advisor on page 2 of the Academic Career. With respect to Instructor/Advisor vs. Personal data, OHIO currently uses a feed from Ad Astra tied to the class section. IR will use PS Instructor Advisor/Personal Data as the data source for IPEDS. Data entered in Ad Astra will need to be loaded into PS and PS will not store ―official‖ data for reporting purposes.

OHIO will need to discuss whether to manage administration of Instructors in PS and be able to pass that information to HR.

Career Pointer Exceptions FIT: NO

Use this component to define rules that allow further refinement of the career pointers setup under academic career. These rules are validated in the enrollment process when students select and attempt to enroll in class sections. Rules can be written using Academic Group, Subject, and Catalog Number. The user can select Yes, No, or Permission under Allow Enrollment for each rule and can assign an alternate grading basis for each rule. These rules take precedence over the Career Pointers that are setup at the career level when validating class section choices during enrollment. CIBER Comments:

OHIO allows students in the MED career to take courses in any career. Undergraduate students would be able to take graduate courses only if they are in Honors Tutorial College (currently handled through prerequisite process), recognized departmental honors status (currently handled with Permission), Senior for Graduate Credit (currently handled with Permission), and Early Admit to Graduate School (currently handled with Permission). GRAD students may register for any Undergraduate course and some medical courses (currently handled with Permission).

For Graduate Appointments/Waivers, only graduate hours will count toward full-time requirement for waiver without approval by the appropriate party.

GAP – In PS configuration, if at the Undergraduate Academic Career you configure course career of Graduate to allow enrollment with permission, then undergraduate students not participating in one of the approved programs could mistakenly be registered in a graduate course. Options for resolution include:

o Develop a query to find students who have incorrectly enrolled and correct their records.

Degree Table FIT: NO

A degree is anything OHIO offers and awards internally or anything OHIO wants to track from an external source (such as a high school diploma). Degrees are mapped to plans. Degree setup should include all degrees, diplomas, certificates, and certifications. CIBER Comments:

ACADEMIC STRUCTURE

27

GAP: The length of the Formal Description field is only 50 characters. OHIO has degree names longer than 50 characters. Options for resolution include:

o Put the first part of the degree name in the Description field and the rest in the Formal Description field.

o Add a longer Degree Description. This is simple to store in the setup table so that it can be printed on reports. If that is the only need, the estimated effort for resolution is 8 hours. If the field needs to be displayed internally, this could be considerably longer depending on the number of pages where it must be displayed.

Academic Group Table FIT: YES

Academic Groups are the highest level academic entity within the institution. Academic Groups own Programs and Subjects. Typically are academic colleges within the institution. Establish course level rules and define class meeting patterns by Academic Group. Security can be set at group level. CIBER Comments:

OHIO has defined colleges, units that confer degrees, and non-credit as Academic Groups. These include:

o Non - Credit o College of Arts & Sciences o College of Business o Scripps College of Communication o College of Education o College of Engineering o College of Fine Arts o Graduate o College of Health and Human Services o Honors Tutorial College o Center for International Studies o College of Osteopathic Medicine o Regional Higher Education o University College

Academic Organization Table FIT: YES

This component is used to represent the organizational structure for courses. Academic subjects are linked at this level. Academic Organizations own plans and courses. Organizations may also be tied to finances through shared ownership of courses/classes through course and class fees. Security for plans, subjects, courses, and class schedule. CIBER Comments:

ACADEMIC STRUCTURE

28

OHIO will include current OHIOU, academic departments, schools, and any unit that offers a course, e.g. College of Arts and Sciences.

During the implementation OHIO will need to compare the current SIS department/school list with Oracle Financials academic organizations (these may be tagged as function of ―instruction‖ as code ―0001.‖)

Academic Program Table FIT: YES

The Academic Program is the entity to which a student applies and to which he/she is admitted. At the undergraduate level, typically the academic college (College of Business). Uses a common set of rules. Financial Aid input is critical for financial aid eligiblity (programs eligible for FA) and primacy rules. CIBER Comments:

Example Programs at OHIO would be College of Fine Arts Undergraduate, College of Fine Arts Graduate, College of Fine Arts Undergraduate Non-Degree, College of Fine Arts Graduate Non-Degree. Example plans under the Program of College of Fine Arts would be Art History (B.A.) and Art History (B.F.A.).

Due to each college having non-degree programs at both the undergraduate and graduate level, OHIO will need to establish an academic program for both the degree-seeking and non-degree programs at each level. It is at the program level where it is indicated if students are eligible for financial aid by checking Financial Aid Eligible.

Academic Plan Table FIT: YES

This component is used to define the student‘s area of study - typically a major, minor, or specialization. Linked to awarding of a single degree. All students must have an academic plan, even if undeclared. Taxonomy allows link to Field of Study, CIP or HEGIS codes. Students can have multiple plans. Plans can be linked to Programs or Careers. CIBER Comments:

OHIO currently has active status, phase out status, and inactive status. The Last Admit Term field may not accomplish its intended use. OHIO does not re-admit or discontinue students, so if a plan is in-activated when the student leaves then returns, the plan must be reactivated to graduate the student.

OHIO will use CIP & HEGIS codes on Plan table.

Academic Organization Ownership – Allows for multiple owners with one being designated as primary. A percentage should be designated for each owner.

ACADEMIC STRUCTURE

29

Academic Sub-Plan Table FIT: YES

This represents an area of specialization linked to a specific Academic Plan. (All students who have selected the academic plan of art must complete the sub-plan of Art History.) Concentration, specialization, or track within a major/minor or certificate program. Once linked to a plan it is required of all students enrolled in the plan unless specifically overridden for the student by an authorized staff member. CIBER Comments:

OHIO will decide whether to use the delivered functionality to identify concentrations and tracks within majors.

CONVERSION: A question was raised if OHIO decides to retain DARS, how will the Plans and Sub-plans be translated to DARS for processing the appropriate degree requirements? There is a company that can supply an interface. They do not have it written yet but should by the time this project goes live. Interface Management Services in Claremont, CA is working with CIBER at UT Dallas on developing this interface. They can provide a resource to implement this at OHIO.

Academic Subject Table FIT: YES

This represents a specific area of instruction within an Academic Group. Course designators (up to 8 characters). ENGL for English, MATH for Mathematics, ECON for Economics are examples of Academic Subjects.

Field of Study Table FIT: YES

Field of Studey is linked to the Academic Plan or subject and can be used for reporting.

CIP Code Table FIT: YES

CIP ( Classification of Instructional Programs) is a national standard, delivered set of curriculum codes. The purpose of the CIP code is to provide a taxonomic scheme that will support the accurate tracking, assessment, and reporting of fields of study and program completions activity.

Reporting Codes - HEGIS Code Table FIT: YES

HEGIS (Higher Education General Information Survey) is a national standard, delivered set of curriculum codes. HEGIS Series was designed to provide comprehensive information on various aspects of postsecondary education in the United States and its territories (American Samoa, Guam, Puerto Rico, the Virgin Islands, and the Marshall Islands) and Department of

ACADEMIC STRUCTURE

30

Defense schools outside the United States. Data are available for both public and private two-year and four-year institutions. There are eight components: Earned Degrees/Completions, Employees, Finance, Residence and Migration, Salaries, Fall Enrollment, Institutional Characteristics, and Libraries.

Term Values Table FIT: YES

High level designation of terms during which classes can be offered and academic processing can occur. Term code = 4 numeric characters; Long Description = 30 characters; Short Description = 10 characters. Term value description is displayed in Student Self-Service. The University can determine the time period (by date range) during which a term may be displayed in Self-Service. CIBER Comments:

CONVERSION: OHIO discussed using YYTT 0910 Fall 2008-2009 but decided against it since a different schema would need to be developed for conversion terms.

OHIO discussed using YYMM 0908 Fall 2008-2009, 0812 Winter Intersession but decided against it since a different schema would need to be developed for conversion terms.

A possibility would be: XYYT where X represents the century (0=1800s, 1=1900s, 2=2000s), YY represents the last two digits of the second year of the academic year, T represents the term code. 1,3,5,7,9 for terms 1-Fall Quarter, 3- Winter Intersession, 5-Winter Quarter, 7-Spring Quarter, 9- Summer Quarter. Thus 2091= Fall 2008-2009.

Need further discussion regarding what processing will need to occur for winter intersession if it is its own term, e.g. do we process probation at the end of winter intersession?

Term Setup - Term/Session Table FIT: YES

A term is an administrative time period for which students are billed, financial aid maybe processed, and academic statistics can accumulate. Terms may have one or many sessions. Different careers within an Institution can have totally different Academic Term structures. Sessions are time periods within a term used for scheduling purposes. Session start and end dates must fall within term dates. Classes are offered for a specific term and session. Class enrollment is controlled by a session. Special sessions are defined for open entry/exit or non-standard class schedules. CIBER Comments:

The MED school 1st & 2nd year students start at different times within the Term.

During the Fit/Gap, OHIO asked, will the Facility Assignment Run Date field interface with Ad Astra? This was covered in Records Fit/Gap. We concluded that OHIO would use the run date and they will run the assignment process in Ad Astra.

Another question was, ―Do session start and end dates have to fall within a term?‖ Session dates can fall before, during or after a term.

ACADEMIC STRUCTURE

31

Academic Calendar FIT: YES

The academic calendar contains control dates for many system processes (e.g. withdrawal and drop deadlines). These dates are used by student enrollment, transcripts, degree posting, statistical reports. Define standard academic calendars for fixed terms and sessions. Define calendars by Academic Careers. CIBER Comments:

Enrollment Request Search- OHIO wants to make sure date and time stamp appear on the record. The current OHIO system retains only the date stamp and not the time stamp.

OHIO will not use Drop w/ Greater Penalty because current business process is for the Instructor to add the P/F grade option to the Withdrawal.

Building Table FIT: YES

Define all campus buildings that you might use in class and event scheduling. Building codes that you create here are prompt values on the Facility Table page.

Facility Table FIT: YES

The facility table defines facilities (a.k.a. Rooms) and facility components. Use this component to link components of facilities to parent facilities.

As an example, you might want to define Angel Hall Room 125, and its components, Angel 125A, 125B, and 125C. Components cannot be linked to parent facilities on the Facility Component page unless both the parent facility and the facility components are defined on the Facility Table page.

Room Characteristics Table FIT: YES

Define room characteristics, such as types of seating and resources that are available. You attach room characteristics to facilities on the Facility Characteristic page and you can use them when you define courses, schedule classes, and plan events. The numeric room characteristic codes are from 01 to 96. Codes 01 – 21 are delivered values from PS.

01 Air Conditioning

02 Heater

03 Podium

04 White Board

05 Overhead Projector

06 Television

ACADEMIC STRUCTURE

32

07 Network Link

08 Fixed Tier Seating

09 Theater Seats

10 Closed Circuit TV Studio

11 Computer

12 Window

13 Amplified Sound System

14 Satellite Link

15 Biology Laboratory

16 Chemistry Lab

17 Computer Technology Lab

18 Culinary Lab

19 Aviation Maintenance Lab

20 Medical Laboratory

21 Practicum Interview Room

Table Loading Sequence

Setup Task Description

Academic Institution Table

Define default and set up values for academic institutions.

Term Values Table

Define the term values and their descriptions.

Campus Table

Define campus values.

Academic Career Table

Define default and set up values for academic careers.

Academic Group Table

Define course defaults, catalog levels and meeting patterns for academic groups.

Time Period Table

Define time periods or critical points in time for each academic career.

Academic Organization Table

Create a listing of all academic organizations defined in the system.

Academic Subject Table

Create subject areas and define taxonomy and workload values.

Term/Session Table

Define terms, sessions within terms, and session time periods.

Academic Calendar

Define cancel, withdrawal, and drop deadlines along with other term and session landmark dates.

Academic Program

Define default and set up values for academic programs.

ACADEMIC STRUCTURE

33

Table

Academic Plan Table

Create academic plans, and define plan related information for transcripts and diplomas.

Academic SubPlan Table

Create academic subplans as well as define taxonomy and descriptions for transcripts and diploma.

CAMPUS COMMUNITY

34

Section 5 Campus Community

CIBER Leads: Dewey Holleman and Micah Marin OU Leads: Steve Flaherty, Shelley Ruff, Debra Benton, Kim Trout, Jean Lewis, Jill Lallier Fit/Gap Sessions were held from March 31 to April 3. Faculty and Staff attended an Overview on March 31 and a wrap up on April 3.

The Person Record / National ID length FIT: YES

When there is no SSN, the PS system gives all 9's. When record is saved, an up to 11 characters ID is assigned; (can use search/match logic to "link" Oracle Data Privacy Shield (ODPS) and PS). SSN can be masked if necessary. OHIO may need to strip all 9's in order to make the functionality work — University is using ODPS to store PID in secure environment to only be viewed when absolutely necessary. OHIO is currently looking at how to store information in ―lock down‖ (visitors on campus are part of the original "guest management" [i.e. parking and library] that used "fake" SSNs for identifiers--OHIO is not intending to store "fake" information in a vault). OHIO intends to minimize the use and display of SSN‘s. Additionally, there is an ID management system that will overarch system for IDs/SSNs.

Campus Community Steering Committee FIT: N/A

There is currently a pre-implementation team that consists of 2 project managers (functional and technical) and 4 functional leads. There needs to be a cross-representation from the whole community.

EmplID Length / Numbering Scheme FIT: YES

PS allows 11 characters--maximize this capacity; consideration for student ID needs to be in collaboration for the ID Management project. Current OHIO ID length is 6 (employee), and 10 (for student-with a leading P). There is a larger discussion around ID management that is taking place on campus. The state of Ohio has also suggested that it may issue a state ‗federated‘ ID.

CAMPUS COMMUNITY

35

Data Mapping for Conversion FIT: N/A

Establish relationship with Oracle HRMS/PS Campus Community so as to not duplicate individuals. There should be a shared relationship with Oracle HRMS and PS Campus Community databases. Integration points need to be finalized by the Campus Community Steering Committee. There are shared tables between Campus Solutions and HRMS. The final decisions on values populating the shared tables need to be agreed upon by both HR and Campus Solutions representatives.

Organization Table Build FIT: YES

There is a need to associate applicant with the myriad of institutions to which they attended. Organization table can hold HS, colleges, and international schools, vendors and other community agencies with whom OHIO does business. Campus Solutions is delivered with an ATP load process that will load College Board list of High Schools and Colleges. The ATP (American Testing Program) code is also referred to commonly as the CEEB code/ College Board code/ the high school code. The ATP code, for high schools, is the same code as the ACT code. The ATP code is different from the ACT for colleges and Universities. Conversion Issue - table needs further review so that codes/names/info loaded into PS is "clean" data. Student Financials will provide a list of current Vendors to be built into Organization Table. OHIO wants unique institutions in the table. Currently, there are duplicates and triplicates. Other organizations such as vendors and community organizations may be added to the organization table. Recruitment Plus relies on College Board as the data sources for organizations. OHIO has a look up table for the admissions office and the source file is CollegeBoard.

Minimum Standards for Person Record Creation

FIT: N/A

There is a need to decide on minimum standards for person record creation; qualifying data is needed to differentiate between individuals. There are several entry points within the OHIO system that will create person records. The Campus Community Steering Committee, or like authority, will need to come up with what is required when a person is created (minimal level of needed information). It is advised to not spend programming effort on custom load process unless there are more than 500 records. The file parser functionality in Campus Community can be used to load data and update tables directly in Campus Solutions.

CAMPUS COMMUNITY

36

Identify any major systems that may be retained and will need student data feeds

FIT: YES

There is a need to identify all major systems from which information is fed into PS (i.e. Recruitment Plus--a connection is needed to be able to send applicant data to Recruitment Plus from PS). A review will take place to determine whether fsaAtlas or PS Solution is used. We must identify every single system on campus and determine whether it needs continued support. We will then assess what interfaces are needed (feed and download). It is important to note that the technical resources to make this work can be significant, and must be imbedded into the project plan and budget. OHIO is piloting a guest management system with an ID management company. If utilized, OHIO would like to feed ID management system with PS—this would be done to replace SSN with local ID at University level.

Shared Tables with HR FIT: YES

Prefixes If prefixes are utilized, it is recommended to add prefixes at the beginning of an application cycle (in order to function more smoothly, it is recommended that all campus areas collect this data; the table that houses prefixes and titles is open to everyone, and each group is responsible for data administered into the system). It is also recommended to initially accommodate what is currently in the system (5 prefixes), and others can be built in the testing phase if necessary. The question to ask is what needs to be converted vs. what needs to go-live? Prefixes can be edited in self service if the name type is released to the student for editing. It is NOT recommended that you allow students to edit any other name type other than the 'Preferred' name type. Prefixes are not collected in the current system, and titles are different from prefixes. Suffixes The Campus Community Steering Committee will come to an agreement on who populates the information and who owns it, as well as who has authority to change suffixes. OHIO must look at its current practice and maintain consistency. There are 10 current values (I through VII, w/Jr. and Sr.) that should be configured in the suffix table. There are issues in the current system with suffixes. If the person writing the extract does not include the suffix field, then mail is being directed to the wrong person. Records not being picked up, and the wrong person getting information.

CAMPUS COMMUNITY

37

Titles OHIO needs to use military titles in several ways, thus a current military inventory list of titles is needed for conversion. International contacts and their respective titles are also needed. OHIO will identify titles. Name Types Name Types are delivered with the system, and each name type is date effective (OHIO will never lose name history when rows of data are added). If a person exists in the system, they will have a legal (primary) name that must be used in a standard way across the University. OHIO may wish to have legal/primary, preferred name, and also (at least) former name [also former1 and former2] used in PS. OHIO will also need primary, preferred, at least one former name, degree name, and alias name for incarcerated students. Address Type (mailing) Addresses are needed for everyone who uses the system. PS delivered address types include: home, mailing, business, check, dormitory, legal, campus, other, billing, other2, permanent, preferred, and veteran. These address types are used across campus, and it is important to review which addresses will be released for revision (i.e. student self-service). OHIO may want a difference between home and permanent addresses (i.e. adjunct faculty); however, it is advised to have as few addresses as possible to provide a ―clean‖ database. OHIO currently has 16 different types of addresses:

1. Billing 2. Duplicate Billing 3. Refund Check 4. Commencement Address 5. Diploma address 6. Grade 7. Duplicate Grade Report 8. Imaged Address Type 9. Local/School 10. Permanent 11. 2nd Permanent 12. Temporary 13. SEVIS Foreign 14. SEVIS U.S. 15. Father 16. Mother 17. Next of Kin

CAMPUS COMMUNITY

38

OHIO may wish to use "legal" in regard to SEVIS; OHIO wishes to use pre-delivered address types and decide if there -or if any current addresses can be eliminated (OHIO does not currently use effective dating with addresses). OHIO CONVERSION MAPPING DECISIONS

Billing and Duplicate Billing addresses OHIO will use only billing address

Check (Refund Check) address Check address

Commencement address Mailing address

Diploma Address Other (possibly rename diploma or degree in the translate table)

Grades and Duplicate Grades address No need for this in conversion

Imaged address

Will not use this address type, but will discuss further as to what to do with these records in conversion. Students with this address type do not have academic records in legacy, but it indicates the person was a student previously and has an imaged record in the Hyland OnBase system.

Local/School Address

Residence hall addresses will be loaded to Dormitory address and other local addresses will go in Mailing Address

Permanent address Permanent address (UGRD is typically parent address; for international students this can be home or home country)

2nd Permanent address OHIO will use relational aspects

Temporary address Not needed with effective dating

SEVIS Foreign address

Legal address (OHIO may create one for SEVIS ID for international students [currently no one is allowed to update except for student, faculty, international services])

SEVIS U.S. address Other

Father/Mother address Taken care of through PS relationships

Next of Kin Use PS relationships (used for refunding purposes when a student dies)

Citizenship Status Code PS values are delivered. This is the status one has with the United States. In some cases OHIO may need to know an international student‘s home country (this is a delivered function—you cannot assign citizenship status to home country without knowing the home country citizenship codes). It is not customary for US universities to store citizenship codes of other countries but it is common practice to record the country that is designated as the home country.

CAMPUS COMMUNITY

39

Definitions of Citizenship status in PS: Native U.S. citizen: Someone who began life as a US citizen and remains a US citizen. CODING: Citizenship Country = USA Citizenship Status = Native Naturalized U.S. citizen: (You may not know or it may be rare that you know naturalized status at the time of admission) but. Someone who began life as a citizen of a country other than the United States but has become a U.S. citizen. CODING: Citizenship Country = USA Citizenship Status = Naturalized Permanent Resident: (in legacy, classified as PR) Persons classified as Permanent Residents are non-US Citizens with permission to stay in the U.S. indefinitely. The largest number of ―Permanent Resident individuals‖ are also known as ―lawful permanent residents‖ (LPRs); they have Resident Alien, or ―green cards.‖ New PR‘s may not yet have their green card, but must then have an I-551 stamp in their passport. A pending permanent resident [I-485 applicant for adjustment to permanent resident status] should NOT be considered a permanent resident. Persons who present employment authorization documents do not have PR status. In addition to Permanent Residents, persons in several other statuses roll up to the Permanent Resident status: Asylee/Political Asylum Alien Permanent Public Interest Parolee Refugee These persons may possess a variety of infrequently seen documents; consult with the international office to clarify status whenever necessary. All persons with ―Permanent Resident‖ status should also have a citizenship row for another country, indicating either native or naturalized status in that country. CODING: Citizenship Country = USA Citizenship Status = Permanent Resident and add a row by clicking the + sign Citizenship Country = enter country code for country of origin Citizenship Status = Leave blank and SAVE

CAMPUS COMMUNITY

40

Alien Temporary - U.S.: Someone in the USA on a temporary visa (F-1, F-2, J-1 and J-2 are the most common for students.) This person will have two rows in the citizenship table, one for USA, and a second row for their country of origin or passport country, indicating either native or naturalized status in that country. CODING: Citizenship Country = USA Citizenship Status = Alien Temporary and add a row by clicking the + sign and enter: Citizenship Country = enter country code for country of origin Citizenship Status = leave blank. Visa / Permit Types Visa/Permit types must be configured, and are a shared table with PS HR. Campus Community Steering Committee needs to agree on the configuration values in recognition of values used previously in legacy system and how Visa Permits will be recorded in the future. Ethnic Group Regulatory region is always the US, and in order to save a record someone must have a primary ethnicity. If a record is populated, the ethnicity detail can denote percentage ethnicity. There are also ethnic groups and ethnic categories. Ethnic groups must be approved by the Campus Community Steering Committee and it is highly recommended that University Legal Affairs review and approve the proposed configuration. The table in PS HRMS is a shared table. Implementation partner will need to know what the groups are, and how they roll up to broader category so that they meet federal requirements. This will align business practices with federal requirements (institutional research will need to be consulted on this, and will need final review). OHIO‘s current values are: 00 Unknown 01 American Indian or Alaskan Native 02 Black, Non-Hispanic 03 Asian or Pacific Islander 04 Hispanic 05 White, Non-Hispanic 06 Non-Resident (International Student) OHIO expects PS will make modifications to accommodate the new federal reporting requirements.

CAMPUS COMMUNITY

41

Physicians Currently, no need to mark physician information. Diagnosis Codes Currently, no need to mark diagnoses. Accommodation Types The accommodation table is designed to link accommodations to individuals. This information can be restricted to be viewed only by necessary individuals. Currently, accommodation is very manually intensive (the only thing stored is those with priority registration). OHIO tracks students only if they are eligible for priority registration as determined by the Office of Disability Service. OHIO would like to be able to produce individual letters automatically that indicates accommodations required and can be sent to the instructors of record for each class the student is registered in. Language Codes We can attach proficiency for reading, writing, and speaking. Preferred communication languages can also be set to note what language may be needed for various school communications. It is advised to establish appropriate role security to protect the populated information. OHIO has the need to track language proficiency (i.e. grad teaching positions) and will utilize the delivered function to track language proficiency. Licenses and Certificates Extracurricular Activities can be used to track real estate audit students. There is a time involvement section to notate time involved in class (must be notated by individual). OHIO will need to notate things such as RN/LPN. Memberships Fit, no comments Department Table Fit, no comments

CAMPUS COMMUNITY

42

External ID Fit, no comments

Personal Information / Biographical FIT: NO

Email Addresses PS can track multiple email addresses and types. Once an address is set to preferred, it cannot be adjusted; addresses are attached to organization and people. A process to switch preferred flag to campus email address is needed. This process would run at the time the campus email address is assigned and inserted to Campus Solutions. The student should not be able to change their preferred email address as the University communicates with the student only via their official university email address. Seasonal Addresses Student can set ―start and end‖ dates for different addresses, which allows for seasonal use of addresses. A delivered process must be run by IT in order to activate these addresses. Final determination on use of seasonal addresses will be reviewed by Campus Community Steering Committee. Work Experience Employer can be an organization within the organization table. All work experiences can be added—retirement information as well. At OHIO, the Graduate Studies Office currently collects this information and stores it in a file. It is made available for department use. Phones Types Implementation partner will need to know what phones require tracking, and whether OHIO needs to know what kind of phone it is. One phone number must be listed as preferred. CollegeNET must also be mapped to PS. It is important to note phone types are mutually exclusive from address. Phone numbers are not always provided at the prospect or applicant stage. International student applicants do not always provide a phone number. OHIO will keep business, campus, dormitory phones (the label ―dormitory‖ phone may be changed to ―residence hall‖ phone), FAX, home, main (as business main contact), mobile (can be changed to cell), and work. OHIO stores Primary and Night phone numbers, and Admissions keeps parental phones. There is a phone tied to each address.

CAMPUS COMMUNITY

43

OHIO may start with only a few phone types, and add as they go. OHIO currently collects private cell phone numbers from the student on a voluntary basis (for internal business use only), public cell phone numbers (FERPA will designate what is/is not published). Address Validation Software— OHIO needs recommendation of address validation software that will mesh well with PS. OHIO wishes to look at VERTEX, which is the current tool being used by Payroll to validate city, state, and zip code. FirstLogic is also an address validation software application that can be investigated. Another option is CLEAN-Address from Runner Technologies, Inc. Emergency Contacts PS can store ―free-form‖ name and designate a relationship; those with same address/phone/name can be auto-populated. There can also be multiples with a primary listed, and address can be edited. Phone can be listed without listing type. It is advised that emergency contact be updatable by student. OHIO collects emergency contacts and permits students to update their emergency contact online. The legacy system permits only one emergency contact. Type of Information Collected—

first, middle, last, suffix, relationship, address, primary and daytime phone

Athletic Participation This is an effective dated field. It is advised to have a "mini-fit/gap" with Athletics in order to ascertain what is needed for tracking purposes. OHIO may need to interface to the NCAA's Compliance Assistant Internet (CAI). The Compliance Assistant is a tool designed to help administrators ensure that their athletic department and student-athletes are in compliance with NCAA legislation. In addition to applying NCAA legislation in the areas of financial aid, eligibility, recruiting, athletics personnel and playing and practice seasons, it is a data-collection system that can be used to generate NCAA-required forms and other forms created by the user. It is much easier to take information from CAI and enter it into PS than it is to interface the other way around. Some translate values need to be added for Div I schools in the Athletic Participation. OHIO needs expanded discussion on athletic participation tracking in order to see what part of Campus Community can be used.

CAMPUS COMMUNITY

44

Health Information FIT: YES

There is a place to store health insurance/immunization information. OHIO can set up codes needed for tracking. There are no requirements in Health Services at this time, other than to add students. There is a service indicator for those who need to pass TB test, and there are a select group of international students who may not require insurance. Accommodation Data The accommodation table is designed to link accommodations to individuals. This information can be restricted to be viewed only by necessary individuals. Currently, accommodation is very manually intensive (the only thing stored is those with priority registration). OHIO tracks students only if they are eligible for priority registration as determined by the Office of Disability Service. OHIO would like to be able to produce individual letters automatically that indicates accommodations required and can be sent to the instructors of record for each class the student is registered in. Immunization There is a place to store health insurance/immunization information, and you can set up codes you are tracking. At OHIO, Hudson Health Medical Services enters data in the legacy system. Current codes used are: DIP Diptheria HEPA Hepatitis A HEPB Hepatitis B HEP2 Hepatitis B – 2nd shot HEP3 Hepatitis B – 3rd shot MEAS Rubeola – Measles MENI Meningitis MUMP Mumps POLI Polio RUBE Rubella TBA Tuberculosis – US Citizen TBA2 Tuberculosis – US Citizen TBI Tuberculosis – International TET Tetanus VIP VIP Clinic XRAY Chest X-ray

CAMPUS COMMUNITY

45

Health Exams This will not be used. Audiometric This will not be used. Eye This will not be used. Physical This will not be used. Respiratory This will not be used.

Identification FIT: YES

Citizenship and Passport One can access this information from different parts of the system. Application panels and Prospect panels "borrow" information from person record tables in Campus Community (Bio-Demo panels look "essentially" the same). OHIO may need to adjust translate values and deactivate citizenship statuses they do not wish to use. Citizenship/Passport is a "silo" panel where information is stored in order to fill necessary information in other panels. One can reach citizenship information from "Add/Update a Person.‖ Using "Add/Update a Person" will allow one to update more information. OHIO enters country of citizenship, and then notes US status—citizenship status is delivered for US only but OHIO can build citizenship statuses for other countries but it is not needed at the current time. Visa/Permit OHIO will need to enter the history of all visa types they have used—anything additional will be added afterward. OHIO wishes to remove "other" and "unknown" from their current list of visa types. They utilize fsaAtlas to generate necessary verification documents which are then stored in PDF form.

CAMPUS COMMUNITY

46

Driver's License Data OHIO needs to identify all areas where driver‘s license is located. It is needed for students who may drive a state-owned vehicle. Student employees who have access to state vehicles are required to have driver‘s license data on file. OHIO stores driver‘s license information in the library. Additionally, driver‘s license information may be stored in the financial aid office, on a student‘s FAFSA data. OHIO will make DL an ID Management discussion issue that may be stored in the Oracle Data Privacy Shield. A Gap is in how this will be handled but will not be considered a Gap for this implementation because this is a future, unknown event. Ethnicity At this time there is no use of ethnic percentage details. The Office of Admissions catalogues and codes ethnicity and Financial Aid will use what admissions catalogues. There is no policy on how, or why, to use ethnicity percentages. OHIO‘s current values are:

00 Unknown 01 American Indian or Alaskan Native 02 Black, Non-Hispanic 03 Asian or Pacific Islander 04 Hispanic 05 White, Non-Hispanic 06 Non-Resident (International Student)

OHIO expects PS will make modifications to accommodate the new federal reporting requirements. Birth Location Birth location is collected and can be stored. Country is recorded here. Country codes and descriptions can be added if they are not present in PS; however, this can create a conflict if PS delivers them at a later date, and with a different code/description. This is currently asked on all applications. External System ID External System ID is where SEVIS ID information is stored for the PDSO (principal designated school official) and DSO‘s (designated school official). If OHIO wishes to create new student IDs, old school IDs can be stored here. OHIO needs to develop methodology of how to handle IDs. All External System ID‘s are stored on this page and associated with a person.

CAMPUS COMMUNITY

47

Residency Data OHIO can create residency exception codes, which are assigned at the person level—thus, the code can be adjusted upon career. It is advised to establish the appropriate role security to protect the entered data. It is important to note that a student can be admitted without residency status being established; however, residency is required before a student may be term activated. SUGGESTION— a student group could be created to address exchange students. OHIO wants to track exceptions to residency rules, and is considering using the tuition portion of the page to judge against the Kentucky Tuition Reciprocity Agreement (exception). OHIO has not utilized appeal status in their current system—this will be new functionality. Residency logic will need to be revisited and reestablished in the interface with CollegeNET to PS. Current system codes for non-residency:

N=Non resident O=Non-resident w/Ohio address E=Ohio residency exchange student R=Resident S=Resident w/out-of-state address K=Kentucky reciprocity student

There are delivered translate values, but a modification can be created in order to add needed non-delivered values for state residency drop-down box. OHIO feels that current delivered residency drop-down options will suit needs temporarily—but these will be reviewed. It is recommended that all exceptions provided to students be captured as a residency exception and not as a residency code. OHIO codes all Ohio students with a county code and Graduate Studies uses Kentucky county codes for the Kentucky reciprocity agreement. County codes are used for both tuition calculation and scholarship eligibility for selective scholarships. The county code information is currently loaded into an external scholarship database used by SFA. County codes are also used to determine commuter status for housing waivers. Residency Exception OHIO may need to adjust exception list and is considering using the tuition portion of the page to judge against the Kentucky Tuition Reciprocity (exception). Supporting Documents Table

CAMPUS COMMUNITY

48

If supporting documents will be identified/associated with established Visa/Permits in the system, those values need to be defined with input from PS HR and International Student Services. Photo This is a fit, but needs further review as to utilize its full capacity. Photos are currently used on class rosters and advisee rosters. If they add photos through CC, they can configure the Self Service setup for SR by using the Show Student Photos on Rosters checkbox. If this checkbox is checked, then student photos will display on the class and advisee rosters in Faculty Center. They do not display on the regular class and advisee rosters (used normally by admin staff). Photos must be in a JPEG format for uploading to PS. PIN This will be further reviewed in discussion of security authentication. The field is 10 characters. Conversion – there needs to be a separate meeting with ID management and the PS team.

Participation FIT: NO

Honors and Awards OHIO stores/tracks information regarding honors and awards for students, faculty, or ―others‖, such as National Merit Finalists in Recruitment Plus. Licenses and Certificates Graduate Studies will use this as well as programs such as Nursing where licenses are required. OHIO may consider using this to track completion of the Ohio Transfer Module, CPR completion, or teacher education licenses. ―Memberships‖ is primarily used for faculty/staff. However, it is possible to track prospective student membership; although this is used primarily in extracurricular activities (―extra curricular activities‖ can store internal and external activities. This could also be used for Greek system). OHIO needs to be able to track/generate Greek enrollment and create a roster. The following currently tracks for students participating in Greek Life: Greek Organization, new or initiate, housing (in house, residence hall, or off-campus), term-new, term-initiate, and term-last. This data is used to create academic reports for the Greek Life Office. CONVERSION NOTE—Oracle HRMS stores particular certifications (SPR, etc.). Faculty memberships are stored in a local area, which may not go directly into PS. CONVERSION NOTE— OHIO NEEDS TO ASK NEW DEAN OF STUDENTS WHETHER A CO-CURRICULAR TRANSCRIPT WILL BE GENERATED.

CAMPUS COMMUNITY

49

Publications This is used a great deal with graduate schools. The publication title is a free-form field to allow for special characters. This could be an area of enhancement for OHIO. OHIO tracks information locally by college and is not a global stored table. A Communication Committee is discussing faculty reporting, which would handle publications for faculty. Conversion — OHIO is looking at a tracking system for thesis/dissertation reporting, and does not recommend storing faculty reporting in ―publications.‖ OHIO will need to link committees to publications for dissertation/thesis, and would like to individually track theses/committees for those enrolled in multiple programs. Membership in committee changes by student, committee can change at publication (status change). A Gap resides in associating committees to publications and thesis tracking. You cannot associate a committee with a person unless the person is a member of the committee. The work-around would be to have the student be a committee member but you would need individual committees for each student. OU will need to look at the hours needed for work-flow on thesis tracking.

Service Indicators / Holds FIT: NO

Service Indicators OHIO currently calls these "holds" (See Appendix for current school holds) In most cases, prospect, admissions, and bio-demo data go-live first. It is then decided what will go-live with these other aspects, leaving service indicators to go-live with these particular modules. Service Indicators are needed in order to provide the best communication possible; thus, the implementation partner will need the inventory of current indicators and their respective impacts. The implementation partner will also need to review the current indicators and determine what changes need to be made. Any gaps can be reviewed at that time. There are 60 different offices with multiple hold codes. In addition to current Service Indicators, "Block all enrollment" must be added, as well as "Allow drop only; no add activity", and "get enrollment verification.‖ The "Description" in service indicator impact is needed in order to inform students as to what is needed in order to rectify the indicator.

CAMPUS COMMUNITY

50

Service Indicator Reasons It is advised to have indicators set up in individual departments/offices, to allow for maximum administrative functionality. Default reasons can be set so that when they are assigned to students, individual reasons can be selected. Service Impacts OHIO needs to develop a "diploma/no diploma" service indicator/service impact, with a description that directs students to a particular department (i.e. see Office of the Bursar) for resolution. Required indicators will be set up in a particular way, with particular impacts. There are four service impacts that need setup as required by PS—beyond these, any can be set. Plus, the impact table can be adjusted to set impacts for certain dates. Audit There needs to be a larger discussion on what audit tags need to be put on particular fields. The audit is a log of all holds on a student, or students with a particular type of indicator. It allows for viewing an overview of indicators, reasons, codes, details, as well as period and assignment details. Contact information is also displayed. Ability to exclude charges from old calc (bursar‘s office) does Not Fit. OHIO has an automated hold and release of a Bursar hold. This needs to be addressed in Student Financials to fully understand the gap and whether or not a business process can be changed or not. Control that whatever office places hold is only one to release it Fit, no comments. Future effective dating for holds Fit, no comments. Mass assign Fit, no comments. Mass release Fit, no comments. Ability to search commuter students for housing hold

CAMPUS COMMUNITY

51

This is used for those without a resident hall, and need a hold to mark as commuter. Override capability--automated (dynamic) The current system has a way of automating temporary release of a hold and then putting the hold back on after a desired transaction takes place...- a Bursar issue. If mail was returned because someone had a bad address, and a service indicator is placed on them, they expressed an interest in being notified if someone changes their address on self-service so that the service indicator can be released. It is advised to have a student who ―stops out‖ discontinued and forced to reapply – this allows for the opportunity to collect new information (gives more accurate picture for enrollment). OHIO wants to keep override capability, which allows for exceptions to be made with an expiration date for release. There is a Gap in notification of address update so hold can be released: out of state address changes trigger hold. This is a gap for financials and admissions. The PhD program requires a readmit process for those reaching "time out" in order to give the department the option to deny continuance. There needs to be a discussion of how to handle those that time out and return (keep current procedure, or adjust).

Committees FIT: YES

Committee Types This functionality may serve little purpose for OHIO. This functionality allows one to inventory governance structure (this is primarily what it is meant for). One could use this for grad committees, but it is not for thesis/dissertation tracking purposes—customization is involved to attach these to a person. However, a student may be a part of a committee. Despite the review of external software, it is advised to judge this against the cost of PS customization--all PeopleCode can be monitored and structured by the school, with no third-party ambiguity. OHIO wants to blend what they are reviewing on committees with checklists. Committee Roles Fit, no comments

CAMPUS COMMUNITY

52

Row Level Security FIT: N/A

It is advised to set up security for appropriate individuals. It is also advised not to give all individuals full row level security during the implementation phase in every instance of the database.

3Cs – Communications, Checklists and Comments

FIT: N/A

OHIO uses a great deal of communication from Recruitment Plus, but still uses some postal mail (i.e. admission). Emails are used for certain continuing campaigns in admissions, but financial aid communicates almost exclusively through OHIO email once students have matriculated. Registrar and Bursar exclusively communicate via email. OHIO email accounts are activated at registration; although, there is a project to create email address at admission. Text messages are used for current students who elect to use the service, in case of emergencies. Each individual module fit/gap will need to discuss particular communication needs. OHIO will decide how communications are tracked, either globally or per module. Someone has to globally look at how complete a communication piece is, while the responsibility for building communications is in each module. It is advised that OHIO use self-service at the point of application in order to manage all school needs.

Administrative Functions FIT: N/A

A naming convention is needed in order to establish shared codes (i.e. convention decides who gets which alpha designation--A=admission, F=financial aid, C=Chillicothe, etc). The naming convention must also decide codes for specific communications, because all codes will be listed on the same table. A decision will also be made to decide specific needs/roles of the individual offices and assign the appropriate security.

Communication Categories FIT: YES

Fit, no comments.

CAMPUS COMMUNITY

53

Communication Contexts FIT: N/A

Some communications do not generate anything, but a record of some kind is needed (i.e. phone-a-thon)--a communication code can be set up in system for "app-reminder-phone call-successful/unsuccessful"; these codes can be queried to review activity; a 2 way can be set up with Recruitment Plus to store communication as completed communication to show in history (this gives record, but does no communication generation)

Standard Letters FIT: YES

Consultant will need to know all extract fields. Question raised during Fit/Gap: At what point do you stop communication in Recruitment Plus and begin communication in Admissions? Is there an extract file-and all communication is out of Recruitment Plus? CONVERSION - communication history will need to be moved into PS from 3rd party. ISSUE--the PDF view of a communication that is stored on PS cannot be adjusted unless one has PDF writer.

3C Groups FIT: YES

Group management can be established based upon role. 3C inquiry groups can be secured down to the individual user. Examples--UGRD admission counselor, UGRD admission operations, UGRD admission student worker, UGRD recruiters, GRAD admission counselor, GRAD admission operations, et al; OHIO needs to think of security and duties of individuals to establish inquiry and update capability--security is necessary to see that a communication happened.

Communication Speed Keys FIT: YES

You will need speed keys for every communication. You will also need communication keys for every communication--communication key is set as the letter code.

Communication Management FIT: N/A

CAMPUS COMMUNITY

54

Specialty Vendor software such as Recruitment Plus that addresses specific functional needs often bring sophistication that may otherwise not be packaged in the same way or may have desired user-friendly functionality. If you have prospects in PS, it is very easy to carry an ID and pull prospect data into the application. (If there are 250K prospects, it may be advisable to move out of system to reduce the possibility of creating duplicates. OHIO intended to continue to use Recruitment Plus for Athens undergraduate recruitment. Every aspect needs to be mapped out before implementation/conversion begins. Regional campuses may use PS recruitment, and OUCOM will use PS Recruitment.

Checklist Table, Items, Function Items, Managing Checklists

FIT: NO

No automation between assigning/completing checklists and the placing/removal of holds. OHIO wishes to provide more detailed information in the description section. Possible Customization: Some due dates may need to be masked in the "to do" section of Self-Service.

Checklist Item Update FIT: YES

Checklists can be triggered to auto assign, as well as comments and communications. NOTE--the trigger function as delivered triggers (records), and PeopleBooks gives the code of how to attach a call function to trigger other records than are delivered.

The 3C engine online triggers are integrated with the system by using a PeopleCode function. The function evaluates certain key variable information provided in the PeopleCode placed in the transactional locations. You must define certain variable assignment values when you place this PeopleCode in other records or components. The following PeopleCode example identifies and describes these variables. For example, the Trigger3CEngine function call placed on the ADM_APPL_DATA record has these variable assignments.

Declare Function Trigger3CEngine PeopleCode FUNCLIB_CS.EVENT_3CS_ID FieldFormula; PanelGroup string &ID, &RECNAME, &ACTION, &OVERRIDE, &VAR_DATA, &INSTITUTION; &ID = "EMPLID"; &RECNAME = "ADM_APPL_DATA"; &ACTION = "N"; &OVERRIDE = "N"; &VAR_DATA = ?Y?; &INSTITUTION = ADM_APPL_DATA.INSTITUTION; Trigger3CEngine(); The PS system delivers some predefined 3C engine PeopleCode function calls. You can use the EmplID (SavePostChange) field on these records: • ADM_APPL_DATA

CAMPUS COMMUNITY

55

• ADM_APPL_PROG • ADM_PRSPCT_CAR • ADM_PRSPCT_PROG • ADM_WEB_PRS_CAR

We can configure the system to provide 3C engine integration in other areas by placing the PeopleCode function call in the appropriate records or components.

Comment, Categories, 3C Groups FIT: YES

OHIO needs to review roles and decide security to allow changes or not. Standard communications can be set up in a category so that it can be designated for all instances (i.e. interview). Comments can be appended meaning that the system displays the ID of the person entering the comment as the responsible ID. If someone else appends the comment, it does not capture the ID of the person appending to the comment that was initially made. When appending the comment, the business practice should be that the person appending to a comment, put the date and their initials in the appending comment before saving the new comment. If this is not done, you will not be able to know who appended the comment that was originally placed. Conversion – Some functional areas may want old comments brought into PS. Possible conversion solution--create a "conversion" comment that will store past info with no ability to append.

Comment categories are developed in each modular area and are associated with a particular administrative function. Comments are tied to a person and reflect the variable data associated with the administrative function.

The Comment short description field =10 characters, long description field =30 characters; the default value for comment entry is that changes are allowed.

Comments can be subpoenaed (use only as official). 3C group security comes into play to allow viewing according to need--default is for changes to be made.

Situation--parent can call on same topic, OHIO needs original comment to remain (need to use append action); their text comments with no changes, append comments, and pre-populated comments.

OHIO does not currently have date/time/originator stamp for all comments and appended remarks (PS does not log appended remarks). Rather, the date/time/originator must be entered as part of the comment text for the appended remarks.

CAMPUS COMMUNITY

56

The Comment field in the PERSON_COMMENT record/table in 3C's Person Comment Entry Page is of type "LONG". This means that it can hold up to 32700 bytes (it's an undefined length in App Designer but is defined with a max size of 32700 bytes), so this can be used to store the converted lengthy comments without problems.

Comment Management FIT: N/A

A conversion discussion with key players is needed to discuss how to handle comments/setup--look at comments for students/events and that between student and waivers; there is also a conversion discussion needed for comments on Recruitment Plus and what events need to receive comments.

Communication Generation FIT: YES

A conversion discussion with key players is needed to discuss how to handle comments/setup of groups; OHIO needs to make business decision on communication practice (i.e. tone, repetitiveness, history)--every aspect needs to be mapped out before implementation/ conversion/configuration begins. OHIO will come up with MS Word template for communication letters that will be stored in a secured drive--process will be run to extract file in a designated folder, you then word merge for output. The output can then be put in imaging system for reference.

Mass Communication FIT: N/A

Have specific module discussion on mass communications and population selections. It is advised to have a query that will give the volume for letter code and day generated. Consider space needed to store output when using letter generation.

Events FIT: NO

This functionality has not changed since its inception; this functionality might work well for events/meetings that are for internal members; there is no web registration for events. The events module does not meet the needs of the OHIO Admissions offices which conduct the majority of events. The tables themselves offer valid functionality but the events area does not offer student interactivity such as web registration for the events set up. Have already noted limitations. OHIO has 6 major yield events as well as many smaller yield events. There are also major events for prospective students.

CAMPUS COMMUNITY

57

Events have "sessions" within them; the template allows OHIO to make the event formulaic; all meeting and event types must be set up (can set up resource items and comments); you can have a history of what was assigned; OHIO currently imports events into Recruitment Plus from a homegrown entity; for school's yield programs, only admitted students are notified; there is a web-registration form, then admit status is researched, and then info is fed into Recruitment Plus--in most cases Recruitment Plus is only updated after event, as to catalogue attendance; NEED TO GET A LIST OF ALL WEB FORMS, AND WHERE THEY ARE BEING USED.

Event Type Table FIT: YES

Setup types needed for institution; a location table must be created. OHIO presently has location information stored in three to four different systems.

Resource Code Table FIT: YES

Fit, no comments

Staff Code Table FIT: YES

Develop staff codes (i.e. Admission Representative); must be setup in order to create template.

Event Template FIT: YES

You create an event ID when creating an event; you can make notes about facility setup, etc.

Meetings FIT: YES

Meetings belong to an event. Can setup meeting, date, expected attendance, and maximum number; more information can be listed (i.e. department, organization, and contact information); specific staff can be added; OHIO is looking at getting a new 3rd party product for event management.

Overview of Organizations FIT: YES

OHIO will have a naming convention for all organizations being loaded; we must know the source data, where it‘s coming from, and whether it can be trusted.

CAMPUS COMMUNITY

58

School Data setup--the school type for secondary MUST be coded as SCD in order to link with Educational Testing Service; you can have multiple locations w/in org and multiple depts. w/in a location.

Identify Source Data FIT: N/A

College Board is the source of organization data in the Recruitment Plus system. ACT is the source data for the OHIO code look up table.

Conversion Issues FIT: YES

Organization Group Table The organization table will be used extensively. Organizations can be categorized into groups to assist in identifying organizations conveniently for recruitment. Contact Type Table Contacts can be added to an organization; look at service area first and then grow from there; Different offices have different contacts at each external organization. This is common and PS allows for the use of the organization table in this way. All modules may have access to maintain contacts in the organization table. External Org Code Type Table This is used with College Board EPS market codes, and can be used for CB Geo-Demographic analysis. External Subject Table The external subject table is used to designate academic interests as well as provide a way to categorize courses in the general subject areas for transfer credit purposes. OHIO records multiple academic interests at the prospect stage. External Term Table These values are delivered. School Type Table The file format for international schools from College Board is not as accommodating for different address formats.

CAMPUS COMMUNITY

59

Organization Table The table can be populated in several ways--one way is to hold all HS in nation and beyond; PS delivers process to upload data from ETS/CB services; ATP and ACT codes are the same at HS level, but not at college level; FICE code is located in Financial Aid and can be pulled in to populate the FICE code field. Organization Contacts Contacts can be added to an organization; look at service area first and then grow from there. Organization Affiliation Interesting functionality--any organization can be assigned a group code and then a group type: this can allow for query research and then be given to specific recruiter; every time a student gets pulled in from that school, you can check the org ID to see how many people you are getting from specific groups.

FERPA FIT: YES

Institution decides what it will give the student the ability to release; HR needs to be at conversion meeting to establish interaction with their records and databases. You can establish and administer FERPA as all or nothing; this can be done via self-service: FERPA flag in PS, once clicked, will display what restricted items have been selected. OHIO may give students control over specific data elements provided in PS FERPA views. FERPA Control This is the location where control is granted--without granting control, it is restricted There are delivered FERPA views in PS; as the tables are populated there is information that can be controlled; you can control all values if you wish; this control governs the items a student can see in self-service. Institution Publications No additional comments. Publication Categories No additional comments. FERPA Conversion

CAMPUS COMMUNITY

60

One conversion element in the plan is the FERPA conversion--if we are importing any employees, we need to look at what their restrictions are. In the system, we will know all records a person has (i.e. employee, student, app, et al).

3C Security FIT: N/A

You will need speed keys for every communication; you will also need communication keys for every communication--communication key is the same as the letter code. Security is setup per ID, where ID holder is granted security for institution/3C group; inquiry indicator and update indicator is granted here. The 3C group provides user-level security access to categories of communications, checklists, and comments while providing or restricting the user‘s ability to edit the data.

Student Service Center FIT: NO

Self Service In student Self Service, the installation requires an all or nothing display of personal information. If personal information is displayed, names are available for edit by the student. This is not a desired business practice. Only in the instance of a preferred name may it be acceptable to have a student edit that name type. Student Center This is the student view/portal for student registration, admission status checking , view account, access financial aid information, etc. SC Setup Personal information section is ALL or NOTHING--this must be noted in configuration (this must also be noted in all fit/gaps)--modification is necessary to display/hide individual information. This is where you setup all SC options: personal info, FA, registration, admission, holds, provided websites, et al. OHIO would like to have students see DOB (this is delivered and is OK), but not have the ability to change, update FERPA restrictions, update preferred name/no edits on others (Gap); OHIO does not want to allow edit on certain areas (i.e. changing names [large issue]), and may want to mask others.

CAMPUS COMMUNITY

61

SEVIS FIT: NO

OHIO needs to review business process to judge how to handle total student work hours for international student employees. A service indicator needs to be built to mark whether a student is eligible or not eligible for work--also need contact information for questions. It is necessary to consult with student employment to set business processes. Gaps: form generation, tracking employees and persons of interest (guests). . Conversion Issue--getting information that is held only in Financial Aid and Oracle HRMS; OHIO needs to track start/end-date of employment for international students; OHIO has two statuses for those eligible to work--campus employment auth 9Y/N field), and employment authorized start/end-date. Gap with tracking international student employment and start/end-dates The workaround is giving the necessary people view into the Oracle HRMS system to look at job start and end dates. This is a gap that should not be solved programmatically. OHIO can solve this via security allowances or a report out of their Oracle HRMS system. The international office does more than just SEVIS: UGRD/GRAD cover immigration at application point--financial verification, credentials from college and/or HS, non-degree and study abroad, application and application fee. Admission Checklist Items Need list of all checklist items. International Admissions and International Services will provide this list at implementation. Collected Items: I-20, financial statement, TOEFL, et al. Application Application center can be devised to house apps from various areas (i.e. international, UGRD, GRAD). GRAD admission decision is delivered prior to demonstration of ability to pay. SEVIS ID SEVIS ID is maintained in PS. I-20 FORM OHIO needs a text box for comments next to the English proficiency section of the form; Gap Work around would be to use the delivered comment box.

CAMPUS COMMUNITY

62

SEVIS and STUDY ABROAD OHIO to find out about the ―Open Doors‖ report.



Supporting Documents

Defines documents used to verify employee information.

Visas/Permits Define visa or permit details and supporting documents for verifying status.

Name Type Defaults

Define or review the name types that will be created by default when adding a new person ID.

Extracurricular Activity Table

Define and update the extracurricular activities your institution tracks.

External Organization Type

Define organization types and related navigation.

NAICS Codes Define North American Industry Classification System codes.

Selection Tool Configure Population Selection Tools.

Application Specific Context

Define the application specific keys used to map a process to a specific context.

Context Definition

Configure Population Selection Context Definition.

Equation to Context Mapping

Map Equation Engine Application Prompt values to Population Selection Contexts

Field Conversion Definition

File Parser Field Conversion Definition

Copy Field Value Conversion

File Parser Copy Field Value Conversion.

Context Definition

File Parser Context Definition

Copy Context Definition

Copy Context Definition.

File Mapping Definition

File definition and mapping.

Copy File Mapping Definition

File Parser Copy File Mapping Definition.

CAMPUS COMMUNITY

63

Population Selection File Map

Population Selection File Mapping Definition

Population Update Setup

Population Update Setup.

Form Image Text

Forms Engine EPS Image Text.

Event Type Table

Define type of events to manage.

Campus Community Installation

Install tables required for Campus Community.

Resource Code Table

Define resources to be used with events.

Health Test Table

Define and update the health tests your institution tracks.

Staff Code Table

Define staff codes to use with events.

Event Template

Define event meeting templates.

Trigger Prompt Table

Identify the edit table for a 3C engine trigger to prompt.

Ext Org Code Type Table

Define an EPS market code organization code type.

EPS Market Code Table

View EPS market codes loaded through the EPS load process.

Relationship / Marital Status

Define and update a marital status corresponding to a joint relationship.

Immunization Table

Define and update the immunization tests your institution tracks.

Relationship Table

Define and update the relationships your institution tracks.

Font Names Font Name Table.

Form Editor Form Editor.

Form Groups Form Group Table.

Out Dest Formats

Forms Engine Out Dest Formats.

Out Dest Types Forms Engine Out Dest Types.

Out Dest Values

Forms Engine output dest prmpt.

Postscript Fonts

Postscript Fonts.

Standard Letter Table CS

Set up standard letter codes to be used in Campus Solutions communications.

CAMPUS COMMUNITY

64

Comment Category Table

Set up categories for comments.

3C Update/Inquiry Group Table

Define 3C group codes.

Comment 3C Groups

Include comments in 3C groups for security purposes.

Tracking Group Table

Set up tracking groups for checklists.

Communication Context Table

Set up contexts for the communications process.

Institution Publications

Define and update the publications your institution tracks.

Iwi Table Maintain Iwi codes and descriptions for NZ Maoris. Used in SDR Reporting.

Legacy Table Define the types of legacy affiliations that individuals can have with your institution.

Communication Category Table

Set up categories to use in the communications process.

Communication 3C Groups

Include communications in 3C groups for security purposes.

Publication Categories

Publication Categories.

Service Impact Table

Define service impacts codes to attach to service indicators.

Service Indicator Table

Create service indicators code, for both positive and negative service indicators.

Committee Type/Role

Define the committee types and member roles.

Checklist Item Table

Set up items to be used in a checklist.

Checklist Item Functions Table

Set up checklist items by administrative function.

Communication Speed Key Table

Manage Speed Keys for communications.

Communication Data Source

Define communication data source to be used in Campus Solutions communications.

Checklist 3C Groups

Include checklists in 3C groups for security purposes.

Event Definition

Define events for management of communications, checklists and/or comments.

Trigger Definition

Define triggers for management of communications, checklists and/or comments.

CAMPUS COMMUNITY

65

Organization Recipient Usage

Define hierarchies of Organization Recipient types to search for and use in a specific usage.

Organization Affiliation

Create or update an organization's affiliation to the institution.

External Organization Codes

Create or update EPS codes for an organization.

Religious Preference Table

Define and update the religious preferences your institution tracks.

Residency Exception Table

Define and update the residency exceptions your institution tracks.

Residency Table

Define and update the residency information your institution tracks.

Standard Industry Table

Define and update the United States standard industrial classifications your institution tracks.

Standard Occupation Table

Define and update the United States standard occupational classifications your institution tracks.

Define External Systems

Define external systems for which external system identifiers can be tracked.

Athletic Participation Table

Define and update athletic participations your institution tracks.

Update Security - Acad Orgs

Link your academic organization security tree to academic organization security.

Honors and Awards Table

Define and update the honors and awards your institution tracks.

Student Services Center Setup

Define the labels and sections to show for the Student Services Center

External Term Define or review external terms sessions for external organizations.

Equation Application Prompts

Add or update the list of applications that use equations.

SEVIS Event Types

Define SEVIS event types and form request defaults.

SEVIS File Errors

Define file errors returned from SEVIS.

User Defaults Define user defaults.

RECRUITING AND ADMISSIONS

66

Section 6 Recruiting and Admissions

CIBER Leads: Dewey Holleman and Micah Marin OU Process Owner: Jean Lewis OU Leads: Steve Flaherty, Shelley Ruff, Debra Benton, Kim Trout, Jill Lallier Fit/Gap Sessions were held from April 7 to April 17.

Setting up Prospects FIT: YES

Application Centers - These are similar to Recruitment Centers and must be set up. Test scores are currently loaded in SIS and then exported to Recruitment Plus (this is done to capture the SIS PID and help with SIS duplicate resolution). It is recommended that the applications centers mirror the various admissions offices through the University.

Recruitment Territories FIT: YES

Regions - This is a fit but final determination of who will use Recruitment Plus and who will use PeopleSoft was not resolved at fit/gap. The initial determination is that Undergraduate Admissions in Athens will continue to use Recruitment Plus and that Regional Campuses and College of Medicine (COM) will use PeopleSoft Recruiting. If the regional campuses and COM use PeopleSoft for recruiting/prospecting, there will be only a need to develop a region tree that would reflect the detail of the state to the county level. In this way you would be able to track prospects by county and this would be especially helpful to identify students from the Appalachian service area. Region Postal Code Table - If we are developing regions, every code off of the Postal Code table will be present; Trees must be updated when ZIPs change. Region Tree - PS will create a tree, but a list of all ZIPs will be needed (ZIPCODEdownload.com is one resource); a ZIP range can then be set for ZIP, county, and state.

Referral Sources FIT: YES

You can keep the sources/descriptions very general, or very specific; You can even set up specific fairs or events (i.e. Cleveland NACAC National College Fair); need a list of how we get a lead to OHIO; Zanesville--HS visit, college fair, test score, phone, letter, or email; OHIO currently has a means by which to get this done.


67

Recruitment FIT: YES

Recruitment Categories

This is or can be how you want to put students into a category in order to message them differently. Categories have delivered types of academic, alumni, athletics, music, or region. Each category developed will be associated with a type of category.

Adding Recruiters

A recruiter must exist in the system with an ID. And a recruiter can have multiple roles such as host, interviewer, and event representative. Recruiters may be assigned a region and from a particular area may be excluded or included in a region. Specific program/plan recruitment can be assigned here as well. For example, OHIO can assign a recruiter by plan, which will aid in equating to a particular school (i.e. nursing or music). A list of a recruiter's students must be pulled from a Query however an online screen view is available. The recruiter summary is an online listing (online list is real time). Business practices must be determined in order to decide who recruiters will be, and when their duties become active and what their particular roles and assignments will be initially.

Recruiter Categories

Anyone designated as a recruiter in the system can be assigned to a specific recruitment category for the purposes of messaging or accountability.

Recruiter Regions/Centers

Recruiters can be assigned a specific Region to represent a geographic region for accountability. The recruitment centers will mirror the application centers.

Recruiter Programs

Persons designated as recruiters may be assigned to specific programs, such as a Nursing recruiter, or Minority Engineering recruiter are examples.

Prospect Record FIT: Yes

First three screens of the prospect record and application are the BIO/Demo screens. PeopleSoft ‗borrows‘ them from Campus Community for user convenience.


68

Admit term is the term to which you are recruiting the student (this marker is also used when purging prospect records from the system). You can purge the prospect record without purging the person record. OHIO will decide if/when prospects will be purged from the system. It is strongly encouraged to revisit the definition "Home Campus" within the OHIO system. When entering prospects, the recruitment status date can be back dated to record the date of the recruitment event in case of data entry time lag. The admission application will feed into PS through CollegeNet. This will require an interface to be built. A student may be a prospect for multiple campuses using the Campus field. This will accommodate current practice for multiple campus recruitment. However, there is a high degree of risk of confusion on the student's part about why they are getting similar information multiple times when they possibly have already decided which campus to attend. This makes the institution appear as if it is competing internally for the student and may send the wrong message. A review of the process is encouraged. The purging process takes place currently in SIS, but not Recruitment Plus. Campus will equal MAIN, which is Athens. This should mirror the academic structure. Financial Aid uses primary campus for projected scholarship awards. Campus must be populated in order to facilitate this (current system only allows for packaging at the most recent application location). (i.e. Athens and Zanesville). Zanesville uses interest category to notate campus. OU hasn't decided whether prospect data will be pulled into PS or not. The link between SIS and Recruitment Plus is by PID. If a two way interface is developed between Recruitment Plus and PeopleSoft, OU will need to store the Empl ID from PeopleSoft in Recruitment Plus. CollegeNet can feed into Recruitment Plus as well as the current SIS; 5 files provided--app file (anyone in SIS w/app), 4 different files for SAT/ACT (new or repeat SAT, new or repeat ACT); it is not a completely reflexive system. A student could make changes after application is locked by Athens. OHIO Athens Admissions recommends loading test scores into PeopleSoft as first entry point.


69

Test Score Setup FIT: NO

Test table and test component table Need a list of current tests that are being tracked in the current system. This was provided. However, further review and research of data in the current system is needed prior to any configuration. OHIO will convert test scores from SIS to PS but the test table and test component tables must be configured first. Implementation team will need to go through every test and define it. We also have a data mapping issue in determining what are the present components with what were past components. The TEST ID is the test name itself; TESTING AGENCY is who administers the exam. A complete listing of ALL tests needing storage in PS must be developed. Implementation team will need to review all current testing in SIS and map it for conversion; we need to accommodate the electronic feeds (ACT, SAT, etc.) and make sure we have the appropriate mapping. New electronic feeds--TOEFL, IELTS, Compass, SATII, GMAT are desired and needed. Current Input Sources: ACT, SAT, GRE, MCAT, AP, LSAT, CLEP, HKLE, A, O, TOEFL, MILLER ANALOGY, IELTS, GMAT, IG, COMPASS, ESL, WAEC, PRAXIS, NURSING (NCLEX), ALEKS, OGT, REGENTS EXAM, SATII. Regional campuses use ACT COMPASS--needs to be added to provided list of exams; manual exam loads are used for A's, O's, HKLE's, and ALEKS; with TOEFL, it is notated as to what career will be receiving the scores; some exams are delivered based upon a delivery schedule; A complete listing of ALL tests needing storage in PS must be given; OU NEEDS TO GATHER LIST SO THAT THE APPROPRIATE CONVERSION MAPPING CAN BE SET UP; TNAM will be a potential source for identifying tests, their components and min/max scores; External Test Score Mapping If OHIO is noting ethnicity, the right code must be mapped to the right test; AP country codes must be mapped to the appropriate PS country codes; academic interest can be mapped to program/plan. Test score Flow from PS to OnBase Imaging system OHIO will load stest scores to PS; there is also a flow of data to Recruitment Plus. Recruitment Plus currently allows viewing of the SAT essay--this is lost in current SIS system; any source documents that will complement will be brought into HIGHLAND OnBase document Imaging system;


70

OHIO will load scores into PS, and will then push to Recruitment Plus in order to capture EMPL ID.

Processing External Test Scores FIT: NO

External Test Score Load Scores are manually brought in -- an automated process where scores are pushed to shared drive, and a scheduler updates student records as desired; ETS has an FTP process to pick up scores (was not the appropriate FTP for SIS); NOTE--whatever new host will be used, we need to establish software needs for automatic transfers. PeopleSoft does not deliver an out of the box process for loading Compass, or IELTS scores. This would be a custom build. It was decided that all Test Scores received (Electronic and paper) will be loaded directly to PeopleSoft. Paper test records received will be entered into PeopleSoft AND will be scanned and indexed into Highland OnBase document imaging system and become a part of the OnBase file for the particular student. The interface from PeopleSoft to Recruitment Plus should include posting test scores to Recruitment Plus; this will reflect current business process and need. OHIO will load scores into PS, and will then push to Recruitment Plus in order to capture EMPL ID. Current Input Sources: ACT, SAT, GRE, MCAT, AP, LSAT, CLEP, HKLE, A, O, TOEFL, MILLER ANALOGY, IELTS, GMAT, IG, COMPASS, ESL, WAEC, PRAXIS, NURSING (NCLEX), ALEKS, OGT, REGENTS EXAM, SATII; Regional campuses use ACT COMPASS--needs to be added to provided list of exams; manual exam loads are used for A's, O's, HKLE's, and ALEKS; with TOEFL, it is notated as to what career will be receiving the scores; some exams are delivered based upon a delivery schedule. Test Score Suspense Data You have the ability to purge the suspense file (anything that did not match/load). All error messages will be listed, and there will need to be someone in office who reconciles suspense files. Search/Match and Post This is a delivered process. External Test Score Purge This is a delivered process.


71

Data Source/Testing Agencies This field is a translate table--thus allowing for additions/subtractions. Part of configuration will be to get the appropriate testing agencies for all external test scores.

Undergraduate and Graduate Business Processes

FIT: Yes

Need to recreate the online application interface to PeopleSoft. Need to give CollegeNet the list of institutions needed to record prior education. Need to look at imaging system and review process. This can be used to benefit Graduate Admissions and International as well as Undergraduate Admissions. PeopleSoft allows for admission offer acceptance or decline through self-service. When the student accepts an offer of admissions an admission action of "intent to MATR" is inserted to the program / plan stack. Go Live dates will affect when certain parts of the system will need to be ready. Checklist assignment can be done automatically through 3C triggers. It is recommended that Graduate departmental checklists be assigned, completed, and monitored by the department. Graduate application form can be imaged and loaded to OnBase. This will allow for a centralized queue area for Graduate admission materials, thus allowing committees to access docs for decisions. OHIO has a rolling admission process. CollegeNet didn't have a list of institutions -- there is still an issue with school/college loading to SIS correctly. Adjustments are still made to application manually because applicants will enter the address or name info incorrectly. International directly enters paper applications into CollegeNet. OHIO has prospect records already in SIS and thus need less data entry for applications. OHIO wants a consolidated screen for entry of applications that does not require the user to navigate too many screens to get the application loaded. It is recommended that a robust interface be built from CollegeNet to PeopleSoft for each application and that few paper applications are printed. Messaging to all students and the guidance community should be to submit the application online whenever possible for the student. It is not recommended to modify the system to accommodate quicker data entry for a smaller percentage of the overall application pool. Instead it is recommended that the staff enter the paper applications into CollegeNet initially and then edit the application after it loads to PeopleSoft as needed. Graduate Admissions edits information as the student goes through the process and additional changes are made after decision.


72

Undergraduate Admissions will be live with imaging before Graduate Admissions and International. Students can review admission status online. Housing deposit is the place holder and is due by (May 1). Housing process is tied to the deposit and the business process only allows for collection of the housing deposit at certain times. OHIO emails are assigned at time of registration. UGRD and GRAD need app ready by Aug 1 a year prior to go-live date. College of Medicine needs to be ready by June 1 a year prior to go-live. Regional campuses stop accepting applications 14 days before start of the term but may continue to accept as enrollment needs shift.

Com Business Process FIT: Yes

We should be able to interface e-application to feed into PeopleSoft. Supplemental form will function as a maintenance form for the submitted applications. New checklists can be made to ask for supplemental form, test scores, etc. We need to know the record layout from the service so that the interface can be built; interfaces need to be ready by August in order to be ready for a fall XX go-live date. GO-LIVE DATES WILL AFFECT WHEN CERTAIN PARTS OF SYSTEM NEED TO BE READY (I.E. APPLICATION, SCORES, GRADES, ETC.); Application process upholds rules set by Osteopathic organization. There is an initial application, additional applications if necessary, and an interview. There is a cross check of the e-app with a paper application. Additional application is an institutional application and it is a PDF sent to the student that is printed and mailed in with a $30 payment. $100 is due 2 weeks after acceptance. $500 is due at enrollment. Students are given OAK ID once accepted and paper forms are coming from OM service. Undergraduate and Graduate admissions application interfaces need to be ready by Aug 1 a year prior to go-live date. COM needs it by June 1 a year prior to go-live. COM has dual degree combination: DO/MBA and DO/PhD.

Continuing Ed Business Process FIT: Yes

Paper applications are received and entered manually. This process will be in tandem with Undergraduate process. Initially, business practice will be looked at separately from undergraduate.

Transfer Business Process FIT: Yes

An image from online application can be created in OnBase for later review by committee; departmental checklists items can also be set up. Communication between department and admissions will need to be fine tuned to eliminate duplicate information. TIME WILL BE NEEDED TO SET UP ONLINE TRANSCRIPTS AND UPDATES TO CLEARINGHOUSE.


73

Fill out a form which has BIO-Demo data on it; docs are requested; PeopleSoft has a delivered process for loading e-transcripts. OHIO has dual admission--those who don't qualify for main campus, can have admission for next fall, but have to attend community college and get guaranteed entry the next fall (creates a transfer record). Those in this category are sent the offer for dual admission instead of a denial letter. County is a required field for OHIO applications and this affects dual admission (this is a free form field in PeopleSoft.

No Shows FIT: Yes

Fees can be waived for anyone who is deemed necessary; for those who reapply and were no shows initially, the same level of effort by staff is necessary to process admission application. No shows currently have their record remain until a clean-up is done. There is a process that runs to adjust the decision code to FN (no show) and applications are not purged/recycled. Those who come after one year will have to reapply through the regular process and pay fee. Those within a year can be reactivated with no application fee assessed. An update form is filled out and a "new" application is created. Graduate admissions currently will keep the applications for one year and those applicants whose applications are inactive for one year must reapply with fee ($25). Regional are basically same as main, but no fee is charged upon readmit. If interface is setup for COM admission application, reporting will improve in this area.

HS Students Taking College Courses FIT: Yes

PSEOP= Post Secondary Options Program. OHIO will set up ‗PSEOP‘ as an admit type. Configuration requires a determination of how to code them. HS (High School). The new 'Seniors to Sophomores' program will need to be an admit type. These students are referred to as HS Non-Degree and must go through the PSEOP program. Regional campuses also administer students through PSEOP. In the past, those who missed the application deadline were admitted as a non-degree. PSEOP students are also coded non degree in the system. OHIO has a new program that will allow Sr's to complete Sr year on a college campus (these may, or may not, be PSEOP). The program is called "SR to SOPH Program". Admission requirements are different; normal ND and Exchange students will be in this same admit type.


74

Distance Learning (Continuing Ed) FIT: Yes

High School students can take courses, but are not covered under PSEOP (have to pay costs). They need recommendation from superintendent or principal and they complete enrollment form and do not apply for admission. There are not a lot in this category but most are PSEOP. OHIO Without Boundaries are degree seeking students and are in the Graduate area. Special students can only take a limited number of courses at this level.

Summer Transition Program FIT: Yes

Students who are denied, appeal, then still denied are admitted for summer, and possibly gain admission for fall if they successfully complete a recommended course of study. A student group may need to be developed to track these students for eligibility to return.

Sixty Plus Program FIT: Yes

This will require a student group to be set up for tracking and reporting purposes.

Adding New Applications Manually FIT: Yes

Search/Match OHIO can search all records in the system for a person or an organization. Search criteria are delivered and can be adjusted to strengthen search / match or allow fewer search results. This is configured by the institution and normally by a Campus Community Steering Committee. Searching for an Applicant OHIO will use the CS Person Traditional search in Search/Match. Entering or updating applicant bio/demo data Prefixes will not be used at the student level and will only be used by department, area, or with parent. Entering application program data Data is sequenced in order to show history of applicant progression (i.e. from applicant status to admit). Once admitted, a student can accept admission offer via self-service (this function can be turned on or off). Entering application data


75

Program Action will always default to APPL (applicant) status and application date is the date stamp from CollegeNet. The ‗created on‘ date is the date it was loaded to the system. CollegeNet loads date and reference number can be stored in the external application field for cross referencing. Warning on application for last school attended does not feed "external education" data. Once an application is saved, it is then ‗attached‘ to the person record. Calculating the application fee when entering a new application The calc app fee is set up to show charge/payment of app fee. There is a fee type that can be described. OHIO may need to adjust the fee type drop-down to correlate with OHIO fees. On the load process for admission you can have a one item checklist termed "application fee". A CollegeNet conversation is necessary to ascertain whether real-time updates are possible. It is advised to touch base with other PeopleSoft/CollegeNet schools to see how they are dealing with application fees. OHIO will check bundle release notes for e-app updates to PeopleSoft 9.0 Student Financials would like to have a history of the charge and payment on the student account. CollegeNet sends a monthly check-with roster-once a month (this may cause an issue in that a charge will show on the account)--the roster is sent to each department (GRAD, UGRD, etc); Some parents want detailed statement of every dollar paid to the school because application fees are added to account detail. Entering program actions Program Action will always default to APPL (applicant) status; Delivered Actions:

ADMT=admit, ADRV=admission revocation, APPL=application, COND=conditional admit, DATA=data change, DDEF=defer decision, DEFR=defer enrollment, DEIN=intention to matriculate, DENY=deny, MATR=matriculate, PLNC=plan change, PRGC=program change, RAPP=readmit application, RECN=reconsideration, WADM=administrative withdrawal, WAIT=waitlist, WAOF=waitlist offer, WAPP=applicant withdrawal;


76

OHIO needs to know more about the action codes in order to align it with their process (may need to add codes). It is highly recommended that the delivered codes be used. OHIO has need for provisional (those admitted but still need docs), and have two different conditional admits (those who are not quite to standards, and need to prove themselves). OHIO will set "intent to MATR" when student pays housing deposit. MATR will occur in a batch process after deadline of May 1 or shortly before Pre-College Orientation. Entering recruiting information for an application Empl ID pre-populates on an application if the person had been a recruit Adding communications, checklists and comments for app When saved, checklists are automatically able to be viewed on self-service (real-time); Checklists be added to the admit letter.

Checklist Items FIT: Yes

If necessary, prospect checklists can be created. See appendix A for applicant/admit checklist requirements. Scanned citizenship docs need to be made available to regional campuses. DOB form is sent when DOB is not submitted on the application. See appendix B for admitted student checklist requirements. Some international students may have limited to no access to internet--may need physical mailers for checklists items.

Auto-Decision FIT: NO

There is no auto admissions decision program delivered with Campus Solutions. There is interest in developing a customization. However, specific parameters will be determined at a later date. This is a moderate modification depending on the complexity of the admission criteria.

External Education FIT: NO

Campus Solutions does not compute a cumulative attempted academic GPA for admission decision purposes. This would be a minor modification to the system to develop a calculation call function when a student has attended more than one institution and wishes to transfer to OHIO and needs to meet a specific GPA/hours requirement to gain entrance to the University.


77

Transcript Date is the date the transcript was generated by the generating school. This is what financial aid uses to note final verification for aid purposes. It is advised to set a default date for graduation.

Test Results FIT: Yes

It is best, when possible to have scores come electronically from the testing agency; otherwise, it is a labor intensive process to enter all test scores. OHIO may wish to index scores on HS transcripts in OnBase to extract that data and populate necessary PeopleSoft tables.

Basis of Admission FIT: Yes

This notates why we admitted someone (different/more specific than action reason). The description on this panel is an extractable field for publication in a communication

Application Student Response FIT: Yes

Can be turned on or off in self-service set up or data can be entered manually through application maintenance. This allows for students to notate that they are going to another school and why they are going to that school. This screen can also be used for those coming to OHIO to notate why they ARE coming to the university.

Quick Admit / Quick Enroll FIT: Yes

Fits; no comments

Admitting Students FIT: Yes

Program Actions Program Action will always default to APPL (applicant) status; Delivered Actions:

ADMT=admit, ADRV=admission revocation, APPL=application, COND=conditional admit, DATA=data change,


78

DDEF=defer decision, DEFR=defer enrollment, DEIN=intention to matriculate, DENY=deny, MATR=matriculate, PLNC=plan change, PRGC=program change, RAPP=readmit application, RECN=reconsideration, WADM=administrative withdrawal, WAIT=waitlist, WAOF=waitlist offer, WAPP=applicant withdrawal;

OHIO needs to know more about the action codes in order to align it with their process (may need to add codes) OHIO has need for provisional (those admitted but still need docs), and have two different conditional admits (those who are not quite to standards, and need to prove themselves); OHIO will set "intent to MATR" when student pays housing deposit - MATR will occur in a batch process after deadline of May 1 or shortly before Pre-College; Matriculate Students Delivered Actions:

ADMT=admit, ADRV=admission revocation, APPL=application, COND=conditional admit, DATA=data change, DDEF=defer decision, DEFR=defer enrollment, DEIN=intention to matriculate, DENY=deny, MATR=matriculate, PLNC=plan change, PRGC=program change, RAPP=readmit application, RECN=reconsideration, WADM=administrative withdrawal, WAIT=waitlist, WAOF=waitlist offer, WAPP=applicant withdrawal;

OHIO needs to know more about the action codes in order to align it with their process (may need to add codes)


79

State Transfer Initiatives in OH FIT: NO

Clearing House EDI -Translation program needs to be written at OHIO or bought/gotten from another school. OHIO can look to Bowling Green to see what they are doing. Component Interface and App Engine can be used to load external data. OHIO is mandated to send and received transcripts electronically. PS Delivers EDI capability but there may need to be further investigation to this process to gather specific requirements from a technical perspective. There may be a need to be an interface in this process with the Imaging system, OnBase to capture the document. Transfer Assurance Guides Gen Ed required courses that are taken at any state school. 38 guides exist, Core + major requirements. CAS (Course Applicability System) OHIO uses CAS. Data translations to and from CAS and DARS. Need a tech fit gap. DARS product and its maintenance are mandated by the state of Ohio to provide students with a central place to research course equivalencies within the state. There was some concern how automated the maintenance would be. There is no delivered interface to DARS or CAS and this would have to be written. This is a moderate interface that would need to be written to push information. Quality point deficit Need a quality point deficit showing continuously. Currently, the admissions decisions include remediation. OHIO needs to decide whether to continue to calculate a cumulative GPA for admissions purposes based on a GPA that includes remediation. Need a cumulative transfer GPA calculator that will calculate a cumulative transferable GPA for Admissions purposes. OHIO system currently calculates and stores the quality point deficit a student may have. This feature is not offered with Campus Solutions and the system would have to be modified. This would be a Moderate modification/ External Education to Course credits manual - No fetch process. The system does not have a 'fetch feature' where the courses entered manually in external education would auto-populate the manual course credits screen. This is a typical and minor mod request. Transfer Credit Report If PS Transfer credit is used. There may be a need to modify the transfer credit evaluation report to provide a Key of terms used on the form. (Legend)


80

Transfer Processing FIT: Yes

Transcript received current student or new. Freshman and Transfers have to be admitted to enter courses. Graduate programs tell admissions which courses will transfer. Send to college to equate if it is not equated already. Most international courses do not have transfer course equivalency. They have loaded some equivalency. OHIO transcript produces summary information for students on Transfer probation students. Students have a combined GPA to graduate. Need to distinguish between -- no grades entered T grade assigned and TP for pass/fail. There is a proposal to centralize transfer credit processing. Grad mass hours: OHIO completed grad degree from somewhere else, certain number of hours Dummy course with hrs posted to reflect degree.

Set up Transfer Credit Processing: FIT: Yes

External Education subject table must be set up. School subject maintenance allows for grouping. External subject information can be reported on a transcript, self-reported, or reported from another source. Storing this data is useful for grouping subjects. For example, if your office tracks subject area requirements but does not want to enter or load all of the external courses that a student has taken, you can record course level, number of courses, units, external GPA, and converted GPA details about external subject areas. You can add multiple rows to enter external subject data. Records set up must have been set up before you can configure. Courses offered check box needs to be checked. Transcript translation check box for electronic transcripts must be checked. System defaults: May need International School Types, this would be a modification. Recommend to not do this if possible. Conversion: Some duplicates exist in legacy org table so a fresh unduplicated data source is needed. You can attach study agreements to individual student records on the External Study page of the Term Activation (STDNT_ACTIVATION) component. Study agreement codes are normally used to represent study abroad, exchange, and visiting programs.

Processing Transfer Credit FIT: Yes

During this timeframe, Leslie demonstrated transfer credit for the group. There will be significant work in this area building the external catalogs if PS Transfer Credit will be used. The group was concerned about abandoning DARS. But if DARS is kept then an interface will


81

have to be developed. OHIO does not use DARS to its fullest capacity. The end of the session the decision was still not certain whether to use PS Transfer credit or not. Final determination on fit will be needed based on the decision to use PS transfer credit or to remain with DARS.

Deleting a prospect/applicant record FIT: Yes

There are ways in PS to delete the prospect record without the person being deleted. Batch job or process on line. Currently in SIS have a batch job that deletes prospect records Batch job in Recruitment Plus. Data warehouse only carries 5 years of data. It is refreshed nightly. If duplication occurs for an application, it must be resolved.

Viewing Summary FIT: Yes

Viewing summary application materials information Can view through self service view. SIS - Summary Screen - no detail information SIS - Application screen for details College Net tracks name of recommender that will be sending the letter of recommendation Viewing a summary of an applicant‘s progression No view currently in SIS Viewing summary recruiter information Recruitment Plus provides same type of information. Viewing prospect summary information Can write queries which can be stored in favorites or possibly through a menu item setup. Viewing prospect/applicant general materials summary Could have a comment code or evaluation status used to track the file or to drive OnBase queue Need to track file location (is the file with the Dean's office for review) Viewing summary checklist, comment, and communication data


82

Can view through self -service and through the management page Viewing schools by groups Fit; no comments Viewing groups of prospects or applicants Fit; no comments Viewing a person‘s account summary Might be helpful for International students - especially housing deposits Need to know if they have a SF hold. If access is given this is possible. The user has to understand the summary information they are viewing. This is a training issue. Viewing application evaluation summaries Fit; no comments

Communication Generation FIT: Yes

This has to do with WHERE communications will be generated for prospects and applications: OHIO Athens Undergraduate Admissions and Graduate Admissions at the end of the fit/gap sessions decided that they would continue to use Recruitment Plus. The Regional Campuses were not completely sure whether they would use Recruitment Plus or move to using PeopleSoft Recruitment/Prospecting. The College of Medicine decided to use PeopleSoft Recruitment. An interface from PeopleSoft to Recruitment Plus is required. It is imperative that the recruitment system be updated when a student applies to prevent further encouragement to submit an application when the application has already arrived. In using two systems, the University will have to decide which communications are generated from Recruitment Plus and which are generated by PeopleSoft. Normally, all recruitment communication will come out of Recruitment Plus and admission decision and processing letters would generate from PS Campus Solutions. However, there is the capability that you could continue to use Recruitment Plus to communicate past the recruitment phase. If this is done, and the institution would like the communication history to be in PeopleSoft, the interface would need to be a two-way interface bringing communication history from Recruitment Plus back in to PeopleSoft.

When using the letter generation process, you can set the frequency that the letter generation extract is generated using Run Control and the Process Scheduler. It goes without saying that training on any of these processes is required. ( I think that was just typing of a statement that was voiced - it can be scratched from this document unless you feel that it is required to state that training is needed.)


83

Process Flow - Freshman and Transfer Process with OnBase

FIT: NO

Two generic interfaced process flows were demonstrated during fit/Gap using PS and OnBase document imagining. There is no delivered interface and this would require a moderate modification to build real time processing between the two applications. It has been done at other clients and I would strongly suggest that it be done here at OHIO. I used examples from NIU, where it has been done before.



External GPA Type Table

Define GPA types for external education data.

External Education Comments

Default comments for external education entry.

Test Component Table

Define components for external tests.

Test Tables Define Test IDs and score ranges for external tests.

External Test Score Mapping

Map test IDs to PeopleSoft defined test codes.

Ethnicity Mapping

Map ethnicity codes from the testing agencies to PeopleSoft ethnic group codes.

AMCAS Ethnicity Mapping

Map ethnicity codes from AMCAS to PeopleSoft ethnic group codes.

CRS Major Codes

Define major codes for CRS search tapes.

SAT Math Recentered Values

Define math recentered values for the SAT test.

SAT Verbal Recentered Values

Define verbal recentered values for the SAT test.

Referral Source Table

Define the source of referral for a prospect.

Admissions Installation

Define installation options for recruiting and admissions features.

Region Table Define regions for prospect and applicant recruiting.


84

Admissions Action Table

Define program actions for application processing.

Teaching Subjects

Define teaching subject for OUAC processing.

CEGEP Program Table

Define the CEGEP program table for OUAC processing.

SAT II Test Codes

Define SAT II test codes.

External Summary Type Table

Define summary types for external education data.

Enrollment Target Population

Define populations for enrollment target processing.

Enrollment Target Division

Define divisions for enrollment target processing.

AMCAS GPA Codes

Define GPA codes for AMCAS tests.

Law Categories

Define law categories for OUAC processing.

AP Country Codes

Define country codes for AP tests.

AP Subject Test Codes

Define subject test codes for AP tests.

GRE Subject Test Codes

Define subject test codes for GRE tests.

Program Action Reason Table

Define program action reasons for application processing.

AMCAS Credit Hour Codes

Define credit hours codes for AMCAS tests.

Basis of Admission Table

Define basis of admission codes for application processing.

ADA Country Codes

Define country codes for ADA tests.

Extracurricular Activity Map

Map external extracurricular activities.

GMAT Country Codes

Define country codes for GMAT tests.

SAT II Test Recentered Values

Define SAT II test recentered values.


85

Region Postal Table

Define postal code ranges for regions.

Religious Preference Map

Map external religious preferences.

Academic Interests Map

Map external academic interests.

Enrollment Target Cohort

Define cohorts for enrollment target processing.

Admission Comments Table

Define admissions comment codes for application processing.

Rating Comp Definition Table

Define rating components for application evaluations.

Evaluation Status Table

Define statuses for application evaluation.

TS130/TS131 Setup

Set up TS 130 and TS 131 and define contacts.

Material Group Table

Define materials groups for application and general materials.

Application Center Table

Define application centers to assign to applicants.

External GPA Rules Table

Define GPA rules for external education data.

Recruiting Center Table

Define recruiter centers to assign a prospect.

Admit Type Table

Define admit types for prospects and applicants.

Recruiting Category Table

Define recuiring categories for prospects and applicants.

Response Reason Table

Define reasons an applicant is attending another school.

Web Prospect Create Table

Define the structure for prospect self service Request Information feature.

Rating Tables Define rating schemes for application evaluation.

Evaluation Tables

Define evaluation codes and committees for application evaluation.

Average Cutoff Table

Define cutoff ranges for alternate admissions offers.

Alternate Average Calculations

Define rules for calculating alternate admissions averages.

Alternate Offer Table

Define rules for alternate offers of admission.


86

Early Financial Aid Categories

Define the types of financial aid considered for an early financial aid offer.

Early Fin Aid Categories

Define early financial aid categories.

FINANCIAL AID

87

Section 7 Financial Aid CIBER Leads: Julie Simpson and Micah Marin OU Process Owner: Jill Lallier OU Leads: Steve Flaherty, Shelley Ruff, Debra Benton, Kim Trout, Jean Lewis Fit/Gap Sessions were held from April 14 to April 17.

The following is a detailed summary of the Fit/Gap sessions that were conducted for the Ohio University Financial Aid Office detailing the fits and gaps within the PS Financial Aid Module. Each area was discussed in length in determining the current business processes and policies and how they would work within the PS Financial Aid Module.

Aid Year FIT: YES

The Financial Aid awarding cycle is a set of recurrent operations used as the institution processes and manages student data to evaluate, award, and disburse federal, state, institutional, and private funding. One of the first steps in setting up the awarding cycle is to define the boundaries of each financial aid year to maintain separate and unique financial aid years throughout a student‘s educational career.

Three standard terms and one non-standard, summer term comprised of sessions

10 base weeks of instruction for standard term and 10 base weeks of instruction for non-standard term

Medical may have early aid year start date

Summer is a header for the financial aid year

Financial Aid Terms FIT: NO

A Financial Aid term is the combination of a period of time that an institution determines as an instructional accounting period and an academic year. Only terms eligible for financial aid are established for each financial aid career. Thus, at OHIO, the Winter Intersession term will not be established as a financial aid eligible term. Many downstream financial aid processes (budgets, awarding students, originating student loans, requesting Pell funds, and disbursing aid), are dependent on having the financial aid term built for a student.

Summer, Fall, Winter, Spring terms built in FA Term

Financial Aid terms build on three career types: medical (MED), graduate (GRAD), and undergraduate (UGRD).

Non Financial Aid eligible programs will not build FA term

The OHIO financial aid system currently interfaces with an online application (Enrollment Confirmation) that is used by students to inform the office of their planned enrollment for the academic year. This application is used primarily for

FINANCIAL AID

88

summer aid awarding. This interface will still need to exist as OHIO implements the PS application.

Gap - Projected enrollment data is used prior to a term until the point of disbursement for the term. At the point of disbursement, actual enrollment is used with updates based on enrollment changes through the census date. This functionality will need to exist in the new PS system.

Gap - If a student changes campus of enrollment during fall/winter/spring from Athens to a regional campus, the campus of attendance is projected forward for the remainder of the quarters of the academic year with budget and appropriate aid recalculations. Regional campus enrollment at any point during fall/winter/spring is projected forward for the remainder of the award year. Staff internally have a mechanism to ―lock‖ enrollment and campus of attendance for any term that has not yet begun. Automatic updates of enrollment for upcoming quarters and the ability to ―lock‖ enrollment and campus are not current functionality in PS.

Second UGRD degree, it is recommended that SR use a separate program for these students so that they will be easily identified. It will need to be able to be determined that a student has a Bachelor‘s degree – whether from OHIO or another institution for aid determination.

Possible Gap – There is no field displaying a prior degree value for a student other than the ISIR. It is not our current or desired practice to correct a student‘s ISIR if OHIO shows that the student has a degree, but the FAFSA is discrepant.

Institutional Student Information Record (ISIR) Processing

FIT: NO

A student‘s application for financial aid begins with the receipt of the student‘s FAFSA information contained in the ISIR data record sent by the CPS. Once this information is loaded into Financial Aid, the evaluation of a student‘s financial aid eligibility begins.

Receive and send ISIR data- Gap - Ohio University requires that this be an automatic process for sending and receiving ISIR data and not a manual process. There is currently a modification available from University of Michigan that can be used to automate message class batch loading.

ISIR data will be loaded with ―Call Institutional Need Analysis‖ (INAS) checked

Data elements from ISIR used: 1. Address if blank 2. Email will be discarded 3. Phone if blank 4. Driver‘s License if blank 5. Update Bio/Demo (DOB, Alien Registration number, Social Security Number,

Gender, Date of Birth, Citizenship and Marital status – OHIO will need to have further discussion about how/when to update Bio/Demo data – this could possibly be a responsibility of a Campus Community Committee.)

FINANCIAL AID

89

ISIR to be loaded: 1. Admits and higher 2. New ISIR if current ISIR in PS is rejected ISIR 3. Other school initiated corrections 4. Student initiated corrections based on ―Discrepancy Load‖ rules

ISIRs to be suspended: 1. Non-applicants 2. Student initiated corrections (after packaging has happened). 3. ISIR with EFC mismatch (after packaging has happened).

ISIR Search/Match current practice for OHIO is to match only on Social Security number, recommend that search match be set to 10- Social Security number (SSN), date of birth (DOB) and first two letters of last name (suspend multiple), 20- SSN and first four characters of last name (suspend all) and 30- SSN and DOB (suspend all)

Suspense Management will show the reasons as to why an ISIR did not load and will remain in suspense management until the student either meets the load status of admitted or if there was a SS mismatch from converted legacy data, the ISIR would load if that was changed in campus community (same for name changes, etc.).

Process to bring in ISIR‘s from file and to generate file (automatically scheduled process).

Gap - EFC Proration is set as a global rule when bringing in ISIR files. OHIO requires that the proration change nightly for a student based on their projections of their enrollment (3 month, 6 month, 9 month, 12 month EFC calculations). PS processing only runs INAS calculation once when an ISIR loads.

Verification FIT: NO

Verification is the process of checking the accuracy of the information supplied by students and their families when applying for financial aid. Institutions are required to perform federal verification on a portion of their aid applicants for the purpose of awarding Title IV aid.

Ohio University is a Quality Assurance school. As such, verification parameters are established at the school level and override CPS verification selections.

Verification must be complete before packaging, in general. However, at the point of initial freshman packaging through the initial upperclass packaging – freshmen do not have to be verification complete to be awarded.

Gap - ISIR selected for verification have to have a process to apply appropriate checklist item during ISIR load process. Process should also remove or complete checklist items, as received and processed. There are other schools that have a modification to apply these checklists during the ISIR load process.

Permanent checklists for Certificate of Naturalization, Birth Certificate, etc. need to be carried with student record from year to year and also apply to aid year specific

FINANCIAL AID

90

requirements. Currently, documentation is requested each year. As these will be requested automatically in the ISIR load process, the population selection tool could be utilized to roll this information from year to year and to apply specific checklists for aid year requirements.

Students are either sent a paper Missing Information Letter (New Freshman) or an email (Returning students) instructing them to go check self-service for checklist items. Students also have the option to select paper only Missing Information Letters and not email notification.

Ability to run verification in a batch process for data entered and use a $400 tolerance level for this processing.

Ability to make changes in simulation to see if a student will have a change in their EFC.

Ability to take the changes made in simulation and use those for an ISIR correction.

Student Budgets FIT: NO

The Cost of Attendance is an estimate of a student‘s educational expenses for the period of enrollment. The budget helps establish a student‘s need (Cost of Attendance minus the student‘s expected family contribution), which permits the financial aid office to award need-based aid.

Undergrad budgets- off or on campus, in or out of state and in-state living with parent

Graduate budgets- in or out of state, on or off campus

Medical students- in or out of state, and also for year of study

Budgets are term-based

Budgets are based on enrollment level; full-time, three-quarter-time, half-time, and less than half-time. Prorated amounts are used for some budget categories for less than full-time enrollment.

Categories: tuition & fees, room & board, books & supplies, travel and personal expenses

Professional judgment categories: child care, computer purchase, out-of-pocket medical & dental expenses (independent student only) and increases in books & supplies or travel – many others, list to be provided by Financial Aid.

Various program budgets for studying abroad, foreign study, transient study, other unique programs; manually entered.

Considering calculating tuition (account type = TUIT) from SF to cover course delivery fees & off campus fees, but will average tuition for initial prototype

Consider auto increasing budgets for books & supplies based on programs

FINANCIAL AID

91

Budget based on highest tuition amount- considering recalculating tuition amount on actual tuition billed & adjusting total budget

If ISIR data for housing is blank- use the lowest budget item amount; if residency is blank use the lowest budget amount

Gap - Ability to lock certain budget categories while allowing others to be rebuilt when there are changes to enrollment, etc.

Ability to lock budgets so that no changes are made to any budget item.

Ability to calculate based on weeks of instruction for those students who are only taking one 5 week session in the summer term.

Item Types/Fund Management FIT: YES

Item Types are the basic units for awarding aid to eligible students. They work in conjunction with student financials and are tied to specific general ledger accounts.

Item types are tied to correct GL accounts

Currently using approximately 2000 item types

Awarding/Mass Packaging FIT: NO

Mass Packaging is a background process that enables you to package a group of students using one or more packaging plans. Students are selected for packaging, and the system assigns the appropriate packaging plan to each student. No matter how a student is packaged, a validation process must be performed to check that all federal eligibility rules, aggregate aid limits, fiscal fund balances and rules, award rules and limits, and packaging plan rules are met. In PS, this is done by running a validation process as the final step in awarding aid.

Packaging based on federal methodology

Verification must be complete before a student is packaged, in general. However, at the point of initial freshman packaging through the initial upperclass packaging – freshmen do not have to be verification complete to be awarded.

All checklist items must be complete before packaging except for specific checklist items that are for counselor action or don‘t impact packaging. However, at the point of initial freshman packaging through the initial upperclass packaging – freshmen do not have to be verification complete to be awarded.

Students are packaged for their planned enrollment according to projected enrollments or data from the interfaced Enrollment Confirmation application. Students are packaged for 1 term, 2 terms, 3 terms, or 4 terms – according to their individual data.

FINANCIAL AID

92

Plus is not packaged upfront

Veteran‘s benefits are placed on before mass packaging if known. Monthly education benefits are not considered when determining need-based aid, but should be considered as a resource when determining unsubsidized Stafford Loan eligibility

Graduate students and Medical students are only packaged with Stafford Loan.

Graduate Assistantships will reside in the Financial Aid module due to extensive array of rules associated with disbursement. An interface to the current Online Graduate Appointments (OGA) will need to be built.

1. Waivers – Graduate Studies – GAP HIGH

2. OU has a system (OGA) system that handles the waivers and this is also an interface to the FA legacy system. When the interface runs, it determines if there is an account code in the FA legacy system that matches the waiver and if not then the OGA interface creates a new account code that will handle the new waiver. - GAP

3. The following are the types of waivers for OU:

o Stipend Awards – OU will continue to process these awards through

payroll.

o Tuition only scholarships – These will continue to be entered manually and SF and FA will need to work together to allow Graduate Studies to have security access to put on these specific scholarships.

o Fellowships – OU can put these awards on through the FA module and

disburse the aid according to the rules of the fellowship (monthly, weekly, etc.).

o Gap - Educational Waiver – these are internal waivers and are processed

through the OGA and post to SAM. These waivers are given to local and/or state school districts for them allowing OU to place their education majors in student teaching positions within their districts. These may also fall into the modification due to the varying diversity in the awards.

o Gap - Continuing Education Waiver – Appointment is created, and posts

to SAM. Hours for these waivers are manually set and then they disburse the next day. There can be varying disbursement rules for these awards and they need to be changed on a student by student basis. Because disbursement rules can only go down to the item type level, it is recommended that this be combined with the OGA modification.

Gap - Spousal Awards – These are awards that are given to spouses of

students receiving a graduate assistant position. These work the same

FINANCIAL AID

93

as the Continuing Education Waiver and will need to be combined with the OGA modification.

The Pell Grant is packaged based on student‘s enrollment data within the system. . Pell is automatically repackaged nightly with the ability to exclude individual students from having their Pell repackaged.

Award letters sent via paper to new freshman and transfer students. All others receive notification via e-mail address to review awards online.

Athletes are packaged and manually adjusted once scholarship is known. Athletes can receive Pell Grant and athletic scholarship over the cost of attendance.

ACG and SMART grant have PS delivered process to obtain eligibility.

PS delivered equations for ACG and SMART grant for continued monitoring of eligibility.

Gap - Ability to show award messages to students in self-service. Functionality of PS online award letter is very limited compared to our current online award letter in regard to messages associated with awards.

Possible Gap – Campus or location is not an indicator in PS. This may prevent us from identifying certain awards be given to students on specific campuses. May be able to modify student ―groups‖ to resolve issue.

Authorization/Disbursement FIT: NO

The authorization process uses rules that are defined by aid year, career, and award. These rules allow or prevent the disbursement of awards for students in a particular career or for a particular award. Awards go through a validation process during awarding or packaging to check on a variety of rules and limits, but student information, particularly registration information, can change before disbursement occurs. The authorization process checks rules just before the disbursement of awards.

Disbursement rules are by fund type, not global rules and all disbursement rules are setup in FA

We will set up a procedure in which the FA authorizes the disbursement and the Bursar‘s Office disburses the aid

Pell, ACG, SMART, Ohio State Grants, OHIO Scholarships, External Scholarship, Stafford Loan, PLUS/Grad PLUS (may want to only defer once approved), Perkins Loan and SEOG pass to SF as deferments once bills run and prior to classes beginning. SF currently works with FA to determine the timing for posting deferments and expiring term deferments.

The default disbursement calendars setup in PS will work. Medical will have their own disbursement calendar.

FINANCIAL AID

94

Tuition waivers, tuition grants and scholarships only disburse for the amount student is charged for tuition and appropriate fees that the grant or scholarship will cover. There are many different rules that will pay different charges for each item.

FA has ability to override disbursement rules.

Gap - Ability to generate report on what items have been disbursed for a particular day which will show who has disbursed aid and how it was disbursed (batch or online). This is needed for daily reconciliation to student accounts.

Ability to run report to show why a student‘s aid is not authorizing for disbursement.

Assigning & Tracking Holds FIT: YES

Disbursement rules can be globally applied to students in a particular career, or applied to individual awards for a particular career. Disbursement rules are used when authorizing aid online and in the background authorization process. Global rules can check that packaging, federal verification, and review of the student‘s financial aid file are complete. You can add service indicators and tracking groups to be checked as a global rule. Global rules can include holding financial aid if the student has withdrawn, honoring any disbursement hold that might exist elsewhere in the system, and withholding disbursement for unsatisfactory academic progress.

OHIO can hold a student‘s aid if student is not properly enrolled, Satisfactory Academic Progress (SAP) status is not met, or a manual hold is placed on student‘s record.

Can force disbursement to override hold.

Pell Payment Processing FIT: NO

Pell awards are based on the students EFC and are calculated automatically by PS. The school must send origination and disbursement files to Common Origination and Disbursement (COD) in a delivered file extract.

Gap - Pell data is sent to Common Origination and Disbursement (COD) System in an automated process. An automated process will need to be developed in PS.

First Pell origination and disbursement record is sent after Pell is disbursed.

Pell Multiple Reporting Record (MMR) and Possible Over Payment Record (POP) reports are delivered.

Possible Gap - OHIO only originates those students‘ Pell awards if they have been disbursed for the quarter, and thus, are registered for that term‘s classes. PS does not have the functionality to trigger origination from the action of having been

FINANCIAL AID

95

disbursed. Thus, if this is a requirement for OHIO policy, then this is a Gap. However, this may be a business decision change to allow origination of Pell records prior to their disbursement.

Loan Processing FIT: NO

OHIO is a Direct Lending institution for GRAD and UGRD and a FFELP institution for MED. They will need to use both delivered functionalities. See following note regarding FFELP and Alt Loan Certification Flow:

FFELP and Alt Loan Certification Flow

Points to consider when using this document:

Lender Flow indicates the school‘s certification is first delivered to the lender for origination. The Lender will then reach out to the guarantor to obtain the guarantee based on the processing type code certified by the school (GP, PG, GO).

Guarantor Flow indicated the school‘s certification is first delivered to the guarantor. Once the loan is guaranteed, it is then passed to the lender for processing and disbursement.

OHIO Medical uploads all CommonLine files to ELM. However, this does not necessarily indicate a lender flow. There are destination tables set up within ELM that will route files based on criteria defined by the school.

ELM will take Application Send files from the school and split them up into smaller files to be routed to the appropriate loan originator (lender or guarantor).

Note: The information below represents how OHIO might transmit loans from PS (not

necessarily how ELM will transmit the files to the loan originator)

STAFFORD LOANS Great Lakes Guarantee Non- Great Lakes

Guarantee

ELM serviced lender Lender Flow, CRC Lender Flow, CRC

Non-ELM serviced lender Guarantor Flow (GL), CRC Lender Flow, Manual

(paper) or CLv4

Stafford loans will be school-initiated, meaning that the school‘s preferred process is to certify the loan BEFORE the student signs the promissory note.

Stafford loans will be transmitted using the GP (Guarantee and Print) processing type code.

ALTERNATIVE LOANS Guarantor not applicable n/a

FINANCIAL AID

96

ELM/Great Lakes serviced lender

Lender Flow, CRC n/a

ELM/Great Lakes serviced lender

Lender Flow, CRC & CLv4 or Manual (paper)

n/a

Alternative loans will be borrower-initiated, meaning that the school‘s preferred process is to certify the loan AFTER the borrower has completed credit-based requirements and the promissory note.

Alt loans will be transmitted using the GO (Guarantee Only) processing.

Gap - Direct Loan data is sent to Common Origination and Disbursement (COD) system in an automated process.

Using Sallie Mae OpenNet for Alternative Loans for UGRD and GRAD. MED will be using ELM.

Loan for students attending less than 3 terms, less than full-time are prorated manually.

Plus loans are not packaged. Parents must be created in PS campus community and relationship made to student. Suggested that they have on the request for PLUS loan a statement that has the parent sign to have the refund given to the student.

Gap - OHIO originates loans that are in an accepted status for students pre-registered for the term or for loans that are offered for the term, even if the student is not pre-registered.

Net amount shows to student in self-service.

Ability to mark a student‘s loan record as additional unsub due to PLUS denial.

Ability to mark a student‘s loan record as additional unsub due to Teacher Cert student.

Ability to print MPN‘s from system.

Ability to use eMPN functionality from DOE.

Perkins FIT: YES

Perkins loans are no longer funded by the Government, the funding used for new loans is the money collected on previous Perkins loans now in repayment for each school. Perkins will need to have a custom interface with the servicer of the loans (Campus Partners), and this communication is handled by the Bursar‘s office at OHIO.

Perkins is part of packaging formula

FINANCIAL AID

97

The FA office will send out the notification to sign the e-MPN in self-service. Suggested that the FA office have all students who receive a Perkins do a new eMPN in PS the first year of go-live.

Satisfactory Academic Progress (SAP) FIT: NO

Satisfactory Academic Progress (SAP) is the term used to define successful completion of coursework to maintain eligibility for student financial aid. Federal regulations require the Financial Aid office to establish, publish and apply standards to monitor students‘ progress towards completion of their degree program. If they fail to meet these standards, they will be placed on financial aid probation or suspension.

SAP is run after every term, including summer for time frame calculations.

Gap - Undergraduate SAP policy: maximum time frame for degree completion based on level of study (Associate or Bachelor) and degree plan (some plans have different time frame completion rates), minimum 2.0 GPA, and completion rate is based on census date hours of enrollment each term.

Gap – Graduate SAP policy: maximum time frame for degree completion based on Master level graduate students and degree plan (some plans have different time frame completion rates), minimum 3.0 GPA, and completion rate is based on census date hours of enrollment each term.

Aid can be canceled if no appeal is received or the appeal is denied

Once the annual SAP review after Spring Grades has occurred, students will go through packaging only if their SAP status is Satisfactory or Warning. Prior to the annual SAP review, students will only go through packaging (for the upcoming award year) if their SAP status from the previous award year is Satisfactory.

Ability to generate communications to student based on SAP status

Return of Title IV Aid FIT: YES

The Federal regulations require a school to return funds for students if they completely withdraw from the university. The student‘s awards are calculated to determine the amount that the student has earned, based on number of days in the term that they attended.

Bursar does Return to Title IV (R2T4) for OHIO

Calculation is done automatically: once student shows up on withdrawal report, the calculation of amount of aid earned is automatically shown based on term calendar

FINANCIAL AID

98

after the staff create a worksheet by adding the ID to the page and clicking on the calculate button.

Bursar and FA will need to work together to work out the business process to determine how they will identify those students whose aid needs to be adjusted

Student Employment FIT: YES

Student Employment is a campus based award that the school awards and monitors for each student.

Payroll information for all student employees is done in Oracle Financials, there will need to be a custom interface with PS to obtain and load the amount the student has earned in work study for the FISAP report.

There will need to be a custom interface between the FWS database and PS. This database currently manages – self-service selection of available work study position by student; communication between SFA office, supervisor, and student; monitoring of earnings and calculation of remaining hrs/week available to work.

FWS for returning students awarded based on if they had FWS the year before.



Define External Award Sources

Define sources of external awards.

Define External Award Types

Define external award types.

Financial Aid Installation

Define installation values required for Financial Aid.

Define Federal Aid Years

Define the aid year using federal guidelines.

Define Financial Aid Years

Define the valid financial aid years for the institution.

Valid Careers for Aid Year

Assign financial aid eligible academic careers for the aid year.

Valid Terms for Career

Define eligible financial aid terms, academic and loan periods for careers.

Define Define database commit levels for eligible financial aid processes.

FINANCIAL AID

99

Commit Levels

Define Demographic Data Use

Define how student bio-demographic information is used by financial aid processes.

PROFILE-Need Access Controls

Define PROFILE and Need Access run controls.

Maintain ISIR Comment Codes

Maintain the ISIR comment codes and their database match usage.

ISIR/SAR Cross Reference

ISIR/SAR Cross Reference.

Maintain NSLDS Codes

Review and update the NSLDS status codes.

INAS Assumption Codes

INAS Assumption Setup Pages.

INAS 2004-2005 Global Options

Define policies for Federal and Institutional need methodologies for 2004-2005.




Define policies for Federal and Institutional need methodologies for 2006-2007

Institutional Cross Reference

Track cross-references of field name to the institutional record field number.

Loan Fee Setup

Define loan fees which are calculated during the packaging process.

Aggregate Programs

Define Stafford, Direct, or HEAL aggregate areas to be linked together to combine loan limits.

Define Sort Order Fields

Update and review Financial Aid Award Notification output Sort Order Fields criteria.

Define Sort Order Names

Define Sort Order Names criteria for Financial Aid Award Notification output processing.

Maintain CRC Loan Status Codes

Maintain CRC status and error codes reported by the loan servicers.

School Codes for Institution

Define valid school codes for institution.

School Code Table

Maintain Title IV school codes by aid year.

FINANCIAL AID

100

Maintain Loan Servicer Codes

Maintain a comprehensive list of loan servicer codes.

Define Loan Report Definitions

Define field specifications and the output format for loan forms.

Equation Editor

Create and edit equations.

Equation Global Space

Work with Equation Global Variables in Equation Spaces.

Budget Tree Address Usage

Define which address type is to be used during the budget assignment process.

Define EDI Business Unit

Define the internal financial aid business unit used in EDI Manager processes.

Maintain EDI Transactions

Maintain the EDI transactions that can be viewed in the ISIR and Loan Review pages.

Maintain Loan Edits

Maintain CommonLine 4 validation edit list.

Maintain Loan Transfer ID

Maintain loan information used to generate loan files for transmission.

Maintain Guarantor Codes

Maintain a comprehensive list of guarantor codes.

Maintain CRC Loan Edits

Maintain list of Common Record CommonLine loan edits.

Create CRC Loan Edit Sets

Create sets of loan edits to be used in creating CRC loan destinations.

Aggregate Level Translation

Associate aggregate levels with academic level definitions from the Department of Education.

Aggregate Aid Limits

Define annual and aggregate aid limits for all sources of funding.

Aggregate Area Translation

Associate aggregate areas with programs from the Department of Education.

Maintain Loan Action Codes

Maintain loan action codes used by Direct Lending and CommonLine.

Maintain Lender Codes

Maintain a comprehensive list of lender codes.

Create CRC Loan Participants

Maintain lender, guarantor, and servicer information for CRC processing.

FINANCIAL AID

101

Create CRC Search Match Setup

Create search match setup conditions for CRC Certification Request processing.

Define School Guarantors

Define the guarantee agencies to be used for processing loans at the institution.

Define School Lenders

Define lending agencies to be used for processing loans at the institution.

Define School Servicers

Define loan servicers to be used for processing loans at the institution.

Direct Loan Change Rules

Define global change parameters for Direct Loan change, hold and suspense processing.

Hold and Release Equations

Define the equations used by the CommonLine Hold and Release process.

Reassign Loan Agencies

Define instances where one loan agency has been replaced by another.

Maintain Loan Report Packages

Setup and update Loan Report Packages for Promissory Note processing.

Setup Perkins MPN Options

Define Perkins MPN Options

CNAS Messages

Define Canadian need analysis messages.

Create Proration Rules

Define the criteria for pro-rating awards based on student enrollment.

Financial Aid Item Types

Define item types as financial aid item types for use in awarding various sources of funds.

Item Type Cross Reference

Map external awards to internal award items.

Search/Match Rules

Define search/match options to use during external award loadng process.

Fiscal Item Types

Define fiscal limits for existing financial aid item types.

Define Rules for Return

Identify financial aid item types used for Return of Title IV calculations.

CSL File Load Control

CSL File Load Setup Page.

Verification Tolerance Setup

Update verification tolerance values for Federal and Institutional processing.

Award Adjustment Reasons

Define reasons for why an award may be adjusted on the various Assign Award pages.

FINANCIAL AID

102

PROFILE Load Parameters

Define PROFILE Data Load Parameters.

Need Access Load Parameters

Define Need Access Data Load Parameters.

View COD XML Fields

View Common Origination and Disbursement XML field mappings.

Budget Categories

Define the individual components that make up the federal, Pell, or institutional budget.

Budget Items Define budget items, term amounts, and Pell annual amounts by budget category.

Create Loan Edit Sets

Create sets of loan edits to be used in creating loan destinations.

Budget Formulas

Define assignment rules for each budget item which are used to calculate the student's budget.

Create CRC Loan Destinations

Define the processing protocols between the school and the CRC loan servicers.

Reconciliation Periods

Create reconciliation periods for cash management.

Application Source Rank

Define the application source order for the batch budget assignment process.

Budget Region Table

Define regions to be used during Budget Tree processing.

Budget Trees Define a Tree Node that will be used to assign a particular detailed value to a budget item.

Setup Financial Aid Term

Define the valid terms that can be used for building financial aid term records.

Define Career Types

Define Financial Aid Career Types to combine statistics for FA Terms.

Self Service Options

Define self service inquiry options as well as awarding access and processing options.

Aid Processing Rule Setup

Define aid processing rule sets for use as career and program defaults.

Term Values Cross Reference

Define equivalent terms across aid years for the aid year rollover process.

Create Loan Destinations

Define the processing protocols between the school and the CL 4 loan servicers.

Pell Payment Define Pell payment parameters and options.

Valid Programs for Aid Year

Assign program specific financial aid processing rule sets.

FINANCIAL AID

103

Pell ID Attending

Assign a campus specific Pell ID.

Pell Comment Code

Set severity level for edits and comments defined by Department of Education.

ISIR Data Load Parameters

Define the rules used to load ISIRs from the staging to the application tables.

Define Serial Promissory Notes

Define and update parameters for Direct Loan MPN and Serial Promissory Note processing.

Package Rating Components

Define admissions rating components and GPA types to be available during packaging.

Packaging Equity Item Types

Define a group of financial aid item types to act as equity offsets in a packaging plan.

Budget Groups

Define a group of budget items for use in manually assigning a term budget to students.

Budget Assignment

Define career/aid year/institution combinations to assign budgets to groups of students.

Define Printer Names

Define institution printer names used by the Financial Aid Award Notification Defaults page.

Define Selection Equations

Define Forms Engine Financial Aid Award Notification Selection Equations.

Define Notification Form Types

Define Forms Engine Financial Aid Award Notification Form Types.

Award Notification Defaults

Update and review award notification defaults.

Assign Status to Admit Levels

Assign an academic program status for each program admit level.

Define Careers for Prospects

Define the career to assign to applicants based on the student's ISIR.

Related Item Type Group

Define related financial aid item types together into similar groups for awarding purposes.

Create Loan Types

Define the loan types that require origination.

Set DL Loan Counseling Search

Direct Loan Search Match Setup for loan counseling data load.

Identify Self Service

Define Lender Select list.

FINANCIAL AID

104

Lenders

Define Loan Counseling Options

Define Loan Counseling options.

Set Up Disbursement Calendars

Define the parameters for the batch authorization and disbursement processes.

Restricted Aid Table

Define parameters and conditions for awarding funds with subjective eligibility requirements.

Budget Assignment Run Control

Define careers and terms to select for the budget assignment process.

Disbursement Plan Table

Define the different disbursement plans for each career by aid year.

Disbursement ID Table

Define disbursement IDs for each disbursement in or across terms for a disbursement plan.

Create User Edit Messages

Create and update user edit messages.

Define Global Rules

Define common authorization rules for students of the same career.

Disbursement Split Codes

Define all disbursement patterns for each disbursement plan in a given aid year.

Disbursement Split Cd Formula

Define percentages of award to be disbursed by disbursement split code.

Packaging Plan

Define award rules and limits for targeted groups of students for use in auto- and mass packaging.

Repackaging Plan

Define rules and limits for targeted groups of students for use in auto- and mass repackaging.

Careers for School Codes

Define valid careers for school codes.

Define Loan Institutions

Define the valid loan processes available at the institution.

Define Item Type Rules

Define common authorization rules for individual Item Types.

STUDENT RECORDS

105

Section 8 Student Records CIBER Leads: Karen King, Leslie Roe and Susan Kretz OU Process Owner: Debra Benton OU Leads: Steve Flaherty, Shelley Ruff, Kim Trout, Jean Lewis, Jill Lallier Fit/Gap Sessions were held from April 21 to May 1. Follow-up Sessions were held from May 19 to May 21.

Review / Define Student Records Installation settings

FIT: NO

The Student Records Installation page is used to set default installation settings for general options and class searches.

CIBER Comments: For the field named Use SR Class Schedule Facility Conflict Checking, note that OHIO uses Ad Astra to initially assign rooms to classes. The classroom data is then imported into their SIS legacy system. OHIO needs to make a decision about whether or not to continue to use Ad Astra going forward, or PS classroom scheduling. OHIO will investigate the Ad Astra-PeopleSoft interface before making the decision. If Ad Astra is used, this checkbox should be cleared. For the field named GPA Rounding/Truncating Option, it permits rounding or truncating up to 3 decimal places. GAP: OHIO calculates and displays the GPA to four decimal places, but truncates to three decimal places on reports. OHIO indicated that the grade points used for calculating the GPA are only two decimal places and so four decimal places for the GPA is not mathematically significant. Options for resolution include:

Display 3 decimal places.

Customize multiple pages that display GPAs.

Define Class Notes FIT: NO

In the legacy system, OHIO uses a custom program to build the Schedule of Classes using information from the data warehouse. Courses have fees associated with them, and these fees will automatically appear in the course/class description. CIBER Comments:

GAP: OHIO currently displays fees associated with a course in the equivalent of Class Search in their legacy system. In PS the delivered Self Service controls for Class

STUDENT RECORDS

106

Search do not offer the option to display course or class fees. This is a GAP, since students need to be aware when a Course/Class has a fee associated with it.

Options for resolution include:

o Modify the detailed display of Class when using Class Search to show Course and/or Class Fees. Est Effort:

o Use the free text PS field Class Notes to contain information about fees. This is accessible through Self Service.

o The Schedule of Classes page has a button to add or update course or class fees. The button can be used to view information regarding the fee.

GAP: OHIO would like Class Notes with hyperlinks for further information about the class. For example, if the class is offered online, we need to provide a link to the online resources for the class. Class Search results have a hyperlink to view further details regarding the class, which includes Class Notes.

The ability to copy Class Notes is an option on the Copy Prior Term Schedule, and the Student Financial module has a job called Class/Course Fees Rollover to roll fees from one term to another.

Define Global Notes FIT: YES

OHIO does not currently have or use Global Notes. OHIO would like to take advantage of this in PS.

Define Course Attributes FIT: YES

OHIO currently uses course attributes for institutional research purposes and to print repetitive text in the schedule of classes or course catalog. Course attributes are attached to courses on the catalog and to classes. Unlike requirement designations, course attributes do not transfer to Academic Advisement. Examples of OHIO course attributes include:

subject code for resource distribution program

education abroad

lifelong learning

winter intersession

online

flag for print controls

STUDENT RECORDS

107

The following two course attributes have been set up in the PS Sandbox: AUDT – Auditing Allowed with values of Yes (Yes – Allow Auditing) and No (Auditing Not Allowed) CORR – Correspondence Course with values of Yes (Yes – Correspondence) and No (No – Correspondence)

In addition, the Sandbox includes a sample course of Chem 121 (Academic Institution = PSUNV) with the course attributes of AUDT and CORR.

Define Exam Codes FIT: YES

OHIO has exams that are defined in two hour blocks. For example, if a class meets MWF at 8:00 AM, the exam is at a set time, T at 8 am. The system uses these codes when you run the exam scheduling process on the Exam Scheduling page. You can also manually post these codes to individual classes. A sample Exam Code is modeled in the Sandbox under Academic Institution of PSUNV and Exam Code of MWF8AM.

Review Buildings FIT: YES

This process is used to define all campus buildings that OHIO might use in class and event scheduling. Building codes are derived from prompt values on the Facility Table.

Review Room Characteristics FIT: YES

This process allows OHIO to define room characteristics, such as types of seating and resources (overhead projectors, and the like) that are available. Room characteristics are attached to facilities on the Facility Characteristic page and can be used when defining courses, scheduling classes, or planning events. Room characteristic codes must be numeric and range from 01 to 96.

Define Facilities and Rooms FIT: NO

This process is used to define facilities and facility components (rooms). CIBER Comments:

During the Fit/Gap, OHIO asked about the difference between the Use SR Checking checkbox in the installation setup, and the Check for Facility Conflict checkbox on Facilities and Rooms.

PeopleBooks states:

STUDENT RECORDS

108

―Select this check box to enable facility conflict checking when scheduling classes. The check box value migrates from the Installation page to the Academic Institution 2 page to the Campus Table page. The system uses the value on the Campus Table page during processing. Clear this check box on the Campus Table page to use an external facility conflict checking process.”

GAP: At OHIO, the Registrar cannot schedule classes in some rooms/buildings without the permission of the department if the room/building is ―owned‖ by the department. There is nothing in PS to prevent the Registrar from scheduling classes without departmental permission. CIBER does not recommend developing a customization to prevent classroom scheduling from occurring without departmental permission, because the logic for determining when this control should and should not be in place, and to whom it applies would be complex and may be difficult to maintain over time. Instead, CIBER recommends that OHIO put a business process in place to handle this gap.

At OHIO, departments can schedule a class. This can be accommodated by providing staff members in the department with the appropriate security and process training to allow them to schedule classes. CIBER recommends creating a security role specifically for this purpose. BRUCE: As delivered, is it possible to set the security so that the math department can schedule math courses but not English courses?

GAP: There are no notes associated with Buildings and Facilities. See the next gap for resolution options.

GAP: There is nothing delivered that associates a contact person for a scheduler in the Facility Component. Options for resolution include:

o Customization: Develop a custom page to record facility notes, scheduler(s) and their contact information. Effort Estimate: 200 hours.

o Work around: It would be possible to add OHIO Departments as Organizations to the Organization Table. Schedulers could be associated with these organizations as Organization Contacts. This also allows contact information to be tracked. In addition, comments can be associated to the Organization.

Review Facility Components FIT: YES

This process is used to define the components (i.e., individual rooms or labs) that make up a given facility.

CIBER Comments:

During the Fit/Gap, OHIO noted that multiple departments may share rooms – for example Bentley Hall 211 is scheduled by History and Political Science. This is allowed in PS.

STUDENT RECORDS

109

Review Facility Characteristics FIT: YES

This process is used to define room characteristics and facility blackout times.

Designate Approved Instructor and Advisors FIT: YES

CIBER Comments:

During the Fit/Gap, OHIO asked if Instructor status (active or inactive) could be maintained here. It can be on the Instructor/Advisor table, using either the Status or Instructor Available fields.

OHIO asked if the status could be used for reporting/research purposes as well. This field can be used in a custom query.

Requirement Designation FIT: YES

CIBER Comments:

PeopleBooks states:

“A Requirement Designation can be extra work that has to be done for a course, such as honors, or a Requirement Designation can specify a category of course to use in a course list for Academic Advisement. For example, you can use a Requirement Designation for all courses that fulfill a writing requirement. Typical requirement designations include Satisfies the Writing Requirement, Honors Requirement, and so on. Requirement designations can be graded as well.”

Note that a course can have only one Requirement Designation associated with it.

Potential GAP: If OHIO uses PS Academic Advisement, OHIO wants to develop a process to automatically assign requirement designations to courses that have TP and TD grades. This is currently done manually. If OHIO continues to use DARS, this will not be necessary. This automatic assignment could be handled via an Application Engine program. Est Effort is 40 hours.

Set Up Unit Conversions FIT: YES

If students at OHIO take classes outside of their current career, OHIO should define unit conversions. The system also uses the unit conversion rules when processing internal transfer credit for students, which can include students with internal coursework that transfers from one career to another career, or students with internal coursework that transfers from one program to another program.

STUDENT RECORDS

110

This was modeled in the Sandbox. Quarter and Semester unit conversions are modeled under the Academic Institution of OHIOU.

Define Standard Meeting Patterns FIT: NO

CIBER Comments:

OHIO needs to be able to find classes that are not using the standard meeting pattern or that do not have a meeting pattern assigned. CIBER recommends that a query be written to look for classes without meeting patterns or to look for classes that do not use the standard meeting patterns.

GAP: OHIO can currently assign two classes (for example Accounting 301 and Accounting 501) into the same facility if they have the same meeting pattern. PS allows this for different sections of the same course, but not different courses. The Facility Check Process in PS will present an error when a user attempts to assign two different courses into the same facility.

Option for resolution:

o Modify the facility check process when assigning the same facility and time to issue a warning instead of an error. Click ‗ok‘ to assign the same facility and time. Click ‗cancel‘ to select another facility and/or time. Effort Estimate: 8 hours.

Define Modes of Instruction FIT: YES

CIBER Comments:

When setting up SEVIS values, use instruction mode(s) to indicate distance learning. This is used to calculate hours in SEVIS. International students are allowed one enrollment in a distance learning class per term.

Use the instruction mode to signify how a course is delivered.

OHIO will need to identify a value for distance learning and other modes of instruction.

Repeat Schemes and Repeat Codes FIT: YES

Repeat schemes are the set of valid repeat codes that an academic institution can use to define the repeat rules for an academic career. The purpose of repeat codes is to adjust students‘ academic statistics appropriately when students repeat courses, rather than having the system calculate statistics by using the grading scheme. At this level, PS fits OHIO‘s needs. There is a gap at the Repeat Rules level.

STUDENT RECORDS

111

At OHIO, each course is identified as being either repeatable or ―retakeable.‖ A repeatable course is one that can be repeated and the student earns credit each time he/she takes it. Generally the content changes each time these courses are offered. Examples are research, workshop, and independent study courses. At OHIO, UGRD level courses are repeatable if the student can take a course multiple times for credit, and in the legacy system, OHIO can set a maximum number of times a course can be repeated to earn credit. The course may have a limit as to how many hours a student may accumulate in the course. For example, a History 440, 4 credit hour repeatable course with max-repeat = 8 hours would allow the student to take this course twice. The system will prohibit registration once the student has two completed courses (8 hours) on his/her record excluding withdrawals. When the Repeat Rule Checking process runs, it looks for a matching pair of course IDs or courses deemed equivalent. When the process finds a matching pair, it uses the appropriate repeat rule to determine whether the repeated class violates the rule. If it does, the process assigns the designated repeat code to the student‘s enrollment record for the repeated class. OHIO had a policy change regarding repeat rules in 1993. Prior to this time, students had to request that the ―old‖ grade be deducted in favor of the repeat course grade. After 1993, this became automatic via the policy. For conversion purposes, any data converted from prior to 1993 must include handling the deduction flag properly. A retakeable course is one in which the student may retake the course but earn credit for it only once. At OHIO, a student may retake a course a set number of times, and the last grade calculates into the student‘s GPA. There can be a maximum retake limit to prohibit the student from completing the course an unlimited number of times. For example, a History 336 4 credit hour retakeable course with max-retake = 12 hours would allow a student to register for this course three times excluding withdrawals. Different courses may have different retake limits; for example, you can take HIST 231 3 times, but take HIST 345 only twice. Only the last course completed will count. Thus, if the student earned a D and then an F it is the F that remains in the student‘s GPA. With a retake, all previous grades are removed from the GPA. Retakes are limited to undergraduates. For both repeats and retakes the student may be granted an exception to the policy to take the course an additional time. If the student does take the course, i.e. exceeds the maximum set on the course the student will continue to receive the credit for a repeatable course and the last course completed will be the one that counts for a retakeable course. At the graduate level there is no retake policy but OHIO does need the ability to limit the number of times a student may register for and earn credit in a course. In addition, if a student repeats a course where the content is fixed, then both grades should be included in the GPA but the hours should be included in hours earned only once.

STUDENT RECORDS

112

GRAD students cannot retake courses for better grades. OHIO averages the two grades, but the units only count once. (Example: ENGL 5300 (3 Units) Grade = A, ENGL 5300 (3 Units) Grade = B, Student gets 3 Units for ENGL 5300 with a 3.5 GPA. CIBER Comments:

OHIO will need to create repeat schemes and repeat codes within each scheme.

Much of repeat checking occurs automatically, without the user seeing it. However, the system also enables you to run the Repeat Rule Checking process in batch and manually.

Define Repeat Rules FIT: NO

CIBER Comments:

OHIO sets repeat schemes on a course-by-course basis.

Multiple rules may apply to any given course. For example, a student may be prohibited from taking a course more than X times, and the course may also be designated as a last grade counts course.

Instructors may effectively override any catalog rules to (for example) allow students to exceed the number of retakes, or to count a different grade than the last.

GAP: OHIO‘s policy is to limit the number of retakes (where credit only counts on the last attempt). In PS, when the Repeat for Credit checkbox is cleared on a course, it is not possible to specify the maximum number of hours allowed for repeat, which effectively prevents this policy from being enforced.


o Change the policy for retakes. This policy primarily affects students who attempt a course multiple times despite the fact that they will only get credit for their last attempt. This may be a comparatively small number of students and not require system modification to accommodate them.

o Build a custom process to handle Repeat Checking. CIBER does not recommend customizing the existing Repeat Checking process since the effort to do so would be high during implementation and during subsequent upgrades.

GAP: OHIO needs to be able to track each occurrence of a course that has been repeated for credit. Students can take a course a certain # of times where the last course taken counts, or take a course an unlimited # of times with the last course taken counts. This information is used for the electronic transcript and for the feed to DARS. DARS logic will trigger a deduction when the same course is loaded to a student‘s record unless a repeat flag is set.


o Change the policy for retakes. This policy primarily affects students who attempt a course multiple times despite the fact that they will only get credit for their last

STUDENT RECORDS

113

attempt. This may be a comparatively small number of students and not require system modification to accommodate them.

o Build a custom process to handle Repeat Checking. CIBER does not recommend customizing the existing Repeat Checking process since the effort to do so would be high during implementation and during subsequent upgrades.

Set up Repeat Checking for Academic Careers FIT: YES

Academic institution level is the highest level of control for the automatic Repeat Rule Checking process. OHIO will need to define default Repeat Rules at this level, as well as those below.

Set up Repeat Checking for Academic Programs FIT: YES

In addition to repeat checking rules at the Academic Institution level, OHIO will need to define repeat checking controls at the academic career level and a link to a repeat rule to an academic career.

Define Course Catalog Data FIT: YES

The PS Course Catalog allows OHIO to structure requirements that can be shared among many courses. The Course Catalog component uses effective dating, to track historical course changes and to prepare for curriculum changes in the future. Requirements can encompass prerequisite courses, grade point average and unit requirements, and course lists, among other factors. The data entered in the course catalog is provided by default to the schedule of classes. This feature saves data entry time when classes are scheduled.

Define Course Offerings FIT: YES

Use this page to capture how a course is offered at OHIO.

Define Course Components FIT: YES

Use the course components page to capture each distinct part of a course that results in the creation of a separately scheduled section. CIBER Comments:

STUDENT RECORDS

114

OHIO needs to identify course fees by campus. Each course and class fee is associated with account type and item type. These could be set up to designate a specific campus when processing course and/or class fees.

The Course/Class fee rollover process is a delivered job, function of Student Financials.

OHIO reviewed the Course Component translate values and determined that the delivered set of values will meet their needs:

Clinical Continuance Discussion Field Studies Independent Study Laboratory Lecture Practicum Research Seminar Supervision Thesis Research Tutorial

Create Course Equivalency Groups FIT: YES

A course equivalency is used for degree auditing, pre- and co-requisite checking, and repeat checking. Two or more courses - each with a different course id – are for all practical purposes the same course and should be treated as such. CIBER Comments: In OHIO terms, we refer to these types of courses as cross-listed courses. In the legacy system, the concept of effective dating does not exist. So, if OHIO wanted to change the title of a course, they had to inactive the old course and create a new course. The term "Equivalent Courses" was used by OHIO to indicate these kinds of courses, and may create semantic confusion. During conversion to PS, legacy course equivalencies will be converted to Effective Dated Course changes to the same course.

View Course Catalog Summary Information FIT: YES

This view is a summary of course offerings.

Print the Course Catalog FIT: YES

This page defines the parameters used to create the course catalog report.

STUDENT RECORDS

115

Define Enrollment Course List FIT: YES

Enrollment course lists are created when creating enrollment requirements that have a course list requirement. Enrollment course lists are set up before enrollment requirements are established.

Course lists and derived course lists are also used in the Academic Advisement application as a precursor for academic requirements.

Define Enrollment Requirements FIT: NO

Enrollment requirements are for more complicated requisite needs. The following example was provided during Fit/Gap: Admission to Professional Education for Early Childhood Majors Prerequisite for any education course numbered 200 and above:

1. Completion of 45 quarter hours of credit with an overall grade-point average (GPA) of 2.75. No education courses may be included in the GPA.

2. Students must complete the following courses with a grade of ―C‖ or better in each course.

a. Psychology 101 b. Communication Studies 103 c. Tier I Freshman Composition d. Early Childhood majors must complete 2 mathematics courses at the 120

level or above. e. Early Childhood majors must complete two science courses with labs.

3. Satisfactory or above performance on the PRAXIS I (PPST/CBT) test. Students must achieve at least minimum scores of 172 in writing and mathematics and 173 in reading. Scores that exceed the minimum are preferred. Students are exempt from the PRAXIS I test if they have earned a 21 or higher on the ACT or a 990 or higher on the SAT prior to enrolling in college coursework.

4. Submission of the results of a background check through BCII.

5. Submission of results of the tuberculosis skin test (administered by Hudson Health Center or other appropriate office).

6. Screening and recommendation by a representative appointed by faculty.

7. Submission of two references by professionals.

8. If you are a transfer student, you may be required to submit recommendations from your previous college. Your GPA may be considered in admission decisions.

STUDENT RECORDS

116

CIBER Comments:

The example illustrated above can be met by the system.

During Fit/Gap, OHIO asked if enrollment requirements can be set at the section level. These can be set at the section level using the Class Associations component and the Class Requisites page. On this page OHIO can indicate to the system to enforce both the course and class requisites.

OHIO has approximately 6,000 prerequisites that are encoded and enforced in the current system.

GAP: OHIO has a process that runs quarterly to drop students who fail to meet the prerequisites based on the final grades for the term. During registration for the next term OHIO assumes the current courses will fulfill prerequisites for future term registration but if the student does not complete the course with an appropriate grade, then they need to be dropped from the course in the future term due to a failed prerequisite. We currently have the ability to run this process in a report only mode and a drop mode. The student‘s class transaction log should appropriately identify the reason for the drop, i.e. failed prerequisite.


o Develop a custom query which would act as the ―report only‖ version of this process. Est. Effort: 80 hours.

o Develop an Application Engine or other program to provide the ―drop mode‖ version of this process. Est. Effort: 200 hours.

Define Enrollment Requirement Groups FIT: YES

Enrollment requirement groups encompass requisites based on a variety of factors including grade point average and units, courses, and much more.

View Enrollment Requisite Summary Information FIT: YES

This functionality provides summary views for Enrollment Requisite data.

Process the Enrollment Advisement Report FIT: YES

The enrollment advisement report lists the contents (or structure) of a specific enrollment requirement group or all enrollment requirement groups that meet the criteria established for the report. For example, if you need a printout of all the enrollment requirement groups that are defined for courses at OHIO with a subject of BIOLOGY, you can run this report.

STUDENT RECORDS

117

Set up Attendance Tracking FIT: NO

OHIO currently is required to track attendance for a finite group of students (e.g. veterans receiving educational benefits, athletes, at risk students, etc. In general, faculty are not required to track attendance in their classes. For specific groups of students there is a paper process where each office that needs attendance data sends a form to the faculty member asking them to return indicating if the student has been attending class. This can be confusing as the faculty member could receive multiple forms for the same student or forms at different times throughout the quarter. OHIO would like to have an electronic process where a faculty member would be notified that attendance data is needed for a set of students, the faculty member enters the data online, and that data is stored centrally so that the offices that need it have access to it and are notified appropriately when the designated students are not attending classes. CIBER Comments:

GAP: PS provides a table for storing attendance data but there are no workflow processes delivered around the attendance tracking system. For example, OHIO currently uses an attendance system tied to the ID Card system and there is no delivered functionality to import this data to PS.


o Use the (manual) delivered PS process to track Attendance.

o Continue to use OHIO‘s existing Harco card system and OHIO‘s custom built attendance tracking (do not use PS Attendance Tracking).

o Develop an interface between the ID Card system and PS Attendance Tracking. Est Effort: 200 hours.

GAP: If a student is identified as not attending a class, there is no delivered functionality to alert an advisor, Veteran‘s Educational Benefits Coordinator, Allen Help Center, etc.


o Extend OHIO‘s existing Harco card system and OHIO‘s custom built attendance tracking to include this functionality (which it does not currently). Est. Effort: Unknown

o Assuming that PS Attendance Tracking is used, develop a query that advisors or counselors can run to identify students with poor attendance. Est. Effort: 4 hours.

o Assuming that PS Attendance Tracking is used, develop PS workflow to alert advisors and others via email of at risk students. Est. Effort: Difficult to estimate without knowing how large the audience of advisors and counselors are; the email integration required and the number of variants on alert are required, however the effort would likely be more than 200 hours.

STUDENT RECORDS

118

Define Academic Standing Action Codes FIT: YES

Creating academic standing action codes is a precursor to defining academic standing rules.

Create Academic Standing Rules FIT: NO

OHIO has a University-wide Academic Standing policy that is enforced through the legacy system. This is calculated at the career level. In addition, some colleges and departments manually calculate Academic Standing based on internal rules for their programs. OHIO also has a segmented transcript policy, which permits students to return after an absence of four or more years without the threat of academic probation. This is handled in the legacy system by changing the student‘s grades to either a CR, if the grades were passing, and NC, if the grades were not passing. However, the original grades are passed to DARS so that it accurately analyzes degree requirements. At the time of graduation all of the grades are returned to their original values. BRUCE: Do you have a recommendation for how to handle this in PS? Can this be handled as we currently do in PS or should this be identified as a GAP? CIBER Comments:

GAP: OHIO uses Deficiency Points as a key element in calculating academic standing. This functionality does not exist in PS. Current functionality automatically drops a student from classes in a future term if that student is academically dismissed and prevents future registration automatically.


o Revise OHIO‘s Academic Standing Policy to exclude Deficiency Points.

o Develop a custom Academic Standing process and rules including Deficiency Points. The process needs to take in account the policy for part time students and their Academic Standing.

GAP: Some departments at OHIO manually calculate a separate academic standing for individual colleges based on a subset of courses taken only in the college or the major. This is a way to track if the students are meeting the requirements for the college.

Options for resolution:

o As long as this does not need to be included in the ―official‖ academic standing for the institution, it can be calculated and reported using a custom query.

GAP: Academic standing for the full-time undergraduate career differs from that for the part-time undergraduate career. The legacy system includes a counter that calculates a part-time student‘s cumulative hours. Once the part-time student‘s cumulative hours exceed 11 hours, the student is subject to probationary review. At that time, the counter

STUDENT RECORDS

119

is reset to zero and the cumulative calculation begins again. In this way, part-time students are subject to periodic review, but not necessarily every quarter.


o Change the academic policy to treat part-time and full-time students similarly.

o Develop a custom counter attached to the student‘s record that is evaluated at the end of each quarter, and resets when the student‘s cumulative hours (per career) exceed 11.

GAP: If a student can‘t pass a class within a certain number of tries, they are dismissed from the major. A ―C‖ or better counts. Also, WF, FS, and F grades count as attempts. A ―D‖ can count in some attempts.


o Develop a custom query or queries identifying students who have exceeded the number of attempts for specific classes. Manually dismiss students who appear on the report.

o Develop a process to dismiss students based on repeat/retake values for classes. The process should also drop students that are academically dismissed and insert a DISM row in the student‘s program/plan stack.

GAP: OHIO‘s current Academic Standing process produces a paper report, which is distributed to Departments by the Office of the University Registrar. The report lists students who have not met the status of Good Standing. The current program assigns an unofficial status to those students and departments/colleges review (and may change) prior to posting the official academic standing. This process applies to all undergraduates. On the web, students are able to review grades but not see their academic standing until it is officially posted. The Academic Standing is listed as ―under review‖ until finalized by the colleges. PS‘s Academic Standing process posts the standing online when run. There is no delivered report only option.


o Develop custom page for Academic Standing results based on running the various Academic Standing processes (delivered and custom). This page would be used for Colleges and Departments for review of the student‘s Academic Standing. In addition, the page would record any overrides to the calculated Academic Standing by the Colleges and Departments.

Academic Probation as defined by OHIO ―To avoid academic probation, you must maintain an accumulative GPA of at least 2.0. At the close of each quarter in which you are a full-time student, your record will be reviewed to verify your GPA. If you are a part-time student, the review will take place at the close of the quarter in which your accumulative number of hours of enrollment since your initial enrollment, or since your last review, exceeds 10. ―Probation and Continuation. If at the time of the review you do not have the required 2.0 minimum GPA, you will be placed on academic probation. If you are already on probation, you may be allowed to continue at the University until the next review if, in the opinion of the dean,

STUDENT RECORDS

120

you are making adequate progress toward attaining a 2.0 GPA. A continuance can be granted a maximum of three times. Thus, there is a limit of four consecutive quarters on academic probation if you are a full-time student. ―Normally, adequate progress is based on reducing, or at least not increasing, the number of deficiency points you have, which is determined by multiplying your total number of hours attempted by two and subtracting grade points earned. For example, if you have attempted 40 hours and have earned 65 grade points for those hours, first multiply hours by 2 (40 x 2 = 80). Then subtract the number of grade points (80 – 65 = 15 deficiency points). Increasing your grade points for additional hours can decrease your deficiency points and show that you are making adequate progress. This can be done by earning grades of C+ and above in the hours you attempt. ―Some colleges require higher standards of performance than the University‘s 2.0 minimum. If you have been dropped from a college because of failure to meet such additional standards but are not subject to dismissal according to the University rules below, you are still eligible for admission to other programs in the University. International students placed on academic probation are strongly encouraged to meet with an advisor in International Student and Faculty Services to discuss their situation. International students in F-1 or J-1 status who are dropped from their program or from the University must see an advisor in International Student and Faculty Services. ―Removal from Probation. Removal of probationary status is automatic at the close of the quarter of review for both part-time and full-time students when your accumulative GPA rises to 2.0 or above. Part-time students may be on probation between quarters of review even though their GPA is 2.0 or higher. ―Dismissal (Drop) and Reinstatement. If you are denied continuation of probation, you will be dropped from the University. A status of ―Drop I‖ means you were dropped because of an increase in deficiency points. ―Drop L‖ means you reached the limit of four probationary quarters. If you have been dropped, you are not able to enroll for regular courses on any OHIO campus. ―You may petition the dean of your college for reinstatement, but normally reinstatement will not be granted until at least 12 months after your dismissal. As a condition for reinstatement, the dean of your college may suggest remedial steps you can take, usually in the form of courses to be taken at other institutions or through OHIO‘s Distance Learning courses in the Division of Lifelong Learning. Successful performance in this coursework may constitute sufficient grounds for waiving or shortening the waiting period for reinstatement. ―If you have been dropped from the University for a second time, reinstatement is possible only under extraordinary circumstances and usually is not granted until at least 24 months after the second dismissal.‖ OHIO Segmented Transcript Policy ―The segmented transcript policy was developed as a way to allow students who leave the University with low grades and re-enroll after an absence of four or more years to begin coursework without the threat of academic probation. Under this policy, all of the student‘s courses are reflected on the transcript, but the GPA grades earned earlier are changed

STUDENT RECORDS

121

temporarily to CR (for any passing grade) and NC (for any failing grade), which removes them from the calculation of accumulative GPA, while the hours earned will be carried forward. The new GPA after segmentation will be used for determining probationary status and liability of being academically dropped. The new GPA also may be used, at the discretion of relevant officials or committees, to determine eligibility for entrance to academic programs or for scholarships and honor societies, although they also have the option of using the combined (true) GPA. However, the GPA for determining the 2.0 minimum overall GPA for graduation and in the major, as well as honor status at graduation, is based on all hours attempted at OHIO, including those attempted before segmentation. Upon graduation, the Office of the University Registrar will return all grades to the originals and recalculate the GPA. Upon graduation, students may request a letter from their academic dean; this letter will explain the Segmented Transcript Policy and include the student‘s ―Fresh Start‖ GPA (the GPA since segmentation). Subsequent gaps of four or more years will not qualify students for further transcript segmentation. The student must petition the college student services office to have the transcript segmented.‖

Link Academic Standing, Honors and Awards Rules to Academic Programs

FIT: YES

Use this page to link rules to Academic Programs.

Set up Honors and Awards FIT: YES

The GPA requirements for graduation with honors at OHIO are:

cum laude (with honor), 3.5 to 3.749;

magna cum laude (with high honor), 3.75 to 3.899; and

summa cum laude (with highest honor), 3.9 to 4.0. Honors and awards include internal and external awards. Guidelines can be created for every academic career at the University.

STUDENT RECORDS

122

Set up Special Grade Point Averages FIT: NO

Special grade point averages are averages that differ from the cumulative grade point average. These can be entered for a student's academic program, academic plan, or academic sub-plan, in order to meet analysis and reporting needs. These are entered manually on the student record. CIBER Comments:

Interface: OHIO needs an interface to load and store special GPAs from DARS for ―GPA in major.‖

GAP: OHIO needs a way to store external cumulative hours attempted, and external cumulative grade points so that this can be combined with the OHIO cumulative hours attempted and cumulative grade points to calculate a combined GPA.


o Create a Special Grade Point Average value (and field) which corresponds to student‘s Academic Plan and External GPA. A process would need to be created to update Student Special GPA‘S from DARS at the end of each term once end of term processing is completed. These values could then be used within a process to calculate the student‘s combined GPA. Est. Effort: 240 hours.

Set up Milestones FIT: YES

Milestones are non-course related requirements a student must complete toward degree progress to graduate. Milestones are more easily related to graduate level programs but can also be created for undergraduate programs.

As an example, OHIO discussed creating milestones for tracking dissertation progress such as:

1) Proposal defended 2) Proposal approved 3) Dissertation defended 4) Dissertation approved 5) Dissertation accepted for deposit

Set up Extracurricular Activities FIT: YES

The OHIO Registrar‘s Office does not track Extracurricular Activities. This functionality was also covered in Campus Community, so that other OHIO Offices could use this component. OHIO

STUDENT RECORDS

123

does currently track Greek life participation in their legacy system. See Campus Community for further discussion.

Set up Student Groups FIT: YES

OHIO may use these to track CAP students, Learning Community students, students with disabilities, ROTC, athletes, etc. OHIO will need to determine what Student Groups need to be defined and set up code and naming conventions.

Set up Student Attributes FIT: YES

This process lets you track the attributes of students based on their career and program. You can then track and report on the student attribute data.

PeopleBooks states:

“You can track students that begin their education at the same time as a single cohort by creating a student attribute for undergraduate incoming freshmen and attaching the attribute to the records of these students. You can then use the data for federal reporting and also for institutional research purposes to gain information about the type of students that you have in a particular cohort, such as a student's typical course load or how long it takes a student to complete his or her program and graduate.”

CIBER Comments: OHIO needs to decide if they will use Student Attributes to track cohorts in terms of reporting needs.

Define Grading Schemes FIT: NO

Before you can grade students, you must define all possible grading schemes for all careers. You can have different grading schemes for different careers. Within each grading scheme, you define all valid grade bases, grades, and grade-related detail.

OHIO currently uses a custom-built internal system for online grading that has been developed to meet the institution‘s specific needs. Most of the gaps noted below would be addressed by continuing to use the existing system, and feeding the final results from that system to PS. For

STUDENT RECORDS

124

this section, GAPS are listed below, but without individual recommendations for solutions. The overall solution is to continue to use OHIO‘s existing online grading system. The Grade Eligibility information below is taken from OHIO‘s current process and policy: Grade Eligibility Codes (GEC) 01 A, A-, B+, B, B-, C+, C, C-, D+, D, D, and F 02 A, A-, B+, B, B-, C+, C, C-, D+, D, D, F, and PR (Progress) 03 A, A-, B+, B, B-, C+, C, C-, D+, D, D, F, and CR (Credit) 04 A, A-, B+, B, B-, C+, C, C-, D+, D, D, F, CR (Credit) and PR (Progress) 05 CR (Credit), PR (Progress) and F 06 CR (Credit) and F 07 CR (Credit), F, and NC (No Credit) Grades that apply to all GEC

Grade Grade Description Notes

WP Withdraw Pass Assigned by faculty to replace system assigned W

WF Withdraw Fail Assigned by faculty to replace system assigned W

FN Failed – No Show Assigned by faculty to indicate student never appeared in class

FS Failed – Stopped Attending

Assigned by faculty to indicate the student stopped attending class and the last date of attendance is also reported which is needed by Financial Aid

I Incomplete Assigned by faculty

NR No Report Default grade if no grade reported by faculty

P Pass Faculty member assigns a grade using the A-F and system converts passing grades to P. Faculty member cannot know a student is taking the class for P/F

F-I Grade Lapse Showing an Incomplete has been lapsed to F

IE Incomplete Extension Assigned by Registrar. To grant an extension of the Incomplete to the end of the next term.

W Withdraw Assigned by the system when a student withdraws. Faculty will then assign a WP or WF.

During the Fit/Gap, OHIO asked how grading schemes are tied to courses. The grading basis is assigned at the course level. For individual classes, the grading basis can be changed on the Adjust Class Associations component. A Grade Basis may be comprised of multiple grading schemes. For example, a grade basis may consist of GEC 01 scheme, Audit scheme, and P/F scheme.

At OHIO, students have the option to take a class for audit, students do not have to seek permission to audit a class, and no seats are reserved for audit. There is a delivered grading basis for Audit (AUD). In addition, there is a delivered grading basis value for Student Option. The grading basis can be set to OPT or set to a grading basis of elective grade basis, and this would allow the option without permission.

OHIO needs to keep the ability to have multiple instructors of record per class – with the grade only entered once. In PS Instructors are assigned on the Meetings page in the

STUDENT RECORDS

125

Schedule of Classes. Multiple instructors can be assigned to a class section. One grade roster is produced listing all instructors.

OHIO needs the ability for staff to enter grades online. In PS, staff can be given the access to enter grades on-line through the Grade Roster or for an individual student they can use Quick Enroll or Enrollment request using the action of Add Grade, Change Grade, or Remove Grade.

OHIO needs to authenticate on-line grading (by the instructor). In PS, when a class section is set up and an instructor is assigned, the access is assigned for grading that class (Grade, Approve, Post, or No Access). Through the Faculty Center, the instructor finishes grading, then sets the grade roster status. When the grades are posted the User ID of the instructor is associated with the grade. The User ID is the electronic authentication.

OHIO‘s current online system enforces valid grade types. PS also only allows the valid grade values for the Grading Basis used for the class. In addition, when defining Grading Schemes, you can block certain grades from being displayed in Self Service. In other words, the instructor would not be able to select that specific grade value, even though it may be valid under the Grading Basis.

GAP: OHIO needs the ability to default grades in certain classes, such as audit and dissertation.

OHIO would like a report by dept / college / campus to see who reported online. A query can be developed to produce this report.

GAP: OHIO needs to be able to track multiple grade changes prior to the grades being posted to the student‘s record. This is currently done in the legacy online system. In PS, once the grades are posted to the students‘ records then you can view grade changes through the Grade Audit process (which is an enhancement compared with OHIO‘s current system) but not during the online grade entry process.

During the Fit/Gap the question arose: Is there a need to record and distribute interim or mid-term grades? Would this help with retention problems? If OHIO decides to use Mid-Term grades, student can view those grades through the Student Center.

GAP: OHIO tracks the last date of attendance for a student with an FS (Fail, Stopped Attending) grade for identifying ―unofficial withdrawals.‖ PS does not have this feature.

GAP: If the Faculty member does not assign a grade, then when grades are approved and ready for posting the legacy system automatically assigns a grade of NR to any blank grade. There is no delivered process in PS to automatically assign a grade of NR where a blank exists. However, OHIO also discussed the possibility of not creating this process, since it would disable late grades from being assigned via a grade roster after grades had posted.

GAP: Ability to load grades directly from BlackBoard into PS.

GAP: Ability to import grades from Excel into PS. In addition the notes above, the following OHIO requirements were modeled in Sandbox during the Fit/Gap.

STUDENT RECORDS

126

1. OHIO Grading Schemes are not career based – they are based for each individual class. A model was created in sandbox with grading basis for each of the 7 OHIO grade eligibility codes with an overall Grading Scheme of OHIO, under the Academic Institution of OHIOU.

2. Students need the ability to select grading. Example: AUD (Audit), GEC 01, or P/F. To satisfy this, use Student Option for grading basis. This was modeled in the sandbox with 7 Student Option Grading Basis under Academic Institution of OHIOU.

3. Faculty need the ability to change the system assigned W to WP or WF.

WF and WP grades should be setup in each of grading basis with the Include in Self Service checkbox checked. This was modeled in the sandbox with each grading basis under the Grading Scheme of OHIOU.

4. Classes need to have multiple grading schemes available. Example: AUD and GEC 01. This was modeled in the sandbox. 7 Student Option grade bases were setup allowing multiple grading types. This was done since students are allowed to audit almost any class at OHIO.

5. Students may choose to take a class for Pass/Fail, but faculty cannot know the student is taking P/F and should grade with regular A-F grades. OHIO needs to convert those grades to P for those grades that are passing (A-D) when posting. This was modeled using the Pass/Not Pass Grading Basis with Convert to Grade. This approach would work if a user at OHIO manually changed the grading basis on the student‘s course. For example if the course had a grade basis of ―GRD‖ (A-F) and a user manually changed the student‘s enrollment to ―PNP‖ the grades would be converted to P or NP as appropriate using this approach.

6. Similarly, P/F grades student seeks approval from the dean and the Registrar‘s Office changes the grading basis for student. The P/F is hidden from faculty and registrar office runs a process that automatically assigns the P grade according to A-D- grade submitted by faculty member. This was modeled in the Sandbox. Setup was done to convert the A – D grade assigned to be converted to the P grade. The P is not a value available to the instructor. This works similarly to item 5 above.

Define Grading Basis Exception Rules FIT: YES

When students in one academic program or career enroll in classes in another program or career (that have a different grade basis), the system uses grade basis mapping rules to convert grade basis values to those that are appropriate for the students' careers and programs.

OHIO Policy on Undergraduates Taking Graduate Classes

―Honors Tutorial College (HTC)‖ An HTC student may without permission. Course is part of the undergraduate student record, i.e. transcript, DARS report, GPA.‖ This will be handled via adding HTC to each of the prerequisite rules.

STUDENT RECORDS

127

―Departmental Honors Student‖ A department honors student may with permission. Limited to a maximum of three graduate courses in their major department during student‘s senior year (after earning 135 hours). Must have permission of the instructor and departmental honors coordinator. Course is part of the undergraduate student record.‖ Likely handle this by putting each departmental honors student into a student group and handling this manually as we do now or look into use of permission numbers.

―Senior for Graduate Credit‖ If you are an OHIO student or a well-qualified senior attending another university and within nine hours of completing all requirements for a bachelor‘s degree, you may be eligible for graduate study as a senior. You must have an overall GPA of at least 2.5 and obtain written permission from the graduate chair of each department offering the graduate courses and from your college student services office. If you are admitted as a senior for graduate credit, you will pay undergraduate fees and will not be eligible for graduate assistant or graduate scholarship support. Generally, no more than two graduate courses may be taken in this way, and graduate courses will not fulfill any undergraduate requirements. The graduate credit becomes part of your graduate record only; it does not affect your undergraduate course requirements, hours earned, or GPA.‖ Likely handle this by adding an additional program/plan record at the graduate career and will need to be sure we handle this in the Equation Engine for fee calculation.

―Early Admission to Graduate Program‖ Based on superior undergraduate performance, you may qualify for early admission to a graduate degree program. You must have an overall GPA of at least 3.5 and must have completed all undergraduate requirements, except the total credit-hour requirements, by the time you enter the graduate degree program. You also must obtain written permission from your department, the department‘s graduate committee, and the student services office of your undergraduate college. Once admitted, you may enroll in graduate classes for graduate credit. These classes can be used to satisfy both graduate degree requirements and undergraduate total credit hour requirements, but the hours and grades are part of your graduate record only. Apply through the Office of Graduate Studies, McKee House, before registering. If you qualify, you pay graduate fees only and are eligible for graduate assistant or scholarship support. Students will be admitted to graduate school and have the appropriate graduate program/plan stack. An exception will need to be processed for the undergraduate degree requirements for total hours.

Create Grade Rosters for a Single Class FIT: NO

Grade rosters can be defined on a class-by-class basis.

CIBER Comments:

GAP: OHIO needs to be able to recreate grade rosters after the initial creation to bring in students who dropped or were added after grade roster creation.


o This can be accomplished in PS by changing the Override Existing Grade Roster field to yes. The process deletes and overrides any pre-existing grade

STUDENT RECORDS

128

rosters when you run the Create Grade Roster process. This results in the loss of any grades which the instructor has already entered.

o Create modification to check if grade exists then retain and append additional students to the roster.

o Use delivered process and change business practice of allowing faculty to enter grades before finals week.

GAP: OHIO needs the ability for the instructor to enter a date for the Last Date of Attendance on the grade roster when they assign a ―FS‖ grade. In addition, if an FS grade is assigned then a Last Date of Attendance is required.


o Add the Last Date of Attendance as a field on grade roster.

o Store last date of attendance as a Transcript Note, allow faculty to enter and then suppress the Print on Transcript functionality through the Transcript Type set up.

GAP: OHIO needs the ability for the instructor to enter a ―P‖ or ―F‖ grade on a student who has an existing ―W‖ grade.


o Unlock assigned ―W‖ grade on grade roster to allow faculty to assign ―P‖ or ―F‖ to assigned ―W‖ grade.

o Change current business practice of allowing faculty to change ―W‖ grade, process a grade change form manually.

GAP: OHIO wants to suppress access to the Transcript Notes link on the grade roster.

GAP: OHIO requires a process to identify missing grades. Current functionality identifies classes with missing grades and notify faculty. Confirmation email sent to faculty once roster has been completed.

GAP: OHIO emails grades to students once posting period is over.

Option for resolution:

o Post message to OHIO Website announcing grades are available, check Self-Service.

Additional option for resolution:

OHIO uses a custom-built internal system for online grading that has been developed to meet the institution‘s specific needs. Most of the gaps noted above would be addressed by continuing to use the existing system, and feeding the final results from that system to PS. The overall solution is to continue to use OHIO‘s existing online grading system.

Create Grade Rosters for Multiple Classes FIT: NO

STUDENT RECORDS

129

Grade rosters can be created for each term and session by subject area or by academic organization.

See immediately preceding section ―Create Grade Rosters for a Single Class‖ above for details.

Define Degrees FIT: YES

This process allows OHIO to define both internal and external degrees for PS Recruiting and Admissions, and Student Records.

Attach Degrees to Academic Plans FIT: YES

Use this process to define a degree for each academic plan.

Define Degree Honors FIT: YES

Student Records shares this page with Recruiting and Admissions because admissions staff may need to track external degree honors of applicants.

Transcript Levels FIT: YES

Transcript level values are delivered as translate values. PS recommends that these values are not modified in any way. Any modifications to these values will require a substantial programming effort.

The transcript levels, their values on the translate table, and their descriptions in PeopleBooks are as follows:

Transcript Level

Value Description

Not Print 00 Do not print the information on any transcript.

Official 20 Print the information on the official transcript, the unofficial transcript, and the student life transcript.

Includes all information that is flagged throughout the system as Official, Unofficial, Student Life, and Degree Progress. Can include an Advising Report if you select the Advising Report or Special Advising Report check boxes.

Unofficial 40 Print the information on the unofficial transcript and the student life transcript.

Includes all information that is flagged throughout the system as Unofficial, Student Life,

STUDENT RECORDS

130

Transcript Level

Value Description

and Degree Progress. Can include an Advising Report if you select the Advising Report or Special Advising Report check boxes.

Stdnt Life (student life)

60 Print the information on the student life transcript.

Includes all information that is flagged throughout the system as Student Life and Degree Progress. Can include an Advising Report if you select the Advising Report or Special Advising Report check boxes.

Degr Prog (degree progress)

80 Print the information on the degree progress transcript, which can include academic advisement information in addition to a transcript.

Does not include a transcript. Includes an Advising Report only if you select the Advising Report or Special Advising Report check boxes. The advising report is ordered and evaluated for each student by career.

Define Transcript Type Security FIT: YES

Transcript type security authorizes users who have access to the transcript request pages to create transcript requests only for those transcript types for which they have security. The appropriate security will be built during the implementation phase.

Create Transcript Notes FIT: YES

Use the Transcript Notes Table page to define transcript notes that can appear alongside a particular student enrollment record.

Create Transcript Text FIT: YES

Use the Transcript Text page to define transcript text for a specific student. Unlike transcript notes, which are predefined and attached to students on the enrollment request pages, transcript text is created for a specific student and is not necessarily associated with a specific enrollment record.

STUDENT RECORDS

131

Review Transcript Print Areas FIT: YES

Transcript print areas are associated with codes that define areas of the transcript on which various types of transcript data appear. Print area values are delivered as translate values. PS recommends that these values are not modified in any way. Any modifications to these values will require a substantial programming effort.

Define Transcript Types FIT: NO

The Transcript Type component is used to define various types of transcripts at OHIO. In addition to the typical unofficial and official transcripts, this component can be used to define academic advisement report types.

CIBER Comments:

GAP: OHIO prints a transfer credit summary that includes the transfer institution‘s name, years of attendance, and total hours transferred.


o Use the delivered transcript.

o Use Transcript Text to manually record a summary of the student‘s incoming transfer credit.

o Customize the transcript to identify the information above. Est. Effort: 120 hours.

GAP: When a student requests a transcript, OHIO permits the student to identify a specific course for which they are expecting a grade change. The course number and term is stored and when the nightly transcript process runs, the process checks to see if the grade change has occurred. The new transcript is only issued once the grade change occurs.


o Discontinue this process or handle it manually.

o Create a custom record to contain the student‘s ID, term and the course number for the expected grade change. Develop a pagelet to allow this information to be entered through Self-Service. Clone and modify the transcript process to include a routine to check this record to see if a student is waiting for a grade change, and to validate whether the change has happened or not. Est. Effort: 300 hours.

Schedule a New Class FIT: YES

STUDENT RECORDS

132

Use this process to create and schedule a new class. The process includes the following steps (from PeopleBooks):

1. Define sections, special class fees, topics, attributes, and course administrator information on the Basic Data page.

2. Enter class meeting times, days, facilities, instructors, and room characteristics on the Meetings page.

3. Define class status, capacity, auto enroll, and resection to section numbers on the Enrollment Cntrl page.

4. Define reserve capacity and enrollment requisites on the Reserve Cap (reserve capacity) page.

5. Link notes to class sections on the Notes page.

6. If you are manually scheduling exams for class sections, enter exam information on the Exam page.

7. Assign classes (class item types) to specific general ledger accounts on the GL Interface page.

Modify Scheduled Classes FIT: NO

CIBER Comments:

GAP: OHIO wants to be able to control who can modify fields on this page on a field by field basis. As delivered, any user with update access to the page can update any/all fields.


o Clone and customize the page to add PeopleCode to check the user‘s security permissions before allowing update to specific fields. This would be comparatively simple if there were only two or three levels of security to check. For example, Role A can modify all fields; Role B can only modify fields 1, 6, 7, 8, 9; Role C can only modify field 1. However, if this customization extended to multiple roles, departments and types of access it could be very complex to implement and maintain.

o Use the system as delivered and utilize a combination of business process training, system auditing (to identify users who are updating incorrect fields) and user retraining to handle this need.

GAP: OHIO also needs to display the instructor name for the class on this page as a check that the user is modifying the correct section of the class.


o Customize the page to include the instructor name. Effort Estimate: 40 hours.

o Validate the class section information prior to updating this page.

STUDENT RECORDS

133

During the Fit/Gap, OHIO asked if individual instructors can be assigned to a course/topic without rescheduling the course. This can be done, however OHIO must use the Schedule of Classes component to make these kinds of changes for classes that have already been scheduled.

GAP: When a class is canceled PS does not provide automatic notification to the students that the class has been canceled.


o Develop custom workflow to notify students who are enrolled in the class when it is canceled. Est. Effort: 120 hours.

GAP: In PS when a class is cancelled the facility, meeting days, times, and instructors are dropped. OHIO would like only the facility to drop so that when courses are rolled the other data remains.


o Clone and customize the delivered cancellation process to retain all information associated with a class except the facility. When classes are rolled from term to term staff must remember to roll cancelled classes. Est. Effort: 200 hours.

Modify Scheduled Class Meetings FIT: YES

Use the Schedule Class Meetings component when you want to modify or maintain data for an individual class section that has been scheduled. This component contains three pages—Meetings, Enrollment Cntrl, and Exam. These pages are the same as those in the Schedule New Course and Schedule of Classes component.

View and Update Class Sections FIT: YES

Review or modify a snapshot summary of section information for a class. The page displays one row for each section scheduled for a course offering during a term.

Roll Data from Course Catalog to the Schedule of Classes

FIT: YES

This process is used to update the schedule of classes with changes to a course offering in the course catalog after a class is scheduled or students are enrolled.

Define Class Associations FIT: NO

Class association numbers link all class sections that constitute a single offering. With a common association number, you can control not only the sections of classes in which a student

STUDENT RECORDS

134

must enroll, but you can also control elements of the sections including units, components, and requisites.

OHIO will sometimes offer a variable hours class for a fixed number of units within the variable range (for example a variable class may be offered for 2-4 hours, but one section of the course is offered for 3 fixed hours). In PS, this is done with Class Associations.

CIBER Comments:

GAP: OHIO needs to validate that the new value entered through a Class Association is within the range of the variable hours for a class. In the example above, the new value could be 2, 3 or 4 but not 10. In PS there are no edits on this field.


o Develop a custom query to find courses where the number of hours offered is outside the allowable range. Use this as an ―after the fact‖ audit of the field.

o Create a customization to add PeopleCode to the class hours field, so that when Class Associations are used, the field is edited against the range of hours allowed for the course. Reject hours outside the range. Est. Effort: 8 hours.

Define Class Permissions FIT: YES

Class permissions are numbers or authorizations that you can associate with a class and assign to students to use at enrollment time. You can create general or student-specific add permissions. You can also generate add permission numbers for an entire subject area. You can create only student-specific drop permissions.

Class permissions can override conditions such as requisites and limits. Permissions allow a student to add or drop a class, as long as the student uses the permission by the expiration date and does not violate overall student limitation rules (such as maximum number of units).

Create Combined Sections FIT: YES

If you need to offer two or more separate classes as one class offering, you can combine sections. OHIO identified the following as the typical combined sections used at the university:

1. UGRD and GRAD meet together 2. Course from different departments that meet together 3. Course where several sections meet together 4. Some classes meet together, may break out into lab sections that are not together 5. Some classes meet together and lab sections meet together

CIBER Comments:

STUDENT RECORDS

135

CIBER was asked to model the following combined sections:

6 sections with 20 student per section

Sections spend 3 days together, one day in different rooms, and the last day back together.

This was modeled in the Sandbox.

Schedule Examinations FIT: YES

Use this process to schedule exams on a class-by-class basis or in large blocks.

Modify Course Events FIT: YES

This can be used to review a class section's facility reservations, and modify or delete facility reservations by date.

View Instructor Schedules FIT: YES

Instructor schedules can be viewed on-line or using the Faculty Center.

Search for an Available Facility Usage FIT: YES

This component provides a summary of events for a term, session, and day within a facility.

View and Update Class Sections FIT: YES

Use this page to review or modify a summary of section information for a class. The page displays one row for each section scheduled for a course offering during a term.

Search for Available Facility FIT: NO

Use the Search for a Facility component to search for available facilities when scheduling classes and non-course events, such as faculty meetings. CIBER Comments:

STUDENT RECORDS

136

GAP: The PS process requires the user who is creating a new class to search for a facility by entering criteria manually. When a facility is found, the user must manually enter the facility into the class. OHIO currently has the ability to search for a facility by entering the class which needs a facility. Class information is pre-populated into the search. When an appropriate facility is displayed the user clicks on it to choose it, and populate it into the class.


o Use the delivered process

o The impact of this may vary depending on integration with Ad Astra. Once that decision has been made, this needs to be revisited.

Search for Classes FIT: NO

The Class Search feature is used to search or browse for classes within a specific institution and term.

CIBER Comments:

GAP: The delivered process is not as feature-rich as OHIO‘s current Search for Classes. OHIO‘s current Online Schedule of Classes permits searching by the following fields:

o Term o Location o Course prefix o Course Title (you may search for a word and if it appears in any title the section

is returned) o Course number o Course level o Course status o General Education Code 1 o General Education Code 2 o Begin date o End date o Last day to add o Last day to drop o Instructor o Credit hours o Start time o End time o Class meeting day(s) o Eligible grades o Building o Room

STUDENT RECORDS

137

Option for resolutions include:

o OHIO currently uses a custom-built internal system for Online Course Offerings that has been developed to meet the institution‘s specific needs. Most of the gaps noted above would be addressed by continuing to use the existing system. The overall solution is to continue to use OHIO‘s existing Online Course Offerings system.

Print the Schedule of Classes Report FIT: NO

Use the Schedule of Classes Report component to print the schedule of classes report for a term.

CIBER Comments:

GAP: The PS report does not provide the level of detail OHIO currently provides in the Schedule of Classes. Ohio‘s Schedule of Classes includes the following fields:

o Call number o Course ID o Section number o Title o Credit hours o Time o Days o Building o Room o Instructor o Prerequisite o Class notes o Class fees

And for each course prefix, i.e. subject, the phone number is displayed so the student knows where to call if they have questions.

OHIO produces an HTML and PDF version of the Schedule of Classes. This is available online: http://www.ohiou.edu/registrar/info/Spring07-08/index.htm Schedules are not printed except for a special version for new student orientation called an Open Section Listing.

Copy Classes from one Term to Another FIT: MAYBE

Use the Prior Term Copy component to copy the schedule of classes from term to term dependent upon criteria and ―roll down‖ options selected. CIBER Comments:

http://www.ohiou.edu/registrar/info/Spring07-08/index.htm

STUDENT RECORDS

138

During Fit/Gap, OHIO asked if it was possible to roll all class sections of 695 and 895, regardless of subject, in the same manner. In addition, OHIO can further limit the roll by subject. For example, the math department may roll from two years ago and roll only a skeleton such as the section and class size for all but 695/895 but English may roll from the previous year and roll meeting days and times but not instructor. Thus, note that OHIO has different roll rules for different groups of classes and the set up to handle this might be tedious.

OHIO asked if this process maintains start/end dates and instructor information for term copying. The term start/end, meeting pattern start/end dates do roll forward based on the term and session(s) indicated on the criteria. In addition, if the checkbox for Roll Instructors is checked, the instructors will roll to the new term. The only information that does not roll is the Facility ID. PS opted not to roll this information since most clients have 3rd party software to assign facilities.

For the regional campuses at OHIO, all or nothing rolls. OHIO can use the campus criteria and ensure all checkboxes are selected to accomplish this.

Understand Academic Program and Plan Activation

FIT: YES

A student must be active in an academic program and plan to later be activated into a term for that academic program and plan. You can activate students into academic programs and plans by either of the following methods:

Transmit the student‘s academic program and plan data through the Activate Applications matriculation process in Recruiting and Admissions, this being the most common method.

Inserting an ACTV row manually in the Student Program/Plan component.

Understand Program Action and Statuses

FIT: NO

When you execute program actions to change a student's program data, the corresponding program action status often changes. Below is an abbreviated table of program actions. PeopleBooks provides a table showing these impacts.

Program Action Selected

Explanation System Updates Program Status To

Additional Steps Required

ACTV (Activate) A student is ready either Activate None

STUDENT RECORDS

139

Program Action Selected

Explanation System Updates Program Status To

Additional Steps Required

to enroll in a term or to be evaluated for transfer credit.

WADM (Administrative Withdrawal)

A student is withdrawn for administrative reasons.

Canceled Post the withdrawal on the student Withdrawal page.

COMP (Completion of Program)

A student has completed the program.

Program Complete

If the student is ready for graduation processing, complete the graduate process on the Student Degrees page.

CIBER Comments:

GAP: At OHIO program and plan changes occur in college and departmental offices. A college/department is not allowed to do a program change from Non-Degree Seeking to Degree Seeking. In PS, if an individual has access to do program changes, this individual can change plans from non-degree to degree-seeking.


o Modification to prevent a program change from Non-Degree Seeking to Degree Seeking, depending on user Role. Est Effort: 200 hours, depending on how broadly this is implemented.

o Business Process Change to centralize all program changes in the Registrar‘s Office.

o Business Process Change to allow program changes in college and departmental offices and create a report to monitor and look for changes from non-degree to degree seeking.

Understand Program Actions Where Future Enrollments Exist

FIT: YES

If you enter certain program actions but the student is enrolled in classes where the start date of the term is after the effective date of that program action, the system displays a warning message. PeopleBooks lists the program actions affected by future enrollments.

STUDENT RECORDS

140

Maintain Student Program Information FIT: NO

CIBER Comments:

GAP: OHIO wants the date, time, and User ID (i.e., last user) who updated the Program/Plan stack to be tracked and displayed. PS does not display the date, time, and User ID on the online display for Student Program/Plan.


o Do not display the last update date, time, and UserID.

o Modify Program/Plan to display date, time, and User ID. Est. Effort: 40 hours.

GAP: In PS the Career Requirement Term field is populated manually. OHIO needs a process to populate this field based on the term in which the student‘s first classes for that career occurred.


o Create an Application Engine program to do this. Est. Effort: 40 hours.

GAP: OHIO needs an automated process to populate and keep current the Expected Grad Term. This is required for SEVIS, National Student Clearinghouse, and financial aid.


o Create an Application Engine program to do this. Est. Effort: 40 hours.

GAP: OHIO needs a process to automatically discontinue students. Graduate Studies will be using a discontinued process to handle ―stop outs‖ and students taking time out from a Masters or Doctoral program.


o Develop an Application Engine program to place a hold on a student‘s record when they are in an applicable program and meet the discontinue criteria. Est. Effort: 40 hours.

GAP: OHIO needs a process to populate and keep current the Campus field, and feel they cannot depend on user defaults to ensure field contains a value. In addition, a student may relocate form one campus to another by registering for classes on a different campus. The student‘s record needs to automatically be updated based on where the student is registered for classes.


o Make the Campus Field a required field so that when data entry is done here, the field must be populated. Est. Effort: 4 hours.

o Develop an Application Engine program to populate this field. Est. Effort: 40 hours.

STUDENT RECORDS

141

Student Records – Part 3

Non-Credit Unique Issues FIT: NO

CIBER Comments: OHIO currently uses EventsPro rather than Informs to manage non-credit needs. Significant differences between the needs and processes of this area versus for-credit process are captured below. There are significant differences at a more detailed level. CIBER recommends that OHIO conduct more detailed Fit/Gap sessions for Admissions, Student Records and Student Financials to develop a more detailed picture of requirements and fits for the non-credit area. OHIO plans to create a career for non-credit. ADMISSIONS

There are no Admission standards for these areas, so no significant gaps were noted.

GAP: With EventsPro non-credit students are able to enter/update bio-demographic data online. Options for resolution include:

o Change business process to not permit self-reporting of bio-demographic data. o Develop interface to permit self-reporting but has a good search/match process

to prevent duplicate student records. STUDENT FINANCIALS

Payment is due at the time of registration and not billable. Payment is done via credit card or echeck. This is a fit with PS.

GAP: There is an exception that if a student has a Purchase Order then they are not required to pay at the time of registration. If this is the case then the registration is processed without payment but the student is not sent to the partner until payment is received. Options for resolution include:

o Change business process to allow PS to assess the fees and bill the student o Process the PO students manually.

There are groups of students who are sometimes offered a discounted rate for non-credit courses. Groups may be OHIO Staff and Students, people from the Appalachian region, a specific employer, etc. PS can accommodate these discounted rates.

Fee structure is completely different from the for credit students.

No withdrawals or refunds are permitted.

GAP: OHIO currently partners with Education Go, Virtual Education Software, Gaitlin Education and must send reports of students who have paid, course registered, bio-demographic information. Would like these reports to be sent automatically to the partner.

Will need to include non-credit in the interface to CASHNet.

OHIO currently sends a receipt for 1098T reporting. FINANCIAL AID

STUDENT RECORDS

142

OHIO courses are eligible for some military financial aid or AmeriCorp funding, but no other financial aid support is offered, so there are no significant gaps here.

STUDENT RECORDS

OHIO needs to be able to track and issue CEUs related to non- credit courses.

OHIO needs to be able to track numeric scores (percentiles). This can be accommodated in PS by using a numeric grade for non-credit courses. In addition, an IE grade will need to be defined for extensions that may be granted from two weeks to one month.

Non-credit does not calculate or track enrollment status, i.e. full-time, part-time, etc.

There are no registration limits regarding the number of courses that may be completed.

OHIO must be able to print out certificates to certify the CEUs completed by the student and also have the ability to create a non-credit transcript with CEUs identified and certificates completed.

There is no charge for a non-credit transcript.

OHIO may use Academic Advisement for tracking completion of non-credit certificates.

OHIO needs to alert a 3rd party vendor when some students register for non- credit courses. This can be accommodated in PS by creating a query to pull new enrollments for non-credit courses daily, and using this to email to the 3rd party vendor. The desire is for this to happen automatically.

GAP: Some classes require a separate book purchase from a third-party site, once registration is complete. PS does not include this functionality. Options for resolution include:

o Create a custom page to direct students to upon completion of enrollment, and use a hyperlink on this page. Est. Effort: 10 hours.

Non-credit currently uses their own course numbering system that does not match the for credit course numbering system, and they do not use section numbers. This can be accommodated in PS by either reworking non-credit courses during conversion to PS, so that they match the for credit standard, or by creating subject and course numbers specific to non-credit during conversion, and using PS functionality to assign section numbers. Currently, OHIO offers approximately 300 non-credit courses.

Non-credit courses are not term based, however this can be accommodated in PS by using PS Open Entry/Exit functionality. There are some courses that start once per month. We discussed possibly setting up a year-long term that has many sessions and dynamic dates.

OHIO noted that since non-credit courses are not eligible for credit, they need to be clearly flagged so as not to confuse people. It would also be helpful if they could be sorted by topic areas. OHIO has currently organized the e-commerce site this way and their students are used to searching this way. This can be accommodated in PS by using non-credit grading basis (to identify non-credit courses) along with numeric grades. Course can also be sorted by topic.

OHIO offers certificate programs which are made up of several classes, and the student needs to be registered in each section to complete the certificate. OHIO asked if the student could be registered for the certificate and be put in each class at the same time so that they can receive a schedule of classes for the whole program? This can be accommodated in PS by creating a block of courses for the certificate program, and registering students in this block.

STUDENT RECORDS

143

Dropping is not permitted for non-credit courses.

There are a few students each year who are regular, for credit students who want to register in non-credit courses. We could continue to handle these manually as we do now. We could also set the Academic Career Pointer so that students can register in the non-credit career.

Students may register for the same non-credit course multiple times but earn the CEUs only once.

OTHER NON-CREDIT PARTNERSHIPS THROUGH OHIO UNIVERSITY WITHOUT BOUNDARIES

o These programs will need a special grading basis and assign a grade of Z, for example. This is necessary so that they may be excluded from the Non-Credit transcript based on the grading basis.

o Real-Estate: certificate is issued by OHIO, must do attendance tracking for seat hours, course is attached to the regular term, student pays through CASHNet and Ohio University Without Boundaries is notified via e-mail of the payment.

o NIAAA: two online self-paced courses, third party (NFHS) issues the certificate, students take as long as they need to complete, this program may have hundreds to thousands of students.

o AED: online courses, certificate is issued by OHIO and sent to AED in Washington, AED pays for the student after being invoiced, 50-60 students per year.

o SOGETI (in Netherlands): Students come to campus for three weeks and do online as well as face-to-face instruction, these students are in SIS in order to have an ID card produced, SOGETI pays for the student after being invoiced, certificate is issued by OHIO, 300 students per year.

VOINOVICH CENTER o Does non-credit training for government training o Classroom based and not term specific o Currently use EventsPro and CASHNet o Amista Lipot is the contact person and was not included in the fit/gap analysis.

Further discussion is necessary but we think that PS will accommodate their needs.

Independent and Distance Learning Programs

FIT: NO

CIBER Comments:

Ohio University‘s Independent and Distance Learning (IDL) is committed to taking the university‘s resources beyond the campus to non-traditional students in the neighboring communities, state of Ohio, the nation and the world. OHIO currently uses Informs SIS

Is Distance Learning going to use PeopleSoft? If so any issues should be discussed in the individual processes in this document. The views on the next few pages don‘t tell whether there is a fit or gap in any of these views. If PeopleSoft is going to be used then we need to know about the fits and gaps. If it is not going to be used, we don‘t need any of the information included here.

STUDENT RECORDS

144

to manage Independent and Distance Learning needs. The courses offered through IDL are all for credit, non-term based, and appear on the Ohio University official transcript, if completed. A student may begin any course at any time. Following is a list of the unique programs/course types offered by Independent and Distance Learning: College Program for the Incarcerated External Student Program Correspondence Courses Course Credit by Examination World Wide Web Courses

GAP: Each course offered in one of the above special formats is tracked and includes information such as the approved instructor, the rate of pay, the number of exams, the study guide, etc. A screen shot is provided below:

GAP: A student will contact IDL to register for the class. IDL staff enter the information into SIS and that class registration is in a ―dummy‖ term until the student completes the course. Once the course is completed the class is automatically removed from the dummy term and added into the term in which the completion date falls into. Students are permitted to use the IDL classes only one quarter for enrollment verification purposes. For example, if a student registers September 30 for a class then the student is reported to the National Student Clearinghouse and those class hours are included with any regular hours but if the student is still working to complete the course in January those hours are not included in the data submitted for the winter quarter. Attached is a

STUDENT RECORDS

145

screen shot that shows the initial date of registration, when the class is expected to be complete, final grade earned, etc.:

GAP: IDL tracks several fees, amount paid, method of payment, amount of refunds, etc. for each student for each class. A screen shot is provided to show the different fields currently used to track this information:

GAP: PeopleSoft does not provide lesson plans within the Campus Solutions product

without the use of Gradebook. IDL needs to track lesson plans for several reasons. For example,

STUDENT RECORDS

146

o Instructors are paid per lesson graded (to ensure that lessons are completed). Pay is calculated at $32 per credit hour, and is processed four times per year. For example, if an instructor teaches a four credit hour course, then he receives $128 ($32 * 4). If the course has 10 lessons, then the instructor is paid $12.80 per lesson graded ($128/10).

o Supervised (proctored) tests are given. These tests may be associated with a specific lesson, and so require lesson plans to be associated with the course.

o Students can go online to see the status of their progress by lesson. PeopleSoft supports online grade review, but not per lesson.

A screen shot is provided that includes the fields currently tracked for each lesson:


1. Implement PS Gradebook. This would allow a query to be written to select graded lessons per instructor, and the output from this query could be used to calculate instructor pay. Proctors could also be associated with courses, sections and lessons, thus allowing a fee to be charged for proctored tests.

2. Utilize lesson plans within Blackboard. 3. CIBER does not recommend building this functionality as a custom bolt-on in

PeopleTools.

GAP: Exams must be taken at an approved site and will be mailed to the location of the test. The Proctor sends the completed exam to the IDL unit, who forwards it to the instructor for grading. Dates are logged when the exams are mailed to the test site, received back from the proctor, sent to the instructor, and received back from instructor. This exam tracking is specific to a class record. PeopleSoft does not track these dates. A screen shot is provided that shows how lessons and exams are tracked by student for each class:

STUDENT RECORDS

147


1. If the dates are associated primarily with a given student rather than with a specific class, then OHIO could use service indicators created for this purpose. The service indicator would be placed when the test is first mailed, updated on each subsequent step, and released (closed) when the test is received by Distance Learning. Est. Effort: Configuration effort of 10 hours.

2. OHIO could also use a custom checklist for this process. Est. Effort: Configuration effort of 40 hours.

3. If the tests should be tracked by class or lesson, then OHIO could build a custom record, component and page for this purpose and attach it to the course, section or lesson. Est. Effort: 80 hours.

GAP: If a student has not completed a Correspondence course within 8 months, Course Credit by Exam course within 6 months, or World Wide Web course within 5 months of the course start, the distance learning office will withdraw the student from the course. Options for resolution:

o Develop a custom query to identify students who have not completed their course within the required timeframe. Manually withdraw them from the course. Est. Effort: 8 hours.

o If students should be automatically withdrawn from the course, then a custom Application Engine could be developed to do so. This would be similar to the query, except that it would also update the course enrollment status. Est. Effort: 80 hours.

GAP: The IDL courses from which the student has been withdrawn will not appear on the official Ohio University transcript.

GAP: IDL tracks some specific information about their students. A screen shot is provided that shows the different fields:

STUDENT RECORDS

148

GAP: Proctor Management. The approved proctors are currently tracked within SIS.

Each proctor has an unique ID and basic demographic data (address and phone) is tracked for the proctor. Once can search by proctor alphabetically by proctor last name (screen ID in SIS is ZISX). This search screen is limited to proctors only, i.e. students are not inter-mingled in the listing of proctors. Below is a screen shot that shows the basic information tracked about a proctor:

GAP: The following reports need to be written to accommodate IDL‘s needs. CIBER

estimates 40 hours per report (280 total) for functional and technical specification, development, testing and documentation.

STUDENT RECORDS

149

Ready for Exam Listing Delinquent Lesson Report Youthful Offender Report Ohio Board of Regents Report of credit hours excluding Course Credit by

Exam Proof Payroll Report Final Payroll Report Payroll Summary Report

College of Arts and Sciences AIMS Unique Issues

FIT: Unknown

CIBER Comments: The College of Arts & Sciences at Ohio University has a home grown stand alone system called AIMS. All processes are generated with a click of a button using the menu illustrated below:

Some specific gaps are documented below:

GAP: The AIMS system is used (daily) for tracking student files going from one college to another. A student file contains information such as the high school transcript, any college transcripts, advisor notes, change of program forms, etc. PS does not deliver this function. Options for resolution include:

1. Create custom checklists for this purpose. Est. Effort: 10 hours per checklist.

2. Continue to use AIMS.

STUDENT RECORDS

150

GAP: The AIMS system contains the location of the archive student files for students who have been gone for 6 or more years. Options for resolution include:

GAP: AIMS is used to send communications (letters and emails) to students and faculty for Probation and Dean‘s List. PeopleSoft does provide many options for communications, however both the format and process may vary from that used in AIMS now. The AIMS system doesn‘t require the user to do any running of queries or mail merges. For example, it permits at the click of a button the dean‘s list letters to be sent to the appropriate students. Options for resolution include:

1. Use Comm Gen to generate letters and emails. Est. Effort: 40 hours to create each Comm Gen process.


GAP: AIMS is used to send Graduation communications (via email) to students, including those used to prompt for missing requirements. The college staff member will enter into the AIMS system the specific missing graduation requirement(s) for the student and upon saving that information an e-mail is automatically generated. PeopleSoft does provide many options for communications, however both the format and process may vary from that used in AIMS now. Options for resolution include:

3. Create graduation checklists for each major and generate missing requirement letters to student each term. Est. Effort: 10 hours per checklist.


GAP: AIMS tracks the reason and date for students who have withdrawn. PS does not track detailed reasons. Options for resolution include:

1. Use PS as delivered. Track only the delivered, high-level withdrawal types. 2. Create a Comment group for this reason, and track withdrawal reasons in

Comments. Est. Effort: Configuration only. 3. Continue to use AIMS.

GAP: AIMS is used to track Undecided students and communication with the undecided students‘ advisors One can retrieve a listing of all undecided students, print letters to be sent to the advisor that includes a listing of the advisor‘s undecided advisees, print thank you letters to the advisors for serving in this capacity. Options for resolution include:

1. Create a Comment group for this reason, and track undecided student information in Comments. Est. Effort: Configuration only.


Recommendation: 1. CIBER strongly recommends that the College participate fully in training and modeling

exercises when PS Campus Solutions is being configured and set up, with the intention of adapting their business practices wherever possible to those of the institution at large.

2. The College could also keep their current system and create a student data interface as required to move data to and from PS.

STUDENT RECORDS

151



Student Records Installation

Define installation values required for Student Records.

Room Characteristics Table

Define specific room characteristics.

Student Special GPA

Create and maintain special grade point averages for a student's term records.

External Subject Table

Define broad categories of the subjects offered at external organizations.

Enrollment Action Reason

Define enrollment action and enrollment action reason values for all academic careers.

Instructor/Advisor Table

Add and modify instructor and advisor records.

Requirement Designation Table

Define requirement designation values.

Course Equivalencies

Define course equivalency groups.

Course Attributes Define course attributes and attribute values.

Course Typically Offered

Define course typically offered values

Instruction Mode Define instruction mode values.

Dynamic Class Dates Table

Dynamic Class Dates Table.

Weekly Schedule Time Periods

Define weekly schedule time periods.

Course Catalog Create, view and update courses, course offerings, and course components.

Classroom Scheduling Interface

Set up classroom scheduling interface.

Study Agreement Table

Create study agreements for use with external organizations.

Milestone Table Define milestone codes, their grading bases and determine the milestone levels.

Milestone Templates

Define milestone templates to be used with milestone values.

Grading Basis Exception Rule

Define mapping rules to convert grading bases for students enrolling across careers.

Grade Review Define grade review values to be used in the grade review process.

Appointment Limits Table

Define appointment limits ID's and full-time and part-time maximum unit limits.

STUDENT RECORDS

152

Appointment Table

Create enrollment appointments for sessions and terms.

Student Group Table

Define student groups to track student membership within various groups.

Student Group Table


Degree Honors Table

Define degree honors and print options for transcripts and diplomas.

Academic Standing Table

Create academic standing action codes for all academic careers.

Academic Standing Rule

Define academic standing rules for all academic careers.

Honors/Awards Rule

Define rules to be used in the honors and awards process.

Student Attribute Table

Define student attributes for tracking and reporting on different cohorts.

Global Notes Table

Define global notes.

Repeat Scheme Table

Define repeat schemes and repeat codes within each scheme.

Repeat Rule Define repeat rules for academic careers and academic programs.

Test Table Define test codes and link test components to them.

Test Transfer Rules

Define test transfer equivalency rules.

Program/Test Equivalency

Select the academic programs and plans to assign test transfer equivalencies.

Transfer Subject Area

Define component subject areas for external or internal institutions.

Course Transfer Rules

Define course transfer equivalency rules.

Program/Source Equivalency

Select the programs and plans to assign course transfer equivalencies.

Gradebook Category

Maintain gradebook assignment categories.

Define Statistics Type

Define statistics types for consolidated statistics.

Define Statistics Period

Define statistics periods for reporting consolidated statistics.

Cum. Grade Point Average

Define cumulative GPA values and associated descriptions.

Transcript Type Define transcript types, associate service indicators and indicate that a transcript type includes an advising report.

Transcript Notes Table

Create transcript notes that relate to a student's enrollment record.

Transcript Print Area Table

Set up codes to define where various types of data appear on the transcript.

Define Transcript Define transcript type and associate service indicators.

STUDENT RECORDS

153

Type

NSC Branch Table

Define branch codes to be used when reporting enrollment status to the NSC.

ACADEMIC ADVISING

154

Section 9 Academic Advising

CIBER Leads: Susan Kretz and Leslie Roe OU Process Owner: Debra Benton OU Leads: Steve Flaherty, Shelley Ruff, Kim Trout, Jean Lewis, Jill Lallier Fit/Gap Sessions were held from April 21 to May 1.

Campus Solutions – Academic Advisement (CS-AA) is the application within PeopleSoft Campus Solutions that is configured to track requirements that a student must satisfy in order to graduate. This section describes Ohio University‘s (OHIO) current Academic Advisement business processes and associated implementation requirements, and comments accordingly on the findings. OHIO‘s existing degree audit system is DARS. DARS is not interactive with the PS 9.0 Self-Service and Enrollment features. Currently, there is not an interface delivered from DARS to PS 9.0. A DARS/PS interface may be purchased from Interface Management Services (IMS) for PS versions 7.6 or newer. Degree Audit setup is maintained centrally in the Office of the University Registrar.

Effective Dating in Advisement FIT: YES

Effective Dating tells when the record was created. There will be an effective date for each Course List, Requirement, Requirement Group, etc. The effective date must be equal to or less than the effective date of the course to which this course requisite is attached in order to see the requirement. PeopleSoft comes with default Effective Date values, 01/01/1900. It is recommended using 01/01/1901, or another OHIO defined value, to differentiate from the delivered setup value. When a student is admitted, a Program/Plan is created with academic Requirement Terms. For Academic Advisement (AA), Requirement term = Catalog year visibility. The Requirement Term for which the student is coded determines the version of the plan that will print on the student‘s AA audit report.

Academic Structure and Academic Advisement FIT: Yes

PeopleSoft CS-AA discussion on how Academic Structure impacts the Academic Advisement Module build and tagging. Reviewed the Program/Plan stack, its components, and the impact on the Academic Advisement Module in regard to Career, Program, Plan, Sub-Plan coding and Requirement Term.

ACADEMIC ADVISING

155

If OHIO will be using intended or premajors, the intended/premajors need to be included in the Academic Plan build for Academic Structure. Typical structure is Institution Level = UNIV; Careers = UGRD, GRAD; Program = School or College; Plan = Major, Minor; Sub-Plan = Concentration/Specialization. The lowest plan sequence number becomes the primary plan.

Requirement Terms FIT: NO

Core curriculum Requirement Term can be tied to either the Career or Program Level to catch catalog year of entry for core requirements. Plan level Requirement Term is tied to Plan Level for major Requirements. For AA, Requirement Term = Catalog Year. OHIO tracks the student‘s First Term, i.e. University Catalog of Entry, and Major Program Catalog Year. Both catalog years are used in evaluating the appropriate requirements for the student. These terms are automatically populated in their current system. PeopleSoft has the ability to store the career requirement term, program term and plan term. There is no delivered process for populating the career requirement term. Career Requirement Term is typically not converted or defaulted. Career Requirement Term is usually left blank. The degree audit will still process if the career requirement term is left blank. PS-AA will default to Program level Requirement Term. You can audit for Career based requirements/rules at the Program Level. If Career Requirement Term is prior to the Effective Date of the degree audit Requirement Group, a message will be generated that the degree audit is out of date.

Capturing Graduation Requirements FIT: YES

CS-AA is the application within PS that is configured to track requirements that a student must satisfy in order to graduate. Define auditable graduation requirements (Example: GPA requirements and defining minimum grades for a particular course) using the academic advisement module. Begin looking at requirements at the University level by building general rules that will be true of everyone in a particular career (UGRD or GRAD). Then, look at what is required in the major/plan (UGRD = # of units, GPA). Build Academic Requirement Groups, Academic Requirements, Course Lists, Course Share Sets, Entity Groups, and Condition Processes. The advisement engine analyzes the students‘ progress toward graduation automatically as complete/incomplete, using data from Student Records and requirements from Academic Advisement.

ACADEMIC ADVISING

156

Creating Course Lists FIT: YES

Course Lists can contain one course, multiple courses, courses from an entire school or college, and other variations of courses. PS provides a way to ―wild card‖ when combining groups of courses. Course List parameters provide the flexibility to attach additional structure to the Course Lists. Base unit for the Academic Advisement Module is the Course. Course ID is pulled from the Course Catalog. Course must be greater than or equal to the Effective Date on the Course List. When a course is updated in the catalog, as long as the Course ID still contains the valid course, the course is used by the audit report. Currently in DARS, if there are changes to courses, OHIO must globally renumber audit reports. Course Lists are the basic building block of Academic Advisement. Course Lists are lists of courses or wild card course lists. Course Lists identify which courses comprise the Course List, define detail parameters, and may be used to satisfy requirements for graduation completion. Course Lists are attached to Academic Requirements. Naming Conventions should be established. The description fields are free text fields. The text needs to make sense and really define what is contained in the Course List. It is recommended that the print commands are left at default for the build. Then, once ensured that the report is working properly, go back and set the print controls for cosmetic purposes. It is recommended using 01/01/1901, another OHIO defined value, as the Effective Date for Course Lists.

Establishing Requirements FIT: YES

Discussed establishing Academic Requirements in the Academic Advisement Module, a high-level overview of how to create a simple enrollment requirement. Academic Requirements are used to create specific types of requirements/rules; defining parameters, preconditions, partitions, connector types, and additional controls. Sequential Restrictions can be set to exclude courses that have been taken out of sequence. Global and Local limits can be setup to place restrictions on a course or groups of courses. Define Academic Requirements, specify requirement parameters, define requirement line detail, set requirement line item parameters, and setup the requirement line item detail. Course Lists are attached to Requirements at the requirement line item detail level. The Course Lists can be general or derived. Academic Requirements are attached to Requirement Groups. Investigated the use of Investigate All Combinations for various OHIO requirements. Note: Investigate All Combinations can be a resource drain if used on large populations such as Core Curriculum which would be attached to every undergraduate (UGRD) student at the University.

ACADEMIC ADVISING

157

Naming Conventions should be established. The description fields are free text fields. The text needs to make sense and really define what is contained in the Requirement. OHIO can also include a reference to the Requirement and Requirement Line numbers in order to ease the Student Exceptions processing, the reference can be included in one or both long descriptions. It is recommended that the print commands are left at default for the build. Then, once ensured that the report is working properly, go back and set the print controls for cosmetic purposes.

Establishing Requirement Groups FIT: YES

Discussed establishing Academic Requirements Groups in the Academic Advisement Module, a high-level overview of how to create simple enrollment requirement groups. Requirement Groups are evaluated on groups/sets of students through broad or specific parameters. When the Requirement Group structure matches the student‘s Academic Structure, the Requirement Group and all its components are audited against the student data. Requirement Groups define academic requirements that point to conditions, courses, and requirements. Enrollment requirement groups encompass requisites based on a variety of factors including grade point average and units, courses, and more. Multiple Requirement Groups can be audited at once (Example: Core, Major, and Minor). Define Academic Requirement Groups, specify requirement group parameters, and define requirement group detail. Additional criteria may be set. Enter the Academic Structure for the Requirement Group. Academic Requirements are attached to Requirement Groups. Course Share sets can be attached to Requirement Groups when necessary. Typically, there will be requirement groups for each of the following areas: Core Curriculum, Courses Not Allocated, and Plan/Major. Requirement Groups should follow catalog descriptions. Naming Conventions should be established. The description fields are free text fields. The text needs to make sense and really define what is contained in the Requirement. OHIO can also include a reference to the Requirement Group numbers in order to ease the Student Exceptions processing, the reference can be included in one or both long descriptions. It is recommended that the print commands are left at default for the build. Then, once ensured that the report is working properly, go back and set the print controls for cosmetic purposes.

Requirement Functionality FIT: NO

OHIO currently has requirements that are based on a percentage, e.g. 50% of the major requirement courses must be completed in residence. The PS AA does not contain a function for calculating a percentage of hours. PS-AA allows a course to count toward a requirement regardless of the grade earned. Courses earned with a grade of F will count toward a requirement unless the requirement is coded to

ACADEMIC ADVISING

158

specifically require a certain grade point in each course (i.e. minimum grade points of .67). OHIO currently does not have to set such a value in each requirement and courses in which a student has earned an F automatically will not count toward the requirement. OHIO has requirements where a limit may be placed on courses in the major from applying to certain requirements. For example, one course in the major may apply toward the Arts and Sciences Humanities requirement.

Transfer Coursework FIT: NO

Transfer Coursework – Work-Around/GAP OHIO accepts D‘s from other Ohio state-assisted institutions as passing/acceptable transfer credit. Of course, a transfer course GPA cannot be used in the evaluation if transfer GPA‘s are not included in the GPA calculation. However, for some requirements in the audit OHIO transfer courses with the D may be permitted to match in certain requirements, but not others. In addition, some transfer courses are accepted even if the student took them electing a pass/fail grading option. Those courses are currently identified with a TP grade. Transfer courses completed under a student-elected pass/fail grading option may only apply toward the total hours requirements at OHIO. To resolve both Enrollment Requirements/Requisites (SR) and AA audit requirements, OHIO can place a Requirement Designation on the transfer courses that have the acceptable grade of D or pass. The Requirement Designation can be picked up by both Student Records and Academic Advisement to include/exclude based on the requirement rule. However, the Requirement Designations must be built and Admissions must attach the appropriate Requirement Designation to the transfer course.

Course Share Sets FIT: YES

Discussed the use of Course Share Sets. In PS, courses cannot be used by multiple requirements by default. Course Share Sets enable courses to be shared by more than one Requirement Group. Currently at OHIO, a few courses can be shared between the Core Curriculum and major/plan requirements. Course Share Sets are tags which are given an Effective Date and a general description. Then, Course Share Sets are attached at the Requirement Group level. Course Share Sets are defined after Course Lists, Requirements, and Requirement Groups are defined. Course Share Sets are only necessary where the Credit Include mode for both requirements is set to All Stats. Course Share Sets do not need to be established for Verify type requirements. Limiting the number of Course Share Sets improves the processing time of the audit. NOTE: The Requirement field is a restrictive field. So, the Course Share Set would share everything except what is entered into the Requirement field.

ACADEMIC ADVISING

159

Requirement Usage FIT: YES

Requirement Usages provide the ability to assign a special usage for the report (Example: Phi Beta Kappa) which checks to make sure students meet certain criteria (Example: GPA, units….). Create special Requirement Groups which reference the user-defined Requirement Usage. The special usage field values generate alternate report formats, which are defined as alternative transcript types. Define the special usage value. The Requirement Usage contains general descriptive information which references the usage. Build the special usage Requirement Group and attach the Requirement Usage to the Requirement Group. Once the rule is written and tied to students, the transcript type must be written to address the report by attaching the Requirement Usage to the Transcript Type. User-defined usage values are set at four characters. Delivered usage values are three characters, except the student planner which is PLNR.

Entity Groups FIT: YES

Discussed Entity Groups used in advisement and requisites. Entity Groups are expanded conditions that are applied to the audit. Entity Groups group together similar items, such as plan, for use as a single condition or group students and give them different sets of requirements. General requirements apply to approximately 80% of the student population, while Entity Groups can pick up the remainder of the requirements. Once general requirements are defined, the exceptions/smaller groups of students are established. Define the Entity Group; set the Effective Date, status, and description. Define the level at which the Entity Group applies; Plan, Program, Student Group, or Sub-Plan. Tie the Entity Group to the Dynamic Condition at the Condition Line as a standard condition. Then, tie the Dynamic Condition to the Requirement or attach the Entity Group directly to the Requirement Group, Requirement, or Requirement Line as a condition. Limiting the number of Entity Groups improves the processing time of the audit.

Dynamic Conditions FIT: YES

Discussed Dynamic Conditions which create multi-dimensional condition specifications. Dynamic Conditions contain connector types, lines, parameters, and various controls. Dynamic Conditions are expanded conditions that are applied to the audit. Condition specifications can be set as conditions/preconditions, academic/enrollment requirements, and academic/enrollment requirement groups. Standard Condition gives the ability to create a common condition type. Define Condition Line requirements, Condition Parameters, and Condition Controls.

ACADEMIC ADVISING

160

Limiting the number of Dynamic Conditions improves the processing time of the audit.

Condition Processes FIT: YES

Discussed defining Condition Processes (Example: External Degree – Student comes in with a degree from another university. For this process to pick up, the external school must be defined along with the status of the degree.). Condition Processes are predefined processes to run other processes. In conjunction with a developer, create the customized process. Create a user-defined condition process identifier which is used to create a condition specification. Include the effective date, status, descriptive text, logical process type and name, process key format, and requirement key format (if necessary). User programmable delivered by P/S (3 types): Milestone Check, Internal Degree Check, and External Degree Check. The Condition Process can then be referenced to the Condition Line. It is recommended that potential Milestones that are used in advisement (Example: Comprehensive Exams, High School Foreign Language requirement) are identified. Milestones are requirements other than a course.

Course Substitution FIT: YES

Course Substitution substitutes one course for another for an individual student. Also, this enters an exception to a degree requirement for a student or group of students. Course Substitution is not major specific, but it is student specific. Course Substitution will follow the student from major to major. Access the Create Course Substitution page. Select appropriate Course Source. Enter appropriate substitution description. Search for Select Course to be used, then select the course to be substituted. It should be noted that a Course Substitution entered without a minimum grade point/unit would permit a course completed with an F to substitute and count toward the requirement. It is recommended to wait until the Academic Advisement Module build is complete and signed off before Course Substitutions are entered.

Authorize Student Exceptions FIT: YES

Currently at OHIO, staff in the college offices process student exceptions in their student information system (SIS). The exceptions are then passed from the student records system to DARS.

ACADEMIC ADVISING

161

In PS, there are several ways to Authorize Student Exceptions: Course Directive, Course Exclusion, Requirement Wavier, and Requirement Change.

Course Directive: Directing a course to a requirement.

Course Exclusion: Course Exclusion is an exclusion of a single course from a group of courses. The exclusion will not allow the course to be used where directed. However, if the course can match elsewhere in the AA audit, it will match unless an additional exclusion is processed or the course is directed elsewhere.

Requirement Change: Requirement Change changes the number of units required (increase or decrease). This action may require additional Student Exceptions.

Requirement Waiver: Requirement Waiver does away with a RG, RQ, or LN. Completely removes the requirement from the plan, including Unit/Course requirements. This action may require additional Student Exceptions.

To process a Student Exception you must access the Authorize Student Exceptions pages and then enter the appropriate descriptive text. Override Detail: Tie the course to the appropriate Academic Levels. Selection Code can be tied to Academic Program, Academic Plan, Student, or Student Group. Selection data field will need to be populated (Example: EmplID). Operation Code will identify which type of transaction will be processed. The Create Exception link, on the Authorize Student Exceptions page, will assign a permanent number in PS. Selecting Create Exception will allow you to define detail about the exception, such as the appropriate RG, RQ, and LN levels and Course Source options. Course Source options are Course Offerings (Course in catalog), Enrollment (Course taken in residence), Other Credit, Test Credit, & Transfer Courses which identify what type of course credit will be used/excluded in the exception. If an Academic Career level exception is made, it is tied to the career and will follow the student as long as the student is in that career. If the student changes Academic Plans, the exception will still follow the career exception. If the exception is tied to the Academic Plan, it will follow the student as long as the student is in the Plan. Once a student changes his/her Plan/major, the exception is orphaned. OHIO inquired to find out if there was a way to direct multiple courses to a Course Directive using a Course List. A list of courses can be directed to a Requirement Line by adding additional rows to the exception; however, a course list cannot be directed as a Course Directive. It is recommended to wait until the Academic Advisement Module build is complete and signed off before Student Exceptions are entered.

Setting Up an Advisement Report FIT: YES

The advisement report, reports a student‘s progress toward graduation (depending on set-up and type). An advisement report is a transcript type. The Transcript level should be set at the appropriate level.

ACADEMIC ADVISING

162

Printing the Advisement Transcript/Degree Audit Report

FIT: YES

Currently, the DARS audit is made available to the student online. In PS, the Academic Advisement Report/Degree Audit report audits a student‘s progress toward graduation based on build criteria. The Advisement Report was reviewed. The formatting/printing of the report and how the set-up impacts the printing on the report was discussed. We reviewed how requirements were appearing as satisfied/not satisfied. We discussed how to read the Units/Course actual/completed/needed. Access the Student Advisement Report or Request Advisement Reports pages. Select appropriate Transcript Type and Output Destination. Update the Request Detail by entering an appropriate student ID. Access to the Advisement Report and report types can be handled via security. Students can request advisement reports via Self-Service. AA reports can be saved for a determined amount of time. However, since the AA report and What-If reports are dynamic, it is recommended to purge the Analysis Database on a periodic basis.

In-Progress Credit FIT: NO

Currently at OHIO, In-Progress units appear on the DARS audit in the appropriate requirements, but do not accumulate in the totals toward satisfying degree requirements. In PS, if In-Progress credit is allowed to print on the AA Report, then the course/units are going to match and the units will adjust like the course is actually satisfying the requirement. However, if the student withdraws from the course(s) or does not meet the Unit and/or Grade Point filters, the course will no longer apply toward the requirement. In addition, when the AA Report is printed, In-Progress courses can be identified by: (1) the grade field is blank because no grade has been assigned and (2) ―IP‖ appears next to the Requirement Group, Requirement, and/or Requirement Line for which the In-progress course is matching. In PS, if you do not allow In-Progress credit to print on the AA Report then you would not see the in-progress courses on the AA Report. PS does not permit the display of In-Progress on the report without having them count and possibly fulfill requirements. OHIO does not allow in-progress courses to apply toward requirements when audits are processed for students and advisors but they do appear on the audit in the appropriate requirements. OHIO also has an option to allow in-progress to count on the audit assuming successful completion. This is a flag that is set at the time the audit is processed. PeopleSoft AA does not provide this functionality.

ACADEMIC ADVISING

163

For configuration, you can create rules for different Transcript Types. An Advisement Report Type can be created that Excludes In-Progress credit and one that Includes In-Progress credit. Regarding the PRINTING ONLY of the In-Progress credit: we recommend using delivered functionality.

However, you can configure lines for display purposes only using derived course lists that print the In-Progress course line item detail as a separate requirement. This is not something that is recommended, due to the configuration effort.

What-If Report FIT: NO

A What-If Report allows the student, faculty, staff to run a student‘s record against another plan. A simulated alternative program and plan can be defined for a student as a What-If scenario. Students also have the ability, if appropriate security, to process the What-If via Self-Service. What-If Reports can be saved for a determined amount of time. However, since the AA report and What-If Reports are dynamic, it is recommended to purge the Analysis Database on a periodic basis. Stored What-If: Enter appropriate Program, Plan, and Sub-Plan data for the What-If desired. Make sure to enter the appropriate requirement term. Selecting the Copy button will populate the student‘s current record, including Program/Plan information. Then, the information can be changed to view the desired information. Multiple Academic Plans and Sub-Plans can be identified. When running the Advisement Report, you will Enable Stored What-If that was created and then process the report. Stored What-Ifs can be run with Course What-Ifs. Stored What-Ifs cannot be processed with Quick What-Ifs. Quick What-If: Allows the user to generate a What-If quickly. This would be generated in the advisement report pages. Quick What-Ifs can be run with Course What-Ifs. Quick What-Ifs cannot be processed with Stored What-Ifs. Currently, OHIO specifies location of Academic Plan type, because the Academic Plan Requirements may be offered at the location the student is located. A potential solution would be to create different Academic Plan coding based on location. What-If analysis does not indicate that program may have application process. A potential solution would be to change the delivered message on the Self-Service pages through the message catalog-app designer or generate a notice when a student selects Create A New Report. To run a What-If report, an advisor or student would need to enter the appropriate requirement term(s). OHIO‘s current What-If process will default the appropriate term based on the student and terms available for the program being run.

ACADEMIC ADVISING

164

Course Applicability System (CAS) FIT: YES

The Ohio Board of Regents supports CAS and requires state-assisted institutions to participate. CAS is an online tool that allows a student to view program requirements, course equivalencies, and see how courses a student has taken or plans to take will transfer to colleges or universities. Currently, there is not an interface for PS 9.0. An interface will be required.

Analysis Table FIT: NO

DARS provides an analysis table that may be created as a result of a batch run of audits. The analysis table may then be used to query against to determine if specific program requirements have been completed or not. PS provides the ability to query based on the completion of an entire program, but not individual program requirements. PS provides the ability to query based on the completion of an entire program. In PS, you set up Transcript Type to run Advisement Reports. The Report Format can be set from Standard Report Format to Analysis Database. You can process Advisement reports in batch. This populates the Analysis Database Tables. Once the Analysis Database Tables are populated, Query Tools, SQR, Crystal Reports, PeopleTools can be used to query the database tables.

Documenting Institutional Rules FIT: YES

The Run Control ID will provide a user defined stored value to run a report. It will also provide the ability to run a report in the future. A run control is a database record that provides values for parameters that determine the content of the report. Academic Requirement, Academic Requirement Group, and Reverse Engineering can be run to document the build of the Academic Advisement Module. An Academic Requirement report can be run to review all of the requirements for a given Requirement. It lists the contents (or structure) of a requirement(s). This will also allow you to document the build. An Academic Requirement Group report can be run to review all of the requirements for a given Requirement Group. It lists the contents (or structure) of a requirement group(s). This will also allow you to document the build. Reverse Engineering can be run if there is a need to identify if/where a requirement is attached using advisement rules. It lists the results of a search for a requirement, course, course list, or condition. Documentation of degree audit requirements should be initiated once the plan requirements have been built/completed.

ACADEMIC ADVISING

165

It is recommended that sign-offs be obtained from academic units (or appropriate resource) once the plan requirements have been built/completed.

Preparing for the Academic Advisement Implementation

FIT: N/A

Typically, there is no conversion of Advisement Rules. Advisement Rules will need to be built. In addition, typically, there is no conversion of Course Substitutions and Student Exceptions. Course Substitutions and Student Exceptions will need to be entered. Look back at catalog versions of Academic Plan requirements. Decide how many Effective Dated Plans to build (How many past catalog years to build advisement rules?). Review legacy system requirements to determine which plans contain changes/updates. Research the value of the course offerings and effective dated changes in the legacy system. Prepare documentation on current build of degree audits in legacy system. It is recommended that building of Academic Advisement rules be centralized. Need to identify plan for maintenance once Academic Advisement build is complete. Need to identify a plan for maintaining Student Exceptions in legacy. Identify a plan for maintaining Student Exceptions in PS. Also, identify a work group for entering Student Exceptions. The description fields are free text fields. The text needs to make sense and really define what is contained in the Requirement. Naming Conventions should be established that are specific to OHIO and follow catalog and documented descriptions. Leave print commands at the default for the build. Then, once ensured that the report is working properly, go back and set the print controls for cosmetic purposes.

STUDENT FINANCIALS

166

Section 10 Student Financials

CIBER Leads: Reed Kofoed and Susan Kretz OU Process Owner: Kim Trout OU Leads: Steve Flaherty, Shelley Ruff, Debra Benton, Jean Lewis, Jill Lallier Fit/Gap Sessions were held from May 5 to May 15.

The following is a detailed summary of the fit/gap sessions that were conducted for the Ohio University Office of the Bursar detailing the fits and gaps within the PS Student Financials Module. Each area was discussed at length in determining how the current business processes and policies will work within the PS Student Financials Module.

General Student Financials Settings: SF Business Units

FIT: YES

SF Business Units – Although OHIO has 5 regional campuses, they will set up one SF Business Unit. This SF Business Unit will be set up to mirror the SetID, ―OHIOU.‖

General Student Financials Settings: Account Types

FIT: YES

Account Types – OHIO currently categorizes all fees for a term together, but they do separate them by term on bills, etc. OHIO would set up one account type in PS called ―TRM‖ or something similar to represent all term fees and would make sure to check the checkbox called ―Account per Term‖ on this setup. If OHIO decides that they would like to categorize housing fees separately from other term fees, they could always set up another account type called ―HSG‖ or something similar to separate TRM fees from HSG fees.

General Student Financials Settings: Item Types FIT: YES

Item Types – PS Item Types are like OHIO‘s Charge Codes and Payment Codes in SIS. The PS Item Type code/field is 12 digits longs. OHIO will use at least the Charge, Financial Aid, Payment, Refund, and Write-Off Item Type Classifications. It will be important for OHIO to categorize these Item Types in groups. For example, Financial Aid, Tuition & Fees, Housing Fees, Miscellaneous Fees, Payments, Refunds, Write-Offs, etc. Grouping similar Item Types will be important as OHIO creates the Item Type Tree which will be used in a number of Student Financials settings. With 12 digits to work with, OHIO can create as many Item Types as they would like and will never run out of numbers if a good Item Type

STUDENT FINANCIALS

167

numbering scheme is used. The GL debit and credit settings are also attached to the Item Type.

General Student Financials Settings: Item Type Tree

FIT: YES

Item Type Tree – OHIO Student Financials will need to set up an ―ITEM_TYPE_TREE.‖ This tree will need to be set up with general tree nodes that match the Item Types that have been grouped together. Most likely, OHIO will also set up more specific or detailed tree nodes within those general tree nodes for various purposes. These general and/or specific tree nodes are used to set charge priority lists for financial aid, payments, etc. These nodes are also used to specify which charges a payment plan or third party contract can pay. These tree nodes can also be used for other purposes.

General Student Financials Settings: Payment Application Rules

FIT: YES

Payment Application Rules – OHIO currently has a basic hierarchy of charges that payments can pay. PS uses Charge Priority Lists to specify how a credit will apply to charges and in what order. Charge Priority Lists will also allow OHIO to specify whether the credit can pay only current term charges, prior term charges, prior year charges, future term charges, or any combination. PS also uses a Payment Overall Priority to determine what order charges should be paid in the case there are charges due in multiple terms. PS uses Payment Priorities to specify which credits can ―swap out‖ another credit on the account, thereby allowing the first credit to go and pay other allowable charges. This functionality is usually used when one credit is more limited in what it can pay than another credit. All of these setting are set at the Item Type level. A strategic combination of this functionality will be a good improvement over the capabilities currently in SIS.

General Student Financials Settings: Student Waiver/Permission Forms

FIT: YES

Student Waiver/Permission Forms – Student Waiver/Permission forms allow a student to waive their rights or give the university permission to apply Financial Aid to any outstanding charge regardless of Federal Financial Aid Regulations. OHIO can accept this form from a student but staff has to manually apply FA have it pay charges that are usually not allowed. A Student Waiver/Permission Form can be set on the Charge Priority Lists that are attached to Financial Aid Item Types. PS then allows staff to ―attach‖ this form to a student, thereby ―automatically‖ allowing FA to apply to any charge. PS 9.0 allows a student to give their permission electronically via Self-Service which means that staff no longer has to collect these forms or attach them to the student in the system. This is a great improvement over the current business process.

STUDENT FINANCIALS

168

General Student Financials Settings: SF Term Default

FIT: YES

SF Term Default –This is a PS setting for those charges or payments that get posted without a term specified. Because PS requires a term on every posted transaction, this is a way for OHIO to specify which term is the ―default‖ term when there is no term specified. For example, a student can make a general payment over the web and a term will not be specified.

Calculating Tuition, Fees, & Waivers: Due Date Calendars

FIT: YES

Due Date Calendars – PS Due Date Calendars will allow OHIO to set up a schedule so that any automated fees will get an appropriate due date. This due date is important for Charges Due on staff and Self-Service pages and for aging, collections, and write-offs. OHIO‘s current SIS system does not have due dates, so this will be a big improvement in aging accounts.

Calculating Tuition, Fees, & Waivers: Adjustment Calendars

FIT: YES

Adjustment Calendars –PS Adjustment Calendars will allow OHIO to set up a schedule so that any automated fee (term fees, course/class fees, etc.) can be adjusted automatically. The adjustment calendar uses a pivot date – usually the term begin date – and adjusts fees based on Drop Codes and Withdrawal Codes used by Student Records. Student Records determines the (Enrollment Action Reason) Drop Codes, so as long as Student Financials and Student Records communicate and coordinate on what those codes are and how fees should be adjusted for those codes, OHIO should be able to adjust fees appropriately. There are three Withdraw Codes that PS delivers as translate values. Although these three codes may not describe why an OHIO student is withdrawing, OHIO can define what these codes mean to OHIO. So, once again, as long as Student Financials and Student Records communicate and coordinate on what those codes mean and how fees should be adjusted for those codes, OHIO should be able to adjust fees appropriately. Different Adjustment Calendars can be set up and attached at the individual fee level. OHIO gives 100% refund for drops during the add/drop period, as long as the student is enrolled in at least one course. This would result in zero fees being calculated if OHIO allowed a student to drop to zero units after the term starts. This would be a potential problem if the student dropped to zero units and did not add any classes back resulting in a withdrawal because a withdrawal should have a pro-rated calculation of fees. Currently, OHIO does not allow students to drop to zero units after the term begins, so this will NOT be a problem as long as OHIO continues to require minimum enrollment units after the term begins. OHIO currently has a number of student petitions for refund of fees. OHIO will be able to use the Last Date of Attendance field in the Term Withdrawal page to get many of these refund

STUDENT FINANCIALS

169

adjustments calculated correctly. However, if there is a student petition that is granted purely on an exception basis that differs from the standard refund policy, then OHIO will have to manually adjust/refund fees due to the nature of the exception. This is NOT a gap due to the fact that these kinds of student by student exceptions will always have to be manually adjusted.

Calculating Tuition, Fees, & Waivers: Application & Deposit Fees

FIT: YES

Application & Deposit Fees –OHIO does not currently post application fees to the student accounts. CollegeNET is currently used to process applications and application fees and the money is posted to the GL. If OHIO decides to use the PS-delivered application fee process, an application fee can be posted to the student account if desired. OHIO does not charge any actual deposit fees. OHIO does require students to pay deposits in the form of a ―pre-payment‖ for some situations, like housing, but this is not handled with the PS Deposit Fee functionality.

Calculating Tuition, Fees, & Waivers: Criteria & Equations

FIT: YES

Criteria & Equations – OHIO Tuition Groups and Term Fees are based on certain criteria. OHIO uses career levels, campuses, number of enrolled units, total passed units, residency, and other values to determine who gets what fees. PS can use standard criteria or equations if necessary to define these Tuition Groups and Term Fees. There are a number of standard fields that can be used as standard criteria values, including 30 user-defined fields. If these standard and/or user-defined fields do not allow the appropriate criteria to be defined for a given fee, then the Equation Engine functionality will have to be used. Equation Engine functionality can pull from virtually any other field in the database and can include SQL that is as simple or complex as your equation requires. Equations can be attached to ―trigger‖ criteria and/or can be attached to ―amount‖ criteria. Between standard criteria, user-defined criteria, and Equation Engines, OHIO should be able to define any tuition group, term fee, and amount required.

Calculating Tuition, Fees, & Waivers: Tuition Groups

FIT: YES

Tuition Groups – OHIO‘s fees are primarily grouped by academic career (Undergraduate, Undergraduate Lower Division and Upper Division, Graduate, Academic Program, Medical, and Online), credit hours, and campus. As noted above in the ―Criteria & Equations‖ section, OHIO‘s tuition groups will be defined using criteria and equations.

STUDENT FINANCIALS

170

Calculating Tuition, Fees, & Waivers: Term Fees FIT: YES

Term Fees – In PS, term fees are attached to tuition groups. OHIO has a number of standard term fees that will be attached to each tuition group. These term fees include Instructional Fees, General Fees, and Non-Resident Fees. The Athens campus also has a standard Technology Fees that vary based on the academic program. Each student is also charged a Student Health Insurance Fee and a Student Legal Service Fee. These two fees can be waived (see section on ―Waivers‖ below for additional information). Residence and Dining Hall charges will not be handled via Term Fee functionality in PS. These Residence and Dining Hall charges will most likely be posted via an interface with the new housing system or via External File Load, Group Post in PS. There was a lengthy discussion regarding the scenario where a student is taking classes on multiple campuses. OHIO has to ―Pro-rate‖ fees in many of these cases. Most likely, this will require a complex Equation Engine program to automate this pro-ration. Because Equation Engine is a delivered PS tool, this is not necessarily a Gap in PS Campus Solutions. However, it will require a fair amount of technical programming to make this happen. Because of the necessary technical programming effort it will require, this will be noted in the Gaps section of this analysis.

Calculating Tuition, Fees, & Waivers: Waivers FIT: YES

Waivers – PS Waivers are generally used when a student meets certain criteria that allows all or a portion of a fee or fees to be waived. A good example of a waiver at OHIO is the employee fee waiver. Waivers can use standard criteria, user-defined criteria, or equations to define who gets a waiver and in what amount. Waivers are then attached to the individual term fees on the various tuition groups. The only downside to PS Waiver functionality is that they are not term driven. They are effective dated only. This usually does not cause a problem unless a flat amount or amount per unit is being waived and the fee goes up. In this case, a new waiver code with a new effective date should be created and attached to the term fee.

Calculating Tuition, Fees, & Waivers: Course/Class Fees

FIT: YES

Course/Class Fees – PS Course/Class Fee functionality is capable of charging appropriate course/class fees at OHIO. Most likely, OHIO will set up class fees instead of course fees because in many cases sections of a class can be charged differently, i.e. Lancaster campus may charge a different rate than the Athens campus, or they may not charge a fee at all.

Calculating Tuition, Fees, & Waivers: Optional Fees FIT: N/A

STUDENT FINANCIALS

171

Optional Fees – Most likely OHIO will not use the Optional Fees functionality in PS Campus Solutions. Most universities that use CASHNet prefer to use CASHNet functionality for optional fees. In PS Campus Solutions 9.0, Miscellaneous Fees functionality is available through Self-Service. If CASHNet is not used for optional fees, then the new Miscellaneous Fees functionality will most likely be a better choice than Optional Fees functionality.

Calculating Tuition, Fees, & Waivers: Transaction Fees FIT: NO

Transaction Fees – Gap. For a number of reasons, the Transaction Fee (Initial Enrollment Fees, Add Fees, and Drop Fees) functionality in PS is not generally usable. First of all, PS‘s definition of ―Initial Enrollment‖ usually differs from that of most universities. Second, Transaction Fees can only be attached at the Tuition Group level. It was determined that OHIO would try and test this functionality for add/drop fees, but because the definition of initial enrollment does not fit, this will be included as a Gap in this analysis. While a query could be built to identify the students who should be charged and the External File Load, Group Post functionality could be used to post these fees in batch, it was determined that OHIO would probably want a ―Bolt-On‖ modification that would be able to calculate and post these fees automatically and on a scheduled basis.

Calculating Tuition, Fees, & Waivers: Tuition Calculation Controls

FIT: YES

Tuition Calculation Controls – Tuition Calculation Controls will allow OHIO to ―turn on‖ the ability to calculate tuition and fees for a given term. Should OHIO decide that they want to ―turn off‖ the ability to calculate tuition for a given term in the past, they can ―turn off‖ these controls for the given term and in effect ―lock in‖ tuition for the term.

Calculating Tuition, Fees, & Waivers: Calculating Tuition for a Single Student

FIT: YES

Calculating Tuition for a Single Student – This PS functionality will allow OHIO to calculate tuition, fees, and waivers by the push of a button for one student. This functionality is very helpful for ―testing‖ individual fee calculations before running the batch tuition calculation for all students. This is also helpful when troubleshooting calculation errors as there is much student information that goes into a tuition calculation linked from this page.

STUDENT FINANCIALS

172

Calculating Tuition, Fees, & Waivers: Calculating Tuition for Multiple Students

FIT: YES

Calculating Tuition for Multiple Students – This batch tuition calculation process will allow OHIO to schedule or run real-time the tuition, fees, and waivers calculation for all students for one or multiple terms. There are two basic settings on this batch tuition calculation process. Usually the setting to calculate ―required‖ students is run each week night. The ―required‖ flag is set for a student if there has been an enrollment change or other change in the database where PS recognizes that tuition calculation probably needs to be run to recalculate fees. Usually the setting for ―all students‖ is run on the weekend. This process will run against all students who have been term activated for the given term(s) regardless of whether the ―require‖ flag has been set or not. The ―all students‖ is usually run on the weekend because it will take longer to run and because not all changes in the database that could require a recalculation will set the ―required‖ flag. One example of this is if the amount of a term fee has been changed.

Calculating Tuition, Fees, & Waivers: Processing Enrollment Cancellation

FIT: YES

Processing Enrollment Cancellation – OHIO does not do a mass or batch enrollment cancellation for non-payment of fees. Should OHIO decide to do a mass or batch enrollment cancellation for non-payment of fees, PS‘s functionality should be a good fit. Student Financials has a number of settings it can use to determine who will get cancelled and who won‘t. Student Records actually owns and runs the process that drops classes and cancels enrollment once Student Financials has created the batch based on certain criteria for non-payment of fees.

Student & Third Party Account Maintenance: Posting Individual Transactions

FIT: YES

Posting Individual Transactions – This functionality will allow OHIO to post charges and/or payments to student and/or third party accounts manually. Most charges posted to student accounts will come through the automated tuition, fees, and waivers calculation. All charges posted to a third party account should come through the automated Third Party Contracts. Most, if not all, payments on student accounts should come through CASHNet. If CASHNet does not have the ability to post Third Party payments, then this will probably be the functionality that would be used to post those payments to individual student charges on the Third Party account.

Student & Third Party Account Maintenance: Reversing Transactions

FIT: YES

Reversing Transactions – This functionality will allow OHIO to reverse charges and/or payments that have posted to a student or third party account. OHIO should remember not to try to reverse charges that have been posted automatically via tuition calculation as those charges will simply repost the next time tuition calculation is run. Also, a payment that has already been

STUDENT FINANCIALS

173

reconciled should only be reversed if posted to a wrong account or if the payment needs to be changed to a general payment. Then, a reconciled payment that has been reversed should always be re-posted on the same day for the same amount in order to keep the cash reconciliation correct.

Student & Third Party Account Maintenance: Item Reasons

FIT: YES

Item Reasons – OHIO can set up standard Item Reasons for reversing transactions. These do not have to be set up. When a transaction is reversed, you have the ability to specify why you are reversing the transaction or you can specify a pre-determined Item Reason that already has the reversal description attached.

Student & Third Party Account Maintenance: Late Payment Fees

FIT: NO

Late Payment Fees – Gap. OHIO currently has a $100 late fee that is charged once per term based on certain late payment criteria. PS‘s Late Fee functionality does NOT fit the requirements for this late fee. Also, OHIO has late payment fees associated with the monthly payment plan(s) that will not be able to be automated with the delivered Late Fee functionality. While a query could be built to identify the students who should be charged the late fee(s) and the External File Load, Group Post functionality could be used to post these fees in batch, it was determined that OHIO would probably want a ―Bolt-On‖ modification that would be able to calculate and post these late fees automatically and on a scheduled basis.

Student & Third Party Account Maintenance: Finance Fees

FIT: N/A

Finance Fees – OHIO does not currently charge ―finance‖ fees. See section for ―Late Payment Fees‖ shown above. OHIO is interested in exploring finance fees being charged rather than the late payment fees listed above.

Student & Third Party Account Maintenance: Dishonored Checks

FIT: YES

Dishonored Checks – This is a business process discussion rather than a functionality fit/gap discussion. It was determined that OHIO would leave the original payment on the account so as not to confuse the cash reconciliation and simply post a charge to collect the money that the check was written for and then post an additional charge for the ―dishonored check fee.‖ Usually, the original payment would be reversed only to re-post and re-apply to the new, outstanding charge. This leaves the original fees that were covered by the dishonored check once again outstanding in the correct receivable account and the ―dishonored check fee‖ outstanding to be paid.

STUDENT FINANCIALS

174

Student & Third Party Account Maintenance: Write-Offs

FIT: YES

Write-Offs – OHIO does not currently do official write-offs to accounts. These delinquent accounts are sent to the State of Ohio Office of the Attorney General. Should OHIO decide to do write-offs in PS, this can be done using the ―post individual transactions‖ functionality or the delivered Write-Off functionality. However, due to accounting requirements that say that charges must be written off to specific accounts and funds, if the delivered write-off functionality is used then the ―Write-Off Item(s)‖ setting will be used to accommodate the correct accounting. The advantage of this functionality is that the process can also place a ―Written Off‖ service indicator as it posts the write-off whereas a ―Written Off‖ service indicator would have to be manually placed if the ―post individual transactions‖ functionality were used.

Student & Third Party Account Maintenance: Origins & Group Types

FIT: YES

Origins & Group Types – Origins and Group Types are required for Financial Aid batches and External File Loads. It is usually recommended that the origins and group types mirror each other. An origin and a group type must be set up for Financial Aid. One of each is usually set up for Conversion of account balances. One of each will also need to be set up for Housing if housing is going to interface using the External File Load, Group Post functionality. If OHIO continues to do Lockbox payment processing and this functionality is used to post the payments, then an Origin and Group Type will need to be set up for Lockbox transactions.

Student & Third Party Account Maintenance: External File Layouts/Loads

FIT: YES

External File Layouts/Loads – This functionality is used to load transactions in mass or batch. PS will allow OHIO to pre-determine a set layout for various types of transactions. The file of transactions that will be loaded ultimately needs to be saved as a ―.dat‖ file. The External File load process loads these mass transactions based on the pre-determined file layout.

Student & Third Party Account Maintenance: Group Posting Transactions

FIT: YES

Group Posting Transactions – OHIO will have the ability to post batches of transactions. These batches of transactions are usually loaded through an External File as mentioned above. OHIO will have the ability to correct and/or delete individual transactions within the batch.

STUDENT FINANCIALS

175

Student & Third Party Account Maintenance: Group Posting Financial Aid Batches

FIT: NO

Group Posting Financial Aid Batches – Gap. While PS will allow OHIO‘s Financial Aid office to create a batch of Financial Aid transactions to be posted to the student accounts, PS does not deliver a way to have those batches automatically posted to the student accounts. Because of the Student Financials group posting process and also the separation of duties, PS requires that Student Financials manually determine if a new FA batch has been created and then run the posting process in order to get the FA posted to the student accounts. It was determined that OHIO would want to either create a modification to automate this posting process as soon as a new FA batch has been created or they could choose to use a third party process scheduler that would have the ability to automate this. There may be reasons why other modules within PS may also want to use a third party process scheduler.

Student & Third Party Account Maintenance: Applying Payments

FIT: YES

Applying Payments – Fit. While PS usually applies payments as the individual payments are posted, there are times when a payment does not apply to all eligible charges at the time of posting. For this reason, PS provides a process that can be run (usually nightly) that ensures that all posted payments have been applied to all eligible charges on the account. See the section ―Payment Application Rules‖ above for more detailed information on how payments apply to charges.

Student & Third Party Receipts: Online Payments & Cashiering

FIT: YES

Online Payments & Cashiering – Fit. Although PS delivers cashiering functionality, very few universities have used the delivered functionality as it is lacking in many ways. Many universities use CASHNet or a similar third party vendor to process cash receipts. OHIO currently uses CASHNet for cashiering and online payments via eCheck and SmartPay. CASHNet has worked closely with PS to deliver Cashiering functionality that is real-time and seamless through Component Interfaces. It was determined that OHIO would continue to use CASHNet for online payments and cashiering with PS. Although CASHNet has a very good reputation for working with clients and getting their software interfaced with PS, this will be included in the interfaces section of this analysis as there will need to be resources allocated on the project to get this interface installed, tested, and working correctly. There will also most likely need to be some small modifications to Self-Service in order to ―re-direct‖ the delivered ―Make a Payment‖ links to CASHNet for online payments.

STUDENT FINANCIALS

176

Student & Third Party Receipts: Departmental Receipts

FIT: YES

Departmental Receipts – Fit. Although PS has the ability to process ―Departmental Receipts,‖ OHIO will continue to use CASHNet for Cashiering. CASHNet has the ability to interface with Oracle Financials for those ―departmental receipts‖ that need to be fed straight to the GL rather than being posted to a student or third party account.

Student & Third Party Receipts: Lockbox Payments

FIT: N/A

Lockbox Payments – N/A. OHIO currently accepts lockbox payments, however, OHIO is open to doing away with these types of payments as the volume continues to decline and as the staff continues to have to check many of these transactions for errors. Should OHIO decide that it wants to continue to accept lockbox payments, OHIO can feed them through CASHNet or can use the PS delivered External File Load, Group Post process.

Student & Third Party Receipts: Third Party Payments

FIT: YES

Third Party Payments – Fit. Although PS has the ability to process third party payments, OHIO will continue to use CASHNet for Cashiering. CASHNet has stated that they have the ability to post third party payments in PS. OHIO will need to confirm with CASHNet that they do in fact have the ability to post payments to third party accounts and that they also have the ability to post payments to individual students on the third party account. If CASHNet does not have the ability to post payments to individual students on the third party account, the ―Post Corporation Transaction‖ functionality could be used to post to individual students on a third party account.

Student & Third Party Billing: Student Billing

FIT: NO

Student Billing – Gap. OHIO currently feeds CASHNet the information to present student statements ―eBills,‖ as of a point in time. CASHNet sends out emails based on certain criteria and at certain points in time. CASHNet monitors whether a student has viewed the eBill or not. CASHNet also allows ―Authorized Users‖ to view eBills and make electronic payments. OHIO needs to determine whether it wants to continue to use and pay for this CASHNet functionality or whether it wants to use PS Self-Service for a comprehensive view of all activity that has ever posted to the student account and do away with statements that are as of a point in time. If OHIO decides that they want to use PS Self-Service and discontinue the use of CASHNet for account presentment and related emails, then there will need to be some ―bolt-on‖ modifications to send out emails about account balances, payment deadlines, etc. There would also need to

STUDENT FINANCIALS

177

be a modification in PS to allow ―Authorized Users,, such as a parent or guardian, to see certain student information and to do certain student tasks. The PS student billing functionality does not have any automated email functionality. Even if the PS student billing functionality is not used to send out paper bills, the configuration will still have to be set up and the process run on a monthly basis to ensure that all transactions have valid due dates and that the aging is correct. Also, should OHIO ever need to print out an actual bill for the student, the PS delivered bill will most likely need to be modified to be usable.

Student & Third Party Billing: Third Party Billing

FIT: NO

Third Party Billing – Gap. Although PS has the ability to process a third party bill, the third party bill will need to be modified to fit the requirements of the various third party sponsors. For example, some of these sponsors require that the student‘s schedule of classes be printed on the bill. PS does not have this ability as delivered.

Student Payment Plans: Installment Payment Plans

FIT: YES

Installment Payment Plans – Fit. OHIO currently has an installment payment plan. The students are currently charged a fee to enroll in the payment plan. The amount of this fee currently depends on how many terms they are going to be on the payment plan. It was determined that OHIO could make a simple policy change that would charge a $25 fee each term the student was on a payment plan rather than charging the fee up front. If OHIO can make this simple policy change, then PS delivered functionality will be a good fit.

Student Payment Plans: Payment Plan Late Fees

FIT: NO

Payment Plan Late Fee – Gap. OHIO currently charges a late fee for installment payments that are late. The PS delivered Payment Plan functionality does not include any late fee functionality. A ―bolt-on‖ modification will have to be developed to automate this late fee assessment if finance charges are not utilized as a business process change.

Third Party Contracts: Third Party Contracts

FIT: YES

Third Party Contracts – Fit. OHIO‘s third party contracts can be processed using PS delivered third party contract functionality.

STUDENT FINANCIALS

178

Third Party Contracts: Third Party Contract Rollover

FIT: NO

Third Party Contract Rollover – Gap. OHIO currently gets some third party contracts that are good for multiple terms or years. There is no ability in PS to roll a third party contract from one term to another. OHIO will have to create a ―bolt-on‖ modification to be able to automatically roll a third party contract from one term to another.

Student, Parent, & Third Party Refunds: Refunds

FIT: NO

Refunds – Gap. While PS has the ability to process student, parent, and third party refunds, PS‘s delivered functionality is seamlessly interfaced with PS Financials and/or PS HR/Payroll for paper check refunds and/or direct deposit refunds. OHIO does not use PS Financials or PS HR/Payroll. OHIO uses the current SIS system to issue refunds. In order for OHIO to be able to continue to process refunds as it does currently, there will need to be a major development effort to both modify and interface the PS Campus Solutions refunding process with the Oracle systems that OHIO uses for Accounts Payable and HR/Payroll. Regardless of how and where OHIO decides to produce paper refunds checks and how and where OHIO decides to split out direct deposit refunds, there will be a lot of resources needed to get the system(s) modified, interfaced, tested, and working correctly. OHIO also currently sends out emails when refunds are processed. PS does not have the ability to automatically send out emails for refunds. This will have to be included in the modification/interface.

Student & Third Party Aging & Collections: Account Aging Process

FIT: YES

Account Aging Process – Fit. The PS delivered account aging process called Credit History will be able to age OHIO‘s accounts correctly.

Student & Third Party Aging & Collections: Account Collections Process

FIT: NO

Account Collections Process – Gap. Although the PS delivered collections process would allow OHIO to process collections activity, PS assumes that the university has a full-time, in-house collections department. Because OHIO does not have a full-time, in-house collections department, the PS collections functionality will be a lot of work to set up, maintain, and process for what OHIO needs to do. OHIO currently sends out a couple of notices before sending accounts to an outside collections agency. Based on these requirements, it was determined that OHIO would probably need a ―bolt-on‖ modification that would automate the notification process and track students through the collections process.

STUDENT FINANCIALS

179

Student Financials Interfaces FIT: YES

There were a number of applications identified at OHIO that will need to interface with Student Financials. Some of these application vendors already have pieces of the interface developed. Many of these application interfaces will need to be developed by OHIO. OHIO will also need to decide how seamless/automated the interfaces have to be. Some of these interfaces could use the PS delivered External File Load, Group Post to interface to the PS student account, but there are some manual steps involved. CASHNet – OHIO currently uses CASHNet for online payments, cashiering, and eBill presentment. CASHNet has worked with PS to deliver the application interfaces to Student Financials. There will still need to be a good amount of effort and technical resources to get this interface set up, tested, and working correctly. Adirondack Housing Management System – OHIO is in the process of implementing a new housing management system – Adirondack. OHIO plans to implement this new housing system prior to converting to PS. OHIO thinks that Adirondack has worked with PS on interfacing the two systems. OHIO needs to confirm whether or not the interface pieces already exist or whether they will need to be built. As mentioned above, the PS delivered External File Load, Group Post process can be used to interface to the PS student account, but there are some manual steps involved. PowerPark Parking Management System – OHIO is in the process of upgrading to the latest PowerPark parking management system (T2 Systems). OHIO will need to determine how it wants to interface this application to Student Financials. OHIO will need to confirm whether T2 Systems has any delivered interface pieces or whether the interface will need to be developed. Library – The library has its own software application. OHIO will need to determine if it wants to interface any library transactions with Student Financials. If so, this interface will have to be developed. Health Center / Pharmacy / Diagnostic Services & Immunizations -- OHIO will need to determine if it wants to interface any of these transactions with Student Financials. If so, this interface will have to be developed. SoftCash Software Sales Application – OHIO will need to determine if it wants to interface any of these transactions with Student Financials. If so, this interface will have to be developed. P-Counter Printing Application – OHIO currently charges students for printing on a monthly basis. OHIO will need to determine if it wants to interface any of these transactions with Student Financials. If so, this interface will have to be developed. OGA Online Graduate Awarding System – OGA is a highly customized, homegrown application that OHIO currently uses and interfaces to SAM and SIS. It was determined that OHIO will keep this application and that a complex modification/interface will need to be developed to replace the existing interfaces. Regardless of whether OHIO decides to use waivers, Financial

STUDENT FINANCIALS

180

Aid, or any other PS functionality to process these awards, this will require a fairly large development effort.

Processing GL Accounting Entries FIT: NO

All of the PS functionality for setting up GL account strings and processing GL accounting entries are built around interfacing with PS Financials. OHIO uses Oracle Financials. While OHIO may be able to use some of the existing fields for setting up account strings and may be able to use the delivered ―Create Accounting Entries‖ functionality to process accounting lines within Campus Solutions, most likely OHIO will need to modify these setup fields and there will have to be an interface developed to actually get the accounting entries into Oracle Financials. This will require a significant development effort. OHIO would also like to interface valid account strings into Campus Solutions so that only valid values can be used on an account string. This will require that the interface go both ways like it does between PS Campus Solutions and PS Financials.

Student Financials Conversions FIT: YES

PS recommends using the delivered External File Load, Group Post process to load student and third party account balances for conversion. OHIO will still need to do a lot of work to complete the conversion correctly. OHIO will have to develop a process for extracting these account balances from SIS and getting them posted to the correct ID in PS. OHIO will need to decide at what level balances will be converted. Will OHIO convert open balances at the individual transaction level? Will OHIO convert open balances at an overall account level? Will OHIO convert open balances at the receivable level? Will OHIO convert open balances by term? OHIO will also have to determine a legitimate due date for transactions (as SIS does not have an official due date) if it wants a valid aging out of PS. It was determined that OHIO would need to clean up third party accounts in SIS prior to converting those balances.

Tax Reporting FIT: NO

1042 Non-Resident Alien Tax – While PS allows an Item Type to be flagged as a potential NRA taxable item, there is no delivered process to process the taxes for Non-Resident Aliens. OHIO will need to either develop a process for this or process these manually. There are some third party vendors, like Glacier International, that also provide help with Non-Resident Alien Tax Reporting requirements. 1098-T Tax – PS does have a process for processing 1098-T tax forms. Oftentimes, PS will have regulatory patches/fixes that will need to be installed and sometimes these come late in the year. OHIO currently prints out the detailed information that makes up the totals on the form. OHIO will need to decide if it wants to use the delivered 1098-T process or develop a process that will take care of these federal requirements. CS v9.0 has some 1098-T

STUDENT FINANCIALS

181

functionality if the data is processed in PS. . There are some third party vendors, like Campus Partners or ECSI, that also provide help with 1098-T Tax Reporting requirements.

Campus Community for SF FIT: YES

Campus Community is a good fit for Student Financials. SF will need to work with the other modules on Name Types, Name Usage, Address Types, Address Usage, and Residency.

Service Indicators for SF FIT: NO

Service Indicators in general will be a good fit for Student Financials. A combination of service impacts and service indicators allow certain services to be held or exceptions to be made in various Student Financials processing. The credit history (aging) process can be set up to automatically place a service indicator for outstanding balances. CS v9.0 even has the ability to mass place or release service indicators based on a user-defined query or population selection. This is a huge improvement over prior versions. However, OHIO currently has the ability to automatically release a service indicator real-time when a student pays, etc. Student Financials does not have any delivered functionality that would allow these service indicators to be removed real-time. It was determined that OHIO would look into ―Event Triggers‖ and/or ―Database Triggers‖ that could possibly accomplish the desired results, but either way decides to go there will have to be a development effort in order to do this.

3C’s for SF FIT: YES

Student Financials will be able to use the delivered comments functionality. Setting up the functionality to input SF comments is quite easy and this will be a good fit. The SF billing functionality has the capability to produce bills without using communications, however a communications records can be created if desired when the billing process is run. Also, if OHIO decides to use the delivered collections process, the communications functionality will have to be set up for SF. However, as stated above in the collections section, based on OHIO‘s collection requirements, it was already determined that OHIO would probably need a ―bolt-on‖ modification that would automate the collections notification process and track students through the collections process.

Self-Service for SF FIT: NO

In general, Campus Solutions Self-Service for Student Financials will be a good fit. OHIO is currently using CASHNet for some of the self-service functionality. OHIO will need to decide whether self-service in Campus Solutions will be good enough for account presentment without having to do ―account statements‖ in CASHNet.

STUDENT FINANCIALS

182

It has already been determined that OHIO will need to be a self-service modification to allow ―authorized users‖ to log in and to do certain tasks. An ―authorized user‖ is someone that has been given authorization by the student to view student account information. PeopleSoft does not have the ability to identify authorized users.

Query/Reporting Tools for SF FIT: YES

The delivered PS Query tool will be a good tool for functional users. PS also delivers a number of reports that can be run from the PS menus, however many of these are Crystal Reports and may not meet the specific OHIO reporting requirements. All of these reports are based on delivered queries. Most likely, OHIO will want to use these delivered queries and build many other queries that can be used as a base for custom reports. OHIO is already looking at using the Oracle OBIEE business intelligence tool to do much of this custom query/reporting work.

Security for SF FIT: YES

PS security can be set up as detailed and tailored to each user as OHIO decides it wants. In addition to the basic row level security, user profiles, roles, and permission lists, Student Financials can also set up Item Type security at the permission list or user level.

SF Integration Points with AD FIT: NO

There are only a few integration points between Student Financials and Admissions. Application Fees are not currently posted to the individual student accounts. As mentioned above in the Application Fees section, CollegeNET is currently used to process applications and application fees and the money is posted to the GL. If OHIO decides to use the PS-delivered application fee process, an application fee can be posted to the student account if desired. OHIO uses a web application for Orientation. OHIO gets a list of students that need to get the orientation charge and these charges are posted to the student accounts. OHIO will have to decide whether it will continue to use this web application and if so, whether it wants to interface to student financials or continue to post these charges manually or through the PS delivered External File Load, Group Post process. OHIO has a business process requirement that states that only those housing students that have paid a housing deposit can get a final admit status and enroll. OHIO will need to develop a business process or ―bolt-on‖ modification to accomplish this.

STUDENT FINANCIALS

183

SF Integration Points with SR FIT: YES

There are quite a few integration points between Student Financials and Student Records. At Ohio, since the Registrar‘s Office is currently responsible for tuition calculation and course/class fees, both units will need to continue to work closely together. Most other integration points are already integrated within Campus Solutions. For example, Student Financials may use a combination of Career/Program/Plan to help define tuition groupings. Student Financials also relies on Add/Drop and Withdrawal Codes to calculate and adjust tuition and fees. OHIO does not allow students to drop to zero units on or after the first day of class without doing an official withdrawal. OHIO also does not do a mass enrollment cancellation for non-payment of fees. Should OHIO decide to do either one of these in the future, Student Financials and Student Records will need to work closely together to get the tuition and fees correctly calculated and adjusted. Transcript Fees, Graduation Application Fees, and the Late Registration Fee will all need to be processed with the same business process that is currently used, the External File Load, Group process will have to be used, or an interface will have to be developed to post these fees.

SF Integration Points with FA FIT: NO

There are also quite a few integration points between Student Financials and Financial Aid. Student Financials and Financial Aid will need to coordinate and work closely together on defining Item Types and the definition of Anticipated Aid. FA has the ability in PS to do ―Online Disbursements‖ which post to the student account real-time. As long as Student Financials is aware that online disbursements are being done and they can take that information into account in the refunding business process, then there should not be a problem with FA doing some online disbursements. As mentioned above, while PS will allow OHIO‘s Financial Aid office to create a batch of Financial Aid transactions to be posted to the student accounts, PS does not deliver a way to have those batches automatically posted to the student accounts. Because of the Student Financials group posting process and also possibly due to PS‘s interpretation of separation of duties, PS requires that Student Financials manually determine if a new FA batch has been created and then run the posting process in order to get the FA posted to the student accounts. It was determined that OHIO would want to either create a modification to automate this posting process as soon as a new FA batch has been created or they could choose to use a third party process scheduler that would have the ability to automate this. There may be reasons why other modules within PS may also want to use a third party process scheduler. SF and FA will need to work together on the payment application rules for Financial Aid Item Types. SF and FA will have to work together to determine in what cases a Waiver should be used, in what cases a Third Party Contract should be used, and in what cases the Financial Aid functionality should be used. In general, a waiver should be used if a student is eligible for a partial or full waiver of the fee. A Third Party Contract should be used if an outside, third party is footing the bill and OHIO needs to send an invoice to cover some or all of the student fees.

STUDENT FINANCIALS

184

Financial Aid should be used for grants, scholarships, loans, and anything else that involves the tracking and managing of money used to help students get through school. PS v9.0 now has functionality called ―External Awards‖ that help FA in determining what ―other resources‖ a student might have. At OHIO, Student Financials currently processes R2T4 calculations. It was determined that Student Financials will continue to process R2T4 calculations, however Student Financials will have to work with Financial Aid (FA will have to be the ones to actually make an adjustment to an award if necessary) and Student Records (SR typically posts the withdrawal to the student and determines the actual ―Last Date of Attendance). As far as Emergency Loans is concerned, OHIO is open to posting a credit to the student‘s account once the Emergency Loan has been approved. These credits can then be refunded in batch as Emergency Loans. If OHIO decides to process Emergency Loans in this manner, it will have to modify its business process to get the promissory note signed by the student up front. It was determined that OHIO would use the delivered functionality within Financial Aid and Student Financials to process Perkins Loans, PLUS Loans, and all other loans. SF and FA will continue to work together to process internal and external scholarships. As mentioned above, the OGA system will need to interface with PS Financial Aid and Student Financials. There were a number of discussion points regarding Graduate Awards. It was determined that Graduate Studies, Financial Aid, and Student Financials will all have to work very closely to determine what exactly the interface between OGA and PS Campus Solutions will have to include and which PS functionality will best handle the business process and each of the respective requirements.



Checklist Table

Set up checklists.

Student Fin Installation

Define number sequencing, maximum row settings, edit tables and commit levels.

Keywords Define and associate keywords with item types to facilitate searches.

SF Account Types

Define account types to classify item types into usable account groups.

Item Types Define attributes, posting restrictions, link account types and map chartfields.

Item Type Groups

Define item type groups to limit the application of credits to certain charge items.

Tax Transaction

Define Value Added Tax transaction types.

STUDENT FINANCIALS

185

Codes

Tax Authorities

Create tax authority codes to process taxes attached to charges.

Tax Codes Define tax codes to link taxes and tax authorities to charge item types.

Aging Set Define aging sets for credit history processing.

Late Fees Create late fee definitions to identify past due charges and assess late fees.

Late Fees - Billing

Create late fee definitions to identify unpaid billed items and assess late fees.

Payment Overall Priority

Define the sorting of eligible charges for payment allocation.

Student Permission Forms

Create form for permission to apply restricted credits.

Charge Priority List

Define charge priority lists and rules and link them to item type tree nodes.

Billing and Due Calendars

Create schedules to determine the amount of fees due, the billing and due dates.

Adjustment Calendars

Define schedules and fees for tuition adjustments for drops and withdrawals.

Origin Table Define sources of receivables posted through group posting.

External File Layouts

Define the file layout for external charges and payments.

Group Type Table

Define sets of frequently posted receivables for use in group data entry.

SF Term Default

Define default terms to populate accounts when term is not used during posting.

Security Views

Review and modify security views for your system.

Valid Records

Review valid records used in trigger criteria for tuition calculation.

Valid Fields Review valid records, fields and edit tables used in trigger criteria.

Credit Card Type

Define the credit card types the institution accepts for payment.

Item Reasons

Create codes to provide brief explanations for payment and charge reversals.

Follow-Up Table

Create Follow-Up action codes that record the steps needed to resolve accounts.

Reason Out Define codes that identify why the system moved an item out of collections.

Fee Classes Define fee classes to enable reporting on specific types of fees.

Void Define codes to provide brief explanations for voided cashiering receipts.

STUDENT FINANCIALS

186

Reasons

AP Set Controls - Vendor

Define vendor information.

Reason In Define codes that identify why the system moved an item into collections.

Liability Status

Defines Liability Status Codes as determined by DEST for element 490.

Tuition Calculation Controls

Define parameters, rules, errors and warnings used for tuition calculation.

Invoice ID Number

Create an unique invoice ID that must appear on your bills.

Billing Type Establish bill types for your institution for students or corporations.

Message Categories

Create message categories to be used with billing messages.

Billing Scan Line

Create a bill scan line if your bank requires it to track transactions.

1098-T TIN Table

Set up a tax identification number for filing 1098-T tax forms with the IRS.

AP Business Unit

Define Accounts Payable interface and voucher numbering parameters.

Criteria Create criteria for tuition groups, fee triggers and waivers.

Invoice Layout

Set of parameters that define invoice information, sorting, and summarization.

Waivers Define waiver codes to waive or reduce a student's tuition and fee charges.

Waiver Groups

Define waiver groups to attach one or more waivers to class and course fees.

SpeedTypes Create shortcut keys of chartfields for department receipt entry in cashiering.

Billing Messages

Create messages that appear on your bills by message categories.

Provider Table

Define the International Health Coverage Provider Table.

SF Merchants

Define ePayment processing rules for different business units, including services performed.

Optional Fees

Create optional fee codes and values.

Coverage and Rates

Define coverage and rates for Providers.

Institutional Contact

Define institutional contact Information.

Combination Period Table

Create a combination period to retrieve consolidated academic statistics.

STUDENT FINANCIALS

187

Collection Letter Template

Create templates and delivery schedule of dunning letters for past due accounts.

Minimum / Maximum Fees

Define ranges for term fees, applications fees and other institutional charges.

Billing Standard Request

Define parameters to determine how you identify and bill groups of customers.

Bank Accounts - Business Unit

Bank account information for the business unit is managed from this page.

Bank Accounts - Corporate

Bank accounts for External Organizations are managed from this page.

Course Lists Create a group of courses for use with third-party contracts or course fees.

Per Credit Charge

Define the Per Credit Charge and Hook on fee defaults for NZQA.

StudyLink Institution Defaults

Define refund, residency and enrollment parameters for the institution.

StudyLink Posting Parameters

Define posting and refund item types for StudyLink.

Transaction Fees

Create transaction fees for adding or dropping classes as of a specific date.

Application Fees

Define rules, item types and fees for enrollment applications.

Loan Default Define parameters for HECS HELP, FEE HELP and OS HELP loans. Also defines status change rules for the HECS Reconciliation.

Optional Fees - Terms

Link optional fee codes to terms and assign date parameters.

SF Business Unit

Define the basic business rules for each business unit.

HECS Band Fees

Create and define HECS Band Fees.

Collector Define and establish collectors within the system.

Corporate Collection Criteria

Create a list of corporate collection criteria defined in your system.

SF Institution Set

Define self service ePayment parameters, rules, and usage for one or more business units.

Rate Tables for Course

Create student criteria to add to the course fee definition.

STUDENT FINANCIALS

188

Fees

Corporation Messages

Link message(s) that appear on a single corporation when the bill is generated.

Aging Set Messages

Link billing messages to specific aging sets and aging categories.

Customer Message

Link message(s) that appear on a single student when the bill is generated.

Item and Account Types

Define Item Types and Account Types for the Business Unit.

Identify SA Deduction Codes

Define student administration deduction codes.

Term Fees Define term fee codes to link to tuition groups.

Tuition Groups

Create tuition groups to assign a set of fees according to specific rules.

Deposit Fees Create admission deposit fees, due dates and status changes for payments.

Item Type Message

Link billing messages to specific item types or ranges of item types.

Business Unit Message

Assign billing messages to business units.

SF Self Service Options

Define business unit information for self service processing.

Course List Fees

Create fees for all courses within a given course list.

Create Deferral Contract

Define deferral contract parameters, administrative fees and eligible charges.

Optional Fees per Term

Define optional fee amounts.

Target Keys Define which charges receive credit for a given transaction.

Class Fees Create fees for particular instances of a course.

Class Fees Modal

Create or update fees for classes through the Schedule of Classes.

Course Fees Create or update course fees.

Course Fees Modal

Create or update course fees through the Course Catalog.

Tender Keys Define the types of tender used in cashiering transactions.

Cashiering Offices

Define the characteristics of each cashiering office for the institution.

STUDENT FINANCIALS

189

Service Indicator Sets

Define sets that automatically attach service indicators during Credit History.

Valid Registers

Define valid cash registers used in each cashiering office.

Valid Cashiers

Define valid cashiers working in each cashiering office.

Receipt Print Messages

Define messages that appear on printed transaction receipts.

Equation SQL Routines

Create or edit SQL that can be authorized to be called from an equation.

Equation External Subroutines

Adds an external cobol routine to the list of routines that can be authorized.

Equation Data Tables

Adds a table or view to the list of tables and views that can be authorized.

Equation Names

Authorize Equation Access.

Equation Test Data

Set up test data for an equation.

PORTAL

190

Section 11 Portal

CIBER Lead: Chris Couture OU Leads: Steve Flaherty, Shelley Ruff, Debra Benton, Jean Lewis, Jill Lallier, Kim Trout

OHIO has an opportunity to aggregate a number of current and new online content items into one single launch point – commonly referred to as a ‗portal.‘ But, what is a portal? The answer to this question varies from person to person. This is no surprise; the term ‗portal‘ is thrown about freely across the internet, by vendors, and end users, making a common definition hard to reach. Further compounding any portal challenge is the very nature of a portal solution. What can a portal do? In truth, a vendor-delivered portal product can do nearly anything. This can be frustrating to functional and technical team members alike. Portal implementation plans require more procedural and scope-based constraints than those plans associated with an application geared toward a defined set of business transactions. Some institutions embark upon an effort to ―home-build‖ a portal solution from scratch. The perceived benefit here of a solution that can, eventually, satisfy each and every requirement put forth by the various units and institutional entities. The return on investment, however, often goes unrealized as the home built solution requires significant upkeep and maintenance, on top of the great resource commitment to design and program the solution in the first place. Ideally, a portal solution should solve student, faculty, staff, and external constituents needs. These needs arise out of the daily operations of offices, departments, business units, and user community groups. Every institution has processes that can be transformed, in part or whole, into a self-service online transaction. These are the processes that fit well into a portal solution. Portals provide secure access to content and information. Portals offer personalization to each user, enabling an easy, intuitive, action based interface. Portals facilitate self-service transactions, reducing staff intervention and freeing those staff members for more creative, enriched involvement in operational responsibilities. But, these aspects of any portal solution must be brought forward as an organic extension of business, not as an IT-driven initiative. Technology alone cannot put forth a solution; technical solutions should support institutional needs. With these considerations in mind, CIBER recommends to OHIO a short-term portal strategy focused on gathering requirements to be used in deciding which portal solution to implement, or whether a portal should be implemented at all. This activity must be conducted in a defined time frame such that the decisions made can lead to action, harmonious with the planned Campus Solutions implementation.

PORTAL

191

General Considerations FIT: N/A

During the pre-implementation phase of OHIO‘s Campus Solutions implementation project, two distinct groups gathered to discuss the possibilities of a parallel portal implementation. The two groups – one technical and the other functional – shared insights, wishes, concerns, and questions about portal products, features, implementation aspects, and ways of doing business today. Though a wide range of items were brought forth, a few key items surfaced repeatedly in various forms. These items, listed here, are worthy of mention as general considerations, such that they form a broad context in which all specific recommendations and actions can be placed.

Any portal solution implemented will be an existing product. This means that the product will either be a commercial product, such as Oracle‘s PeopleSoft portal, or a freely available open-source product such as uPortal. No consideration will be given to a ―home-built‖ portal. If none of the portal products currently available can satisfy requirements, then no portal solution will be deployed under the umbrella of the forthcoming project.

Requirements must be defined. There are no defined, documented, and prioritized portal requirements from the various university entities. Until these are documented, no solution can be evaluated to determine a best fit.

An Identity Management System (IDMS) replacement effort will be undertaken. The current IDMS is institutionally crafted and will be replaced by a commercial product to expand capabilities and leverage vendor resources. This effort will have an impact on the implementation of any chosen portal solution, though the effort will be undertaken regardless of whether a portal will be deployed or not.

The remainder of this portal strategy document focuses on details of the latter two considerations.

Portal Requirements FIT: N/A

‗Portal,‘ being a term of varied meaning, needs to be defined for common understanding at OHIO. The processes outlined here will give each participating entity – department, office, business unit, etc. – an opportunity to help craft that definition by specifying the on-line services and communications important to daily business activity. The aggregate results of the described Requirement Gathering effort will be the ‗portal‘ OHIO is seeking to deploy.

Requirement Gathering

Described here is a basic approach to gathering requirements for a portal solution. OHIO University can enhance this approach to suit cultural and organizational nuances, but a fancy rework of the approach will take focus away from the intended purpose. Simple is best. 1. Set a defined time period for the effort. Leaving an open-ended duration often translates

into lackluster results or failure to obtain any information at all. Six months should be the

PORTAL

192

outer limit on this time period. The entire set of activities can be conducted in less if the involved members are prepared, focused, and realistic.

2. Identify all relevant entities. These can be departments, offices, business units, user community groups, advisory groups, boards, etc. The list of entities should reflect all, or at least most of the university. Some areas may legitimately have no need for portal functionality. Request that each of these entities designate one individual to serve as the lead for this requirement gathering effort.

3. Meet with members of each entity, charging each entity lead with inviting appropriate entity members to participate.

4. Gather requirements. See Appendix A for a detailed list of questions and considerations that can be used in gaining useful information on requirements. Document all requirements offered; each will be reviewed in subsequent activities.

It is important that the entity members feel free to offer up every possible idea. All ideas won’t make the final list but constraining the requirements at this phase is both unnecessary and discouraging. The creative, generative, forward thinking mindset of each participant needs to be fully engaged for this activity.

5. Collate the requirements, identifying similarities and requirements unique to specific entities. Organize the requirements such that similar items are together.

6. Distribute the full set of requirements to the entity leads, requesting that each return entity rankings for the relevant requirements (which may or may not have been generated from within the respective entity). Refer to Appendix B for a suggested ranking methodology.

7. Collect the requirements, order the entire list by rank, and distribute for final confirmation of

priority. 8. Analyze the requirements. Is there sufficient need to bring a portal product online? If so,

review existing portal solutions and determine which would be most appropriate.

IDMS Replacement FIT: N/A

Ohio University intends to move away from the home-built Identity Management System (IDMS) to the use of a commercial product. Expressed by the technical team was a desire to use the directory as the source of security for as many systems as possible, such that security information could be passed into each integrated system at the time a user signs in. Also, rather than storing sensitive data in each application, the technical team would like to have this information stored only in the directory, passing it into the application as it is requested. The changing in IDMS is not specifically tied to any portal implementation decision. An appropriate IDMS needs to be in place in the near future to support technological growth, new

PORTAL

193

implementations, etc. But, having planned for a solid IDMS will serve a portal implementation well, as a portal will be connecting to a number of other authenticated systems.

Requirement Gathering

Described here is a basic approach to gathering requirements for a replacement IDMS solution. OHIO can enhance this approach to suit cultural and organizational nuances, but a fancy rework of the approach will take focus away from the intended purpose. Simple is best. 1. Set a defined time period for the activity. Leaving an open-ended duration often translates

into lackluster results or failure to obtain any information at all. Ideally the new IDMS would have been identified before the Campus Solutions implementation begins.

2. Identify every system that requires authentication, secure access, or some type of user-

specific data to be passed when the application is requested. Indicate any system which will be terminated in the near future such that these can be excluded from plans for configuring the new IDMS.

3. For each retained or new system, document the specific security element used. As an

example: Oracle‘s PeopleSoft applications connect each user to a User Profile; each User Profile is connected to one or more Roles; each Role is connected to one or more Permission Lists. It is not important to document any specific security element names (such as the list of all delivered roles or the list of delivered Permission Lists), just the structure and use of those elements within the system to provide access to users.

4. Identify the similarities and differences between the ways each system handles security. 5. Working with each system‘s users, and based on business needs/requirements for that

system:

o Identify the broad and granular user communities. o Identify sensitive data, indicating that which is common to most of the systems

and that which is system-specific. o Document desired business process(es) for creating, modifying, and deleting

user data. o Use the documents resulting from these activities to determine which

commercially available IDMS will meet the needs of the university.

Requirement Gathering Questions for Portal FIT: N/A

Use these questions as a starter for gathering useful information on requirements. Note that certain questions may not be applicable to all entities.

General

Describe organizational communications. What types of communications are delivered to which audiences? What delivery vehicles are used? Is there an organization

PORTAL

194

communication plan? Who creates, approves, and delivers messages? Is automation used in one or more delivery vehicles?

How are projects/initiatives executed?

Which of the Oracle and PeopleSoft products are in use or being implemented?

Describe the current process for requesting new content on the portal or authenticated web site.

Indicate issues, concerns, and external factors that may impact progress.

Identify calendar periods of greatest business activity.

Identify environmental concerns that portal use may address.

Branding

Does an official organizational identity guide or manual exist? If not, do guides exist for logo usage, official colors, publication, web standards, etc.?

Consider a branding spectrum. On one end is a portal with a consistent branding scheme applied universally. On the other end is a portal with multiple, unique branding schemes applied to different areas of the portal. Describe the point at which the organization would get the most value.

Should different users, such as students and alumni, see different branding after authentication?

Should the portal look like the organization web site? Should it look like a child of the web site? Should it utilize delivered branding layouts with institutional coloring and logo? Should it use delivered branding?

Content

Who develops content such as documents, forms, web pages, promotional items, etc.? Describe the process for developing content from inspiration through delivery.

Is there a CMS system in use and will it continue to be used? Describe how the system is currently used and indicate any plans for expanded or more effective use.

List all systems available to the user communities. For each, indicate whether the system is currently available via a single sign on or reduced authentication (SSO/RA). Indicate, too, whether the system should be included in the new portal's SSO/RA configuration plan.

List all secure web sites available to the user communities. For each, indicate whether the site is currently available via a single sign-on or reduced authentication configuration. Indicate, too, whether the site should be included in the new portal's SSO/RA configuration plan.

List and describe the key business processes for each user community. Include detail on calendar periods when the processes are most important, not necessary, etc.

What vehicles are currently used to deliver critical and topical news to user communities? Describe when and how news should be delivered.

What tools, systems, or methods are used for document sharing and collaboration?

Which calendar and email applications are available? Which are in use?

Indicate the importance of 'external' content (weather, news, travel info, etc.) being made available via portal?

PORTAL

195

How personalized can a user make his/her current portal experience?

List all content currently available. Add new items and mark items not to be brought over. Associate each with a business process. Indicate whether the content is critical, supporting, informational, or unnecessary in relation to the business process.

How should users be able to interact with other users via portal (instant messaging, discussion, community directory, blog)?

What types of community directories or online phonebooks are in current use?

What reporting solutions are or will be used? Is there a data warehouse? Is there a BI solution?

List and briefly describe all applications in use or available to user communities. Include desktop applications and legacy systems.

What web browser is deemed the institutional standard, if any?

List and briefly describe all websites related to the institution.

Navigation

Should users be able to search for and render external content that is not available on the portal menu?

How important is graphic representation in regard to navigation?

What content needs to be available via mobile devices?

What content needs to be available via public kiosk?

Should unauthenticated users see some content? What content would that be?

Security, Integration and Technical Considerations

Will Workflow be deployed? If so, how extensively?

Will Integration Broker be deployed? If so, will custom messaging be included in scope?

For each broad user community, list and describe various user roles.

Describe the current process for granting access to users. Is the process satisfactory? When are new users entered into the system en masse? How are administrative users added? Are system administrators added in the same way?

List all systems available to the user communities. For each, indicate whether the system is currently available via a SSO/RA. Indicate, too, whether the system should be included in the new portal's SSO/RA configuration plan.

List all secure web sites available to the user communities. For each, indicate whether the site is currently available via a SSO/RA configuration. Indicate, too, whether the site should be included in the new portal's SSO/RA configuration plan.

List and describe user communities with no access today but who would, ideally, have access in the next three years.

List and describe the measures executives and administrators would find useful in guiding portal activity.

PORTAL

196

Ranking Requirements FIT: N/A

When ranking a requirement it is critical that the participant can grasp the relative importance of that requirement relative to the initial launch of the product or solution. Thus, the rankings below are relative to the initial launch, or Phase I Go-Live. After that launch – in other words, when Phase I ends and Phase II begins – any unmet requirements can be pooled with new requirements, and the same ranking activity can be undertaken to set Phase II priorities. Rankings For the participants, rankings need to convey a sense of importance. Lettered rankings are useful for this purpose. When ranking requirements, each participant assigns each ranking exactly one ranking letter, which represent the meanings described below.

Ranking Meaning Phase I Priority

A This requirement is critical to business and must be satisfied in Phase I.

First

B This requirement is a must-have, but can slip past the initial go live as long as it is satisfied shortly thereafter.

Second. A number of these will be satisfied in Phase I. However, if time and resources become limited it is these ―B‖ requirements that will be deferred. Any of these that are unsatisfied at the conclusion of Phase I would likely become ―A‖ requirements in Phase II, excluding those which lose value during the implementation.

C This requirement is a ‗nice to have‘ but will not impact business.

―C‖ requirements are out of scope for Phase I unless satisfaction of an ―A‖ requirement would make the additional effort to also satisfy the ―C‖ requirement nearly non-existent.

X This requirement is not relevant. The indicated requirement has no bearing on the business activity of the entity.

Tabulating and Ordering Results Each of the top three rankings is assigned a numeric value:

A = 3 B = 2 C = 1

PORTAL

197

For each requirement, convert each ranking to the appropriate numeric value to determine the ranked value. Thus, if there are ten entities ranking requirements and each ranks a particular requirement as an ―A‖ that requirement has a ranked value of 30. The ―X‖ ranking is used to account for requirements that are not relevant to all ranking entities. For each of the first three ―X‖ rankings assigned to a requirement, deduct .33 from the total ranked value. For example, of ten entities, eight rank a requirement as ―B‖ and two rank the requirement as ―X.‖ The eight ―B‖ rankings result in a ranked value of 16, but the two ―X‖ rankings reduce the value to 15.33. The idea here is that a requirement relevant only to some entities is, generally, of less importance than a requirement relevant to all entities. For this last point, it is important to exercise good judgment in recognizing the value of certain entity-specific requirements. For example, a requirement indicating the necessity of on-line class registration has no relevance to fundraisers, but is of critical importance to Student Records. Use the rankings as a method to get a general sense of priority, with the understanding that some requirements will be promoted beyond the priority indicated by rankings. It may serve the university to prioritize rankings both institutionally and within each entity.

BUSINESS INTELLIGENCE

198

Section 12 Business Intelligence

Business Intelligence Summary

Until recently, OHIO has not pursued an integrated, enterprise approach to Institutional Business Intelligence. But as OHIO considered moving to a new student system it seemed appropriate to also address reporting issues in both the student and Oracle eBusiness HR and Financials products. To that end, OHIO purchased Oracle Business Intelligence Enterprise Edition (OBIEE) in conjunction with the purchase of PeopleSoft Campus Solutions.

CIBER conducted two weeks of workshops focused on Institutional Business Intelligence at Ohio University (OHIO) the weeks of May 5th and 12th 2008. The workshops and those participating were put into two categories, regulatory reporting (external) and management reporting (internal).

This document summarizes the results gathered from those workshops and proposes an Institutional Intelligence approach that can be implemented in parallel with OHIO planned PeopleSoft Campus Solutions implementation project. This document also addresses the current state of reporting, and the future vision of reporting within the institution. The document discusses both architectural and functional approaches to achieve the future state, and includes information on proposed tools, warehousing and hardware. The architectural approach includes a description of current tools within OHIO‘s inventory as well as suggested additions to that inventory. The functional approach discusses options for which functional group would be best served by being the first group to use OBIEE, as well as the Campus Community benefits of different groups implementing first.

Current State

Overview –

The current state of reporting at OHIO is one that is common across institutions in Higher Education. There is an Institutional Research (IR) group who have centralized access to most critical data throughout the university, and who are primarily responsible for reporting ―OHIO‘s official numbers‖ to internal and external constituencies.

But when it comes to end user reporting, most Departments or Colleges work very independently within their programs and requirements. When a need arises for the capture or extraction of data, independent budgets and guidelines within each area are often used to address that need. As a result, OHIO does not have a university-wide standard for reporting technology, security approach metadata definition or architecture, and this makes cross-silo data analysis challenging.

Listed below are details of OHIO‘s current state gathered through discussions with CIBER. They are categorized into

data sources;

tools that are being used for analysis and reporting today;

the processes that are used to retain data for analysis, and

the means of distribution of data, and security provided for data.

Current and Proposed Data Sources at OHIO


199

System Description

SIS – Student Information System The current Informs student system of record

SAM – Student Aid Management The current financial aid system of record

Oracle eBusiness Suite System of record for Financials, Human Resources, Payroll and Project Management for Grants

Data Warehouse

Tapes of history

PeopleSoft Campus Solutions Will become the new student and financial aid system of record

DARS – Degree Audit Requirements System System of record for transfer credit articulation and degree requirements

Recruitment Plus Student prospect recruiting system

Ad Astra Classroom scheduling system

CashNet Electronic payment (ePay) system

EventsPro (formerly PeopleAdmin) Scheduling and ―mini-registration‖ software used by Continuing Education and Lifelong Learning

Workforce Management Software Time and attendance system

Adirondack Used for housing operations and judicial affairs

BlackBoard Course management system

Conference Programmer Summer conference and guest housing

Pitney Bowes Mail Mailstream software

BSR Advance Alumni and development fundraising system

TMA – Total Maintenance App ???

Facility work orders

Space Management

Micros Point of Sale software

Aurora FoodPro Food Service software

Harco Optim Bobcat Cash card

Custom Systems ???

OGA – Online Grad Appointments

EMS – Employee Management System Is this Kronos?

IT Systems – custom built

FileMaker Pro for Telephone Billing

Mainframe CMS for Long Distance Billing

FootPrints Billing Data Numara?

SFA Custom Built Database

PACE

Workstudy

Scholarship (donor and scholarship recipients)

Registrar Custom Built Databases

Course fee tracking

Graduation tracking (holds data used for graduation programs and the like)

Custom Built Admissions Campus Visit


200

Database

PARIS PCard Purchasing Accounting Reporting Information System for purchasing card transactions

Hyland OnBase Document Imaging

LEO Pre- and post-award grant data

CollegeNet

SunGardHE fsaAtlas SEVIS tracking and reporting

FoxPro Budget Management Budget control values by unit

JumpTV Event Ticketing Athletic ticketing

Credentials, Inc. Online transcription service, host requests for credentials, forwards to requestor and updates OU regularly

Cumulus – UCM (L Lockhart)

Tools used for Reporting at OHIO

SAS (used primarily by Institutional Research)

Custom Web Applications

Multiple middle tiers for custom query applications

TOAD (Tool for Application Developers)

Oracle Discoverer

Microsoft Access

Microsoft Excel

Tableau (used to merge multiple spreadsheets into a single analyzable format)

Brio Query

Crystal reports

Open Source Jasper Reports

Microsoft Query

Processes used to gather, characterize and retain data

In order to have agreement between the numbers that different departments report, it is necessary to have

common processes for assembling the data together from multiple sources (if necessary)

common definitions for terms used for aggregate or ―meta-data‖ (i.e., what is an ―enrolled student?‖ How is a ―cohort‖ defined and reported?)

common processes for archiving and retaining data for longitudinal or historical reporting.

At OHIO, processes to gather, characterize and retain data differ greatly within the university community. With the exception of Institutional Research (IR, which will be discussed in the next paragraph) most analysis is done on an as-needed basis. These as-needed requirements are met through a multitude of primarily manual processes, and (as demonstrated by the list of tools above) requirements are met through the tools that are closest to hand, or that the user has the most familiarity with. This often results in inconsistent presentation of information, and confusion over how numbers were calculated and data was extracted.


201

The colleges and departments are not presently following a systematic process for extracting and using data within OHIO. Each area has its own methods for gathering information, and these are not typically congruent with university-wide standards or conventions. Each may use their own definitions for the terms on their reports. In the worst case, two different reports will show widely varying numbers for the same statistic because the data sources and data points used to calculate the statistic vary. And finally different departments follow different processes for archiving and retaining data. In many cases historical data is not maintained in any consistent manner and has to be recreated when needed.

The Institutional Research group is much more regimented and process- and standards- driven. Because their numbers are the official OHIO statistics reported to external constituencies, consistency is a baseline requirement. For that reason all data extractions are done following the same strict guidelines and have been for years. Although IR is not the only source of data on campus, the data they do provide is considered clean, correct and people are confident of these numbers.

Accessibility/Distribution

Access to and distribution of data (with a few minor exceptions) is fairly open. Data is primarily distributed in stagnant formats (static graphs on a website, data saved to a non-updating Excel spreadsheet or the like), rather than dynamically updating reports or dashboards.

Security

There appears to be no standard security processes defining and controlling user access to data in a uniform manner across the University. Each area that controls a data source system has defined its own security and the rules are not consistent from source to source. For example one system may control access by department, dean or chair while another controls access by program and yet another may control is user by user. This will be very apparent as an enterprise reporting strategy starts to develop. This is an issue that should be addressed in totality not just with regard to a warehouse.

Future Vision

The future vision discussions of reporting were very well defined. Reporting users at OHIO know what they want and presented those requirements concisely and with near consensus. They want the following:

Consistently presented data, and numbers that can be tied back to known standards

―My Dashboard‖: the ability to create their own vision of reporting using university-defined data

A Glossary: a clearly documented (and routinely updated) repository which defines the data within the BI subject areas to be created, describes how it was calculated. For example, when a report counts ―enrolled students,‖ what data points are used to define an ―enrolled student?‖

The ability to view and analyze data in multiple ways through table, pivot table, ad-hoc, or graphical charts and graphs


202

Easy integration with common tools such as Microsoft Excel

Up to date information. Users would like to see data no more than 48 hours hold (although current manual business processes and data extraction process do not support that at this time)

Reduction of shadow systems that currently house duplicate data, thus supporting better stewardship of data and confidence in reporting.

Approaches

Architectural Approach 1

The first approach utilizes only the products OHIO has already purchased. This approach assumes that OHIO will create a Campus Solutions data warehouse using the PeopleSoft Enterprise Performance Management (EPM) data mart with OBIEE as the presentation layer. It would only include PeopleSoft Campus Solutions as a data source, since Campus Solutions are the only ETLs (Extract, Transform and Load scripts) that are delivered for EPM at this time. OHIO‘s future direction would be significantly affected by Oracle‘s plans for supporting the EPM Campus Solutions Warehouse, which will presumably be phased out in favor of Oracle‘s newer toolsets.

Campus Solutions

ETL Process and

Staging area

DataStage

Campus Solutions Warehouse

OBIEE Analytics Server

OBIEE Web

Services


203

Architectural Approach 2

The second approach is to follow Oracle‘s strategic direction for Business Intelligence. Oracle‘s current strategic direction is a combination of Oracle products and partner, best of breed, products. This includes OBIEE (which OHIO has already purchased), Informatica, which would be a new purchase, using an Oracle database for the warehouse. The selection of Informatica as the ETL tool would provide two significant benefits over approach 1:

1. First is the ability to connect to any Open Database Connectivity (ODBC) compliant source of data and integrate that information into the data warehouse.

2. Second is the ability to purchase pre-packaged ETL processes, data mart architecture and pre-designed presentation layers for any of OHIO‘s eBusiness or PeopleSoft modules (except PeopleSoft Campus Solutions).

CIBER recommends this approach.

3.

Data Warehouse

OBIEE Analytics Server

OBIEE Web

Services

Campus Solutions

Campus Solutions

ETL Process and

Staging area

Informatica

All Source

Systems


204

Functional Approach

The most important predictor for a successful Business Intelligence implementation is to resist the temptation to solve all of the institution’s reporting needs or problems in one large project. Regardless of which technical approach above is taken, CIBER recommends that OHIO take no more than 6 months to design, deploy and socialize a business intelligence ―proof of concept‖ for a designated portion of the campus community. In order to accomplish this,

the project should include several easily-managed phases to provide quick successes along the way,

there should be a limitation on the initial audiences for, or users of reporting,

OHIO should also limit the number of source systems to be integrated into the warehouse for each phase.

Again it is important that each phase take no more than about 6 months before it is in a production environment. This allows users to see some real progress and benefit from reporting quickly, and it makes it easier to involve more users, more deeply in report definition and testing without taking them out of their normal jobs for too long a project. Obviously the functional approach will be partially dictated by the architectural approach in that approach 1 will only be useful for users of Campus Solutions data.

Functional Approach 1

Functional approach 1 would be to select a smaller user community to use as the prototype audience for the initial roll out. The group should:

Be visible and respected within the larger university community, and if possible be a reporting resource for other institutional audiences. In other words, choose a group whose reporting data has good visibility or reuse within the university.

Have already defined very specific reporting requirements,

Be willing to be champions of the process and the successes.

As noted above, CIBER recommends that a very limited amount of data is included in initial scope and no more than 3 source systems be included.

Functional Approach 2

The second functional approach would be to work with the largest consumer of university data to get their buy in and confidence in the new system. As with many universities, this largest data consumer is Institutional Research. As noted above, IR currently faces some challenges that could be resolved within the context of a BI implementation:

They currently use many manual steps to extract and clean their data,

They use many tools to report their data both internally within the campus and to their numerous external constituencies.

While they have the most consistent processes within OHIO, their data archiving process is not completely uniform yet, and could benefit from increased security.


205

It would be a significant first step to get all of IR‘s history stored within tables on an accessible database, and to begin automating the manually intensive process of massaging data currently in place. Choosing this approach first could win over the largest consumer of data within the campus community. And since they are currently the most respected source of ―official numbers‖ for OHIO, their stamp of approval will increase user adoption for later projects.

CIBER recommends this approach.

INTERFACES

206

Section 13 Interfaces An interface can best be described as an automated inbound and/or outbound flow of information from/to the PeopleSoft application to/from another computerized system for processing.

A review of each of the Existing legacy interfaces was conducted during the Fit/Gap process. These interfaces are listed in the table below. OHIO will need to review these during the Implementation process to determine the appropriate process for each interface.

Oracle/PS Module Application Name Function provided

Integrate/ Interface

Student Financials Oracle Financials Summary Student Revenue

Student Records CAS

Student Records National Student Clearinghouse

Student Records Campus Recreation

Campus Community FSAtlas

ID Card System

Recruiting and Admissions/Student Records

Articulation and Transfer Clearinghouse

Student Records HC70 (Historic OHIO Electronic Records) (temp)

Student Records Library

Student Records/Student Financials

Pyramed

Student Records AlcoholEDU

Student Records Titanium

Financial Aid Work-Study Database

Financial Aid PACE Database

Financial Aid Scholarship Database

Student Financials State of Ohio Office of the Attorney General

Student Financials Campus Partners

Financial Aid Change of Income Database

Student Financials Power Park

Recruiting and Admissions

On-Campus Visit Database

Student Financials Sales Point

Student Financials P-Counter

Student Financials Chase Bank

Financial Aid OpenNet

Financial Aid ScholarNet

Financial Aid Oracle HR/Payroll

Financial Aid Enrollment Confirmation Database

Financial Aid OGA – Graduate

INTERFACES

207

Appointments/Fellowships Database

Financial Aid Biennial Budget Survey Database

Student Records

Student Records

Student Financials

Student Financials, Person Data

Blackboard LMS

Financial Aid SCT BSR Advance Alumni Contributions

Financial Aid CASHNet Student Payment

Student FinancialsRecords

Adirondack Housing and Judiciaries

Academic Advising SIGMA SAM (temp) Financial Aid

Recruiting &and Admissions


AD Astra


DARS Degree Audit

Recruiting &and Admissions, Registrar, Financial Aid

CollegeNet Online Application

Student Records CollegeNet -- Contact Manager

Recruiting

Academic Advising


Highland OnBase Imaging and Workflow


Acalog


Recruiting &and Admissions (Med)

Hobsons EMT (interface with Recruitment Plus)

Chat

Recruiting &and Admissions (Med)

Continuum 422 Campaigns

Event Management

AACAMAS Online admissions

Recruitment Plus Student recruiting

INTERFACES

208

The following table identifies Potential New Interfaces to be developed as a result of the PeopleSoft Implementation and as described in the Fit/Gap Document..

MODULE SECTION INTERFACE

ACADEMIC STRUCTURE

Department Table Departments- possibly parking and internal organizations in the University - interfaces with Student Financials.

Academic Sub-Plan Table

A question was raised if OHIO decides to retain DARS, how will the Plans and Sub-plans be translated to DARS for processing the appropriate degree requirements?. Interface Management Services is working with CIBER at UT Dallas on developing this interface.

CAMPUS COMMUNITY

Identify any major systems that may be retained and will need student data feeds

We must identify every single system on campus and determine whether it needs continued support. We will then assess what interfaces are needed (feed and download).

Personal Information / Biographical

OHIO may need to interface to the NCAA's Compliance Assistant Internet (CAI).

Identification Residency logic will need to be revisited and reestablished in the interface with CollegeNET to PS.

RECRUITING / ADMISSIONS

FINANCIAL AID

Financial Aid Terms

The OHIO financial aid system currently interfaces with an online application (Enrollment Confirmation) that is used by students to inform the office of their planned enrollment for the academic year. This application is used primarily for summer aid awarding. This interface will still need to exist.

Awarding/Mass Packaging

An interface to the current Online Graduate Appointments (OGA) will need to be built.

Awarding/Mass Packaging

OU has a system (OGA) system that handles the waivers and this is also an interface to the FA legacy system. When the interface runs, it determines if there is an account code in the FA legacy system

INTERFACES

209

that matches the waiver and if not then the OGA interface creates a new account code that will handle the new waiver.

Perkins Perkins will need to have a custom interface with the servicer of the loans (Campus Partners).

Student Employment

Payroll information for all student employees is done in Oracle Financials, there will need to be a custom interface with PS to obtain and load the amount the student has earned in work study for the FISAP report.

Student Employment

There will need to be a custom interface between the FWS database and PS.

STUDENT RECORDS

Set up Attendance Tracking

Develop an interface between the ID Card system and PS Attendance Tracking

Set up Special Grade Point Averages

OHIO needs an interface to load and store special GPAs from DARS for ―GPA in major.‖

ACADEMIC ADVISING

Currently, there is not an interface delivered from DARS to PS 9.0. A DARS/PS interface may be purchased from Interface Management Services (IMS) for PS versions 7.6 or newer

Course Applicability System (CAS

The Ohio Board of Regents supports CAS and requires state-assisted institutions to participate. Currently, there is not an interface for PS 9.0. An interface will be required.

STUDENT FINANCIALS

Calculating Tuition, Fees, & Waivers: Term Fees

Residence and Dining Hall charges will not be handled via Term Fee functionality in PS. These Residence and Dining Hall charges will most likely be posted via an interface with the new housing system or via External File Load, Group Post in PS.


One of each will also need to be set up for Housing if housing is going to interface using the External File Load, Group Post functionality.

Student & Third Party Receipts:

Although CASHNet has a very good reputation for working with clients and getting their software interfaced with PS,

INTERFACES

210

Online Payments & Cashiering

this will be included in the interfaces section of this analysis

Student & Third Party Receipts: Departmental Receipts

CASHNet has the ability to interface with Oracle Financials for those ―departmental receipts‖ that need to be fed straight to the GL rather than being posted to a student or third party account.


There will need to be a major development effort to both modify and interface the PS Campus Solutions refunding process with the Oracle systems that OHIO uses for Accounts Payable and HR/Payroll.

Student Financials Interfaces

OHIO currently uses CASHNet for online payments, cashiering, and eBill presentment. CASHNet has worked with PS to deliver the application interfaces to Student Financials.


Adirondack Housing Management System –OHIO thinks that Adirondack has worked with PS on interfacing the two systems. OHIO needs to confirm whether or not the interface pieces already exist or whether they will need to be built.


OHIO is in the process of upgrading to the latest PowerPark parking management system (T2 Systems). OHIO will need to determine how it wants to interface this application to Student Financials.


OHIO will need to determine if it wants to interface any library transactions with Student Financials. If so, this interface will have to be developed


Health Center / Pharmacy / Diagnostic Services & Immunizations -- OHIO will need to determine if it wants to interface any of these transactions with Student Financials. If so, this interface will have to be developed


SoftCash Software Sales Application – OHIO will need to determine if it wants to interface any of these transactions with Student Financials. If so, this interface will have to be developed


OHIO currently charges students for printing on a monthly basis. OHIO will need to determine if it wants to interface any of these transactions with Student Financials.

INTERFACES

211

If so, this interface will have to be developed


OGA Online Graduate Awarding System –It was determined that OHIO will keep this application and that a complex modification/interface will need to be developed to replace the existing interfaces.

Processing GL Accounting Entries

OHIO uses Oracle Financials. most likely OHIO will need an interface developed to actually get the accounting entries into Oracle Financials.

SF Integration Points with AD

OHIO uses a web application for Orientation. OHIO will have to decide whether it will continue to use this web application and if so, whether it wants to interface to student financials or continue to post these charges manually or through the PS delivered External File Load, Group Post process.

SF Integration Points with SR

Transcript Fees, Graduation Application Fees, and the Late Registration Fee will all need to be processed with the same business process that is currently used, Group process will have to be used, or an interface will have to be developed to post these fees.

SF Integration Points with FA

the OGA system will need to interface with PS Financial Aid and Student Financials.

MODIFICATIONS

212

Section 14 Modifications The over arching philosophy for the Ohio University project is ―NO‖ modifications. The University team has aggressively supported this philosophy. Gaps were identified and solutions proposed. The following chart provides a brief narrative of the modification. The second chart identifies the modification and a preliminary estimate of the effort for the solution.

Gap Descriptions

MODULE SECTION GAP ACADEMIC STRUCTURE

Load/Level Rules Ohio University may need minor modification to Academic Level Translates to reflect various Graduate levels.

Career Pointer Exceptions If you set at the Undergraduate Academic Career that course career of Graduate allows enrollment with permission, then undergraduate students not participating in one of the approved programs could mistakenly be registered in a graduate course.

Degree Table The length of the Formal Description field is only 50 characters. OHIO has degree names longer than 50 characters.

CAMPUS COMMUNITY

Personal Information / Biographical

A process to switch preferred flag to campus email address is needed.

Participation A Gap resides in associating committees to publications and thesis tracking.

Service Indicators / Holds Ability to exclude charges from old calc (bursar‘s office) does Not Fit.

Service Indicators / Holds There is a Gap in notification of address update so hold can be released: out of state address changes trigger hold. This is a gap for financials and admissions


No automation between assigning/completing checklists and the placing/removal of holds. OHIO wishes to provide more detailed

MODIFICATIONS

213

information in the description section.


Possible Customization: Some due dates may need to be masked in the "to do" section of Self-Service

Events The events module does not meet the needs of the OHIO Admissions offices which conduct the majority of events.

Student Service Center OHIO would like to have students see DOB (this is delivered and is OK), but not have the ability to change, update FERPA restrictions, update preferred name/no edits on others.

SEVIS A service indicator needs to be built to mark whether a student is eligible or not eligible for work--also need contact information for questions. It is necessary to consult with student employment to set business processes. Gaps: form generation, tracking employees and persons of interest (guests).


FINANCIAL AID Financial Aid Terms At the point of disbursement, actual enrollment is used with updates based on enrollment changes through the census date. This functionality will need to exist in the new PS system

Financial Aid Terms Automatic updates of enrollment for upcoming quarters and the ability to ―lock‖ enrollment and campus are not current functionality in PS.

Financial Aid Terms Possible Gap – There is no field displaying a prior degree value for a student other than the ISIR.


OHIO requires that this be an automatic process for sending and receiving ISIR data and not a manual process.

MODIFICATIONS

214


OHIO requires that the proration change nightly for a student based on their projections of their enrollment. PS processing only runs INAS calculation once when an ISIR loads

Verification ISIR selected for verification have to have a process to apply appropriate checklist item during ISIR load process. Process should also remove or complete checklist items, as received and processed.

Student Budgets Ability to lock certain budget categories while allowing others to be rebuilt when there are changes to enrollment, etc

Awarding/Mass Packaging Waivers – Graduate Studies – GAP HIGH

Awarding/Mass Packaging Educational Waiver – these are internal waivers and are processed through the OGA and post to SAM. These may also fall into the modification due to the varying diversity in the awards.

Awarding/Mass Packaging Continuing Education Waiver – it is recommended that this be combined with the OGA modification

Awarding/Mass Packaging Spousal Awards – will need to be combined with the OGA modification.

Awarding/Mass Packaging Functionality of PS online award letter is very limited compared to our current online award letter in regard to messages associated with awards

Awarding/Mass Packaging Possible Gap – Campus or location is not an indicator in PS.

Authorization/Disbursement Ability to generate report on what items have been disbursed for a particular day.

Pell Payment Processing Pell data is sent to COD System in an automated process which will need to be developed in PS

Pell Payment Processing Possible Gap - OHIO only originates those students‘ Pell awards if they have been disbursed for the quarter. PS does not have the functionality to

MODIFICATIONS

215

trigger origination from the action of having been disbursed.

Loan Processing Direct Loan data is sent to COD system in an automated process which must be developed in PS

Loan Processing OHIO originates loans that are in an accepted status for students pre-registered for the term or for loans that are offered for the term, even if the student is not pre-registered.

Satisfactory Academic Progress (SAP)

Undergraduate SAP policy: maximum time frame for degree completion based on level of study and degree plan.

Satisfactory Academic Progress (SAP)

Graduate SAP policy: maximum time frame for degree completion based on Master level graduate students and degree plan.

STUDENT RECORDS

Review / Define Student Records Installation settings

OHIO calculates and displays the GPA to four decimal places, but truncates to three decimal places on reports.

Define Class Notes In PS the delivered Self Service controls for Class Search do not offer the option to display course or class fees.

Define Class Notes OHIO would like Class Notes with hyperlinks for further information about the class.

Define Facilities and Rooms

There is nothing in PS to prevent the Registrar from scheduling classes without departmental permission.

Define Facilities and Rooms

There is nothing delivered that associates a contact person for a scheduler in the Facility Component.

Requirement Designation Potential GAP: If OHIO uses PS AA, OHIO wants to develop a process to automatically assign requirement designations to courses that have TP and TD grades.

Define Standard Meeting Patterns

OHIO can currently assign two classes into the same facility if they have the same meeting pattern. PS allows this for different sections of the same course, but not different

MODIFICATIONS

216

courses.

Define Repeat Rules OHIO‘s policy is to limit the number of retakes. In PS, when the Repeat for Credit checkbox is cleared on a course, it is not possible to specify the maximum number of hours allowed for repeat.

Define Repeat Rules OHIO needs to be able to track each occurrence of a course that has been repeated for credit.

Define Enrollment Requirements

OHIO has a process that runs quarterly to drop students who fail to meet the prerequisites based on the final grades for the term.

Set up Attendance Tracking PS provides a table for storing attendance data but there are no workflow processes delivered around the attendance tracking system.

Set up Attendance Tracking If a student is identified as not attending a class, there is no delivered functionality to alert an advisor, etc

Create Academic Standing Rules

OHIO uses Deficiency Points as a key element in calculating academic standing. This functionality does not exist in PS.


Some departments at OHIO manually calculate a separate academic standing for individual colleges based on a subset of courses taken only in the college or the major.


Academic standing for the full-time undergraduate career differs from that for the part-time undergraduate career.


If a student can‘t pass a class within a certain number of tries, they are dismissed from the major. A ―C‖ or better counts. Also, WF, FS, and F grades count as attempts. A ―D‖ can count in some attempts.


OHIO produces a report, which is distributed to Departments that lists students who have not met the

MODIFICATIONS

217

status of Good Standing. . PS‘s Academic Standing process posts the standing online when run. There is no delivered report only option.

Set up Special Grade Point Averages

OHIO needs a way to store external cumulative hours attempted, and external cumulative grade points.

Define Grading Schemes OHIO needs the ability to default grades in certain classes, such as audit and dissertation.

Define Grading Schemes OHIO needs to be able to track multiple grade changes prior to the grades being posted to the student‘s record. In PS, once the grades are posted to the students‘ records then you can view grade changes through the Grade Audit process but not during the online grade entry process

Define Grading Schemes OHIO tracks the last date of attendance for a student with an FS grade for identifying ―unofficial withdrawals.‖ PS does not have this feature.

Define Grading Schemes There is no delivered process in PS to automatically assign a grade of NR where a blank exists.

Define Grading Schemes Ability to load grades directly from BlackBoard into PS

Define Grading Schemes Ability to import grades from Excel into PS

Create Grade Rosters for a Single Class

OHIO needs to be able to recreate grade rosters after the initial creation to bring in students who dropped or were added after grade roster creation.


OHIO needs the ability for the instructor to enter a date for the Last Date of Attendance on the grade roster when they assign a ―FS‖ grade.


OHIO needs the ability for the instructor to enter a ―P‖ or ―F‖ grade on a student who has an existing ―W‖ grade.

MODIFICATIONS

218


OHIO wants to suppress access to the Transcript Notes link on the grade roster.


OHIO requires a process to identify missing grades. Current functionality identifies classes with missing grades and notify faculty. Confirmation email sent to faculty once roster has been completed


OHIO emails grades to students once posting period is over

Define Transcript Types OHIO prints a transfer credit summary that includes the transfer institution‘s name, years of attendance, and total hours transferred

Define Transcript Types When a student requests a transcript, OHIO permits the student to identify a specific course for which they are expecting a grade change.

Modify Scheduled Classes OHIO wants to be able to control who can modify fields on this page on a field by field basis.

Modify Scheduled Classes OHIO also needs to display the instructor name for the class on this page as a check that the user is modifying the correct section of the class

Modify Scheduled Classes When a class is canceled PS does not provide automatic notification to the students .

Modify Scheduled Classes In PS when a class is cancelled the facility, meeting days, times, and instructors are dropped. OHIO would like only the facility to drop so that when courses are rolled the other data remains

Define Class Associations OHIO needs to validate that the new value entered through a Class Association is within the range of the variable hours for a class. In PS there are no edits on this field

Search for Available Facility OHIO currently has the ability to search for a facility by entering the class which needs a facility. Class

MODIFICATIONS

219

information is pre-populated into the search.

Search for Classes The delivered process is not as feature-rich as OHIO‘s current Search for Classes.

Print the Schedule of Classes Report

The PS report does not provide the level of detail OHIO currently provides in the Schedule of Classes.

Copy Classes from one Term to Another

OHIO has different roll rules for different groups of classes and the set up to handle this might be tedious.

Understand Program Action and Statuses

A college/department is not allowed to do a program change from Non-Degree Seeking to Degree Seeking. In PS, if an individual has access to do program changes, this individual can change plans from non-degree to degree-seeking.

Maintain Student Program Information

OHIO wants the date, time, and User ID (i.e., last user) who updated the Program/Plan stack to be tracked and displayed. PS does not display the date, time, and User ID on the online display for Student Program/Plan.


In PS the Career Requirement Term field is populated manually. OHIO needs a process to populate this field based on the term in which the student‘s first classes for that career occurred


OHIO needs an automated process to populate and keep current the Expected Grad Term. This is required for SEVIS, National Student Clearinghouse, and financial aid.


OHIO needs a process to automatically discontinue students.


OHIO needs a process to populate and keep current the Campus field.


A student may relocate from one campus to another by registering for classes on a different campus. The student‘s record needs to

MODIFICATIONS

220

automatically be updated based on where the student is registered for classes

ACADEMIC ADVISING

Requirement Terms PeopleSoft has the ability to store the career requirement term, program term and plan term. There is no delivered process for populating the career requirement term.

Requirement Functionality OHIO currently has requirements that are based on a percentage of the major requirement courses must be completed in residence. The PS AA does not contain a function for calculating a percentage of hours

Transfer Coursework OHIO can place a Requirement Designation on the transfer courses that have the acceptable grade of D or pass. The Requirement Designation can be picked up by both Student Records and Academic Advisement to include/exclude based on the requirement rule.

In-Progress Credit PS does not permit the display of In-Progress on the report without having them count and possibly fulfill requirements. OHIO currently does not allow in-progress courses to apply toward requirements when audits are processed for students and advisors but they do appear on the audit in the appropriate requirements.

In-Progress Credit OHIO also has an option to allow in-progress to count on the audit assuming successful completion. This is a flag that is set at the time the audit is processed. PeopleSoft AA does not provide this functionality

What-If Report What-If analysis does not indicate that program may have application process.

MODIFICATIONS

221

What-If Report To run a What-If report, an advisor or student would need to enter the appropriate requirement term(s). OHIO‘s current What-If process will default the appropriate term based on the student and terms available for the program being run

Analysis Table PS provides the ability to query based on the completion of an entire program, but not individual program requirements

STUDENT FINANCIALS

Calculating Tuition, Fees, & Waivers: Term Fees

Because Equation Engine is a delivered PS tool, this is not a Gap. However, it will require a fair amount of technical programming to make this happen.

Calculating Tuition, Fees, & Waivers: Transaction Fees

For a number of reasons, the Transaction Fee functionality in PS is not generally usable.

Student & Third Party Account Maintenance: Late Payment Fees

PS‘s Late Fee functionality does NOT fit the requirements for this late fee.

Student & Third Party Account Maintenance: Group Posting Financial Aid Batches

While PS will allow OHIO‘s FA office to create a batch of transactions to be posted to the student accounts, PS does not deliver a way to have those batches automatically posted to the student accounts.


If OHIO decides that they want to use PS Self-Service and discontinue the use of CASHNet, there will need to be modifications to send out emails about account balances, payment deadlines, etc. There would also need to be a modification in PS to allow ―Authorized Users,, such as a parent or guardian, to see certain student information and to do certain student tasks.


The PS student billing functionality does not have any automated email functionality. Even if the PS student billing functionality is not used to send out paper bills, configuration will still have to be set up and the

MODIFICATIONS

222

process run on a monthly basis to ensure that all transactions have valid due dates and that the aging is correct. Also, should OHIO ever need to print out an actual bill for the student, the PS delivered bill will most likely need to be modified to be usable

Student & Third Party Billing: Third Party Billing

Although PS has the ability to process a third party bill, the bill will need to be modified to fit the requirements of the various third party sponsors.

Student Payment Plans: Payment Plan Late Fees

OHIO charges a late fee for late installment payments. The PS delivered Payment Plan functionality does not include late fee functionality.

Third Party Contracts: Third Party Contract Rollover

There is no ability in PS to roll a third party contract from one term to another.


PS‘s delivered functionality is seamlessly interfaced with PS Financials and/or PS HR/Payroll for paper check refunds and/or direct deposit refunds. OHIO uses the current SIS system to issue refunds. A modification will be required..

Student & Third Party Aging & Collections: Account Collections Process

OHIO probably needs a modification that would automate the notification process and track students through the collections process


OHIO will keep OGA and a modification/interface will need to be developed to replace the existing interfaces.

Tax Reporting 1042 Non-Resident Alien Tax – there is no delivered PS process to handle taxes for Non-Resident Aliens.

Tax Reporting OHIO will need to decide if it wants to use the PS delivered 1098-T process or develop a process.

Service Indicators for SF PS does not have any delivered functionality that would allow these

MODIFICATIONS

223

service indicators to be removed real-time.

Self-Service for SF OHIO will need a self-service modification to allow ―authorized users‖ to log in. PS does not have the ability to identify authorized users.

SF Integration Points with AD

OHIO has a requirement that only those housing students that have paid a housing deposit can get a final admit status and enroll. OHIO will need to develop a business process or modification to accomplish this.

SF Integration Points with FA

PS does not deliver a way to have batches automatically posted to the student accounts.

MODIFICATIONS

224

Gap Effort Estimates

NOTE: All Gaps did not receive estimates because (1) resolution was not confirmed to be a modification, and (2) resolution was confirmed to be a business process change.

GAPS MINOR MEDIUM MAJOR N/A

ACADEMIC STRUCTURE Academic Level Translates to reflect various Graduate levels

X

CAMPUS COMMUNITY Switch preferred flag to campus email address

X

Associate committees to publications and thesis tracking

X

Exclude charges from old calc X Notification of address update so hold can be released:

X

Automation between assigning/ completing checklists and the placing/removal of holds

X

Events module does not meet the needs of Admissions

X

Have students see DOB but no change, update FERPA restrictions, update preferred name/no edits on others

X

Student work hours for international student employees

X

ADMISSIONS Load Compass, or IELTS scores X Data entry screen for the application process

X

Physical mailers for checklists items

X

Auto admissions decision program X Cumulative attempted academic GPA for admission decision purposes.

X

Clearing House XML-Translation program

X

Calculate and store the quality point deficit a student may have

X

A 'fetch feature' to auto-populate the manual course credits screen.

X

Real time processing between OnBase and PeopleSoft

X

MODIFICATIONS

225

FINANCIAL AID Projected enrollment data used prior to term until point of disbursement for term. At point of disbursement, actual enrollment is used

X

Mechanism to ―lock‖ enrollment and campus of attendance for any term that has not yet begun.

X

Automate message class batch loading.

X

Send corrections need to be an automated process in uploading the generated file

X

EFC proration change nightly for a student based on projections of their terms attending

X

INAS calculation to run nightly X ISIR - apply appropriate checklist item during ISIR load process

X

Permanent checklists carried with student record

X

Lock only certain adjustments to budgets

X

Show award messages to students in self-service

X

Campus or location should be an indicator

X

Report on items disbursed for a particular day

X

Pell data sent to COD System in an automated process

X

Direct Loan data sent to COD system in an automated process

X

Originate loans in an accepted status for students pre-registered

X

Maximum time for degree completion based on level of study

Maximum time for degree completion based on Master level students and degree plan

X

Custom interface to load amount student earned in work study for the FISAP report

X

If account code in FA matches the waiver an OGA interface should create a new account code

X

STUDENT RECORDS

MODIFICATIONS

226

In PS the delivered Self Service controls for Class Search do not offer the option to display course or class fees.

X

OHIO would like Class Notes with hyperlinks for further information about the class.

X

There is nothing in PS to prevent the Registrar from scheduling classes without departmental permission

X

OHIO can currently assign two classes into the same facility if they have the same meeting pattern. PS allows this for different sections of the same course, but not different courses.

X

OHIO has a process that runs quarterly to drop students who fail to meet the prerequisites based on the final grades for the term.

X

OHIO produces a report, which is distributed to Departments that lists students who have not met the status of Good Standing. . PS‘s Academic Standing process posts the standing online when run. There is no delivered report

only option.

X

OHIO needs a way to store external cumulative hours attempted, and external cumulative grade points

X

OHIO needs the ability to default grades in certain classes, such as audit and dissertation.

X

OHIO needs to be able to track multiple grade changes prior to the grades being posted to the student‘s record. In PS, once the grades are posted to the students‘ records then you can view grade changes through the Grade Audit process but not during the online grade entry process

X

OHIO tracks the last date of attendance for a student with an FS grade for identifying ―unofficial withdrawals.‖ PS does not have

X

MODIFICATIONS

227

this feature.

Ability to load grades directly from BlackBoard into PS

X

Ability to import grades from Excel into PS

X

OHIO needs to be able to recreate grade rosters after the initial creation to bring in students who dropped or were added after grade roster creation.

X

OHIO wants to suppress access to the Transcript Notes link on the grade roster.

X

OHIO requires a process to identify missing grades. Current functionality identifies classes with missing grades and notify faculty. Confirmation email sent to faculty once roster has been completed

X

When a class is canceled PS does not provide automatic notification

to the students . X

In PS when a class is cancelled the facility, meeting days, times, and instructors are dropped. OHIO would like only the facility to drop so that when courses are rolled the other data remains

X

OHIO needs to validate that the new value entered through a Class Association is within the range of the variable hours for a class. In PS there are no edits on this field

X

The PS report does not provide the level of detail OHIO currently provides in the Schedule of Classes.

X

In PS the Career Requirement Term field is populated manually. OHIO needs a process to populate this field based on the term in which the student‘s first classes for that career occurred

X

OHIO needs an automated process to populate and keep current the Expected Grad Term. This is required for SEVIS, National Student Clearinghouse, and financial aid.

X

MODIFICATIONS

228

OHIO needs a process to automatically discontinue students.

X

OHIO needs a process to populate and keep current the Campus field.

X

A student may relocate from one campus to another by registering for classes on a different campus. The student‘s record needs to automatically be updated based on where the student is registered for classes

X

ACADEMIC ADVISING Populate career requirement term X Major must be completed in residence function for calculating a percentage of hours.

X,

Requirement Designations must be built

X

Flag set at time audit is processed X Location of Academic Plan type X Query based on completion of an entire program and individual program requirements

X

STUDENT FINANCIALS Calculate and post transaction fees automatically and on a scheduled basis.

X

Late fee charged once per term based on late payment criteria.

X

Automate posting process as soon as new FA batch has been created

X

Send out emails about account balances, payment deadlines,

X

Allow ―Authorized Users‖, to see certain student information

X

Delivered bill will need to be modified to be usable.

X

3rd party bill modified to fit the requirements of 3rd party sponsors.

X

Automate late fee assessment. X Refund process with Oracle for Accounts Payable and HR/Payroll.

X

Automate notification process and track students through collections.

X

MODIFICATIONS

229

OGA Online Graduate Awarding System

X

Setup fields and interface to get accounting entries into Oracle Financials.

X

1042 Non-Resident Alien Tax X 1098-T Tax X Allow service indicators to be removed real-time

X

Allow ―authorized users‖ to log in and to do certain tasks.

X

Requirement designations must be built

X

Only housing students that have paid a housing deposit can get a final admit status and enroll.

X

Allow in-progress to count on the audit assuming successful completion.

X

49 TOTAL ITEMS 21 19 9

CONVERSION

230

Section 15 Conversion Issues identified during Fit/Gap

MODULE SECTION CONVERSION ISSUE

ACADEMIC STRUCTURE

Installation Table

Once the production environment is established, the Last ID Assigned will need to be reset when conversion occurs.

Term Values Table

OHIO discussed using YYTT 0910 Fall 2008-2009 but decided against it since a different schema would need to be developed for conversion terms

Term Values Table

OHIO discussed using YYMM 0908 Fall 2008-2009, 0812 Winter Intersession but decided against it since a different schema would need to be developed for conversion terms

CAMPUS COMMUNITY

Data Mapping for Conversion

There should be a shared relationship with Oracle HRMS and PS Campus Community databases. Integration points need to be finalized by the Campus Community Steering Committee. The final decisions on values populating the shared tables need to be agreed upon by both HR and Campus Solutions representatives

Organization Table Build Table needs further review so that codes/names/info loaded into PS is "clean" data.

Shared Tables with HR

OHIO needs to use military titles in several ways, thus a current military inventory list of titles is needed for conversion.

OHIO CONVERSION MAPPING DECISIONS – See table of decisions in Fit/Gap Document

Identification there needs to be a separate meeting with ID management and the PS team

Participation

Oracle HRMS stores particular certifications (SPR, etc.). Faculty memberships are stored in a local area, which may not go directly into PS.

Participation OHIO needs to determine whether a co-curricular transcript will be generated.

Participation

OHIO will need to link committees to publications for dissertation/thesis, and would like to individually track theses/committees for those enrolled in

CONVERSION

231

multiple programs.

Standard Letters Communication history will need to be moved into PS from 3rd party

Communication Management

If you have prospects in PS, it is very easy to carry an ID and pull prospect data into the application. OHIO intended to continue to use Recruitment Plus for Athens undergraduate recruitment. Every aspect needs to be mapped out before implementation/conversion begins.

Comment, Categories, 3C Groups

Some functional areas may want old comments brought into PS. Possible conversion solution--create a "conversion" comment that will store past info with no ability to append

Comment Management

A conversion discussion with key players is needed to discuss how to handle comments/setup--look at comments for students/events and that between student and waivers; there is also a conversion discussion needed for comments on Recruitment Plus and what events need to receive comments

Communication Generation

A conversion discussion with key players is needed to discuss how to handle comments/setup of groups; OHIO needs to make business decision on communication practice (i.e. tone, repetitiveness, history)--every aspect needs to be mapped out before implementation/ conversion/configuration begins.

Conversion Issues

Organizations can be categorized into groups to assist in identifying organizations conveniently for recruitment.

Conversion Issues

Contacts can be added to an organization; look at service area first and then grow from there; All modules may have access to maintain contacts in the organization table

Conversion Issues

External Org Code Type Table - This is used with College Board EPS market codes, and can be used for CB Geo-Demographic analysis.

Conversion Issues

The external subject table is used to designate academic interests as well as provide a way to categorize courses in the general subject areas for transfer

CONVERSION

232

credit purposes.

Conversion Issues External Term Table - These values are delivered

Conversion Issues

School Type Table - The file format for international schools from College Board is not as accommodating for different address formats

Conversion Issues

Organization Table - The table can be populated in several ways--one way is to hold all HS in nation and beyond; PS delivers process to upload data from ETS/CB services; ATP and ACT codes are the same at HS level, but not at college level; FICE code is located in Financial Aid and can be pulled in to populate the FICE code field.

Conversion Issues Contacts can be added to an organization; look at service area first and then grow from there

Conversion Issues

Organization Affiliation - any organization can be assigned a group code and then a group type: this can allow for query research and then be given to specific recruiter.

FERPA HR needs to be at conversion meeting to establish interaction with their records and databases.

FERPA

If we are importing any employees, we need to look at what their restrictions are. In the system, we will know all records a person has.

SEVIS

getting information that is held only in Financial Aid and Oracle HRMS; OHIO needs to track start/end-date of employment for international students.


FINANCIAL AID No conversion issues identified

STUDENT RECORDS

Repeat Schemes and Repeat Codes

For conversion purposes, any data converted from prior to 1993 must include handling the deduction flag properly.

Create Course Equivalency Groups

During conversion to PS, legacy course equivalencies will be converted to Effective Dated Course changes to the same course

CONVERSION

233

ACADEMIC ADVISING

No conversion issues identified

STUDENT FINANCIALS


Origins and Group Types are required for Financial Aid batches and External File Loads. One of each is usually set up for Conversion of account balances.

Student Financials Conversions

PS recommends using the delivered External File Load, Group Post process to load student and third party account balances for conversion.

APPENDIX

234

Section 16 Appendices

18.1 Reporting

18.2 Support Document for Converting Holds

18.3 Complete Table Loading Sequence

APPENDIX

235

18.1 Reporting

The Charter for this phase of the project outlined a requirement to analyze OHIO reporting requirements. A data collection process was initiated during the project but the result revealed that there were likely ―thousands‖ of reports and it was virtually impossible to catalog and thereby assess the report development effort within the timeframe of this project.

A Business Intelligence Strategy was discussed and proposed to OHIO that would deal with a segment of reporting but obviously not resolve the extreme volumes that apparently exist.

Accordingly, this element of reporting will be an on-going activity for the Core Team and will be reviewed and appraised by the implementation team when it is assembled.

APPENDIX

236

18.2 Support Document for Converting Holds

And Mapping to Developed PeopleSoft Service Indicators

HOLD CODE HOLD NAME

REGISTRATION

GRADES

DIPLOMAS

TRANSCRIPTS

ADMISSIONS

A&S College of Arts and Sciences

Approved: AADV ACADEMIC ADVISING Y N N N N

AACT

Academic Advancement Center

Approved: CAP

ACADEMIC ADVANCEMENT CNTR HOLD Y N N N Y

AADM

Athens Admissions Office

Approved: ADM ADMISSIONS CREDENTIALS HOLD Y N N N Y

BDM BRANCH ADM CREDENTIALS HOLD Y N N N Y

LGLA HOLD PER LEGAL AFFAIRS Y N N N N

SXTY SIXTY PLUS PROGRAM HOLD Y N N N N

AADV

Athens Academic Advisor


ACRC

Accounts Receivable

Approved: AGB ATHENS GENERAL BALANCE HOLD Y Y Y Y Y

ARAD ACCTS RECEIV INCORRECT ADDRESS Y Y N Y Y

AREC ATHENS ACCTS RECEIVABLE HOLD Y Y Y Y Y

ALIB Alden Library

Approved: ALIB ATHENS ALDEN LIBRARY HOLD Y N Y Y Y

Approved: 11/10/2005 FLIB 2ND FL REFERENCE DESK Y N Y Y Y

ILIB INSTRUCTIONAL MEDIA Y N Y Y Y

MLIB ATHENS MUSIC LIBRARY HOLD Y N Y Y Y

APPENDIX

237

RLIB IDC DESK Y N Y Y Y

Approved: 11/10/2005 TLIB

2ND FL COMPUTER CONCOURSE Y N Y Y Y

AREG Athens Registrar

Approved: GRAD SPEC GRADUATION HOLD FOR JANE N N Y Y N

LGLA HOLD PER LEGAL AFFAIRS Y N N N N

Approved: 5/23/2006 LGL2 LEGAL AFFAIRS II HOLD N Y Y Y N

RCON FINANCIAL CONVERSION Y Y Y Y Y

REC REGISTRAR/RECORDS N Y Y Y N

REC2 SPECIAL RECORDS HOLD FOR PJB Y N N N N

REG ATHENS REGISTRARS OFFICE HOLD Y Y Y Y Y

REG2 ATHENS REGISTRARS OFFICE HOLD Y Y Y Y Y

REGD DECEASED STUDENT HOLD Y Y Y Y Y

RESS INVALID SOCIAL SECURITY NUMBER Y Y Y Y Y

SXTY SIXTY PLUS PROGRAM HOLD Y N N N N

TRAN TRANSCRIPT HOLD N N N Y Y

BADV Branch Advisor

Approved: BADV BRANCH ADVISING HOLD Y N N N N

BURS Bursar

Approved: 6/18/2001 AGO

ATTORNEY GENERALS OFFICE Y Y Y Y Y

APTP APARTMENT PENALTIES Y Y Y Y Y

APTR APARTMENT RENT Y Y Y Y Y

BAD2 ATHENS BAD CHECK HOLD # 2 Y Y Y Y Y




BADC ATHENS BAD CHECK HOLD Y Y Y Y Y

BAK2 ATHENS BAKER CENTER HOLD # 2 Y Y Y Y Y


APPENDIX

238


BAKE ATHENS BAKER CENTER HOLD Y Y Y Y Y

BDAD BURSAR INCORRECT ADDRESS Y Y N Y N

BURX SPECIAL BURSAR N Y Y Y Y

CA BURSAR FINANCIAL HOLD Y Y Y Y Y

DDA2 DORMITORY DAMAGE HOLD # 2 Y Y Y Y Y



DDAM DORMITORY DAMAGE Y Y Y Y Y

EXT2 ATHENS OVERDUE EXT BAL HOLD #2 Y Y Y Y Y



EXTN OVERDUE EXTENDED BALANCES Y Y Y Y Y

GRDS GRADE HOLD Y Y Y Y Y

HPL HEALTH PROFESSIONAL LOAN HOLD Y Y Y Y Y

LDS LOANS DISADVANT-AGE STUDENTS Y Y Y Y Y

LGTM LONG TERM LOANS Y Y Y Y Y

LOAN OVERDUE EMERGENCY LOAN Y Y Y Y Y

MIS2 ATHENS MISC HOLD # 2 Y Y Y Y Y



MISC ATHENS MISC HOLD Y Y Y Y Y

MPA2 MONTHLY PAYMENT PLAN HOLD # 2 Y Y Y Y Y



MPAY MONTHLY PAYMENT PLAN Y Y Y Y Y

NSL NURSING STUDENT LOAN HOLD Y Y Y Y Y

PERK PERKINS HOLD Y Y Y Y Y

PHON PHONE SYSTEM HOLD Y Y Y Y Y

PKG UNIV PARKING VIOLATIONS Y Y Y Y Y

PKG2 UNIV PARKING VIOLATION HOLD #2 Y Y Y Y Y

APPENDIX

239



SHTM SHORT TERM LOAN HOLD Y Y Y Y Y

TEL ATHENS TELEPHONE HOLD Y Y Y Y Y

CBA College of Business


CHEM

Chemistry and Biochemistry

Approved: KEYS CHEMISTRY KEYS Y Y Y Y Y

CLIB Chillicothe Library

Approved: CLIB CHILLICOTHE LIBRARY HOLD Y N Y Y Y

COM College of Communication


CPS

Counseling & Psychological Services

Approved: CPSY COUNSELING PSYCHOLOGY SER HOLD Y N N N Y

CREG

Chillicothe Registration

Approved: CGB CHILLICOTHE GEN BALANCE HOLD Y Y Y Y Y

CLNS CHILLICOTHE DEL LOAN HOLD Y Y Y Y Y

DISB Disbursements/Loan

Approved: HPL HEALTH PROFESSIONS LOAN PROG Y Y Y Y Y

LDS

LOAN FOR DISADVANTAGED STUDENT Y Y Y Y Y

LGTM LONG TERM LOAN Y Y Y Y Y

MISC MISCELLANEOUS Y Y Y Y Y

NSL NURSING STUDENT LOAN PROGRAM Y Y Y Y Y

APPENDIX

240

PERK PERKINS LOAN PROGRAM Y Y Y Y Y

SHTM SHORT TERM LOAN Y Y Y Y Y

EDU College of Education


ELIB Eastern Library

Approved: ELIB EASTERN LIBRARY HOLD Y N Y Y Y

ENT

College of Engineering and Technology


Approved: 11/3/2004 KEYS

ENGINEERING KEYS FOR STOCKER Y Y Y Y N

EREG

Eastern Registration

Approved: EGB EASTERN GEN BALANCE HOLD Y Y Y Y Y

EIGB EASTERN INCARCERATED GEN BAL Y Y Y Y Y

ELNS EASTERN DELINQUENT LOAN HOLD Y Y Y Y Y

EMD MEDIA-ASSISTED COURSES Y Y Y Y Y

FAR College of Fine Arts


GAPP

Graduate Appointments

Approved: CONT GA CONTRACT PROBLEM Y N N N N

GSS

Graduate Student Services


ACCD ACADEMIC DROP FROM PROGRAM Y N N N N

AFEE APPLICATION FEE Y N N N N

CONF NO CONFLICT OF INTEREST FORMS Y N N N N

Approved: 5/30/2001 CRED

CREDENTIALS INCOMPLETE Y N Y Y N

FIND FINANCIAL DOCUMENTS Y N N N N

I9 EMPLOYMENT ELIGIBILITY Y N N N N

APPENDIX

241

Approved: 4/29/2005 ICRD

INTL CREDENTIALS INCOMPLETE N N Y Y N

NSHO NO SHOW Y N N N N

REER DEPARTMENT REENROLL HOLD Y N N N N

RESI RESIDENT DOCUMENTS Y N N N N

SEVI SEVIS Y N N N N

TRAN NO OFFICIAL TRANSCRIPT Y N N N N

HHC Hudson Health Center

Approved: MDC

O MEDICAL CONVERSION Y N N N Y

MDTS MEDICAL TESTING HOLD Y N N N N

MDW

D MEDICAL WITHDRAWAL HOLD Y N N N Y

HHS

College of Health and Human Services


HOUS Housing

Approved: CONV IMAGING CONVERSION HOLD D Y N N N Y

HOUF ATHENS HOUSING FINANCIAL HOLD Y N N N Y

HOUS ATHENS HOUSING HOLD Y N N N Y

HSTR Historic Imaging Project

Approved: 5/22/2001 AREG

ATHENS REGISTRAR HOLD Y Y Y Y Y

Approved: 5/22/2001 BURS BURSAR Y Y Y Y Y

Approved: 5/22/2001 CLIB

CHILLICOTHE LIBRARY HOLD Y N Y Y Y

Approved: 5/22/2001 CREG

CHILLICOTHE REGISTRATION Y Y Y Y Y

Approved: 5/22/2001 DISB DISBURSEMENT/LOAN Y Y Y Y Y

Approved: 5/22/2001 EREG EASTERN REGISTRATION Y Y Y Y Y

Approved: 5/22/2001 HHC HUDSON HEALTH CENTER Y Y Y Y Y

Approved: 5/22/2001 JUDI JUDICIARIES Y Y Y Y Y

Approved: 5/22/2001 LREG

LANCASTER REGISTRATION Y Y Y Y Y

APPENDIX

242

Approved: 5/22/2001 SFA FINANCIAL AID Y Y Y Y Y

Approved: 5/22/2001 SLIB

SOUTHERN LIBRARY HOLD Y N Y Y Y

Approved: 5/22/2001 SREG

SOUTHERN REGISTRATION Y Y Y Y Y

Approved: 5/22/2001 ZLIB

ZANESVILLE LIBRARY HOLD Y N Y Y Y

Approved: 5/22/2001 ZREG

ZANESVILLE REGISTRATION Y Y Y Y Y

HTC Honors Tutorial College


ICA Intercollegiate Athletics


ILIB Ironton Library

Approved: CONV IMAGING CONVERSION HOLD Y N Y Y Y

ILIB IRONTON LIBRARY HOLD Y N Y Y Y

INDS Independent Study

Approved: 5/31/2001 ISGB

INDEPENDENT STUDY GENERAL BAL Y Y Y Y Y

INEQ Institutional Equity

Approved: 9/4/2001 EQIP

INSITUTIONAL EQUITY EQUIPMENT Y Y Y Y Y

INST

Center for International Studies


IREG Ironton Registration

Approved: CONV IMAGING CONVERSION HOLD Y Y Y Y Y

IGB IRONTON GEN BALANCE HOLD Y Y Y Y Y

ILNS IRONTON DELINQUENT LOAN HOLD Y Y Y Y Y

IRON Southern

APPENDIX

243

Campus

Approved: BADV ACADEMIC ADVISING HOLD Y N N N N

ISFS

International Student and Faculty Services

Approved: ISHI INTERNATIONAL HEALTH INSURANCE Y N N N N

SEVI SEVIS Y N N N N

VISA VISA PROBLEM Y N N Y N

VISR VISA PROBLEM Y N N N N

JUDI University Judiciaries

Approved: DIS2 JUDICIAL-HOLD ALL TRANSACTIONS Y Y Y Y Y

DIS3 JUDICIAL-HOLD REGISTRATION Y N N N N

DISC JUDICIAL DISCIPLINARY HOLD Y N N Y Y

LGAF Office of Legal Affairs

Approved: 5/16/2000 LGAF

OFFICE OF LEGAL AFFAIRS Y N N N Y

LLIB Lancaster Library

Approved: CONV IMAGING CONVERSION HOLD Y N Y Y Y

LLIB LANCASTER LIBRARY HOLD Y N Y Y Y

LREG Lancaster Registration

Approved: CONV IMAGING CONVERSION HOLD Y Y Y Y Y

LCC LANC CHILD CARE CHARGE Y Y Y Y Y

LGB LANCASTER GEN BALANCE HOLD Y Y Y Y Y

LIGB LANCASTER INCARCERATED GEN BAL Y Y Y Y Y

LLNS LANCASTER DELINQUENT LOAN HOLD Y Y Y Y Y

M SC Military Science

Approved: 5/18/2000 EQIP

MILITARY SCIENCE EQUIPMENT Y Y Y Y Y

APPENDIX

244

Approved: 5/18/2000 SCHL

MILITARY SCIENCE SCHOLARSHIP Y Y Y Y Y

NSHO No Show

Approved: NSHG NO SHOW - GRADUATE Y N N N Y

NSHM NO SHOW - OSTEOPATHIC MEDICINE Y N N N Y

NSHU NO SHOW - UNDERGRADUATE Y N N N Y

OPIE

Ohio Program of Intensive English

Approved: OADV OPIE ACADEMIC ADVISING HOLD Y N N N N

OSRC Osteo Records

Approved: HEAL OSTEO HEAL DEFAULT Y N Y Y Y

ODEL OSTEO DELINQUENT LOAN HOLD Y N Y Y Y

OST

College of Osteopathic Medicine


CONV IMAGING CONVERSION HOLD Y Y Y Y N

LOAN OVERDUE EMERGENCY LOAN Y Y Y Y N

PING Ping Recreation Center

Approved: NPIP NON PAYMENT OF ITEM PURCHASE Y Y Y Y Y

NREQ NON RETURN OF EQUIPMENT Y Y Y Y Y

VAND VANDALISM,MISUSE OF EQUIPMENT Y Y Y Y Y

PLIB Portsmouth Library

Approved: PLIB PORTSMOUTH LIBRARY HOLD Y N Y Y Y

PREG

Portsmouth Registration

Approved: PGB PORTSMOUTH GEN BALANCE HOLD Y Y Y Y Y

APPENDIX

245

PLNS PORTSMOUTH DEL LOAN HOLD Y Y Y Y Y

RHE Regional Higher Education


RHEP PROBATION Y N N N N

SEVI Sevis

Approved: SEVI SEVIS Y N N N N

SFA Student Financial Aid

Approved: GSL GUARANTEED STUDENT LOAN HOLD Y Y Y Y Y

HPL HEALTH PROFESSIONAL LOAN HOLD Y Y Y Y Y

LDS LOANS DISADVANT-AGE STUDENTS Y Y Y Y Y

LGTM LONG TERM LOANS Y Y Y Y Y

NEXT NO EXIT INTERVIEW HOLD Y Y Y Y Y

NSL NURSING STUDENT LOAN HOLD Y Y Y Y Y

PERK PERKINS HOLD Y Y Y Y Y

QAP QUALITY ASSURANCE PROGRAM Y Y Y Y Y

RPAY REPAYMENT SFA FUNDS Y Y Y Y Y

SCON STUDENT FIN AID CONVERSION Y Y Y Y Y

SHTM SHORT TERM LOAN HOLD Y Y Y Y Y

TRSS

Transfer Probation Security System

Approved: TPR1 TRANSFER PROB HOLD (SAME DAY) Y N N N N

TPRO TRANSFER PROBATION HOLD Y N N N N

UNC University College


SBAD SB 140 ACADEMIC ADVISING Y N N N N

SBB SB 140 DID NOT RETURN BOOKS Y Y N Y N

SBOR DID NOT ATTEND SB 140 ORIENT Y N N N N

UNC1 UNC 90 OR MORE HOURS Y N N N N

APPENDIX

246

HOLD

UNC2 UNC 115 OR MORE HOURS HOLD Y N N N N

UNC5 UNC DID NOT ATTEND ORIENTATION Y N N N N

UNCP PROBATION Y N N N N

ZLIB Zanesville Library

Approved: ZLIB ZANESVILLE LIBRARY HOLD Y N Y Y Y

ZREG

Zanesville Registration

Approved: ZGB ZANSVILLE GEN BALANCE HOLD Y Y Y Y Y

ZLNS ZANSVILLE DELINQUENT LOAN HOLD Y Y Y Y Y

APPENDIX

247

18.3 Complete Table Loading Sequence

Setup Task Description Products Affected

Features Affected

Installation Table Specify the PeopleSoft applications for your installation.

AV, HR, SA

CS General, HRMS General

Country Table Predefined information by Country as defined by ISO.

AV, HR, SA


State/Province Add a state, province or equivalent entity for the selected country.

AV, HR, SA


Regulatory Region

Set up a regulatory region. AV, HR, SA


Person Object Installation

Installation settings for the PERSONAL_DATA component and Person Object

AV, HR, SA


TableSet IDs Define TableSet ID. AV, HR, SA


Record Group Define record group and record name. AV, HR, SA


Business Unit Define business units. AV, HR, SA


Company Define and describe companies. AV, HR, SA


AV, HR, SA

CS General, HRMS General, US Recruitment Extension

Establishment An establishment is usually a physical location in the organization.

AV, HR, SA


AV, HR, SA

CS General, HRMS General, US Recruitment Extension

National ID Type Define types of national indentification numbers. AV, HR, SA


Name Type Define the types of names that can be recorded for a person.

AV, HR, SA


Name Title Defines titles used by individuals (e.g., Ms., prince, professor).

AV, HR, SA


Supporting Documents

Defines documents used to verify employee information.

AV, HR, SA

Campus Community, Workforce Administration

APPENDIX

248

Holiday Schedule Define a company's paid holidays for a given year.

AV, HR, SA


Schools Define schools. AV, HR, SA

CS General, Workforce Administration

Visas/Permits Define visa or permit details and supporting documents for verifying status.

AV, HR, SA

Campus Community, Workforce Administration

Address Usage Table

Define hierarchies of address types to search for and use in a specific usage.

AV, SA CS General

Student Admin Installation

Define installation values required for Student Administration.

AV, SA CS General

Name Type Defaults

Define or review the name types that will be created by default when adding a new person ID.

AV, SA Campus Community

Name Usage Table

Define hierarchies of name types to search for and use in a specific usage.

AV, SA CS General

Phone Usage Table

Define hierarchies of phone types to search for and use in a specific usage.

AV, SA CS General

Salutation Table Define or review the salutations available in your system.

AV, SA CS General

Name Suffix Defines name suffixes such as Jr. and Sr. AV, SA CS General

Location Address Table

Define or review campus addresses for your institution.

AV, SA CS General

Student Records Installation

Define installation values required for Student Records.

SA Student Records

Program Action Table

Define program action codes. AV, SA CS General

Administrative Function Table

Review administrative functions. AV, SA CS General

CIP Code Table Create a listing of all Classification of Instructional Program codes.

AV, SA CS General

HEGIS Code Table

Create a listing of all Higher Education General Information Survey codes.

AV, SA CS General

Extracurricular Activity Table

Define and update the extracurricular activities your institution tracks.


FERPA Control Review or make additional directory data and other information available to FERPA privacy control.

AV, SA CS General

Building Table Define building information. AV, SA CS General

Room Characteristics Table

Define specific room characteristics. SA Student Records

Facility Table Define facility information. AV, SA CS General

Unit Conversion Define unit conversions formulas. AV, SA CS General

APPENDIX

249

Table

Complete Grade Flag

Define grade flag values and descriptions. AV, SA CS General

Grade Category Create new grade category values to be used for derived lists.

AV, SA, SG

CS General, Gradebook

Grading Scheme Table

Define all valid grading schemes and grading bases for academic careers.

AV, SA CS General

Degree Table Define internal and external degrees. AV, SA CS General

Joint Salutation Type Table

Define salutation types to make available for joint communications.

AV, SA CS General

External Organization Type

Define organization types and related navigation.


NAICS Codes Define North American Industry Classification System codes.


Level/Load Rules Table

Define academic level and load rules by SetID. AV, SA CS General

Demographic Data Access

Define demographic data access for primary permission lists.

AV, SA CS General

Demographic Data Access

Update demographic data access settings. AV, SA CS General

Search/Match Rules

Search/Match Rule configuration AV, SA CS General

Search/Match Parameters

Search/Match Parameter configuration AV, SA CS General

Search/Match Result Fields

Search/Match Result Fields Setup AV, SA CS General

Search/Match Results

Search/Match Results configuration AV, SA CS General

Selection Tool Configure Population Selection Tools. AV, SA Campus Community

Application Specific Context

Define the application specific keys used to map a process to a specific context.


Context Definition Configure Population Selection Context Definition.


Equation to Context Mapping

Map Equation Engine Application Prompt values to Population Selection Contexts


Field Conversion Definition

File Parser Field Conversion Definition AV, SA Campus Community

Copy Field Value Conversion

File Parser Copy Field Value Conversion. AV, SA Campus Community

Context Definition File Parser Context Definition AV, SA Campus Community

Copy Context Definition

Copy Context Definition. AV, SA Campus Community

File Mapping File definition and mapping. AV, SA Campus

APPENDIX

250

Definition Community

Copy File Mapping Definition

File Parser Copy File Mapping Definition. AV, SA Campus Community

Population Selection File Map

Population Selection File Mapping Definition AV, SA Campus Community

Population Update Setup

Population Update Setup. AV, SA Campus Community

Form Image Text Forms Engine EPS Image Text. AV, SA Campus Community

Event Type Table Define type of events to manage. AV, SA Campus Community

Campus Community Installation

Install tables required for Campus Community. AV, SA Campus Community

Resource Code Table

Define resources to be used with events. AV, SA Campus Community

Health Test Table Define and update the health tests your institution tracks.


Staff Code Table Define staff codes to use with events. AV, SA Campus Community

Event Template Define event meeting templates. AV, SA Campus Community

Trigger Prompt Table

Identify the edit table for a 3C engine trigger to prompt.


Ext Org Code Type Table

Define an EPS market code organization code type.


EPS Market Code Table

View EPS market codes loaded through the EPS load process.


Relationship / Marital Status

Define and update a marital status corresponding to a joint relationship.


Immunization Table

Define and update the immunization tests your institution tracks.


Relationship Table

Define and update the relationships your institution tracks.



Font Names Font Name Table. AV, SA Campus Community

Form Editor Form Editor. AV, SA Campus Community

Form Groups Form Group Table. AV, SA Campus Community

Out Dest Formats Forms Engine Out Dest Formats. AV, SA Campus Community

APPENDIX

251

Out Dest Types Forms Engine Out Dest Types. AV, SA Campus Community

Out Dest Values Forms Engine output dest prmpt. AV, SA Campus Community

Postscript Fonts Postscript Fonts. AV, SA Campus Community

Standard Letter Table CS

Set up standard letter codes to be used in Campus Solutions communications.


Academic Institution Table

Define default and set up values for academic institutions.

AV, SA Academic Structure

Comment Category Table

Set up categories for comments. AV, SA Campus Community

3C Update/Inquiry Group Table

Define 3C group codes. AV, SA Campus Community

Comment 3C Groups

Include comments in 3C groups for security purposes.


Tracking Group Table

Set up tracking groups for checklists. AV, SA Campus Community

Communication Context Table

Set up contexts for the communications process.


Institution Publications

Define and update the publications your institution tracks.


Iwi Table Maintain Iwi codes and descriptions for NZ Maoris. Used in SDR Reporting.


Legacy Table Define the types of legacy affiliations that individuals can have with your institution.


Communication Category Table

Set up categories to use in the communications process.


Communication 3C Groups

Include communications in 3C groups for security purposes.


Publication Categories

Publication Categories. AV, SA Campus Community

Service Impact Table

Define service impacts codes to attach to service indicators.


Service Indicator Table

Create service indicators code, for both positive and negative service indicators.


Committee Type/Role

Define the committee types and member roles. AV, SA Campus Community

Checklist Item Table

Set up items to be used in a checklist. AV, SA Campus Community

Checklist Item Functions Table

Set up checklist items by administrative function.


Communication Speed Key Table

Manage Speed Keys for communications. AV, SA Campus Community

Communication Data Source

Define communication data source to be used in Campus Solutions communications.


APPENDIX

252

Checklist Table Set up checklists. SA Student Financials

Checklist 3C Groups

Include checklists in 3C groups for security purposes.


Event Definition Define events for management of communications, checklists and/or comments.


Trigger Definition Define triggers for management of communications, checklists and/or comments.


Contact Type Table

Setup the type of contacts your institution wants to track.

AV, SA Campus Solutions General

Organization Recipient Usage

Define hierarchies of Organization Recipient types to search for and use in a specific usage.


School Type Table

Define school types for external education data. AV, SA CS General, Admissions & Recruiting

Organization Table

Create or update an external organization. AV, SA CS General

Organization Locations

Create or update locations for your external organizations.

AV, SA CS General

Organization Departments

Create or update departments for your external organizations.

AV, SA CS General

Organization Contacts

Create or update contact persons for your external organizations.

AV, SA CS General

External GPA Type Table

Define GPA types for external education data. SA Admissions & Recruiting

Student Special GPA

Create and maintain special grade point averages for a student's term records.

AV, SA Student Records

Organization Affiliation

Create or update an organization's affiliation to the institution.


External Organization Codes

Create or update EPS codes for an organization.


External Subject Table

Define broad categories of the subjects offered at external organizations.

SA Student Records

External Education Comments

Default comments for external education entry. SA Admissions & Recruiting

School Subject Maintenance

Create or update school subjects for an organization.

AV, SA CS General, Student Records

School Course Classification

Create or update school courses for an organization.

AV, SA CS General, Student Records

Religious Preference Table

Define and update the religious preferences your institution tracks.


APPENDIX

253

Residency Exception Table

Define and update the residency exceptions your institution tracks.


Residency Table Define and update the residency information your institution tracks.


Standard Industry Table

Define and update the United States standard industrial classifications your institution tracks.


Standard Occupation Table

Define and update the United States standard occupational classifications your institution tracks.


Define External Systems

Define external systems for which external system identifiers can be tracked.


Athletic Participation Table

Define and update athletic participations your institution tracks.


Citizen Status Defines citizenship details for specified country. AV, SA CS General

Term Values Table

Define the term values and their descriptions. AV, SA Academic Structure

Field of Study Table

Define values for field of study. AV, SA CS General

Campus Table Define campus values. AV, SA Academic Structure

Academic Career Table

Define default and set up values for academic careers.


Academic Group Table

Define course defaults, catalog levels and meeting patterns for academic groups.


Time Period Table Define time periods or critical points in time for each academic career.


Academic Organization Table

Create a listing of all academic organizations defined in the system.


Update Security - Acad Orgs

Link your academic organization security tree to academic organization security.


Academic Subject Table

Create subject areas and define taxonomy and workload values.


Term/Session Table

Define terms, sessions within terms, and session time periods.


Enrollment Action Reason

Define enrollment action and enrollment action reason values for all academic careers.

SA Student Records

Academic Calendar

Define cancel, withdrawal, and drop deadlines along with other term and session landmark dates.


Academic Program Table

Define default and set up values for academic programs.


Academic Plan Table

Create academic plans, and define plan related information for transcripts and diplomas.


Academic Create academic subplans as well as define AV, SA Academic

APPENDIX

254

SubPlan Table taxonomy and descriptions for transcripts and diploma.

Structure

Instructor/Advisor Table

Add and modify instructor and advisor records. SA Student Records

Requirement Designation Table

Define requirement designation values. SA Student Records

Course Equivalencies

Define course equivalency groups. SA Student Records

Course Attributes Define course attributes and attribute values. SA Student Records

Course Typically Offered

Define course typically offered values SA Student Records

Instruction Mode Define instruction mode values. SA Student Records

Dynamic Class Dates Table

Dynamic Class Dates Table. SA Student Records

Weekly Schedule Time Periods

Define weekly schedule time periods. SA Student Records

Course Catalog Create, view and update courses, course offerings, and course components.

SA Student Records

Classroom Scheduling Interface

Set up classroom scheduling interface. SA Student Records

Study Agreement Table

Create study agreements for use with external organizations.

SA Student Records

Honors and Awards Table

Define and update the honors and awards your institution tracks.

SA

Campus Community Student Records

Milestone Table Define milestone codes, their grading bases and determine the milestone levels.

SA Student Records

Milestone Templates

Define milestone templates to be used with milestone values.

SA Student Records

Grading Basis Exception Rule

Define mapping rules to convert grading bases for students enrolling across careers.

SA Student Records

Grade Review Define grade review values to be used in the grade review process.

SA Student Records

Career Pointer Exception Rule

Create career pointer exception rules. SA

Academic Structure Student Records

Appointment Limits Table

Define appointment limits ID's and full-time and part-time maximum unit limits.

SA Student Records

Appointment Table

Create enrollment appointments for sessions and terms.

SA Student Records

Student Group Define student groups to track student SA Student

APPENDIX

255

Table membership within various groups. Records

Student Group Table


SA Student Records

Student Services Center Setup

Define the labels and sections to show for the Student Services Center


Degree Honors Table

Define degree honors and print options for transcripts and diplomas.

SA Student Records

Academic Standing Table

Create academic standing action codes for all academic careers.

SA Student Records

Academic Standing Rule

Define academic standing rules for all academic careers.

SA Student Records

Honors/Awards Rule

Define rules to be used in the honors and awards process.

SA Student Records

Student Attribute Table

Define student attributes for tracking and reporting on different cohorts.

SA Student Records

Global Notes Table

Define global notes. SA Student Records

Repeat Scheme Table

Define repeat schemes and repeat codes within each scheme.

SA Student Records

Repeat Rule Define repeat rules for academic careers and academic programs.

SA Student Records

Test Component Table

Define components for external tests. SA Admissions & Recruiting

Test Tables Define Test IDs and score ranges for external tests.

SA Admissions & Recruiting

External Test Score Mapping

Map test IDs to PeopleSoft defined test codes. SA Admissions & Recruiting

Ethnicity Mapping Map ethnicity codes from the testing agencies to PeopleSoft ethnic group codes.


AMCAS Ethnicity Mapping

Map ethnicity codes from AMCAS to PeopleSoft ethnic group codes.


Test Table Define test codes and link test components to them.

SA Student Records

Test Transfer Rules

Define test transfer equivalency rules. SA Student Records

Program/Test Equivalency

Select the academic programs and plans to assign test transfer equivalencies.

SA Student Records

Transfer Subject Area

Define component subject areas for external or internal institutions.

SA Student Records

Course Transfer Rules

Define course transfer equivalency rules. SA Student Records

Program/Source Equivalency

Select the programs and plans to assign course transfer equivalencies.

SA Student Records

Gradebook Category

Maintain gradebook assignment categories. SA Student Records

APPENDIX

256

External Term Define or review external terms sessions for external organizations.

SA

Campus Community Student Records

NQF Field/Subfield Domain NZL

Define Fields, Subfields and Domains for NZ National Qualifications Framework Unit Standards.

SA Student Records

Define Statistics Type

Define statistics types for consolidated statistics.

SA Student Records

Define Statistics Period

Define statistics periods for reporting consolidated statistics.

SA Student Records

Academic Advising

Define parameters and rules for self service academic advising activities.

SA Academic Advisement

Academic Advising Installation

Configure academic advising options at the installation level.


Cum. Grade Point Average

Define cumulative GPA values and associated descriptions.

SA

Student Records Academic Advisement

Transcript Type Define transcript types, associate service indicators and indicate that a transcript type includes an advising report.

SA

Student Records, Academic Advisement

Transcript Notes Table

Create transcript notes that relate to a student's enrollment record.

SA Student Records

Transcript Print Area Table

Set up codes to define where various types of data appear on the transcript.

SA Student Records

Define Transcript Type

Define transcript type and associate service indicators.

SA Student Records

Define an Entity Group

Group together similar items, such as plan, for use as a single condition.


Define Requirement Usages

Create special usage field values for generating alternate report formats.


Define Advisement Report

Define and assign valid careers to an advisement report.


Define Condition Processes

Establish custom condition processes. SA Academic Advisement

Define Course Lists

Establish exactly which courses comprise the course list and define detail parameters.


Define Course Share Sets

Enable courses to be shared by more than one requirement group.


Define Dynamic Condition

Create multi-dimensional condition specifications.


APPENDIX

257

Define Academic Requirements

Create specific types of requirements, defining parameters and controls.


Define Requirement Groups

Define academic requirement groups that point to conditions, courses, and requirements.


CRS Major Codes Define major codes for CRS search tapes. SA Admissions & Recruiting

SAT Math Recentered Values

Define math recentered values for the SAT test. SA Admissions & Recruiting

SAT Verbal Recentered Values

Define verbal recentered values for the SAT test.


Referral Source Table

Define the source of referral for a prospect. SA Admissions & Recruiting

Admissions Installation

Define installation options for recruiting and admissions features.


Region Table Define regions for prospect and applicant recruiting.


Admissions Action Table

Define program actions for application processing.


Teaching Subjects

Define teaching subject for OUAC processing. SA Admissions & Recruiting

CEGEP Program Table

Define the CEGEP program table for OUAC processing.


SAT II Test Codes Define SAT II test codes. SA Admissions & Recruiting

External Summary Type Table

Define summary types for external education data.


Enrollment Target Population

Define populations for enrollment target processing.


Enrollment Target Division

Define divisions for enrollment target processing.


AMCAS GPA Codes

Define GPA codes for AMCAS tests. SA Admissions & Recruiting

Law Categories Define law categories for OUAC processing. SA Admissions & Recruiting

AP Country Codes

Define country codes for AP tests. SA Admissions & Recruiting

AP Subject Test Codes

Define subject test codes for AP tests. SA Admissions & Recruiting

GRE Subject Test Codes

Define subject test codes for GRE tests. SA Admissions & Recruiting

Program Action Reason Table

Define program action reasons for application processing.


APPENDIX

258

AMCAS Credit Hour Codes

Define credit hours codes for AMCAS tests. SA Admissions & Recruiting

Basis of Admission Table

Define basis of admission codes for application processing.


ADA Country Codes

Define country codes for ADA tests. SA Admissions & Recruiting

Extracurricular Activity Map

Map external extracurricular activities. SA Admissions & Recruiting

GMAT Country Codes

Define country codes for GMAT tests. SA Admissions & Recruiting

SAT II Test Recentered Values

Define SAT II test recentered values. SA Admissions & Recruiting

Region Postal Table

Define postal code ranges for regions. SA Admissions & Recruiting

Religious Preference Map

Map external religious preferences. SA Admissions & Recruiting

Academic Interests Map

Map external academic interests. SA Admissions & Recruiting

Enrollment Target Cohort

Define cohorts for enrollment target processing. SA Admissions & Recruiting

Admission Comments Table

Define admissions comment codes for application processing.


Rating Comp Definition Table

Define rating components for application evaluations.


Evaluation Status Table

Define statuses for application evaluation. SA Admissions & Recruiting

TS130/TS131 Setup

Set up TS 130 and TS 131 and define contacts. SA Admissions & Recruiting

Material Group Table

Define materials groups for application and general materials.


Application Center Table

Define application centers to assign to applicants.


External GPA Rules Table

Define GPA rules for external education data. SA Admissions & Recruiting

Recruiting Center Table

Define recruiter centers to assign a prospect. SA Admissions & Recruiting

Admit Type Table Define admit types for prospects and applicants. SA Admissions & Recruiting

Recruiting Category Table

Define recuiring categories for prospects and applicants.


Response Reason Table

Define reasons an applicant is attending another school.


Web Prospect Create Table

Define the structure for prospect self service Request Information feature.


APPENDIX

259

Rating Tables Define rating schemes for application evaluation.


Evaluation Tables Define evaluation codes and committees for application evaluation.


Average Cutoff Table

Define cutoff ranges for alternate admissions offers.


Alternate Average Calculations

Define rules for calculating alternate admissions averages.


Alternate Offer Table

Define rules for alternate offers of admission. SA Admissions & Recruiting

Student Fin Installation

Define number sequencing, maximum row settings, edit tables and commit levels.

SA Student Financials

Keywords Define and associate keywords with item types to facilitate searches.


Define External Award Sources

Define sources of external awards. SA Financial Aid

Define External Award Types

Define external award types. SA Financial Aid

SF Account Types Define account types to classify item types into usable account groups.


Item Types Define attributes, posting restrictions, link account types and map chartfields.

AV, SA

Student Financials, Contributor Relations

Item Type Groups Define item type groups to limit the application of credits to certain charge items.


Tax Transaction Codes

Define Value Added Tax transaction types. SA Student Financials

Tax Authorities Create tax authority codes to process taxes attached to charges.


Tax Codes Define tax codes to link taxes and tax authorities to charge item types.


Aging Set Define aging sets for credit history processing. SA Student Financials

Late Fees Create late fee definitions to identify past due charges and assess late fees.


Late Fees - Billing Create late fee definitions to identify unpaid billed items and assess late fees.


Payment Overall Priority

Define the sorting of eligible charges for payment allocation.


Student Permission Forms

Create form for permission to apply restricted credits.


Charge Priority List

Define charge priority lists and rules and link them to item type tree nodes.


Billing and Due Calendars

Create schedules to determine the amount of fees due, the billing and due dates.


APPENDIX

260

Adjustment Calendars

Define schedules and fees for tuition adjustments for drops and withdrawals.


Origin Table Define sources of receivables posted through group posting.


External File Layouts

Define the file layout for external charges and payments.


Group Type Table Define sets of frequently posted receivables for use in group data entry.


SF Term Default Define default terms to populate accounts when term is not used during posting.


Security Views Review and modify security views for your system.


Valid Records Review valid records used in trigger criteria for tuition calculation.


Valid Fields Review valid records, fields and edit tables used in trigger criteria.


Credit Card Type Define the credit card types the institution accepts for payment.


Item Reasons Create codes to provide brief explanations for payment and charge reversals.


Follow-Up Table Create Follow-Up action codes that record the steps needed to resolve accounts.


Reason Out Define codes that identify why the system moved an item out of collections.


Fee Classes Define fee classes to enable reporting on specific types of fees.


Void Reasons Define codes to provide brief explanations for voided cashiering receipts.


AP Set Controls - Vendor

Define vendor information. SA Student Financials

Reason In Define codes that identify why the system moved an item into collections.


Liability Status Defines Liability Status Codes as determined by DEST for element 490.


Tuition Calculation Controls

Define parameters, rules, errors and warnings used for tuition calculation.


Invoice ID Number

Create an unique invoice ID that must appear on your bills.


Billing Type Establish bill types for your institution for students or corporations.


Message Categories

Create message categories to be used with billing messages.


Billing Scan Line Create a bill scan line if your bank requires it to track transactions.


APPENDIX

261

1098-T TIN Table Set up a tax identification number for filing 1098-T tax forms with the IRS.


AP Business Unit Define Accounts Payable interface and voucher numbering parameters.


Criteria Create criteria for tuition groups, fee triggers and waivers.


Invoice Layout Set of parameters that define invoice information, sorting, and summarization.


Waivers Define waiver codes to waive or reduce a student's tuition and fee charges.


Waiver Groups Define waiver groups to attach one or more waivers to class and course fees.


SpeedTypes Create shortcut keys of chartfields for department receipt entry in cashiering.


Billing Messages Create messages that appear on your bills by message categories.


Provider Table Define the International Health Coverage Provider Table.


SF Merchants Define ePayment processing rules for different business units, including services performed.

CSS, SA

Student Financials, Campus Self-Service

Optional Fees Create optional fee codes and values. SA Student Financials

Coverage and Rates

Define coverage and rates for Providers. SA Student Financials

Institutional Contact

Define institutional contact Information. SA Student Financials

Combination Period Table

Create a combination period to retrieve consolidated academic statistics.


Collection Letter Template

Create templates and delvery schedule of dunning letters for past due accounts.


Minimum / Maximum Fees

Define ranges for term fees, applications fees and other institutional charges.


Billing Standard Request

Define parameters to determine how you identify and bill groups of customers.


Bank Accounts - Business Unit

Bank account information for the business unit is managed from this page.


Bank Accounts - Corporate

Bank accounts for Exertnal Organizations are managed from this page.


Course Lists Create a group of courses for use with third-party contracts or course fees.


Per Credit Charge Define the Per Credit Charge and Hook on fee defaults for NZQA.


StudyLink Institution

Define refund, residency and enrollment parameters for the institution.


APPENDIX

262

Defaults

StudyLink Posting Parameters

Define posting and refund item types for StudyLink.


Transaction Fees Create transaction fees for adding or dropping classes as of a specific date.


Application Fees Define rules, item types and fees for enrollment applications.


Loan Default Define parameters for HECS HELP, FEE HELP and OS HELP loans. Also defines status change rules for the HECS Reconciliation.


Optional Fees - Terms

Link optional fee codes to terms and assign date parameters.


SF Business Unit Define the basic business rules for each business unit.


HECS Band Fees Create and define HECS Band Fees. SA Student Financials

Collector Define and establish collectors within the system.


Corporate Collection Criteria

Create a list of corporate collection criteria defined in your system.


SF Institution Set Define self service ePayment parameters, rules, and usage for one or more business units.

CSS, SA


Rate Tables for Course Fees

Create student criteria to add to the course fee definition.


Corporation Messages

Link message(s) that appear on a single corporation when the bill is generated.


Aging Set Messages

Link billing messages to specific aging sets and aging categories.


Customer Message

Link message(s) that appear on a single student when the bill is generated.


Item and Account Types

Define Item Types and Account Types for the Business Unit.


Identify SA Deduction Codes

Define student administration deduction codes. SA Student Financials

Term Fees Define term fee codes to link to tuition groups. SA Student Financials

Tuition Groups Create tuition groups to assign a set of fees according to specific rules.


Deposit Fees Create admission deposit fees, due dates and status changes for payments.


Item Type Message

Link billing messages to specific item types or ranges of item types.


Business Unit Message

Assign billing messages to business units. SA Student Financials

APPENDIX

263

SF Self Service Options

Define business unit information for self service processing.

CSS, SA


Course List Fees Create fees for all courses within a given course list.


Create Deferral Contract

Define deferral contract parameters, administrative fees and eligible charges.


Optional Fees per Term

Define optional fee amounts. SA Student Financials

Target Keys Define which charges receive credit for a given transaction.


Class Fees Create fees for particular instances of a course. SA Student Financials

Class Fees Modal Create or update fees for classes through the Schedule of Classes.


Course Fees Create or update course fees. SA Student Financials

Course Fees Modal

Create or update course fees through the Course Catalog.


Tender Keys Define the types of tender used in cashiering transactions.


Cashiering Offices Define the characteristics of each cashiering office for the institution.


Service Indicator Sets

Define sets that automatically attach service indicators during Credit History.


Valid Registers Define valid cash registers used in each cashiering office.


Valid Cashiers Define valid cashiers working in each cashiering office.


Receipt Print Messages

Define messages that appear on printed transaction receipts.


Financial Aid Installation

Define installation values required for Financial Aid.

SA Financial Aid

Define Federal Aid Years

Define the aid year using federal guidelines. SA Financial Aid

Define Financial Aid Years

Define the valid financial aid years for the institution.

SA Financial Aid

Valid Careers for Aid Year

Assign financial aid eligible academic careers for the aid year.

SA Financial Aid

Valid Terms for Career

Define eligible financial aid terms, academic and loan periods for careers.

SA Financial Aid

Define Commit Levels

Define database commit levels for eligible financial aid processes.

SA Financial Aid

Define Demographic

Define how student bio-demographic information is used by financial aid processes.

SA Financial Aid

APPENDIX

264

Data Use

PROFILE-Need Access Controls

Define PROFILE and Need Access run controls. SA Financial Aid

SA Financial Aid

Maintain ISIR Comment Codes

Maintain the ISIR comment codes and their database match usage.

SA Financial Aid

ISIR/SAR Cross Reference

ISIR/SAR Cross Reference. SA Financial Aid

Maintain NSLDS Codes

Review and update the NSLDS status codes. SA Financial Aid

INAS Assumption Codes

INAS Assumption Setup Pages. SA Financial Aid



SA Financial Aid



SA Financial Aid


Define policies for Federal and Institutional need methodologies for 2006-2007

SA Financial Aid

Institutional Cross Reference

Track cross-references of field name to the institutional record field number.

SA Financial Aid

Loan Fee Setup Define loan fees which are calculated during the packaging process.

SA Financial Aid

Aggregate Programs

Define Stafford, Direct, or HEAL aggregate areas to be linked together to combine loan limits.

SA Financial Aid

Define Sort Order Fields

Update and review Financial Aid Award Notification output Sort Order Fields criteria.

SA Financial Aid

Define Sort Order Names

Define Sort Order Names criteria for Financial Aid Award Notification output processing.

SA Financial Aid

Maintain CRC Loan Status Codes

Maintain CRC status and error codes reported by the loan servicers.

SA Financial Aid

School Codes for Institution

Define valid school codes for institution. SA Financial Aid

School Code Table

Maintain Title IV school codes by aid year. SA Financial Aid

Maintain Loan Servicer Codes

Maintain a comprehensive list of loan servicer codes.

SA Financial Aid

Define Loan Report Definitions

Define field specifications and the output format for loan forms.

SA Financial Aid

Equation SQL Routines

Create or edit SQL that can be authorized to be called from an equation.

SA Student Financials, Financial Aid

Equation External Subroutines

Adds an external cobol routine to the list of routines that can be authorized.

SA Student Financials, Financial Aid

APPENDIX

265

Equation Data Tables

Adds a table or view to the list of tables and views that can be authorized.


Equation Editor Create and edit equations. SA Financial Aid

Equation Names Authorize Equation Access. SA Student Financials

Equation Test Data

Set up test data for an equation. SA Student Financials, Financial Aid

Equation Global Space

Work with Equation Global Variables in Equation Spaces.

SA Financial Aid

Equation Application Prompts

Add or update the list of applications that use equations.


Budget Tree Address Usage

Define which address type is to be used during the budget assignment process.

SA Financial Aid

Define EDI Business Unit

Define the internal financial aid business unit used in EDI Manager processes.

SA Financial Aid

Maintain EDI Transactions

Maintain the EDI transactions that can be viewed in the ISIR and Loan Review pages.

SA Financial Aid

Maintain Loan Edits

Maintain CommonLine 4 validation edit list. SA Financial Aid

Maintain Loan Transfer ID

Maintain loan information used to generate loan files for transmission.

SA Financial Aid

Maintain Guarantor Codes

Maintain a comprehensive list of guarantor codes.

SA Financial Aid

Maintain CRC Loan Edits

Maintain list of Common Record CommonLine loan edits.

SA Financial Aid

Create CRC Loan Edit Sets

Create sets of loan edits to be used in creating CRC loan destinations.

SA Financial Aid

Aggregate Level Translation

Associate aggregate levels with academic level definitions from the Department of Education.

SA Financial Aid

Aggregate Aid Limits

Define annual and aggregate aid limits for all sources of funding.

SA Financial Aid

Aggregate Area Translation

Associate aggregate areas with programs from the Department of Education.

SA Financial Aid

Maintain Loan Action Codes

Maintain loan action codes used by Direct Lending and CommonLine.

SA Financial Aid

Maintain Lender Codes

Maintain a comprehensive list of lender codes. SA Financial Aid

Create CRC Loan Participants

Maintain lender, guarantor, and servicer information for CRC processing.

SA Financial Aid

Create CRC Search Match Setup

Create search match setup conditions for CRC Certification Request processing.

SA Financial Aid

Define School Guarantors

Define the guarantee agencies to be used for processing loans at the institution.

SA Financial Aid

APPENDIX

266

Define School Lenders

Define lending agencies to be used for processing loans at the institution.

SA Financial Aid

Define School Servicers

Define loan servicers to be used for processing loans at the institution.

SA Financial Aid

Direct Loan Change Rules

Define global change parameters for Direct Loan change, hold and suspense processing.

SA Financial Aid

Hold and Release Equations

Define the equations used by the CommonLine Hold and Release process.

SA Financial Aid

Reassign Loan Agencies

Define instances where one loan agency has been replaced by another.

SA Financial Aid

Maintain Loan Report Packages

Setup and update Loan Report Packages for Promissory Note processing.

SA Financial Aid

Setup Perkins MPN Options

Define Perkins MPN Options SA Financial Aid

CNAS Messages Define Canadian need analysis messages. SA Financial Aid

Create Proration Rules

Define the criteria for pro-rating awards based on student enrollment.

SA Financial Aid

Financial Aid Item Types

Define item types as financial aid item types for use in awarding various sources of funds.

SA Financial Aid

Item Type Cross Reference

Map external awards to internal award items. SA Financial Aid

Search/Match Rules

Define search/match options to use during external award loadng process.

SA Financial Aid

Fiscal Item Types Define fiscal limits for existing financial aid item types.

SA Financial Aid

Define Rules for Return

Identify financial aid item types used for Return of Title IV calculations.

SA Financial Aid

CSL File Load Control

CSL File Load Setup Page. SA Financial Aid

Verification Tolerance Setup

Update verification tolerance values for Federal and Institutional processing.

SA Financial Aid

Award Adjustment Reasons

Define reasons for why an award may be adjusted on the various Assign Award pages.

SA Financial Aid

PROFILE Load Parameters

Define PROFILE Data Load Parameters. SA Financial Aid

Need Access Load Parameters

Define Need Access Data Load Parameters. SA Financial Aid

View COD XML Fields

View Common Origination and Disbursement XML field mappings.

SA Financial Aid

Budget Categories

Define the individual components that make up the federal, Pell, or institutional budget.

SA Financial Aid

Budget Items Define budget items, term amounts, and Pell annual amounts by budget category.

SA Financial Aid

Create Loan Edit Sets

Create sets of loan edits to be used in creating loan destinations.

SA Financial Aid

APPENDIX

267

Budget Formulas Define assignment rules for each budget item which are used to calculate the student's budget.

SA Financial Aid

Create CRC Loan Destinations

Define the processing protocols between the school and the CRC loan servicers.

SA Financial Aid

Reconciliation Periods

Create reconciliation periods for cash management.

SA Financial Aid

Application Source Rank

Define the application source order for the batch budget assignment process.

SA Financial Aid

Budget Region Table

Define regions to be used during Budget Tree processing.

SA Financial Aid

CNAS Setup Define Canadian need analysis parameter setup.

SA Financial Aid

CNAS Cost Code Define Canadian need analysis cost codes. SA Financial Aid

Budget Trees Define a Tree Node that will be used to assign a particular detailed value to a budget item.

SA Financial Aid

Setup Financial Aid Term

Define the valid terms that can be used for building financial aid term records.

SA Financial Aid

Define Career Types

Define Financial Aid Career Types to combine statistics for FA Terms.

SA Financial Aid

Early Financial Aid Categories

Define the types of financial aid considered for an early financial aid offer.

SA Admissions & Recruiting, Financial Aid

Early Fin Aid Categories

Define early financial aid categories. SA Admissions & Recruiting, Financial Aid

Self Service Options

Define self service inquiry options as well as awarding access and processing options.

CSS, SA Financial Aid, Campus Self-Service

Aid Processing Rule Setup

Define aid processing rule sets for use as career and program defaults.

SA Financial Aid

Term Values Cross Reference

Define equivalent terms across aid years for the aid year rollover process.

SA Financial Aid

Create Loan Destinations

Define the processing protocols between the school and the CL 4 loan servicers.

SA Financial Aid

Pell Payment Define Pell payment parameters and options. SA Financial Aid

CNAS Rule Setup Define Canadian need analysis rule sets. SA Financial Aid

Valid Programs for Aid Year

Assign program specific financial aid processing rule sets.

SA Financial Aid

Pell ID Attending Assign a campus specific Pell ID. SA Financial Aid

Pell Comment Code

Set severity level for edits and comments defined by Department of Education.

SA Financial Aid

CNAS Option Table

Define Canadian need analysis options. SA Financial Aid

APPENDIX

268

ISIR Data Load Parameters

Define the rules used to load ISIRs from the staging to the application tables.

SA Financial Aid

Define Serial Promissory Notes

Define and update parameters for Direct Loan MPN and Serial Promissory Note processing.

SA Financial Aid

Package Rating Components

Define admissions rating components and GPA types to be available during packaging.

SA Financial Aid

Packaging Equity Item Types

Define a group of financial aid item types to act as equity offsets in a packaging plan.

SA Financial Aid

Budget Groups Define a group of budget items for use in manually assigning a term budget to students.

SA Financial Aid

Budget Assignment

Define career/aid year/institution combinations to assign budgets to groups of students.

SA Financial Aid

Define Printer Names

Define institution printer names used by the Financial Aid Award Notification Defaults page.

SA Financial Aid

Define Selection Equations

Define Forms Engine Financial Aid Award Notification Selection Equations.

SA Financial Aid

Define Notification Form Types

Define Forms Engine Financial Aid Award Notification Form Types.

SA Financial Aid

Award Notification Defaults

Update and review award notification defaults. SA Financial Aid

Assign Status to Admit Levels

Assign an academic program status for each program admit level.

SA Financial Aid

Define Careers for Prospects

Define the career to assign to applicants based on the student's ISIR.

SA Financial Aid

Related Item Type Group

Define related financial aid item types together into similar groups for awarding purposes.

SA Financial Aid

Create Loan Types

Define the loan types that require origination. SA Financial Aid

Set DL Loan Counseling Search

Direct Loan Search Match Setup for loan counseling data load.

SA Financial Aid Student Financials

Identify Self Service Lenders

Define Lender Select list. SA Financial Aid Student Financials

Define Loan Counseling Options

Define Loan Counseling options. SA Financial Aid Student Financials

Set Up Disbursement Calendars

Define the parameters for the batch authorization and disbursement processes.

SA Financial Aid

Restricted Aid Table

Define parameters and conditions for awarding funds with subjective eligibility requirements.

SA Financial Aid

Budget Assignment Run Control

Define careers and terms to select for the budget assignment process.

SA Financial Aid

Disbursement Define the different disbursement plans for each SA Financial Aid

APPENDIX

269

Plan Table career by aid year.

Disbursement ID Table

Define disbursement IDs for each disbursement in or across terms for a disbursement plan.

SA Financial Aid

Create User Edit Messages

Create and update user edit messages. SA Financial Aid

Define Global Rules

Define common authorization rules for students of the same career.

SA Financial Aid

Disbursement Split Codes

Define all disbursement patterns for each disbursement plan in a given aid year.

SA Financial Aid

Disbursement Split Cd Formula

Define percentages of award to be disbursed by disbursement split code.

SA Financial Aid

Packaging Plan Define award rules and limits for targeted groups of students for use in auto- and mass packaging.

SA Financial Aid

Repackaging Plan Define rules and limits for targeted groups of students for use in auto- and mass repackaging.

SA Financial Aid

Careers for School Codes

Define valid careers for school codes. SA Financial Aid

Define Loan Institutions

Define the valid loan processes available at the institution.

SA Financial Aid

Define Item Type Rules

Define common authorization rules for individual Item Types.

SA Financial Aid

Contributor Rel Installation

Install tables required for Contributor Relations. AV, SA Contributor Relations

Action Types Set up the types of actions that will be tracked for constituents and initiatives.

AV, SA Contributor Relations

Action Contact Types

Set up types of contacts that will be used to carry out a constituent or an initiative action.


Roles Create Roles for Staff, Volunteers, and Units. AV, SA Contributor Relations

Recognition Types

Set up the types of donor recognition you wish to track.


Action Results Set up types of results that will be used to track completion of initiative actions.


Designation Types

Institution Type Codes. AV, SA Contributor Relations

Person / Org Relationships

Set up the types of relationships between a person and an external organization.


Constituent Types Set up values to indicate the types of CR constituents being tracked.


Goal Type Table Set up the types of goals to track for initiatives. AV, SA Contributor Relations

Trust Terms Set up the terms for trusts to be tracked for donors.


Action Status Set up status codes to be used for constituent AV, SA Contributor

APPENDIX

270

Codes and initiative actions. Relations

Credit Card Type Set up credit cards to be used with CR electronic payment processing.


Rating Type Set up types of ratings to track for donor prospects.


Initiative Type Table

Set up the types of initiatives to track. AV, SA Contributor Relations

Membership Category

Set up the categories of membership to track. AV, SA Contributor Relations

Matching Gift Types

Set up the types of gifts to use in matching gift rules.


Gift Types Set up gift types for donor commitments. AV, SA Contributor Relations

Attribute Type Set up attributes to use in creating audiences. AV, SA Contributor Relations

Campaign Donor Phase Table

Set up the donor phases expected to support a campaign.


Asset Types Set up asset types to track for prospects. AV, SA Contributor Relations

Rating Origin Set up origin code values for prospect management ratings categories and indicators.


Rating Indicators Set up values that indicate a rating level for a donor prospect.


Adjustment Reasons

Define reasons for making adjustments to gift, pledge, and membership transactions.


Trust Types Set up the types of trusts to be tracked for donors.


Rating Categories Set up categories of ratings to track for donor prospects.


Appreciation Items

Set up items that will be tracked as tokens of appreciation.


Membership Type Set up the types of membership to track. AV, SA Contributor Relations

Appeal Type Table

Set up the types of appeals to track. AV, SA Contributor Relations

Method Table Set up methods through which actions will be executed.


Trust Categories Set up categories of trusts to track for donors. AV, SA Contributor Relations

Functional Group Security

AV Functional Group Categories. AV, SA Contributor Relations

Areas of Responsibility

Setup the areas of responsibility to which volunteers will be assigned.


Involvement Types

Set up the types of involvement required to track constituent involvement.


APPENDIX

271

Budget Table Set up budget items to track for initiatives. AV, SA Contributor Relations

Involvement Categories

Set up the categories required to track constituent involvement.


Involvement Codes

Set up the values to track specific constituent involvement.


Add/Update Matching Rules

Enter rules that an external organization uses to determine gifts to match financially.


Audience Criteria Define criteria to be used in audience selection. AV, SA Contributor Relations

Leadership Types Define types of volunteer leadership to track. AV, SA Contributor Relations

Staff Identify Contributor Relations staff members. AV, SA Contributor Relations

Default Comment Categories

Set up default comment categories for CR components.


Giving Vehicles Giving Vehicles. AV, CSS, SA

Contributor Relations, Campus Self-Service

Org Reciprocal Relationships

Set up the types of relationships between two external organizations.


Foundation Types Define Foundation Types. AV, SA Contributor Relations

Geographic Areas Define Geographic Areas. AV, SA Contributor Relations

Support Types Define Foundation Support Types. AV, SA Contributor Relations

Merchant Table Set up merchants for processing credit cards with CR business units.


Acknowledgement Setup

Setup gift and pledge acknowledgement rules. AV, SA Contributor Relations

Assignment Types

Set up the types of volunteer assignments to track.


Units Define Contributor Relations units. AV, SA Contributor Relations

Volunteers Define Volunteers. AV, SA Contributor Relations

Tender Types Set up the types of legal tender that you wish to track for gifts and memberships.


Market Rates Enter and maintain market rates on the Market Rates Data table.


Business Unit CR Set up business units for Contributor Relations. AV, SA Contributor Relations

Institution Defaults

Set up institution defaults for Contributor Relations business rules.


APPENDIX

272

Appeal Code Table

Appeal Code Setup. AV, SA Contributor Relations

Designation Funds

Setup designation funds for distribution of gifts, pledge, and memberships.


Involvement Web Setup. AV, CSS, SA

Contributor Relations, Campus Self-Service

Operator Defaults Set up Contributor Relations defaults for an individual user.


NSC Branch Table

Define branch codes to be used when reporting enrollment status to the NSC.

SA Student Records

Cluster Code Table NLD

Set Up Dutch Cluster Codes. SA Student Records

GBA Country Code Table

GBA Country Codes for the Netherlands. SA Student Records

MBO Code Table NLD

Set up MBO Codes Netherlands. SA Student Records

BRINcode Table NLD

Set Up BRINcodes for Dutch Schools/Campus/Locations.


GBA Nationality Code Table

GBA Nationality Code Table. SA Student Records

Prior Education Table NLD

Set up Prior Education for the Netherlands. SA Student Records

J Visa Termination Reasons

Define termination reasons for exchange visitors.

SA

CS USA USA Regulatory Reporting

Port of Entry Table

Define the SEVIS port of entry values. SA


Position Code Table

Define SEVIS position code values. SA


Fee Code Table Define the fees and expenses for the I-20 form defaults.

SA


US Government Agency Code Tbl

Define SEVIS US government agency values. SA


International Organization Tbl

Define SEVIS international organizations values.

SA CS USA USA

APPENDIX

273

Regulatory Reporting

Dept of State Post Code Table

Define the Department of State post codes. SA


Visa/Level of Education Map

Map levels of education to SEVIS visa types. SA


Country Mapping Map SEVIS country codes to PeopleSoft countries.

SA


Visa Mapping Map SEVIS visa code to PeopleSoft visa types. SA


Suffix Mapping Map SEVIS suffix codes to PeopleSoft suffix values.

SA


SEVIS Event Types

Define SEVIS event types and form request defaults.


SEVIS File Errors Define file errors returned from SEVIS. AV, SA Campus Community

Site of Activity Table

Define site of activity information reportable to SEVIS.

SA


SEVIS Program Sponsor Table

Define SEVIS program sponsor and reporting structure information.

SA


SEVIS School Code Table

Define SEVIS school codes and reporting structure information.

SA


SEVIS Setup Define processing rules for addresses, names, majors and minors.

SA


I-20 Template Define default values for the I-20 form by institution, career, program or plan.

SA


APPENDIX

274

User Defaults Define user defaults. AV, SA Campus Community

ohiosisfit-gapanalysis

Documents

implementation

adrvadmission

obiee analytics

condconditional

tests needing

individually

title iv calculations

defrdefer