Download - Fit-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
Table Loading Sequence ..................................................................................................................... 62
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
Table Loading Sequence ..................................................................................................................... 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
Table Loading Sequence ..................................................................................................................... 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
Detailed Project Plan
Deliverables Approval and Signoff Process
Discovery Prototype Acceptance Signoff for:
Project Charter
Fit/Gap Analysis Document
Detailed Project Plan
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 re- activated 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.
Table Loading Sequence
Setup Task Description
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.
RECRUITING AND ADMISSIONS
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.
RECRUITING AND ADMISSIONS
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.
RECRUITING AND ADMISSIONS
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;
RECRUITING AND ADMISSIONS
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.
RECRUITING AND ADMISSIONS
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.
RECRUITING AND ADMISSIONS
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.
RECRUITING AND ADMISSIONS
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.
RECRUITING AND ADMISSIONS
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
RECRUITING AND ADMISSIONS
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;
RECRUITING AND ADMISSIONS
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.
RECRUITING AND ADMISSIONS
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,
RECRUITING AND ADMISSIONS
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)
RECRUITING AND ADMISSIONS
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)
RECRUITING AND ADMISSIONS
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
RECRUITING AND ADMISSIONS
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
RECRUITING AND ADMISSIONS
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.)
RECRUITING AND ADMISSIONS
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.
Table Loading Sequence
Setup Task Description
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.
RECRUITING AND ADMISSIONS
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.
RECRUITING AND ADMISSIONS
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.
RECRUITING AND ADMISSIONS
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.
Table Loading Sequence
Setup Task Description
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.
INAS 2005-2006 Global Options
Define policies for Federal and Institutional need methodologies for 2005-2006.
INAS 2006-2007 Global Options
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution include:
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.
Options for resolution:
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:
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.
Options for resolution include:
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.
Options for resolution:
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.
Options for resolution:
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.
Options for resolution:
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.
Options for resolution:
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.
Options for resolution:
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:
Options for resolution include:
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
Options for resolution include:
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.
2. Continue to use AIMS.
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.
4. Continue to use AIMS.
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.
2. Continue to use AIMS.
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
Table Loading Sequence
Setup Task Description
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
Define student groups to track student membership within various groups.
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.
Table Loading Sequence
Setup Task Description
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
BUSINESS INTELLIGENCE
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
BUSINESS INTELLIGENCE
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.
BUSINESS INTELLIGENCE
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
BUSINESS INTELLIGENCE
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
BUSINESS INTELLIGENCE
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
BUSINESS INTELLIGENCE
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.
BUSINESS INTELLIGENCE
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
Recruiting &and Admissions
AD Astra
Recruiting &and Admissions
DARS Degree Audit
Recruiting &and Admissions, Registrar, Financial Aid
CollegeNet Online Application
Student Records CollegeNet -- Contact Manager
Recruiting
Academic Advising
Recruiting &and Admissions
Highland OnBase Imaging and Workflow
Recruiting &and Admissions
Acalog
Recruiting &and Admissions
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.
Student & Third Party Account Maintenance: Origins & Group Types
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.
Student, Parent, & Third Party Refunds: Refunds
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.
Student Financials Interfaces
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.
Student Financials Interfaces
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.
Student Financials Interfaces
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
Student Financials Interfaces
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
Student Financials Interfaces
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
Student Financials Interfaces
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
Student Financials Interfaces
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
Checklist Table, Items, Function Items, Managing Checklists
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.
Checklist Table, Items, Function Items, Managing Checklists
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).
RECRUITING / ADMISSIONS
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.
Institutional Student Information Record (ISIR) Processing
OHIO requires that this be an automatic process for sending and receiving ISIR data and not a manual process.
MODIFICATIONS
214
Institutional Student Information Record (ISIR) Processing
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.
Create Academic Standing Rules
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.
Create Academic Standing Rules
Academic standing for the full-time undergraduate career differs from that for the part-time undergraduate career.
Create Academic Standing Rules
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.
Create Academic Standing Rules
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.
Create Grade Rosters for a Single Class
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.
Create Grade Rosters for a Single Class
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
Create Grade Rosters for a Single Class
OHIO wants to suppress access to the Transcript Notes link on the grade roster.
Create Grade Rosters for a Single Class
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
Create Grade Rosters for a Single Class
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.
Maintain Student Program Information
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
Maintain Student Program Information
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.
Maintain Student Program Information
OHIO needs a process to automatically discontinue students.
Maintain Student Program Information
OHIO needs a process to populate and keep current the Campus field.
Maintain Student Program Information
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.
Student & Third Party Billing: Student Billing
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.
Student & Third Party Billing: Student Billing
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.
Student, Parent, & Third Party Refunds: 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 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
Student Financials Interfaces
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.
RECRUITING / ADMISSIONS
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
Student & Third Party Account Maintenance: Origins & Group Types
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
Approved: AADV ACADEMIC ADVISING Y N N N N
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
BAD3 ATHENS BAD CHECK HOLD # 3 Y Y Y Y Y
BAD4 ATHENS BAD CHECK HOLD # 4 Y Y Y Y Y
BAD5 ATHENS BAD CHECK HOLD # 5 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
BAK3 ATHENS BAKER CENTER HOLD # 3 Y Y Y Y Y
APPENDIX
238
BAK4 ATHENS BAKER CENTER HOLD # 4 Y Y Y Y Y
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
DDA3 DORMITORY DAMAGE HOLD # 3 Y Y Y Y Y
DDA4 DORMITORY DAMAGE HOLD # 4 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
EXT3 ATHENS OVERDUE EXT BAL HOLD #3 Y Y Y Y Y
EXT4 ATHENS OVERDUE EXT BAL HOLD #4 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
MIS3 ATHENS MISC HOLD # 3 Y Y Y Y Y
MIS4 ATHENS MISC HOLD # 4 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
MPA3 MONTHLY PAYMENT PLAN HOLD # 3 Y Y Y Y Y
MPA4 MONTHLY PAYMENT PLAN HOLD # 4 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
PKG3 UNIV PARKING VIOLATION HOLD #3 Y Y Y Y Y
PKG4 UNIV PARKING VIOLATION HOLD #4 Y Y Y Y Y
SHTM SHORT TERM LOAN HOLD Y Y Y Y Y
TEL ATHENS TELEPHONE HOLD Y Y Y Y Y
CBA College of Business
Approved: AADV ACADEMIC ADVISING Y N N N N
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
Approved: AADV ACADEMIC ADVISING Y N N N N
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
Approved: AADV ACADEMIC ADVISING Y N N N N
ELIB Eastern Library
Approved: ELIB EASTERN LIBRARY HOLD Y N Y Y Y
ENT
College of Engineering and Technology
Approved: AADV ACADEMIC ADVISING Y N N N N
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
Approved: AADV ACADEMIC ADVISING Y N N N N
GAPP
Graduate Appointments
Approved: CONT GA CONTRACT PROBLEM Y N N N N
GSS
Graduate Student Services
Approved: AADV ACADEMIC ADVISING Y N N N N
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
Approved: AADV ACADEMIC ADVISING Y N N N N
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
Approved: AADV ACADEMIC ADVISING Y N N N N
ICA Intercollegiate Athletics
Approved: AADV ACADEMIC ADVISING Y N N N N
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
Approved: AADV ACADEMIC ADVISING Y N N N N
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
Approved: AADV ACADEMIC ADVISING Y N N N N
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
Approved: AADV ACADEMIC ADVISING Y N N N N
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
Approved: AADV ACADEMIC ADVISING Y N N N N
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
CS General, HRMS General
State/Province Add a state, province or equivalent entity for the selected country.
AV, HR, SA
CS General, HRMS General
Regulatory Region
Set up a regulatory region. AV, HR, SA
CS General, HRMS General
Person Object Installation
Installation settings for the PERSONAL_DATA component and Person Object
AV, HR, SA
CS General, HRMS General
TableSet IDs Define TableSet ID. AV, HR, SA
CS General, HRMS General
Record Group Define record group and record name. AV, HR, SA
CS General, HRMS General
Business Unit Define business units. AV, HR, SA
CS General, HRMS General
Company Define and describe companies. AV, HR, SA
CS General, HRMS General
AV, HR, SA
CS General, HRMS General, US Recruitment Extension
Establishment An establishment is usually a physical location in the organization.
AV, HR, SA
CS General, HRMS General
AV, HR, SA
CS General, HRMS General, US Recruitment Extension
National ID Type Define types of national indentification numbers. AV, HR, SA
CS General, HRMS General
Name Type Define the types of names that can be recorded for a person.
AV, HR, SA
CS General, HRMS General
Name Title Defines titles used by individuals (e.g., Ms., prince, professor).
AV, HR, SA
CS General, HRMS General
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
CS General, HRMS General
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.
AV, SA Campus Community
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.
AV, SA Campus Community
NAICS Codes Define North American Industry Classification System codes.
AV, SA Campus Community
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.
AV, SA Campus Community
Context Definition Configure Population Selection Context Definition.
AV, SA Campus Community
Equation to Context Mapping
Map Equation Engine Application Prompt values to Population Selection Contexts
AV, SA Campus Community
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.
AV, SA Campus Community
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.
AV, SA Campus Community
Ext Org Code Type Table
Define an EPS market code organization code type.
AV, SA Campus Community
EPS Market Code Table
View EPS market codes loaded through the EPS load process.
AV, SA Campus Community
Relationship / Marital Status
Define and update a marital status corresponding to a joint relationship.
AV, SA Campus Community
Immunization Table
Define and update the immunization tests your institution tracks.
AV, SA Campus Community
Relationship Table
Define and update the relationships your institution tracks.
AV, SA Campus Community
AV, SA Campus Community
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.
AV, SA Campus Community
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.
AV, SA Campus Community
Tracking Group Table
Set up tracking groups for checklists. AV, SA Campus Community
Communication Context Table
Set up contexts for the communications process.
AV, SA Campus Community
Institution Publications
Define and update the publications your institution tracks.
AV, SA Campus Community
Iwi Table Maintain Iwi codes and descriptions for NZ Maoris. Used in SDR Reporting.
AV, SA Campus Community
Legacy Table Define the types of legacy affiliations that individuals can have with your institution.
AV, SA Campus Community
Communication Category Table
Set up categories to use in the communications process.
AV, SA Campus Community
Communication 3C Groups
Include communications in 3C groups for security purposes.
AV, SA Campus Community
Publication Categories
Publication Categories. AV, SA Campus Community
Service Impact Table
Define service impacts codes to attach to service indicators.
AV, SA Campus Community
Service Indicator Table
Create service indicators code, for both positive and negative service indicators.
AV, SA Campus Community
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.
AV, SA Campus Community
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.
AV, SA Campus Community
APPENDIX
252
Checklist Table Set up checklists. SA Student Financials
Checklist 3C Groups
Include checklists in 3C groups for security purposes.
AV, SA Campus Community
Event Definition Define events for management of communications, checklists and/or comments.
AV, SA Campus Community
Trigger Definition Define triggers for management of communications, checklists and/or comments.
AV, SA Campus Community
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.
AV, SA Campus Community
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.
AV, SA Campus Community
External Organization Codes
Create or update EPS codes for an organization.
AV, SA Campus Community
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.
AV, SA Campus Community
APPENDIX
253
Residency Exception Table
Define and update the residency exceptions your institution tracks.
AV, SA Campus Community
Residency Table Define and update the residency information your institution tracks.
AV, SA Campus Community
Standard Industry Table
Define and update the United States standard industrial classifications your institution tracks.
AV, SA Campus Community
Standard Occupation Table
Define and update the United States standard occupational classifications your institution tracks.
AV, SA Campus Community
Define External Systems
Define external systems for which external system identifiers can be tracked.
AV, SA Campus Community
Athletic Participation Table
Define and update athletic participations your institution tracks.
AV, SA Campus Community
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.
AV, SA Academic Structure
Academic Group Table
Define course defaults, catalog levels and meeting patterns for academic groups.
AV, SA Academic Structure
Time Period Table Define time periods or critical points in time for each academic career.
AV, SA Academic Structure
Academic Organization Table
Create a listing of all academic organizations defined in the system.
AV, SA Academic Structure
Update Security - Acad Orgs
Link your academic organization security tree to academic organization security.
AV, SA Campus Community
Academic Subject Table
Create subject areas and define taxonomy and workload values.
AV, SA Academic Structure
Term/Session Table
Define terms, sessions within terms, and session time periods.
AV, SA Academic Structure
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.
AV, SA Academic Structure
Academic Program Table
Define default and set up values for academic programs.
AV, SA Academic Structure
Academic Plan Table
Create academic plans, and define plan related information for transcripts and diplomas.
AV, SA Academic Structure
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
Define student groups to track student membership within various groups.
SA Student Records
Student Services Center Setup
Define the labels and sections to show for the Student Services Center
AV, SA Campus Community
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.
SA Admissions & Recruiting
AMCAS Ethnicity Mapping
Map ethnicity codes from AMCAS to PeopleSoft ethnic group codes.
SA Admissions & Recruiting
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.
SA Academic Advisement
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.
SA Academic Advisement
Define Requirement Usages
Create special usage field values for generating alternate report formats.
SA Academic Advisement
Define Advisement Report
Define and assign valid careers to an advisement report.
SA Academic Advisement
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.
SA Academic Advisement
Define Course Share Sets
Enable courses to be shared by more than one requirement group.
SA Academic Advisement
Define Dynamic Condition
Create multi-dimensional condition specifications.
SA Academic Advisement
APPENDIX
257
Define Academic Requirements
Create specific types of requirements, defining parameters and controls.
SA Academic Advisement
Define Requirement Groups
Define academic requirement groups that point to conditions, courses, and requirements.
SA Academic Advisement
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.
SA Admissions & Recruiting
Referral Source Table
Define the source of referral for a prospect. SA Admissions & Recruiting
Admissions Installation
Define installation options for recruiting and admissions features.
SA Admissions & Recruiting
Region Table Define regions for prospect and applicant recruiting.
SA Admissions & Recruiting
Admissions Action Table
Define program actions for application processing.
SA Admissions & Recruiting
Teaching Subjects
Define teaching subject for OUAC processing. SA Admissions & Recruiting
CEGEP Program Table
Define the CEGEP program table for OUAC processing.
SA Admissions & Recruiting
SAT II Test Codes Define SAT II test codes. SA Admissions & Recruiting
External Summary Type Table
Define summary types for external education data.
SA Admissions & Recruiting
Enrollment Target Population
Define populations for enrollment target processing.
SA Admissions & Recruiting
Enrollment Target Division
Define divisions for enrollment target processing.
SA Admissions & Recruiting
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.
SA Admissions & Recruiting
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.
SA Admissions & Recruiting
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.
SA Admissions & Recruiting
Rating Comp Definition Table
Define rating components for application evaluations.
SA Admissions & Recruiting
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.
SA Admissions & Recruiting
Application Center Table
Define application centers to assign to applicants.
SA Admissions & Recruiting
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.
SA Admissions & Recruiting
Response Reason Table
Define reasons an applicant is attending another school.
SA Admissions & Recruiting
Web Prospect Create Table
Define the structure for prospect self service Request Information feature.
SA Admissions & Recruiting
APPENDIX
259
Rating Tables Define rating schemes for application evaluation.
SA Admissions & Recruiting
Evaluation Tables Define evaluation codes and committees for application evaluation.
SA Admissions & Recruiting
Average Cutoff Table
Define cutoff ranges for alternate admissions offers.
SA Admissions & Recruiting
Alternate Average Calculations
Define rules for calculating alternate admissions averages.
SA Admissions & Recruiting
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.
SA Student Financials
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.
SA Student Financials
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.
SA Student Financials
Tax Transaction Codes
Define Value Added Tax transaction types. SA Student Financials
Tax Authorities Create tax authority codes to process taxes attached to charges.
SA Student Financials
Tax Codes Define tax codes to link taxes and tax authorities to charge item types.
SA Student Financials
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.
SA Student Financials
Late Fees - Billing Create late fee definitions to identify unpaid billed items and assess late fees.
SA Student Financials
Payment Overall Priority
Define the sorting of eligible charges for payment allocation.
SA Student Financials
Student Permission Forms
Create form for permission to apply restricted credits.
SA Student Financials
Charge Priority List
Define charge priority lists and rules and link them to item type tree nodes.
SA Student Financials
Billing and Due Calendars
Create schedules to determine the amount of fees due, the billing and due dates.
SA Student Financials
APPENDIX
260
Adjustment Calendars
Define schedules and fees for tuition adjustments for drops and withdrawals.
SA Student Financials
Origin Table Define sources of receivables posted through group posting.
SA Student Financials
External File Layouts
Define the file layout for external charges and payments.
SA Student Financials
Group Type Table Define sets of frequently posted receivables for use in group data entry.
SA Student Financials
SF Term Default Define default terms to populate accounts when term is not used during posting.
SA Student Financials
Security Views Review and modify security views for your system.
SA Student Financials
Valid Records Review valid records used in trigger criteria for tuition calculation.
SA Student Financials
Valid Fields Review valid records, fields and edit tables used in trigger criteria.
SA Student Financials
Credit Card Type Define the credit card types the institution accepts for payment.
SA Student Financials
Item Reasons Create codes to provide brief explanations for payment and charge reversals.
SA Student Financials
Follow-Up Table Create Follow-Up action codes that record the steps needed to resolve accounts.
SA Student Financials
Reason Out Define codes that identify why the system moved an item out of collections.
SA Student Financials
Fee Classes Define fee classes to enable reporting on specific types of fees.
SA Student Financials
Void Reasons Define codes to provide brief explanations for voided cashiering receipts.
SA Student Financials
AP Set Controls - Vendor
Define vendor information. SA Student Financials
Reason In Define codes that identify why the system moved an item into collections.
SA Student Financials
Liability Status Defines Liability Status Codes as determined by DEST for element 490.
SA Student Financials
Tuition Calculation Controls
Define parameters, rules, errors and warnings used for tuition calculation.
SA Student Financials
Invoice ID Number
Create an unique invoice ID that must appear on your bills.
SA Student Financials
Billing Type Establish bill types for your institution for students or corporations.
SA Student Financials
Message Categories
Create message categories to be used with billing messages.
SA Student Financials
Billing Scan Line Create a bill scan line if your bank requires it to track transactions.
SA Student Financials
APPENDIX
261
1098-T TIN Table Set up a tax identification number for filing 1098-T tax forms with the IRS.
SA Student Financials
AP Business Unit Define Accounts Payable interface and voucher numbering parameters.
SA Student Financials
Criteria Create criteria for tuition groups, fee triggers and waivers.
SA Student Financials
Invoice Layout Set of parameters that define invoice information, sorting, and summarization.
SA Student Financials
Waivers Define waiver codes to waive or reduce a student's tuition and fee charges.
SA Student Financials
Waiver Groups Define waiver groups to attach one or more waivers to class and course fees.
SA Student Financials
SpeedTypes Create shortcut keys of chartfields for department receipt entry in cashiering.
SA Student Financials
Billing Messages Create messages that appear on your bills by message categories.
SA Student Financials
Provider Table Define the International Health Coverage Provider Table.
SA Student Financials
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.
SA Student Financials
Collection Letter Template
Create templates and delvery schedule of dunning letters for past due accounts.
SA Student Financials
Minimum / Maximum Fees
Define ranges for term fees, applications fees and other institutional charges.
SA Student Financials
Billing Standard Request
Define parameters to determine how you identify and bill groups of customers.
SA Student Financials
Bank Accounts - Business Unit
Bank account information for the business unit is managed from this page.
SA Student Financials
Bank Accounts - Corporate
Bank accounts for Exertnal Organizations are managed from this page.
SA Student Financials
Course Lists Create a group of courses for use with third-party contracts or course fees.
SA Student Financials
Per Credit Charge Define the Per Credit Charge and Hook on fee defaults for NZQA.
SA Student Financials
StudyLink Institution
Define refund, residency and enrollment parameters for the institution.
SA Student Financials
APPENDIX
262
Defaults
StudyLink Posting Parameters
Define posting and refund item types for StudyLink.
SA Student Financials
Transaction Fees Create transaction fees for adding or dropping classes as of a specific date.
SA Student Financials
Application Fees Define rules, item types and fees for enrollment applications.
SA Student Financials
Loan Default Define parameters for HECS HELP, FEE HELP and OS HELP loans. Also defines status change rules for the HECS Reconciliation.
SA Student Financials
Optional Fees - Terms
Link optional fee codes to terms and assign date parameters.
SA Student Financials
SF Business Unit Define the basic business rules for each business unit.
SA Student Financials
HECS Band Fees Create and define HECS Band Fees. SA Student Financials
Collector Define and establish collectors within the system.
SA Student Financials
Corporate Collection Criteria
Create a list of corporate collection criteria defined in your system.
SA Student Financials
SF Institution Set Define self service ePayment parameters, rules, and usage for one or more business units.
CSS, SA
Student Financials, Campus Self-Service
Rate Tables for Course Fees
Create student criteria to add to the course fee definition.
SA Student Financials
Corporation Messages
Link message(s) that appear on a single corporation when the bill is generated.
SA Student Financials
Aging Set Messages
Link billing messages to specific aging sets and aging categories.
SA Student Financials
Customer Message
Link message(s) that appear on a single student when the bill is generated.
SA Student Financials
Item and Account Types
Define Item Types and Account Types for the Business Unit.
SA Student Financials
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.
SA Student Financials
Deposit Fees Create admission deposit fees, due dates and status changes for payments.
SA Student Financials
Item Type Message
Link billing messages to specific item types or ranges of item types.
SA Student Financials
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
Student Financials, Campus Self-Service
Course List Fees Create fees for all courses within a given course list.
SA Student Financials
Create Deferral Contract
Define deferral contract parameters, administrative fees and eligible charges.
SA Student Financials
Optional Fees per Term
Define optional fee amounts. SA Student Financials
Target Keys Define which charges receive credit for a given transaction.
SA Student Financials
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.
SA Student Financials
Course Fees Create or update course fees. SA Student Financials
Course Fees Modal
Create or update course fees through the Course Catalog.
SA Student Financials
Tender Keys Define the types of tender used in cashiering transactions.
SA Student Financials
Cashiering Offices Define the characteristics of each cashiering office for the institution.
SA Student Financials
Service Indicator Sets
Define sets that automatically attach service indicators during Credit History.
SA Student Financials
Valid Registers Define valid cash registers used in each cashiering office.
SA Student Financials
Valid Cashiers Define valid cashiers working in each cashiering office.
SA Student Financials
Receipt Print Messages
Define messages that appear on printed transaction receipts.
SA Student Financials
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
INAS 2004-2005 Global Options
Define policies for Federal and Institutional need methodologies for 2004-2005.
SA Financial Aid
INAS 2005-2006 Global Options
Define policies for Federal and Institutional need methodologies for 2005-2006.
SA Financial Aid
INAS 2006-2007 Global Options
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.
SA Student Financials
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.
AV, SA Campus Community
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.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
Action Results Set up types of results that will be used to track completion of initiative actions.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
Constituent Types Set up values to indicate the types of CR constituents being tracked.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
Rating Type Set up types of ratings to track for donor prospects.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
Rating Indicators Set up values that indicate a rating level for a donor prospect.
AV, SA Contributor Relations
Adjustment Reasons
Define reasons for making adjustments to gift, pledge, and membership transactions.
AV, SA Contributor Relations
Trust Types Set up the types of trusts to be tracked for donors.
AV, SA Contributor Relations
Rating Categories Set up categories of ratings to track for donor prospects.
AV, SA Contributor Relations
Appreciation Items
Set up items that will be tracked as tokens of appreciation.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
Involvement Types
Set up the types of involvement required to track constituent involvement.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
Involvement Codes
Set up the values to track specific constituent involvement.
AV, SA Contributor Relations
Add/Update Matching Rules
Enter rules that an external organization uses to determine gifts to match financially.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
Acknowledgement Setup
Setup gift and pledge acknowledgement rules. AV, SA Contributor Relations
Assignment Types
Set up the types of volunteer assignments to track.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
Market Rates Enter and maintain market rates on the Market Rates Data table.
AV, SA Contributor Relations
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.
AV, SA Contributor Relations
APPENDIX
272
Appeal Code Table
Appeal Code Setup. AV, SA Contributor Relations
Designation Funds
Setup designation funds for distribution of gifts, pledge, and memberships.
AV, SA Contributor Relations
Involvement Web Setup. AV, CSS, SA
Contributor Relations, Campus Self-Service
Operator Defaults Set up Contributor Relations defaults for an individual user.
AV, SA Contributor Relations
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.
AV, SA Campus Community
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
CS USA USA Regulatory Reporting
Position Code Table
Define SEVIS position code values. SA
CS USA USA Regulatory Reporting
Fee Code Table Define the fees and expenses for the I-20 form defaults.
SA
CS USA USA Regulatory Reporting
US Government Agency Code Tbl
Define SEVIS US government agency values. SA
CS USA USA Regulatory Reporting
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
CS USA USA Regulatory Reporting
Visa/Level of Education Map
Map levels of education to SEVIS visa types. SA
CS USA USA Regulatory Reporting
Country Mapping Map SEVIS country codes to PeopleSoft countries.
SA
CS USA USA Regulatory Reporting
Visa Mapping Map SEVIS visa code to PeopleSoft visa types. SA
CS USA USA Regulatory Reporting
Suffix Mapping Map SEVIS suffix codes to PeopleSoft suffix values.
SA
CS USA USA Regulatory Reporting
SEVIS Event Types
Define SEVIS event types and form request defaults.
AV, SA Campus Community
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
CS USA USA Regulatory Reporting
SEVIS Program Sponsor Table
Define SEVIS program sponsor and reporting structure information.
SA
CS USA USA Regulatory Reporting
SEVIS School Code Table
Define SEVIS school codes and reporting structure information.
SA
CS USA USA Regulatory Reporting
SEVIS Setup Define processing rules for addresses, names, majors and minors.
SA
CS USA USA Regulatory Reporting
I-20 Template Define default values for the I-20 form by institution, career, program or plan.
SA
CS USA USA Regulatory Reporting
APPENDIX
274
User Defaults Define user defaults. AV, SA Campus Community