PeopleSoft Student Administration Fit/Gap Analysis

REVISION CONTROL Document Title:

Ohio University Fit/Gap Analysis

Action Initial Outline of document Append with Academic Structure

Date 3/19/2008 3/30/2008

By Eric Baker Leslie Roe / Byron Gibbs / Eric Baker Dewey Holleman / Micah Marin / Eric Baker Julie Simpson / Micah Marin / Eric Baker Dewey Holleman / Micah Marin / Eric Baker Susan Kretz / Eric Baker Chris Couture Reed Kofoed / Eric Baker Leslie Roe / Susan Kretz / Karen King / Eric Baker/ Bruce Moore Colleen Egan Team / Eric Baker Shelley Ruff

4/4/2008

Append with Campus Community

4/28/2008

Append with Financial Aid

5/13/2008

Append with Recruiting and Admissions

5/13/2008 5/13/2008 5/27/2008

Append with Academic Advisement Append with Portal Append with Student Financials

6/4/2008

Append with Student Records

6/4/2008 6/16/2008 11/10/2008

Append with Business Intelligence Append with Final Team revisions for AS, CC, SF and FA Append with Non-Credit, Independent Distance Learning and AIMS (submitted by Debra Benton)

ii

Review/Approval History Academic Structure By Debra Benton Action Final Review Academic Structure Approved Yes

Review/Approval History Campus Community By Steve Flaherty Action Final Review Campus Community Approved Yes

Review/Approval History Recruiting and Admissions By Jean Lewis Action Final Review Recruiting and Admissions Approved Yes

Review/Approval History Financial Aid By Jill Lallier Action Final Review Financial Aid Approved Yes

Review/Approval History Student Records By Debra Benton Action Final Review Student Records Approved Yes

Review/Approval History Academic Advising By Debra Benton Action Final Review Student Records Approved Yes

Review/Approval History Student Financials By Kim Trout Action Final Review Student Financials Approved Yes

iii

Table of Contents
Section 1 Section 2 Section 3 Fit/Gap Summary ....................................................................................................................12 Scope ......................................................................................................................................13 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

iv

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

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

vi

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

vii

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

viii

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

ix

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 3Cs 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

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

xi

SCOPE

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.

12

SCOPE

Section 2

Scope
Resulting Deliverables 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 Four day overview per module for: Recruiting and Admissions Student Records and Academic Advisement Financial Aid Student Financials Fit/Gap Sessions Fit/Gap Analysis Document Revised scope if necessary Readiness Assessment BI Strategy Detailed Project Plan Deliverables Approval and Signoff Process Discovery Prototype Acceptance Signoff for: Project Charter Fit/Gap Analysis Document Detailed Project Plan 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.

Prototype 1 Discovery Project Charter Sessions

Project Team Pre-Fit/Gap Training

Fit/Gap Analysis Workshops, including technical and BI interviews

Detailed Project Plan

Presentation of Materials

13

PROJECT TEAM

Section 3

Project Team
Core Team
Shelley Ruff Steve Flaherty Jean Lewis Kim Trout Jill Lallier Debra Benton

Ohio University
Project Manager - Technical Project Manager - Functional Recruiting and Admissions Lead Student Financials Lead Financial Aid Lead Student Records Lead

CIBER
Vice President Program Manager Project Manager Technical Consultant Consultant (Academic Structure, Student Records) Consultant (Campus Community, Admissions) Consultant (Financial Aid) Consultant (Academic Advising) Consultant (Business Intelligence) Consultant (Student Financials) Consultant (Portal) Consultant Consultant Technical Consultant Security Consultant

Active Participants
Henry Tran Bruce Moore Eric Baker Mark Sanderson Leslie Roe Dewey Holleman Julie Simpson Susan Kretz Colleen Egan Reed Kofoed Chris Couture Byron Gibbs Micah Marin Jesus Chanlatte Carolyn Ryll

14

ACADEMIC STRUCTURE

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. Set up product-specific values for Campus Solutions. Set up ID assignment numbers for Campus Solutions.

Product Specific: Last ID Assigned:

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 createbefore you have created any additional business unitscreate 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.

15

ACADEMIC STRUCTURE

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 organizations 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

16

ACADEMIC STRUCTURE

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:

17

ACADEMIC STRUCTURE

o o

Regulatory Region: Currency Code:

USA USD

US Dollar FIT: YES

Establishment

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: o Phone: Regulatory Region

MAIN 740/593-1000 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).

18

ACADEMIC STRUCTURE

Number: Location

FIT: YES

Location is a separate physical administrative unit associated within an institution. Uses the Institutions 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 instructors 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,

19

ACADEMIC STRUCTURE

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 o o o Holiday: Description: Day Number of Hours: Holiday Type: 11/27/2008 Thanksgiving Day 24.00 Standard Holiday: Description: Number of Hours: Holiday Type: 12/25/2008 Christmas 24.00 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.

20

ACADEMIC STRUCTURE

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 rates 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 its 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.

21

ACADEMIC STRUCTURE

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

22

ACADEMIC STRUCTURE

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 classSR 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:

23

ACADEMIC STRUCTURE

G 01 G 02 G 03 G 04 G 05 G 06 Medical M 01 M 02 M 03 M 04

POST BAC <51 POST BAC 51> MASTERS <51 MASTERS 51> PHD <51 PHD 51>

GRADUATE POST BAC/NON-DEG <51 GRADUATE POST BAC/NON-DEG 51> GRADUATE MASTERS <51 GRADUATE MASTERS 51> GRADUATE PHD <51 GRADUATE PHD 51>

PHASE I PHASE II PHASE III PHASE IV

MEDICAL, PHASE I MEDICAL, PHASE II MEDICAL, PHASE III 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 students 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.

24

ACADEMIC STRUCTURE

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 fulltime. 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 Institutions 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 students 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: OHIOs 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.

25

ACADEMIC STRUCTURE

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:

26

ACADEMIC STRUCTURE

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:

27

ACADEMIC STRUCTURE

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 degreeseeking 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 students 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.

28

ACADEMIC STRUCTURE

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

29

ACADEMIC STRUCTURE

Defense schools outside the United States. Data are available for both public and private twoyear 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, 5Winter 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 nonstandard 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.

30

ACADEMIC STRUCTURE

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 02 03 04 05 06 Air Conditioning Heater Podium White Board Overhead Projector Television

31

ACADEMIC STRUCTURE

07 08 09 10 11 12 13 14 15 16 17 18 19 20 21

Network Link Fixed Tier Seating Theater Seats Closed Circuit TV Studio Computer Window Amplified Sound System Satellite Link Biology Laboratory Chemistry Lab Computer Technology Lab Culinary Lab Aviation Maintenance Lab Medical Laboratory Practicum Interview Room

Table Loading Sequence Setup Task Academic Institution Table Term Values Table Campus Table Academic Career Table Academic Group Table Time Period Table Academic Organization Table Academic Subject Table Term/Session Table Academic Calendar Academic Program Description Define default and set up values for academic institutions. Define the term values and their descriptions. Define campus values. Define default and set up values for academic careers. Define course defaults, catalog levels and meeting patterns for academic groups. Define time periods or critical points in time for each academic career. Create a listing of all academic organizations defined in the system. Create subject areas and define taxonomy and workload values. Define terms, sessions within terms, and session time periods. Define cancel, withdrawal, and drop deadlines along with other term and session landmark dates. Define default and set up values for academic programs.

32

ACADEMIC STRUCTURE

Table Academic Plan Table Academic SubPlan Table Create academic plans, and define plan related information for transcripts and diplomas. Create academic subplans as well as define taxonomy and descriptions for transcripts and diploma.

33

CAMPUS COMMUNITY

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

34

CAMPUS COMMUNITY

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.

35

CAMPUS COMMUNITY

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 PSthis would be done to replace SSN with local ID at University level.

Shared Tables with HR Prefixes

FIT: YES

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.

36

CAMPUS COMMUNITY

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

37

CAMPUS COMMUNITY

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 Check (Refund Check) address Commencement address Diploma Address Grades and Duplicate Grades address

Imaged address

OHIO will use only billing address Check address Mailing address Other (possibly rename diploma or degree in the translate table) No need for this in conversion 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. Residence hall addresses will be loaded to Dormitory address and other local addresses will go in Mailing Address Permanent address (UGRD is typically parent address; for international students this can be home or home country) OHIO will use relational aspects Not needed with effective dating 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]) Other Taken care of through PS relationships Use PS relationships (used for refunding purposes when a student dies)

Local/School Address

Permanent address 2nd Permanent address Temporary address SEVIS Foreign address SEVIS U.S. address Father/Mother address Next of Kin 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 students home country (this is a delivered functionyou 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.

38

CAMPUS COMMUNITY

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 PRs 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

39

CAMPUS COMMUNITY

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). OHIOs current values are: 00 01 02 03 04 05 06 Unknown American Indian or Alaskan Native Black, Non-Hispanic Asian or Pacific Islander Hispanic White, Non-Hispanic Non-Resident (International Student)

OHIO expects PS will make modifications to accommodate the new federal reporting requirements.

40

CAMPUS COMMUNITY

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

41

CAMPUS COMMUNITY

External ID Fit, no comments

Personal Information / Biographical Email Addresses

FIT: NO

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

42

CAMPUS COMMUNITY

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.

43

CAMPUS COMMUNITY

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

44

CAMPUS COMMUNITY

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 Citizenship and Passport

FIT: YES

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 (BioDemo 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 statuscitizenship 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 usedanything 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.

45

CAMPUS COMMUNITY

Driver's License Data OHIO needs to identify all areas where drivers 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 drivers license data on file. OHIO stores drivers license information in the library. Additionally, drivers license information may be stored in the financial aid office, on a students 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. OHIOs current values are: 00 01 02 03 04 05 06 Unknown American Indian or Alaskan Native Black, Non-Hispanic Asian or Pacific Islander Hispanic White, Non-Hispanic 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 DSOs (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 IDs are stored on this page and associated with a person.

46

CAMPUS COMMUNITY

Residency Data OHIO can create residency exception codes, which are assigned at the person levelthus, 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 systemthis 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 temporarilybut 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

47

CAMPUS COMMUNITY

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 Honors and Awards

FIT: NO

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

48

CAMPUS COMMUNITY

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 Service Indicators

FIT: NO

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.

49

CAMPUS COMMUNITY

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 PSbeyond 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 (bursars 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

50

CAMPUS COMMUNITY

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 Committee Types

FIT: YES

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 purposescustomization 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

51

CAMPUS COMMUNITY

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, no comments.

FIT: YES

52

CAMPUS COMMUNITY

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 callsuccessful/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 Consultant will need to know all extract fields. Question raised during Fit/Gap:

FIT: YES

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

53

CAMPUS COMMUNITY

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

54

CAMPUS COMMUNITY

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.

55

CAMPUS COMMUNITY

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.

56

CAMPUS COMMUNITY

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 Setup types needed for institution; a location table must be created.

FIT: YES

OHIO presently has location information stored in three to four different systems.

Resource Code Table Fit, no comments

FIT: YES

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 its coming from, and whether it can be trusted.

57

CAMPUS COMMUNITY

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 Organization Group Table

FIT: YES

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.

58

CAMPUS COMMUNITY

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

59

CAMPUS COMMUNITY

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 users ability to edit the data.

Student Service Center Self Service

FIT: NO

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.

60

CAMPUS COMMUNITY

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.

61

CAMPUS COMMUNITY

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

Table Loading Sequence Setup Task Supporting Documents Visas/Permits Name Type Defaults Extracurricular Activity Table External Organization Type NAICS Codes Selection Tool Application Specific Context Context Definition Equation to Context Mapping Field Conversion Definition Copy Field Value Conversion Context Definition Copy Context Definition File Mapping Definition Copy File Mapping Definition Description Defines documents used to verify employee information. Define visa or permit details and supporting documents for verifying status. Define or review the name types that will be created by default when adding a new person ID. Define and update the extracurricular activities your institution tracks. Define organization types and related navigation. Define North American Industry Classification System codes. Configure Population Selection Tools. Define the application specific keys used to map a process to a specific context. Configure Population Selection Context Definition. Map Equation Engine Application Prompt values to Population Selection Contexts File Parser Field Conversion Definition

File Parser Copy Field Value Conversion. File Parser Context Definition Copy Context Definition. File definition and mapping. File Parser Copy File Mapping Definition.

62

CAMPUS COMMUNITY

Population Selection File Map Population Update Setup Form Image Text Event Type Table Campus Community Installation Resource Code Table Health Test Table Staff Code Table Event Template Trigger Prompt Table Ext Org Code Type Table EPS Market Code Table Relationship / Marital Status Immunization Table Relationship Table Font Names Form Editor Form Groups Out Dest Formats Out Dest Types Out Dest Values Postscript Fonts Standard Letter Table CS

Population Selection File Mapping Definition Population Update Setup. Forms Engine EPS Image Text. Define type of events to manage. Install tables required for Campus Community. Define resources to be used with events. Define and update the health tests your institution tracks. Define staff codes to use with events. Define event meeting templates. Identify the edit table for a 3C engine trigger to prompt. Define an EPS market code organization code type. View EPS market codes loaded through the EPS load process. Define and update a marital status corresponding to a joint relationship. Define and update the immunization tests your institution tracks. Define and update the relationships your institution tracks. Font Name Table. Form Editor. Form Group Table. Forms Engine Out Dest Formats. Forms Engine Out Dest Types. Forms Engine output dest prmpt. Postscript Fonts. Set up standard letter codes to be used in Campus Solutions communications.

63

CAMPUS COMMUNITY

Comment Category Table 3C Update/Inquiry Group Table Comment 3C Groups Tracking Group Table Communication Context Table Institution Publications Iwi Table Legacy Table Communication Category Table Communication 3C Groups Publication Categories Service Impact Table Service Indicator Table Committee Type/Role Checklist Item Table Checklist Item Functions Table Communication Speed Key Table Communication Data Source Checklist 3C Groups Event Definition Trigger Definition

Set up categories for comments. Define 3C group codes. Include comments in 3C groups for security purposes. Set up tracking groups for checklists. Set up contexts for the communications process. Define and update the publications your institution tracks. Maintain Iwi codes and descriptions for NZ Maoris. Used in SDR Reporting. Define the types of legacy affiliations that individuals can have with your institution. Set up categories to use in the communications process. Include communications in 3C groups for security purposes. Publication Categories. Define service impacts codes to attach to service indicators. Create service indicators code, for both positive and negative service indicators. Define the committee types and member roles. Set up items to be used in a checklist. Set up checklist items by administrative function.

Manage Speed Keys for communications. Define communication data source to be used in Campus Solutions communications. Include checklists in 3C groups for security purposes. Define events for management of communications, checklists and/or comments. Define triggers for management of communications, checklists and/or comments.

64

CAMPUS COMMUNITY

Organization Recipient Usage Organization Affiliation External Organization Codes Religious Preference Table Residency Exception Table Residency Table Standard Industry Table Standard Occupation Table Define External Systems Athletic Participation Table Update Security - Acad Orgs Honors and Awards Table Student Services Center Setup External Term Equation Application Prompts SEVIS Event Types SEVIS File Errors User Defaults

Define hierarchies of Organization Recipient types to search for and use in a specific usage. Create or update an organization's affiliation to the institution. Create or update EPS codes for an organization.

Define and update the religious preferences your institution tracks.

Define and update the residency exceptions your institution tracks. Define and update the residency information your institution tracks. Define and update the United States standard industrial classifications your institution tracks. Define and update the United States standard occupational classifications your institution tracks. Define external systems for which external system identifiers can be tracked. Define and update athletic participations your institution tracks. Link your academic organization security tree to academic organization security. Define and update the honors and awards your institution tracks. Define the labels and sections to show for the Student Services Center Define or review external terms sessions for external organizations. Add or update the list of applications that use equations. Define SEVIS event types and form request defaults. Define file errors returned from SEVIS. Define user defaults.

65

RECRUITING AND ADMISSIONS

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.

66

RECRUITING AND ADMISSIONS

Recruitment Recruitment Categories

FIT: YES

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.

67

RECRUITING AND ADMISSIONS

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.

68

RECRUITING AND ADMISSIONS

Test Score Setup Test table and test component table

FIT: NO

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; 69

RECRUITING AND ADMISSIONS

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

Processing External Test Scores External Test Score Load

FIT: NO

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.

70

RECRUITING AND ADMISSIONS

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.

71

RECRUITING AND ADMISSIONS

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

RECRUITING AND ADMISSIONS

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 PSEOP= Post Secondary Options Program. OHIO will set up PSEOP as an admit type. Configuration requires a determination of how to code them.

FIT: Yes

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

RECRUITING AND ADMISSIONS

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 Search/Match

FIT: Yes

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 74

RECRUITING AND ADMISSIONS

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; 75

RECRUITING AND ADMISSIONS

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.

76

RECRUITING AND ADMISSIONS

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 Fits; no comments

FIT: Yes

Admitting Students 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,

FIT: Yes

77

RECRUITING AND ADMISSIONS

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) 78

RECRUITING AND ADMISSIONS

State Transfer Initiatives in OH Clearing House

FIT: NO

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) 79

RECRUITING AND ADMISSIONS

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 80

RECRUITING AND ADMISSIONS

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 Viewing summary application materials information

FIT: Yes

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 applicants 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 81

RECRUITING AND ADMISSIONS

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 persons 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.) 82

RECRUITING AND ADMISSIONS

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 External GPA Type Table External Education Comments Test Component Table Test Tables External Test Score Mapping Ethnicity Mapping AMCAS Ethnicity Mapping CRS Major Codes SAT Math Recentered Values SAT Verbal Recentered Values Referral Source Table Admissions Installation Region Table Description Define GPA types for external education data. Default comments for external education entry.

Define components for external tests. Define Test IDs and score ranges for external tests. Map test IDs to PeopleSoft defined test codes. Map ethnicity codes from the testing agencies to PeopleSoft ethnic group codes. Map ethnicity codes from AMCAS to PeopleSoft ethnic group codes. Define major codes for CRS search tapes. Define math recentered values for the SAT test.

Define verbal recentered values for the SAT test. Define the source of referral for a prospect. Define installation options for recruiting and admissions features. Define regions for prospect and applicant recruiting. 83

RECRUITING AND ADMISSIONS

Admissions Action Table Teaching Subjects CEGEP Program Table SAT II Test Codes External Summary Type Table Enrollment Target Population Enrollment Target Division AMCAS GPA Codes Law Categories AP Country Codes AP Subject Test Codes GRE Subject Test Codes Program Action Reason Table AMCAS Credit Hour Codes Basis of Admission Table ADA Country Codes Extracurricular Activity Map GMAT Country Codes SAT II Test Recentered Values

Define program actions for application processing. Define teaching subject for OUAC processing. Define the CEGEP program table for OUAC processing. Define SAT II test codes. Define summary types for external education data.

Define populations for enrollment target processing.

Define divisions for enrollment target processing. Define GPA codes for AMCAS tests. Define law categories for OUAC processing. Define country codes for AP tests. Define subject test codes for AP tests. Define subject test codes for GRE tests. Define program action reasons for application processing.

Define credit hours codes for AMCAS tests.

Define basis of admission codes for application processing. Define country codes for ADA tests. Map external extracurricular activities. Define country codes for GMAT tests.

Define SAT II test recentered values.

84

RECRUITING AND ADMISSIONS

Region Postal Table Religious Preference Map Academic Interests Map Enrollment Target Cohort Admission Comments Table Rating Comp Definition Table Evaluation Status Table TS130/TS131 Setup Material Group Table Application Center Table External GPA Rules Table Recruiting Center Table Admit Type Table Recruiting Category Table Response Reason Table Web Prospect Create Table Rating Tables Evaluation Tables Average Cutoff Table Alternate Average Calculations Alternate Offer Table

Define postal code ranges for regions. Map external religious preferences. Map external academic interests. Define cohorts for enrollment target processing. Define admissions comment codes for application processing.

Define rating components for application evaluations. Define statuses for application evaluation. Set up TS 130 and TS 131 and define contacts. Define materials groups for application and general materials. Define application centers to assign to applicants. Define GPA rules for external education data. Define recruiter centers to assign a prospect. Define admit types for prospects and applicants. Define recuiring categories for prospects and applicants. Define reasons an applicant is attending another school. Define the structure for prospect self service Request Information feature. Define rating schemes for application evaluation. Define evaluation codes and committees for application evaluation. Define cutoff ranges for alternate admissions offers. Define rules for calculating alternate admissions averages. Define rules for alternate offers of admission.

85

RECRUITING AND ADMISSIONS

Early Financial Aid Categories Early Fin Aid Categories

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

86

FINANCIAL AID

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 students 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

87

FINANCIAL AID

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 Bachelors 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 students ISIR if OHIO shows that the student has a degree, but the FAFSA is discrepant.

Institutional Student Information Record (ISIR) Processing

FIT: NO

A students application for financial aid begins with the receipt of the students FAFSA information contained in the ISIR data record sent by the CPS. Once this information is loaded into Financial Aid, the evaluation of a students financial aid eligibility begins. Receive and send ISIR dataGap - 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. Drivers 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.)

88

FINANCIAL AID

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 ISIRs 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 89

FINANCIAL AID

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 students educational expenses for the period of enrollment. The budget helps establish a students need (Cost of Attendance minus the students expected family contribution), which permits the financial aid office to award needbased 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

90

FINANCIAL AID

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 dont 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. 91

FINANCIAL AID

Plus is not packaged upfront Veterans 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 o Stipend Awards OU will continue to process these awards through payroll. 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. 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.). 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. 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

92

FINANCIAL AID

as the Continuing Education Waiver and will need to be combined with the OGA modification. The Pell Grant is packaged based on students 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 Bursars 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. 93

FINANCIAL AID

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 students 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 students 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 students aid if student is not properly enrolled, Satisfactory Academic Progress (SAP) status is not met, or a manual hold is placed on students 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 terms classes. PS does not have the functionality to trigger origination from the action of having been 94

FINANCIAL AID

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 schools 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 schools 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 ELM serviced lender Non-ELM serviced lender Great Lakes Guarantee Lender Flow, CRC Guarantor Flow (GL), CRC Non- Great Lakes Guarantee Lender Flow, CRC Lender Flow, Manual (paper) or CLv4

Stafford loans will be school-initiated, meaning that the schools 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

95

FINANCIAL AID

ELM/Great Lakes serviced lender ELM/Great Lakes serviced lender

Lender Flow, CRC Lender Flow, CRC & CLv4 or Manual (paper)

n/a n/a

Alternative loans will be borrower-initiated, meaning that the schools 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 preregistered 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 students loan record as additional unsub due to PLUS denial. Ability to mark a students loan record as additional unsub due to Teacher Cert student. Ability to print MPNs 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 Bursars office at OHIO. Perkins is part of packaging formula 96

FINANCIAL AID

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 students 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

97

FINANCIAL AID

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 Define External Award Sources Define External Award Types Financial Aid Installation Define Federal Aid Years Define Financial Aid Years Valid Careers for Aid Year Valid Terms for Career Define Description Define sources of external awards.

Define external award types. Define installation values required for Financial Aid. Define the aid year using federal guidelines.

Define the valid financial aid years for the institution. Assign financial aid eligible academic careers for the aid year. Define eligible financial aid terms, academic and loan periods for careers. Define database commit levels for eligible financial aid processes. 98

FINANCIAL AID

Commit Levels Define Demographic Data Use PROFILENeed Access Controls Maintain ISIR Comment Codes ISIR/SAR Cross Reference Maintain NSLDS Codes INAS Assumption Codes INAS 20042005 Global Options INAS 20052006 Global Options INAS 20062007 Global Options Institutional Cross Reference Loan Fee Setup Aggregate Programs Define Sort Order Fields Define Sort Order Names Maintain CRC Loan Status Codes School Codes for Institution School Code Table

Define how student bio-demographic information is used by financial aid processes. Define PROFILE and Need Access run controls.

Maintain the ISIR comment codes and their database match usage.

ISIR/SAR Cross Reference.

Review and update the NSLDS status codes.

INAS Assumption Setup Pages. Define policies for Federal and Institutional need methodologies for 2004-2005. Define policies for Federal and Institutional need methodologies for 2005-2006. Define policies for Federal and Institutional need methodologies for 2006-2007 Track cross-references of field name to the institutional record field number. Define loan fees which are calculated during the packaging process. Define Stafford, Direct, or HEAL aggregate areas to be linked together to combine loan limits. Update and review Financial Aid Award Notification output Sort Order Fields criteria. Define Sort Order Names criteria for Financial Aid Award Notification output processing. Maintain CRC status and error codes reported by the loan servicers. Define valid school codes for institution. Maintain Title IV school codes by aid year.

99

FINANCIAL AID

Maintain Loan Servicer Codes Define Loan Report Definitions Equation Editor Equation Global Space Budget Tree Address Usage Define EDI Business Unit Maintain EDI Transactions Maintain Loan Edits Maintain Loan Transfer ID Maintain Guarantor Codes Maintain CRC Loan Edits Create CRC Loan Edit Sets Aggregate Level Translation Aggregate Aid Limits Aggregate Area Translation Maintain Loan Action Codes Maintain Lender Codes Create CRC Loan Participants

Maintain a comprehensive list of loan servicer codes.

Define field specifications and the output format for loan forms. Create and edit equations. Work with Equation Global Variables in Equation Spaces. Define which address type is to be used during the budget assignment process. Define the internal financial aid business unit used in EDI Manager processes. Maintain the EDI transactions that can be viewed in the ISIR and Loan Review pages. Maintain CommonLine 4 validation edit list. Maintain loan information used to generate loan files for transmission.

Maintain a comprehensive list of guarantor codes. Maintain list of Common Record CommonLine loan edits. Create sets of loan edits to be used in creating CRC loan destinations. Associate aggregate levels with academic level definitions from the Department of Education. Define annual and aggregate aid limits for all sources of funding. Associate aggregate areas with programs from the Department of Education. Maintain loan action codes used by Direct Lending and CommonLine.

Maintain a comprehensive list of lender codes.

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

100

FINANCIAL AID

Create CRC Search Match Setup Define School Guarantors Define School Lenders Define School Servicers Direct Loan Change Rules Hold and Release Equations Reassign Loan Agencies Maintain Loan Report Packages Setup Perkins MPN Options CNAS Messages Create Proration Rules Financial Aid Item Types Item Type Cross Reference Search/Match Rules Fiscal Item Types Define Rules for Return CSL File Load Control Verification Tolerance Setup Award Adjustment Reasons

Create search match setup conditions for CRC Certification Request processing. Define the guarantee agencies to be used for processing loans at the institution. Define lending agencies to be used for processing loans at the institution. Define loan servicers to be used for processing loans at the institution. Define global change parameters for Direct Loan change, hold and suspense processing. Define the equations used by the CommonLine Hold and Release process. Define instances where one loan agency has been replaced by another. Setup and update Loan Report Packages for Promissory Note processing. Define Perkins MPN Options Define Canadian need analysis messages. Define the criteria for pro-rating awards based on student enrollment. Define item types as financial aid item types for use in awarding various sources of funds. Map external awards to internal award items. Define search/match options to use during external award loadng process. Define fiscal limits for existing financial aid item types. Identify financial aid item types used for Return of Title IV calculations. CSL File Load Setup Page. Update verification tolerance values for Federal and Institutional processing. Define reasons for why an award may be adjusted on the various Assign Award pages.

101

FINANCIAL AID

PROFILE Load Parameters Need Access Load Parameters View COD XML Fields Budget Categories Budget Items Create Loan Edit Sets Budget Formulas Create CRC Loan Destinations Reconciliation Periods Application Source Rank Budget Region Table Budget Trees Setup Financial Aid Term Define Career Types Self Service Options Aid Processing Rule Setup Term Values Cross Reference Create Loan Destinations Pell Payment Valid Programs for Aid Year

Define PROFILE Data Load Parameters.

Define Need Access Data Load Parameters. View Common Origination and Disbursement XML field mappings. Define the individual components that make up the federal, Pell, or institutional budget. Define budget items, term amounts, and Pell annual amounts by budget category. Create sets of loan edits to be used in creating loan destinations. Define assignment rules for each budget item which are used to calculate the student's budget. Define the processing protocols between the school and the CRC loan servicers. Create reconciliation periods for cash management. Define the application source order for the batch budget assignment process. Define regions to be used during Budget Tree processing. Define a Tree Node that will be used to assign a particular detailed value to a budget item. Define the valid terms that can be used for building financial aid term records. Define Financial Aid Career Types to combine statistics for FA Terms. Define self service inquiry options as well as awarding access and processing options. Define aid processing rule sets for use as career and program defaults. Define equivalent terms across aid years for the aid year rollover process. Define the processing protocols between the school and the CL 4 loan servicers. Define Pell payment parameters and options. Assign program specific financial aid processing rule sets.

102

FINANCIAL AID

Pell ID Attending Pell Comment Code ISIR Data Load Parameters Define Serial Promissory Notes Package Rating Components Packaging Equity Item Types Budget Groups Budget Assignment Define Printer Names Define Selection Equations Define Notification Form Types Award Notification Defaults Assign Status to Admit Levels Define Careers for Prospects Related Item Type Group Create Loan Types Set DL Loan Counseling Search Identify Self Service

Assign a campus specific Pell ID. Set severity level for edits and comments defined by Department of Education. Define the rules used to load ISIRs from the staging to the application tables. Define and update parameters for Direct Loan MPN and Serial Promissory Note processing. Define admissions rating components and GPA types to be available during packaging. Define a group of financial aid item types to act as equity offsets in a packaging plan. Define a group of budget items for use in manually assigning a term budget to students. Define career/aid year/institution combinations to assign budgets to groups of students. Define institution printer names used by the Financial Aid Award Notification Defaults page. Define Forms Engine Financial Aid Award Notification Selection Equations. Define Forms Engine Financial Aid Award Notification Form Types.

Update and review award notification defaults.

Assign an academic program status for each program admit level.

Define the career to assign to applicants based on the student's ISIR. Define related financial aid item types together into similar groups for awarding purposes. Define the loan types that require origination. Direct Loan Search Match Setup for loan counseling data load. Define Lender Select list.

103

FINANCIAL AID

Lenders Define Loan Counseling Options Set Up Disbursement Calendars Restricted Aid Table Budget Assignment Run Control Disbursement Plan Table Disbursement ID Table Create User Edit Messages Define Global Rules Disbursement Split Codes Disbursement Split Cd Formula Packaging Plan Repackaging Plan Careers for School Codes Define Loan Institutions Define Item Type Rules Define Loan Counseling options. Define the parameters for the batch authorization and disbursement processes. Define parameters and conditions for awarding funds with subjective eligibility requirements. Define careers and terms to select for the budget assignment process. Define the different disbursement plans for each career by aid year. Define disbursement IDs for each disbursement in or across terms for a disbursement plan. Create and update user edit messages. Define common authorization rules for students of the same career. Define all disbursement patterns for each disbursement plan in a given aid year. Define percentages of award to be disbursed by disbursement split code. Define award rules and limits for targeted groups of students for use in auto- and mass packaging. Define rules and limits for targeted groups of students for use in autoand mass repackaging. Define valid careers for school codes. Define the valid loan processes available at the institution. Define common authorization rules for individual Item Types.

104

STUDENT RECORDS

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 AstraPeopleSoft 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 105

STUDENT RECORDS

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 o o Modify the detailed display of Class when using Class Search to show Course and/or Class Fees. Est Effort: Use the free text PS field Class Notes to contain information about fees. This is accessible through Self Service. 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

106

STUDENT RECORDS

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: 107

STUDENT RECORDS

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 o Customization: Develop a custom page to record facility notes, scheduler(s) and their contact information. Effort Estimate: 200 hours. 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.

108

STUDENT RECORDS

Review Facility Characteristics

FIT: YES

This process is used to define room characteristics and facility blackout times.

Designate Approved Instructor and Advisors CIBER Comments:

FIT: YES

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 CIBER Comments: PeopleBooks states:

FIT: YES

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.

109

STUDENT RECORDS

This was modeled in the Sandbox. Quarter and Semester unit conversions are modeled under the Academic Institution of OHIOU.

Define Standard Meeting Patterns CIBER Comments:

FIT: NO

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. FIT: YES

Define Modes of Instruction 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 OHIOs needs. There is a gap at the Repeat Rules level.

110

STUDENT RECORDS

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 students 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 students 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 students 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. 111

STUDENT RECORDS

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 CIBER Comments: OHIO sets repeat schemes on a course-by-course basis.

FIT: NO

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: OHIOs 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. 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 students 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 112

STUDENT RECORDS

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 Use this page to capture how a course is offered at OHIO.

FIT: YES

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:

113

STUDENT RECORDS

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 Discussion Independent Study Lecture Research Supervision Tutorial Continuance Field Studies Laboratory Practicum Seminar Thesis Research

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 This view is a summary of course offerings.

FIT: YES

Print the Course Catalog

FIT: YES

This page defines the parameters used to create the course catalog report.

114

STUDENT RECORDS

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 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:

FIT: NO

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. b. c. d. Psychology 101 Communication Studies 103 Tier I Freshman Composition 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. 115

STUDENT RECORDS

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 students class transaction log should appropriately identify the reason for the drop, i.e. failed prerequisite. Options for resolution include: o o Develop a custom query which would act as the report only version of this process. Est. Effort: 80 hours. 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. 116

STUDENT RECORDS

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 o o Use the (manual) delivered PS process to track Attendance. Continue to use OHIOs existing Harco card system and OHIOs custom built attendance tracking (do not use PS Attendance Tracking). 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, Veterans Educational Benefits Coordinator, Allen Help Center, etc. Options for resolution include: o Extend OHIOs existing Harco card system and OHIOs custom built attendance tracking to include this functionality (which it does not currently). Est. Effort: Unknown 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. 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.

117

STUDENT RECORDS

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 students 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 o Revise OHIOs Academic Standing Policy to exclude Deficiency Points. 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 students cumulative hours. Once the part-time students cumulative hours exceed 11 hours, the student is subject to probationary review. At that time, the counter 118

STUDENT RECORDS

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 o Change the academic policy to treat part-time and full-time students similarly. Develop a custom counter attached to the students record that is evaluated at the end of each quarter, and resets when the students cumulative hours (per career) exceed 11.

GAP: If a student cant 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. 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 students program/plan stack.

GAP: OHIOs 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. PSs 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 students 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, 119

STUDENT RECORDS

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 Universitys 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 OHIOs 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 students courses are reflected on the transcript, but the GPA grades earned earlier are changed 120

STUDENT RECORDS

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 students 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 Use this page to link rules to Academic Programs.

FIT: YES

Set up Honors and Awards 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.

FIT: YES

Honors and awards include internal and external awards. Guidelines can be created for every academic career at the University.

121

STUDENT RECORDS

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
students Academic Plan and External GPA. A process would need to be created to update Student Special GPAS 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 students 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 Registrars Office does not track Extracurricular Activities. This functionality was also covered in Campus Community, so that other OHIO Offices could use this component. OHIO

122

STUDENT RECORDS

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 institutions 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 123

STUDENT RECORDS

this section, GAPS are listed below, but without individual recommendations for solutions. The overall solution is to continue to use OHIOs existing online grading system. The Grade Eligibility information below is taken from OHIOs 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 WP WF FN FS Grade Description Withdraw Pass Withdraw Fail Failed No Show Failed Stopped Attending Incomplete No Report Pass Notes Assigned by faculty to replace system assigned W Assigned by faculty to replace system assigned W Assigned by faculty to indicate student never appeared in class 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 Assigned by faculty Default grade if no grade reported by faculty 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 Showing an Incomplete has been lapsed to F Assigned by Registrar. To grant an extension of the Incomplete to the end of the next term. Assigned by the system when a student withdraws. Faculty will then assign a WP or WF.

I NR P

F-I IE W

Grade Lapse Incomplete Extension Withdraw

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 124

STUDENT RECORDS

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. OHIOs 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 students 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 OHIOs 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 MidTerm 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. 125

STUDENT RECORDS

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 students course. For example if the course had a grade basis of GRD (A-F) and a user manually changed the students 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 Registrars 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.

126

STUDENT RECORDS

Departmental Honors Student A department honors student may with permission. Limited to a maximum of three graduate courses in their major department during students 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 bachelors 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 departments 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 Grade rosters can be defined on a class-by-class basis.

FIT: NO

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 127

STUDENT RECORDS

rosters when you run the Create Grade Roster process. This results in the loss of any grades which the instructor has already entered. o o Create modification to check if grade exists then retain and append additional students to the roster. 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 o Add the Last Date of Attendance as a field on grade roster. 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 o Unlock assigned W grade on grade roster to allow faculty to assign P or F to assigned W grade. 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 SelfService.

Additional option for resolution: OHIO uses a custom-built internal system for online grading that has been developed to meet the institutions 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 OHIOs existing online grading system.

Create Grade Rosters for Multiple Classes

FIT: NO

128

STUDENT RECORDS

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 Use this process to define a degree for each academic plan.

FIT: YES

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 Not Print Official Value 00 20 Description Do not print the information on any transcript. 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. 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, 129

Unofficial

40

STUDENT RECORDS

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

Degr Prog (degree progress)

80

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.

130

STUDENT RECORDS

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 institutions name, years of attendance, and total hours transferred. Options for resolution include: o o o Use the delivered transcript. Use Transcript Text to manually record a summary of the students incoming transfer credit. 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 o Discontinue this process or handle it manually. Create a custom record to contain the students 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

131

STUDENT RECORDS

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 CIBER Comments:

FIT: NO

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 users 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. 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 o Customize the page to include the instructor name. Effort Estimate: 40 hours. Validate the class section information prior to updating this page.

132

STUDENT RECORDS

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 133

STUDENT RECORDS

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 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. 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. 2. 3. 4. 5. UGRD and GRAD meet together Course from different departments that meet together Course where several sections meet together Some classes meet together, may break out into lab sections that are not together Some classes meet together and lab sections meet together

CIBER Comments: 134

STUDENT RECORDS

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: 135

STUDENT RECORDS

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 o Use the delivered process 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 OHIOs current Search for Classes. OHIOs current Online Schedule of Classes permits searching by the following fields: o o o o o o o o o o o o o o o o o o o o o Term Location Course prefix Course Title (you may search for a word and if it appears in any title the section is returned) Course number Course level Course status General Education Code 1 General Education Code 2 Begin date End date Last day to add Last day to drop Instructor Credit hours Start time End time Class meeting day(s) Eligible grades Building Room

136

STUDENT RECORDS

Option for resolutions include: o OHIO currently uses a custom-built internal system for Online Course Offerings that has been developed to meet the institutions 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 OHIOs 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. Ohios Schedule of Classes includes the following fields: o o o o o o o o o o o o o Call number Course ID Section number Title Credit hours Time Days Building Room Instructor Prerequisite Class notes 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: 137

STUDENT RECORDS

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 students 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 Activate Additional Steps Required

ACTV (Activate)

A student is ready either

None 138

STUDENT RECORDS

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) COMP (Completion of Program) A student is withdrawn for administrative reasons. A student has completed the program. Canceled Post the withdrawal on the student Withdrawal page.

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. Business Process Change to centralize all program changes in the Registrars Office. 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.

o o

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.

139

STUDENT RECORDS

Maintain Student Program Information CIBER Comments:

FIT: NO

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 o Do not display the last update date, time, and UserID. 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 students 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 students 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 students record needs to automatically be updated based on where the student is registered for classes. Options for resolution: o 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. Develop an Application Engine program to populate this field. Est. Effort: 40 hours.

140

STUDENT RECORDS

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 noncredit 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, biodemographic 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

141

STUDENT RECORDS

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

STUDENT RECORDS

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

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 dont 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 dont need any of the information included here. CIBER Comments:

Ohio Universitys Independent and Distance Learning (IDL) is committed to taking the universitys 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
143

STUDENT RECORDS

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

144

STUDENT RECORDS

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,

145

STUDENT RECORDS

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:

146

STUDENT RECORDS

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:

147

STUDENT RECORDS

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 IDLs needs. CIBER estimates 40 hours per report (280 total) for functional and technical specification, development, testing and documentation. 148

STUDENT RECORDS

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.

149

STUDENT RECORDS

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 Deans 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 doesnt require the user to do any running of queries or mail merges. For example, it permits at the click of a button the deans 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 advisors 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.

150

STUDENT RECORDS

Table Loading Sequence Setup Task Student Records Installation Room Characteristics Table Student Special GPA External Subject Table Enrollment Action Reason Instructor/Advisor Table Requirement Designation Table Course Equivalencies Course Attributes Course Typically Offered Instruction Mode Dynamic Class Dates Table Weekly Schedule Time Periods Course Catalog Classroom Scheduling Interface Study Agreement Table Milestone Table Milestone Templates Grading Basis Exception Rule Grade Review Appointment Limits Table Description Define installation values required for Student Records. Define specific room characteristics. Create and maintain special grade point averages for a student's term records. Define broad categories of the subjects offered at external organizations. Define enrollment action and enrollment action reason values for all academic careers. Add and modify instructor and advisor records. Define requirement designation values. Define course equivalency groups. Define course attributes and attribute values. Define course typically offered values Define instruction mode values. Dynamic Class Dates Table. Define weekly schedule time periods. Create, view and update courses, course offerings, and course components. Set up classroom scheduling interface. Create study agreements for use with external organizations. Define milestone codes, their grading bases and determine the milestone levels. Define milestone templates to be used with milestone values. Define mapping rules to convert grading bases for students enrolling across careers. Define grade review values to be used in the grade review process. Define appointment limits ID's and full-time and part-time maximum unit limits. 151

STUDENT RECORDS

Appointment Table Student Group Table Student Group Table Degree Honors Table Academic Standing Table Academic Standing Rule Honors/Awards Rule Student Attribute Table Global Notes Table Repeat Scheme Table Repeat Rule Test Table Test Transfer Rules Program/Test Equivalency Transfer Subject Area Course Transfer Rules Program/Source Equivalency Gradebook Category Define Statistics Type Define Statistics Period Cum. Grade Point Average Transcript Type Transcript Notes Table Transcript Print Area Table Define Transcript

Create enrollment appointments for sessions and terms. Define student groups to track student membership within various groups. Define student groups to track student membership within various groups. Define degree honors and print options for transcripts and diplomas. Create academic standing action codes for all academic careers. Define academic standing rules for all academic careers. Define rules to be used in the honors and awards process. Define student attributes for tracking and reporting on different cohorts. Define global notes. Define repeat schemes and repeat codes within each scheme. Define repeat rules for academic careers and academic programs. Define test codes and link test components to them. Define test transfer equivalency rules. Select the academic programs and plans to assign test transfer equivalencies. Define component subject areas for external or internal institutions. Define course transfer equivalency rules. Select the programs and plans to assign course transfer equivalencies. Maintain gradebook assignment categories. Define statistics types for consolidated statistics. Define statistics periods for reporting consolidated statistics. Define cumulative GPA values and associated descriptions. Define transcript types, associate service indicators and indicate that a transcript type includes an advising report. Create transcript notes that relate to a student's enrollment record. Set up codes to define where various types of data appear on the transcript. Define transcript type and associate service indicators. 152

STUDENT RECORDS

Type NSC Branch Table Define branch codes to be used when reporting enrollment status to the NSC.

153

ACADEMIC ADVISING

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 Universitys (OHIO) current Academic Advisement business processes and associated implementation requirements, and comments accordingly on the findings. OHIOs existing degree audit system is DARS. DARS is not interactive with the PS 9.0 SelfService 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 students 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.

154

ACADEMIC ADVISING

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

155

ACADEMIC ADVISING

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

156

ACADEMIC ADVISING

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 students 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 157

ACADEMIC ADVISING

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 Ds 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 GPAs 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.

158

ACADEMIC ADVISING

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

ACADEMIC ADVISING

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.

160

ACADEMIC ADVISING

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 students 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. 161

ACADEMIC ADVISING

Printing the Advisement Transcript/Degree Audit Report Currently, the DARS audit is made available to the student online.

FIT: YES

In PS, the Academic Advisement Report/Degree Audit report audits a students 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. 162

ACADEMIC ADVISING

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 students 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 students 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). OHIOs current What-If process will default the appropriate term based on the student and terms available for the program being run.

163

ACADEMIC ADVISING

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

ACADEMIC ADVISING

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.

165

STUDENT FINANCIALS

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 OHIOs 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

166

STUDENT FINANCIALS

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.

167

STUDENT FINANCIALS

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

168

STUDENT FINANCIALS

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 OHIOs 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, OHIOs tuition groups will be defined using criteria and equations.

169

STUDENT FINANCIALS

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

170

STUDENT FINANCIALS

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 SelfService. 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, PSs 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.

171

STUDENT FINANCIALS

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, PSs functionality should be a good fit. Student Financials has a number of settings it can use to determine who will get cancelled and who wont. 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 172

STUDENT FINANCIALS

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

173

STUDENT FINANCIALS

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.

174

STUDENT FINANCIALS

Student & Third Party Account Maintenance: Group Posting Financial Aid Batches

FIT: NO

Group Posting Financial Aid Batches Gap. While PS will allow OHIOs 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.

175

STUDENT FINANCIALS

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

176

STUDENT FINANCIALS

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 students schedule of classes be printed on the bill. PS does not have this ability as delivered.

Student Payment Plans: FIT: YES Installment Payment Plans 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. OHIOs third party contracts can be processed using PS delivered third party contract functionality.

177

STUDENT FINANCIALS

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, PSs 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 OHIOs 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.

178

STUDENT FINANCIALS

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

179

STUDENT FINANCIALS

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

180

STUDENT FINANCIALS

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.

3Cs 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 OHIOs 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.

181

STUDENT FINANCIALS

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.

182

STUDENT FINANCIALS

SF Integration Points with SR

FIT: YES

There are quite a few integration points between Student Financials and Student Records. At Ohio, since the Registrars 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 OHIOs 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 PSs 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.

183

STUDENT FINANCIALS

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 students 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 Checklist Table Student Fin Installation Keywords SF Account Types Item Types Item Type Groups Tax Transaction Description Set up checklists. Define number sequencing, maximum row settings, edit tables and commit levels. Define and associate keywords with item types to facilitate searches. Define account types to classify item types into usable account groups. Define attributes, posting restrictions, link account types and map chartfields. Define item type groups to limit the application of credits to certain charge items. Define Value Added Tax transaction types.

184

STUDENT FINANCIALS

Codes Tax Authorities Tax Codes Aging Set Late Fees Late Fees Billing Payment Overall Priority Student Permission Forms Charge Priority List Billing and Due Calendars Adjustment Calendars Origin Table External File Layouts Group Type Table SF Term Default Security Views Valid Records Valid Fields Credit Card Type Item Reasons Follow-Up Table Reason Out Fee Classes Void Create tax authority codes to process taxes attached to charges. Define tax codes to link taxes and tax authorities to charge item types. Define aging sets for credit history processing. Create late fee definitions to identify past due charges and assess late fees. Create late fee definitions to identify unpaid billed items and assess late fees. Define the sorting of eligible charges for payment allocation.

Create form for permission to apply restricted credits. Define charge priority lists and rules and link them to item type tree nodes. Create schedules to determine the amount of fees due, the billing and due dates. Define schedules and fees for tuition adjustments for drops and withdrawals. Define sources of receivables posted through group posting. Define the file layout for external charges and payments. Define sets of frequently posted receivables for use in group data entry. Define default terms to populate accounts when term is not used during posting. Review and modify security views for your system. Review valid records used in trigger criteria for tuition calculation. Review valid records, fields and edit tables used in trigger criteria. Define the credit card types the institution accepts for payment. Create codes to provide brief explanations for payment and charge reversals. Create Follow-Up action codes that record the steps needed to resolve accounts. Define codes that identify why the system moved an item out of collections. Define fee classes to enable reporting on specific types of fees. Define codes to provide brief explanations for voided cashiering receipts.

185

STUDENT FINANCIALS

Reasons AP Set Controls Vendor Reason In Liability Status Tuition Calculation Controls Invoice ID Number Billing Type Message Categories Billing Scan Line 1098-T TIN Table AP Business Unit Criteria Invoice Layout Waivers Waiver Groups SpeedTypes Billing Messages Provider Table SF Merchants Optional Fees Coverage and Rates Institutional Contact Combination Period Table Define vendor information. Define codes that identify why the system moved an item into collections. Defines Liability Status Codes as determined by DEST for element 490. Define parameters, rules, errors and warnings used for tuition calculation. Create an unique invoice ID that must appear on your bills. Establish bill types for your institution for students or corporations. Create message categories to be used with billing messages. Create a bill scan line if your bank requires it to track transactions. Set up a tax identification number for filing 1098-T tax forms with the IRS. Define Accounts Payable interface and voucher numbering parameters. Create criteria for tuition groups, fee triggers and waivers. Set of parameters that define invoice information, sorting, and summarization. Define waiver codes to waive or reduce a student's tuition and fee charges. Define waiver groups to attach one or more waivers to class and course fees. Create shortcut keys of chartfields for department receipt entry in cashiering. Create messages that appear on your bills by message categories. Define the International Health Coverage Provider Table. Define ePayment processing rules for different business units, including services performed. Create optional fee codes and values. Define coverage and rates for Providers. Define institutional contact Information. Create a combination period to retrieve consolidated academic statistics.

186

STUDENT FINANCIALS

Collection Letter Template Minimum / Maximum Fees Billing Standard Request Bank Accounts Business Unit Bank Accounts Corporate Course Lists Per Credit Charge StudyLink Institution Defaults StudyLink Posting Parameters Transaction Fees Application Fees Loan Default Optional Fees - Terms SF Business Unit HECS Band Fees Collector Corporate Collection Criteria SF Institution Set Rate Tables for Course

Create templates and delivery schedule of dunning letters for past due accounts. Define ranges for term fees, applications fees and other institutional charges. Define parameters to determine how you identify and bill groups of customers. Bank account information for the business unit is managed from this page.

Bank accounts for External Organizations are managed from this page. Create a group of courses for use with third-party contracts or course fees. Define the Per Credit Charge and Hook on fee defaults for NZQA. Define refund, residency and enrollment parameters for the institution.

Define posting and refund item types for StudyLink. Create transaction fees for adding or dropping classes as of a specific date. Define rules, item types and fees for enrollment applications. Define parameters for HECS HELP, FEE HELP and OS HELP loans. Also defines status change rules for the HECS Reconciliation. Link optional fee codes to terms and assign date parameters. Define the basic business rules for each business unit. Create and define HECS Band Fees. Define and establish collectors within the system. Create a list of corporate collection criteria defined in your system. Define self service ePayment parameters, rules, and usage for one or more business units. Create student criteria to add to the course fee definition.

187

STUDENT FINANCIALS

Fees Corporation Messages Aging Set Messages Customer Message Item and Account Types Identify SA Deduction Codes Term Fees Tuition Groups Deposit Fees Item Type Message Business Unit Message SF Self Service Options Course List Fees Create Deferral Contract Optional Fees per Term Target Keys Class Fees Class Fees Modal Course Fees Course Fees Modal Tender Keys Cashiering Offices Link message(s) that appear on a single corporation when the bill is generated. Link billing messages to specific aging sets and aging categories. Link message(s) that appear on a single student when the bill is generated. Define Item Types and Account Types for the Business Unit.

Define student administration deduction codes. Define term fee codes to link to tuition groups. Create tuition groups to assign a set of fees according to specific rules. Create admission deposit fees, due dates and status changes for payments. Link billing messages to specific item types or ranges of item types. Assign billing messages to business units.

Define business unit information for self service processing. Create fees for all courses within a given course list. Define deferral contract parameters, administrative fees and eligible charges. Define optional fee amounts. Define which charges receive credit for a given transaction. Create fees for particular instances of a course. Create or update fees for classes through the Schedule of Classes. Create or update course fees. Create or update course fees through the Course Catalog. Define the types of tender used in cashiering transactions. Define the characteristics of each cashiering office for the institution.

188

STUDENT FINANCIALS

Service Indicator Sets Valid Registers Valid Cashiers Receipt Print Messages Equation SQL Routines Equation External Subroutines Equation Data Tables Equation Names Equation Test Data

Define sets that automatically attach service indicators during Credit History. Define valid cash registers used in each cashiering office. Define valid cashiers working in each cashiering office. Define messages that appear on printed transaction receipts. Create or edit SQL that can be authorized to be called from an equation. Adds an external cobol routine to the list of routines that can be authorized. Adds a table or view to the list of tables and views that can be authorized. Authorize Equation Access. Set up test data for an equation.

189

PORTAL

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.

190

PORTAL

General Considerations

FIT: N/A

During the pre-implementation phase of OHIOs 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 Oracles PeopleSoft portal, or a freely available open-source product such as uPortal. No consideration will be given to a homebuilt 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

191

PORTAL

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 wont 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

192

PORTAL

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 userspecific 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: Oracles 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 systems users, and based on business needs/requirements for that system: o o o o Identify the broad and granular user communities. Identify sensitive data, indicating that which is common to most of the systems and that which is system-specific. Document desired business process(es) for creating, modifying, and deleting user data. 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 193

PORTAL

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?

194

PORTAL

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.

195

PORTAL

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 A Meaning This requirement is critical to business and must be satisfied in Phase I. This requirement is a must-have, but can slip past the initial go live as long as it is satisfied shortly thereafter. Phase I Priority First

This requirement is a nice to have but will not impact business.

This requirement is not relevant.

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

196

PORTAL

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.

197

BUSINESS INTELLIGENCE

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 OHIOs 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 OHIOs 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 OHIOs 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 198

BUSINESS INTELLIGENCE

System SIS Student Information System SAM Student Aid Management Oracle eBusiness Suite

Description The current Informs student system of record The current financial aid system of record System of record for Financials, Human Resources, Payroll and Project Management for Grants

Data Warehouse Tapes of history PeopleSoft Campus Solutions DARS Degree Audit Requirements System Recruitment Plus Ad Astra CashNet EventsPro (formerly PeopleAdmin)

Workforce Management Software Adirondack BlackBoard Conference Programmer Pitney Bowes Mail BSR Advance TMA Total Maintenance App Facility work orders Space Management Micros Aurora FoodPro Harco Optim Custom Systems OGA Online Grad Appointments EMS Employee Management System IT Systems custom built FileMaker Pro for Telephone Billing Mainframe CMS for Long Distance Billing FootPrints Billing Data 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

Will become the new student and financial aid system of record System of record for transfer credit articulation and degree requirements Student prospect recruiting system Classroom scheduling system Electronic payment (ePay) system Scheduling and mini-registration software used by Continuing Education and Lifelong Learning Time and attendance system Used for housing operations and judicial affairs Course management system Summer conference and guest housing Mailstream software Alumni and development fundraising system ???

Point of Sale software Food Service software Bobcat Cash card ??? Is this Kronos?

Numara?

199

BUSINESS INTELLIGENCE

Database PARIS PCard Hyland OnBase Document Imaging LEO CollegeNet SunGardHE fsaAtlas FoxPro Budget Management JumpTV Event Ticketing Credentials, Inc. Cumulus UCM (L Lockhart)

Purchasing Accounting Reporting Information System for purchasing card transactions Pre- and post-award grant data SEVIS tracking and reporting Budget control values by unit Athletic ticketing Online transcription service, host requests for credentials, forwards to requestor and updates OU regularly

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

BUSINESS INTELLIGENCE

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 standardsdriven. 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 201

BUSINESS INTELLIGENCE

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. OHIOs future direction would be significantly affected by Oracles plans for supporting the EPM Campus Solutions Warehouse, which will presumably be phased out in favor of Oracles newer toolsets.

OBIEE Web Services

OBIEE Analytics Server

ETL Process and Staging area DataStage Campus Solutions Warehouse

Campus Solutions

202

BUSINESS INTELLIGENCE

Architectural Approach 2 The second approach is to follow Oracles strategic direction for Business Intelligence. Oracles 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 OHIOs eBusiness or PeopleSoft modules (except PeopleSoft Campus Solutions). CIBER recommends this approach.
All Source Systems
OBIEE Web Services

OBIEE Analytics Server

Campus Solutions

Campus Solutions

ETL Process and Staging area Informatica Data Warehouse

3.

203

BUSINESS INTELLIGENCE

Functional Approach The most important predictor for a successful Business Intelligence implementation is to resist the temptation to solve all of the institutions 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.

204

BUSINESS INTELLIGENCE

It would be a significant first step to get all of IRs 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.

205

INTERFACES

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 Student Financials Student Records Student Records Student Records Campus Community Recruiting and Admissions/Student Records Student Records Student Records Student Records/Student Financials Student Records Student Records Financial Aid Financial Aid Financial Aid Student Financials Student Financials Financial Aid Student Financials Recruiting and Admissions Student Financials Student Financials Student Financials Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Application Name Oracle Financials CAS National Student Clearinghouse Campus Recreation FSAtlas ID Card System Articulation and Transfer Clearinghouse HC70 (Historic OHIO Electronic Records) (temp) Library Pyramed Function provided Summary Student Revenue Integrate/ Interface

AlcoholEDU Titanium Work-Study Database PACE Database Scholarship Database State of Ohio Office of the Attorney General Campus Partners Change of Income Database Power Park On-Campus Visit Database Sales Point P-Counter Chase Bank OpenNet ScholarNet Oracle HR/Payroll Enrollment Confirmation Database OGA Graduate

206

INTERFACES

Financial Aid Student Records Student Records Student Financials Student Financials, Person Data Financial Aid Financial Aid Student FinancialsRecords Academic Advising Recruiting &and Admissions Recruiting &and Admissions Recruiting &and Admissions Recruiting &and Admissions, Registrar, Financial Aid Student Records Academic Advising Recruiting &and Admissions Recruiting &and Admissions Recruiting &and Admissions Recruiting &and Admissions (Med) Recruiting &and Admissions (Med)

Appointments/Fellowships Database Biennial Budget Survey Database

Blackboard SCT BSR Advance CASHNet Adirondack SIGMA SAM (temp)

LMS Alumni Contributions Student Payment Housing and Judiciaries Financial Aid

AD Astra DARS CollegeNet Degree Audit Online Application

CollegeNet -- Contact Manager Highland OnBase Acalog

Recruiting

Imaging and Workflow

Hobsons EMT (interface with Recruitment Plus) Continuum 422 Event Management AACAMAS Recruitment Plus

Chat Campaigns

Online admissions Student recruiting

207

INTERFACES

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 ACADEMIC STRUCTURE

SECTION
Department Table

INTERFACE
Departments- possibly parking and internal organizations in the University - interfaces with Student Financials. A question was raised if OHIO decides to retain DARS, how will the Plans and Subplans be translated to DARS for processing the appropriate degree requirements?. Interface Management Services is working with CIBER at UT Dallas on developing this interface. 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). OHIO may need to interface to the NCAA's Compliance Assistant Internet (CAI). Residency logic will need to be revisited and reestablished in the interface with CollegeNET to PS.

Academic SubPlan Table

CAMPUS COMMUNITY

Identify any major systems that may be retained and will need student data feeds Personal Information / Biographical Identification

RECRUITING / ADMISSIONS

FINANCIAL AID

Financial Aid Terms

Awarding/Mass Packaging Awarding/Mass Packaging

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. An interface to the current Online Graduate Appointments (OGA) will need to be built. 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

208

INTERFACES

Perkins

Student Employment Student Employment Set up Attendance Tracking Set up Special Grade Point Averages

that matches the waiver and if not then the OGA interface creates a new account code that will handle the new waiver. Perkins will need to have a custom interface with the servicer of the loans (Campus Partners). 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. Develop an interface between the ID Card system and PS Attendance Tracking OHIO needs an interface to load and store special GPAs from DARS for GPA in major.

STUDENT RECORDS

ACADEMIC ADVISING

Course Applicability System (CAS Calculating Tuition, Fees, & Waivers: Term Fees Student & Third Party Account Maintenance: Origins & Group Types Student & Third Party Receipts:

STUDENT FINANCIALS

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 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. Residence and Dining Hall charges will not be handled via Term Fee functionality in PS. These Residence and Dining Hall charges will most likely be posted via an interface with the new housing system or via External File Load, Group Post in PS. One of each will also need to be set up for Housing if housing is going to interface using the External File Load, Group Post functionality. Although CASHNet has a very good reputation for working with clients and getting their software interfaced with PS, 209

INTERFACES

Online Payments & Cashiering Student & Third Party Receipts: Departmental Receipts Student, Parent, & Third Party Refunds: Refunds Student Financials Interfaces

Student Financials Interfaces

Student Financials Interfaces Student Financials Interfaces Student Financials Interfaces

Student Financials Interfaces Student Financials Interfaces

this will be included in the interfaces section of this analysis CASHNet has the ability to interface with Oracle Financials for those departmental receipts that need to be fed straight to the GL rather than being posted to a student or third party account. There will need to be a major development effort to both modify and interface the PS Campus Solutions refunding process with the Oracle systems that OHIO uses for Accounts Payable and HR/Payroll. OHIO currently uses CASHNet for online payments, cashiering, and eBill presentment. CASHNet has worked with PS to deliver the application interfaces to Student Financials. Adirondack Housing Management System OHIO thinks that Adirondack has worked with PS on interfacing the two systems. OHIO needs to confirm whether or not the interface pieces already exist or whether they will need to be built. OHIO is in the process of upgrading to the latest PowerPark parking management system (T2 Systems). OHIO will need to determine how it wants to interface this application to Student Financials. OHIO will need to determine if it wants to interface any library transactions with Student Financials. If so, this interface will have to be developed Health Center / Pharmacy / Diagnostic Services & Immunizations -- OHIO will need to determine if it wants to interface any of these transactions with Student Financials. If so, this interface will have to be developed SoftCash Software Sales Application OHIO will need to determine if it wants to interface any of these transactions with Student Financials. If so, this interface will have to be developed OHIO currently charges students for printing on a monthly basis. OHIO will need to determine if it wants to interface any of these transactions with Student Financials.

210

INTERFACES

Student Financials Interfaces Processing GL Accounting Entries

SF Integration Points with AD

SF Integration Points with SR

SF Integration Points with FA

If so, this interface will have to be developed OGA Online Graduate Awarding System It was determined that OHIO will keep this application and that a complex modification/interface will need to be developed to replace the existing interfaces. OHIO uses Oracle Financials. most likely OHIO will need an interface developed to actually get the accounting entries into Oracle Financials. 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. 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. the OGA system will need to interface with PS Financial Aid and Student Financials.

211

MODIFICATIONS

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 ACADEMIC STRUCTURE

SECTION Load/Level Rules

GAP
Ohio University may need minor modification to Academic Level Translates to reflect various Graduate levels. 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. The length of the Formal Description field is only 50 characters. OHIO has degree names longer than 50 characters. A process to switch preferred flag to campus email address is needed. A Gap resides in associating committees to publications and thesis tracking. Ability to exclude charges from old calc (bursars office) does Not Fit. There is a Gap in notification of address update so hold can be released: out of state address changes trigger hold. This is a gap for financials and admissions No automation between assigning/completing checklists and the placing/removal of holds. OHIO wishes to provide more detailed

Career Pointer Exceptions

Degree Table

CAMPUS COMMUNITY

Personal Information / Biographical Participation Service Indicators / Holds Service Indicators / Holds

Checklist Table, Items, Function Items, Managing Checklists

212

MODIFICATIONS

Checklist Table, Items, Function Items, Managing Checklists Events

Student Service Center

SEVIS

information in the description section. Possible Customization: Some due dates may need to be masked in the "to do" section of Self-Service The events module does not meet the needs of the OHIO Admissions offices which conduct the majority of events. 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. 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

Financial Aid Terms

Financial Aid Terms Institutional Student Information Record (ISIR) Processing

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 Automatic updates of enrollment for upcoming quarters and the ability to lock enrollment and campus are not current functionality in PS. Possible Gap There is no field displaying a prior degree value for a student other than the ISIR. OHIO requires that this be an automatic process for sending and receiving ISIR data and not a manual process.

213

MODIFICATIONS

Institutional Student Information Record (ISIR) Processing

Verification

Student Budgets

Awarding/Mass Packaging Awarding/Mass Packaging

Awarding/Mass Packaging Awarding/Mass Packaging Awarding/Mass Packaging

Awarding/Mass Packaging Authorization/Disbursement Pell Payment Processing Pell Payment 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 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. Ability to lock certain budget categories while allowing others to be rebuilt when there are changes to enrollment, etc Waivers Graduate Studies GAP HIGH 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. Continuing Education Waiver it is recommended that this be combined with the OGA modification Spousal Awards will need to be combined with the OGA modification. 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. Ability to generate report on what items have been disbursed for a particular day. Pell data is sent to COD System in an automated process which will need to be developed in PS Possible Gap - OHIO only originates those students Pell awards if they have been disbursed for the quarter. PS does not have the functionality to

214

MODIFICATIONS

Loan Processing Loan Processing

Satisfactory Academic Progress (SAP) Satisfactory Academic Progress (SAP)

STUDENT RECORDS

Review / Define Student Records Installation settings Define Class Notes

Define Class Notes Define Facilities and Rooms Define Facilities and Rooms Requirement Designation

Define Standard Meeting Patterns

trigger origination from the action of having been disbursed. Direct Loan data is sent to COD system in an automated process which must be developed in PS OHIO originates loans that are in an accepted status for students preregistered for the term or for loans that are offered for the term, even if the student is not pre-registered. Undergraduate SAP policy: maximum time frame for degree completion based on level of study and degree plan. Graduate SAP policy: maximum time frame for degree completion based on Master level graduate students and degree plan. OHIO calculates and displays the GPA to four decimal places, but truncates to three decimal places on reports. In PS the delivered Self Service controls for Class Search do not offer the option to display course or class fees. OHIO would like Class Notes with hyperlinks for further information about the class. There is nothing in PS to prevent the Registrar from scheduling classes without departmental permission. There is nothing delivered that associates a contact person for a scheduler in the Facility Component. 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. 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

215

MODIFICATIONS

Define Repeat Rules

Define Repeat Rules Define Enrollment Requirements Set up Attendance Tracking

Set up Attendance Tracking

Create Academic Standing Rules Create Academic Standing Rules

Create Academic Standing Rules Create Academic Standing Rules

Create Academic Standing Rules

courses. OHIOs 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. OHIO needs to be able to track each occurrence of a course that has been repeated for credit. OHIO has a process that runs quarterly to drop students who fail to meet the prerequisites based on the final grades for the term. PS provides a table for storing attendance data but there are no workflow processes delivered around the attendance tracking system. If a student is identified as not attending a class, there is no delivered functionality to alert an advisor, etc OHIO uses Deficiency Points as a key element in calculating academic standing. This functionality does not exist in PS. Some departments at OHIO manually calculate a separate academic standing for individual colleges based on a subset of courses taken only in the college or the major. Academic standing for the full-time undergraduate career differs from that for the part-time undergraduate career. If a student cant pass a class within a certain number of tries, they are dismissed from the major. A C or better counts. Also, WF, FS, and F grades count as attempts. A D can count in some attempts. OHIO produces a report, which is distributed to Departments that lists students who have not met the

216

MODIFICATIONS

Set up Special Grade Point Averages Define Grading Schemes Define Grading Schemes

Define Grading Schemes

Define Grading Schemes Define Grading Schemes Define Grading Schemes Create Grade Rosters for a Single Class

Create Grade Rosters for a Single Class

Create Grade Rosters for a Single Class

status of Good Standing. . PSs Academic Standing process posts the standing online when run. There is no delivered report only option. OHIO needs a way to store external cumulative hours attempted, and external cumulative grade points. OHIO needs the ability to default grades in certain classes, such as audit and dissertation. OHIO needs to be able to track multiple grade changes prior to the grades being posted to the students 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 OHIO tracks the last date of attendance for a student with an FS grade for identifying unofficial withdrawals. PS does not have this feature. There is no delivered process in PS to automatically assign a grade of NR where a blank exists. Ability to load grades directly from BlackBoard into PS Ability to import grades from Excel into PS OHIO needs to be able to recreate grade rosters after the initial creation to bring in students who dropped or were added after grade roster creation. OHIO needs the ability for the instructor to enter a date for the Last Date of Attendance on the grade roster when they assign a FS grade. OHIO needs the ability for the instructor to enter a P or F grade on a student who has an existing W grade.

217

MODIFICATIONS

Create Grade Rosters for a Single Class Create Grade Rosters for a Single Class

Create Grade Rosters for a Single Class Define Transcript Types

Define Transcript Types

Modify Scheduled Classes Modify Scheduled Classes

Modify Scheduled Classes Modify Scheduled Classes

Define Class Associations

Search for Available Facility

OHIO wants to suppress access to the Transcript Notes link on the grade roster. OHIO requires a process to identify missing grades. Current functionality identifies classes with missing grades and notify faculty. Confirmation email sent to faculty once roster has been completed OHIO emails grades to students once posting period is over OHIO prints a transfer credit summary that includes the transfer institutions name, years of attendance, and total hours transferred When a student requests a transcript, OHIO permits the student to identify a specific course for which they are expecting a grade change. OHIO wants to be able to control who can modify fields on this page on a field by field basis. 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 When a class is canceled PS does not provide automatic notification to the students . 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 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 OHIO currently has the ability to search for a facility by entering the class which needs a facility. Class

218

MODIFICATIONS

Search for Classes Print the Schedule of Classes Report Copy Classes from one Term to Another Understand Program Action and Statuses

Maintain Student Program Information

Maintain Student Program Information

Maintain Student Program Information

Maintain Student Program Information Maintain Student Program Information Maintain Student Program Information

information is pre-populated into the search. The delivered process is not as feature-rich as OHIOs current Search for Classes. The PS report does not provide the level of detail OHIO currently provides in the Schedule of Classes. OHIO has different roll rules for different groups of classes and the set up to handle this might be tedious. A college/department is not allowed to do a program change from NonDegree 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. OHIO wants the date, time, and User ID (i.e., last user) who updated the Program/Plan stack to be tracked and displayed. PS does not display the date, time, and User ID on the online display for Student Program/Plan. In PS the Career Requirement Term field is populated manually. OHIO needs a process to populate this field based on the term in which the students first classes for that career occurred OHIO needs an automated process to populate and keep current the Expected Grad Term. This is required for SEVIS, National Student Clearinghouse, and financial aid. OHIO needs a process to automatically discontinue students. OHIO needs a process to populate and keep current the Campus field. A student may relocate from one campus to another by registering for classes on a different campus. The students record needs to

219

MODIFICATIONS

automatically be updated based on where the student is registered for classes

ACADEMIC ADVISING

Requirement Terms

Requirement Functionality

Transfer Coursework

In-Progress Credit

In-Progress Credit

What-If Report

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. 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 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. PS does not permit the display of InProgress 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. OHIO also has an option to allow inprogress 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 analysis does not indicate that program may have application process.

220

MODIFICATIONS

STUDENT FINANCIALS

To run a What-If report, an advisor or student would need to enter the appropriate requirement term(s). OHIOs current What-If process will default the appropriate term based on the student and terms available for the program being run PS provides the ability to query Analysis Table based on the completion of an entire program, but not individual program requirements Calculating Tuition, Fees, & Because Equation Engine is a delivered PS tool, this is not a Gap. Waivers: Term Fees However, it will require a fair amount of technical programming to make this happen. Calculating Tuition, Fees, & For a number of reasons, the Waivers: Transaction Fees Transaction Fee functionality in PS is not generally usable. PSs Late Fee functionality does Student & Third Party NOT fit the requirements for this late Account Maintenance: fee. Late Payment Fees While PS will allow OHIOs FA office Student & Third Party to create a batch of transactions to Account Maintenance: Group Posting Financial Aid be posted to the student accounts, PS does not deliver a way to have Batches those batches automatically posted to the student accounts. If OHIO decides that they want to Student & Third Party use PS Self-Service and discontinue Billing: Student Billing the use of CASHNet, there will need to be modifications to send out emails about account balances, payment deadlines, etc. There would also need to be a modification in PS to allow Authorized Users,, such as a parent or guardian, to see certain student information and to do certain student tasks. The PS student billing functionality Student & Third Party does not have any automated email Billing: Student Billing 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

What-If Report

221

MODIFICATIONS

Student & Third Party Billing: Third Party Billing Student Payment Plans: Payment Plan Late Fees

Third Party Contracts: Third Party Contract Rollover Student, Parent, & Third Party Refunds: Refunds

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 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. OHIO charges a late fee for late installment payments. The PS delivered Payment Plan functionality does not include late fee functionality. There is no ability in PS to roll a third party contract from one term to another. PSs 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.. OHIO probably needs a modification that would automate the notification process and track students through the collections process

Student & Third Party Aging & Collections: Account Collections Process OHIO will keep OGA and a Student Financials modification/interface will need to be Interfaces Tax Reporting Tax Reporting Service Indicators for SF

developed to replace the existing interfaces. 1042 Non-Resident Alien Tax there is no delivered PS process to handle taxes for Non-Resident Aliens. OHIO will need to decide if it wants to use the PS delivered 1098-T process or develop a process. PS does not have any delivered functionality that would allow these

222

MODIFICATIONS

Self-Service for SF

SF Integration Points with AD

SF Integration Points with FA

service indicators to be removed real-time. OHIO will need a self-service modification to allow authorized users to log in. PS does not have the ability to identify authorized users. 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. PS does not deliver a way to have batches automatically posted to the student accounts.

223

MODIFICATIONS

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
ACADEMIC STRUCTURE
Academic Level Translates to reflect various Graduate levels

MINOR X X

MEDIUM

MAJOR

N/A

CAMPUS COMMUNITY
Switch preferred flag to campus email address Associate committees to publications and thesis tracking Exclude charges from old calc Notification of address update so hold can be released: Automation between assigning/ completing checklists and the placing/removal of holds Events module does not meet the needs of Admissions Have students see DOB but no change, update FERPA restrictions, update preferred name/no edits on others Student work hours for international student employees

X X X X X X X X X X X X X X X X

ADMISSIONS
Load Compass, or IELTS scores Data entry screen for the application process Physical mailers for checklists items Auto admissions decision program Cumulative attempted academic GPA for admission decision purposes. Clearing House XML-Translation program Calculate and store the quality point deficit a student may have A 'fetch feature' to auto-populate the manual course credits screen. Real time processing between OnBase and PeopleSoft

224

MODIFICATIONS

FINANCIAL AID
Projected enrollment data used prior to term until point of disbursement for term. At point of disbursement, actual enrollment is used Mechanism to lock enrollment and campus of attendance for any term that has not yet begun. Automate message class batch loading. Send corrections need to be an automated process in uploading the generated file EFC proration change nightly for a student based on projections of their terms attending INAS calculation to run nightly ISIR - apply appropriate checklist item during ISIR load process Permanent checklists carried with student record Lock only certain adjustments to budgets Show award messages to students in self-service Campus or location should be an indicator Report on items disbursed for a particular day Pell data sent to COD System in an automated process Direct Loan data sent to COD system in an automated process Originate loans in an accepted status for students pre-registered Maximum time for degree completion based on level of study Maximum time for degree completion based on Master level students and degree plan Custom interface to load amount student earned in work study for the FISAP report If account code in FA matches the waiver an OGA interface should create a new account code

X X X X X X X X X X X X X X

X X X

STUDENT RECORDS

225

MODIFICATIONS

In PS the delivered Self Service controls for Class Search do not offer the option to display course or class fees. OHIO would like Class Notes with hyperlinks for further information about the class. There is nothing in PS to prevent the Registrar from scheduling classes without departmental permission 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. OHIO has a process that runs quarterly to drop students who fail to meet the prerequisites based on the final grades for the term. OHIO produces a report, which is distributed to Departments that lists students who have not met the status of Good Standing. . PSs Academic Standing process posts the standing online when run. There is no delivered report only option. OHIO needs a way to store external cumulative hours attempted, and external cumulative grade points OHIO needs the ability to default grades in certain classes, such as audit and dissertation. OHIO needs to be able to track multiple grade changes prior to the grades being posted to the students 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 OHIO tracks the last date of attendance for a student with an FS grade for identifying unofficial withdrawals. PS does not have

226

MODIFICATIONS

this feature. Ability to load grades directly from BlackBoard into PS Ability to import grades from Excel into PS OHIO needs to be able to recreate grade rosters after the initial creation to bring in students who dropped or were added after grade roster creation. OHIO wants to suppress access to the Transcript Notes link on the grade roster. OHIO requires a process to identify missing grades. Current functionality identifies classes with missing grades and notify faculty. Confirmation email sent to faculty once roster has been completed When a class is canceled PS does not provide automatic notification to the students . 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 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 The PS report does not provide the level of detail OHIO currently provides in the Schedule of Classes. 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 students first classes for that career occurred OHIO needs an automated process to populate and keep current the Expected Grad Term. This is required for SEVIS, National Student Clearinghouse, and financial aid.

X X

227

MODIFICATIONS

OHIO needs a process to automatically discontinue students.

X X

OHIO needs a process to populate and keep current the Campus field.
A student may relocate from one campus to another by registering for classes on a different campus. The students record needs to automatically be updated based on where the student is registered for classes ACADEMIC ADVISING Populate career requirement term Major must be completed in residence function for calculating a percentage of hours. Requirement Designations must be built Flag set at time audit is processed Location of Academic Plan type Query based on completion of an entire program and individual program requirements STUDENT FINANCIALS Calculate and post transaction fees automatically and on a scheduled basis. Late fee charged once per term based on late payment criteria. Automate posting process as soon as new FA batch has been created Send out emails about account balances, payment deadlines, Allow Authorized Users, to see certain student information Delivered bill will need to be modified to be usable. 3rd party bill modified to fit the requirements of 3rd party sponsors. Automate late fee assessment. Refund process with Oracle for Accounts Payable and HR/Payroll. Automate notification process and track students through collections.

X X, X X X X

X X X X X X X X X X

228

MODIFICATIONS

OGA Online Graduate Awarding System Setup fields and interface to get accounting entries into Oracle Financials. 1042 Non-Resident Alien Tax 1098-T Tax Allow service indicators to be removed real-time Allow authorized users to log in and to do certain tasks. Requirement designations must be built Only housing students that have paid a housing deposit can get a final admit status and enroll. Allow in-progress to count on the audit assuming successful completion. 49 TOTAL ITEMS

X X X X X X X X X 21 19 9

229

CONVERSION

Section 15 Conversion Issues identified during Fit/Gap

MODULE ACADEMIC STRUCTURE SECTION Installation Table CONVERSION ISSUE Once the production environment is established, the Last ID Assigned will need to be reset when conversion occurs. 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 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 Table needs further review so that codes/names/info loaded into PS is "clean" data. 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 there needs to be a separate meeting with ID management and the PS team Oracle HRMS stores particular certifications (SPR, etc.). Faculty memberships are stored in a local area, which may not go directly into PS. OHIO needs to determine whether a co-curricular transcript will be generated. OHIO will need to link committees to publications for dissertation/thesis, and would like to individually track theses/committees for those enrolled in

Term Values Table

Term Values Table

CAMPUS COMMUNITY

Data Mapping for Conversion

Organization Table Build

Shared Tables with HR

Identification

Participation

Participation

Participation

230

CONVERSION

Standard Letters

Communication Management

Comment, Categories, 3C Groups

Comment Management

Communication Generation

Conversion Issues

Conversion Issues

Conversion Issues

Conversion Issues

multiple programs. Communication history will need to be moved into PS from 3rd party 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. 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 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 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. Organizations can be categorized into groups to assist in identifying organizations conveniently for recruitment. 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 External Org Code Type Table - This is used with College Board EPS market codes, and can be used for CB GeoDemographic analysis. 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

231

CONVERSION

Conversion Issues

Conversion Issues

Conversion Issues

Conversion Issues

Conversion Issues

FERPA

FERPA

SEVIS RECRUITING / ADMISSIONS

credit purposes. 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 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. Contacts can be added to an organization; look at service area first and then grow from there 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. HR needs to be at conversion meeting to establish interaction with their records and databases. 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. getting information that is held only in Financial Aid and Oracle HRMS; OHIO needs to track start/end-date of employment for international students.

FINANCIAL AID STUDENT RECORDS Repeat Schemes and Repeat Codes

Create Course Equivalency Groups

No conversion issues identified For conversion purposes, any data converted from prior to 1993 must include handling the deduction flag properly. During conversion to PS, legacy course equivalencies will be converted to Effective Dated Course changes to the same course 232

CONVERSION

ACADEMIC ADVISING STUDENT FINANCIALS Student & Third Party Account Maintenance: Origins & Group Types Student Financials Conversions

No conversion issues identified 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. PS recommends using the delivered External File Load, Group Post process to load student and third party account balances for conversion.

233

APPENDIX

Section 16 Appendices
18.1 Reporting 18.2 Support Document for Converting Holds 18.3 Complete Table Loading Sequence

234

APPENDIX

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.

235

APPENDIX

18.2 Support Document for Converting Holds And Mapping to Developed PeopleSoft Service Indicators
HOLD CODE A&S College of Arts and Sciences Approved: Academic Advancement Center ACADEMIC ADVANCEMENT CNTR HOLD

HOLD NAME

REGIST RATION

GRAD ES

DIPLO MAS

TRANS CRIPTS

ADMISS IONS

AADV

ACADEMIC ADVISING

AACT

Approved: Athens Admissions Office Approved:

CAP

AAD M

ADM BDM LGLA SXTY

ADMISSIONS CREDENTIALS HOLD BRANCH ADM CREDENTIALS HOLD HOLD PER LEGAL AFFAIRS SIXTY PLUS PROGRAM HOLD

Y Y Y Y

N N N N

N N N N

N N N N

Y Y N N

AADV

Athens Academic Advisor Approved: Accounts Receivable Approved:

AADV

ACADEMIC ADVISING

ACR C

AGB ARAD AREC

ATHENS GENERAL BALANCE HOLD ACCTS RECEIV INCORRECT ADDRESS ATHENS ACCTS RECEIVABLE HOLD

Y Y Y

Y Y Y

Y N Y

Y Y Y

Y Y Y

ALIB

Alden Library Approved: Approved: 11/10/2005 ALIB FLIB ILIB MLIB ATHENS ALDEN LIBRARY HOLD 2ND FL REFERENCE DESK INSTRUCTIONAL MEDIA ATHENS MUSIC LIBRARY HOLD Y Y Y Y N N N N Y Y Y Y Y Y Y Y Y Y Y Y

236

APPENDIX

RLIB Approved: 11/10/2005 ARE G TLIB

IDC DESK 2ND FL COMPUTER CONCOURSE

Y Y

N N

Y Y

Y Y

Y Y

Athens Registrar Approved: Approved: 5/23/2006 GRAD LGLA LGL2 RCON REC REC2 REG REG2 REGD RESS SXTY TRAN SPEC GRADUATION HOLD FOR JANE HOLD PER LEGAL AFFAIRS LEGAL AFFAIRS II HOLD FINANCIAL CONVERSION REGISTRAR/RECORDS SPECIAL RECORDS HOLD FOR PJB ATHENS REGISTRARS OFFICE HOLD ATHENS REGISTRARS OFFICE HOLD DECEASED STUDENT HOLD INVALID SOCIAL SECURITY NUMBER SIXTY PLUS PROGRAM HOLD TRANSCRIPT HOLD N Y N Y N Y Y Y Y Y Y N N N Y Y Y N Y Y Y Y N N Y N Y Y Y N Y Y Y Y N N Y N Y Y Y N Y Y Y Y N Y N N N Y N N Y Y Y Y N Y

BADV

Branch Advisor Approved:

BADV

BRANCH ADVISING HOLD

BUR S

Bursar Approved: 6/18/2001

AGO APTP APTR BAD2 BAD3 BAD4 BAD5 BADC BAK2 BAK3

ATTORNEY GENERALS OFFICE APARTMENT PENALTIES APARTMENT RENT ATHENS BAD CHECK HOLD # 2 ATHENS BAD CHECK HOLD # 3 ATHENS BAD CHECK HOLD # 4 ATHENS BAD CHECK HOLD # 5 ATHENS BAD CHECK HOLD ATHENS BAKER CENTER HOLD # 2 ATHENS BAKER CENTER HOLD # 3

Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y

237

APPENDIX

BAK4 BAKE BDAD BURX CA DDA2 DDA3 DDA4 DDAM EXT2 EXT3 EXT4 EXTN GRDS HPL LDS LGTM LOAN MIS2 MIS3 MIS4 MISC MPA2 MPA3 MPA4 MPAY NSL PERK PHON PKG PKG2

ATHENS BAKER CENTER HOLD # 4 ATHENS BAKER CENTER HOLD BURSAR INCORRECT ADDRESS SPECIAL BURSAR BURSAR FINANCIAL HOLD DORMITORY DAMAGE HOLD # 2 DORMITORY DAMAGE HOLD # 3 DORMITORY DAMAGE HOLD # 4 DORMITORY DAMAGE ATHENS OVERDUE EXT BAL HOLD #2 ATHENS OVERDUE EXT BAL HOLD #3 ATHENS OVERDUE EXT BAL HOLD #4 OVERDUE EXTENDED BALANCES GRADE HOLD HEALTH PROFESSIONAL LOAN HOLD LOANS DISADVANT-AGE STUDENTS LONG TERM LOANS OVERDUE EMERGENCY LOAN ATHENS MISC HOLD # 2 ATHENS MISC HOLD # 3 ATHENS MISC HOLD # 4 ATHENS MISC HOLD MONTHLY PAYMENT PLAN HOLD # 2 MONTHLY PAYMENT PLAN HOLD # 3 MONTHLY PAYMENT PLAN HOLD # 4 MONTHLY PAYMENT PLAN NURSING STUDENT LOAN HOLD PERKINS HOLD PHONE SYSTEM HOLD UNIV PARKING VIOLATIONS UNIV PARKING VIOLATION HOLD #2

Y Y Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

Y Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

Y Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

238

APPENDIX

PKG3 PKG4 SHTM TEL College of Business Approved: Chemistry and Biochemistry Approved: Chillicothe Library Approved: College of Communication Approved: Counseling & Psychological Services Approved: CRE G Chillicothe Registration Approved: CGB CLNS Disbursements/L oan Approved: HPL CPSY CLIB

UNIV PARKING VIOLATION HOLD #3 UNIV PARKING VIOLATION HOLD #4 SHORT TERM LOAN HOLD ATHENS TELEPHONE HOLD

Y Y Y Y

Y Y Y Y

Y Y Y Y

Y Y Y Y

Y Y Y Y

CBA

AADV

ACADEMIC ADVISING

CHE M

KEYS

CHEMISTRY KEYS

CLIB

CHILLICOTHE LIBRARY HOLD

COM

AADV

ACADEMIC ADVISING

CPS

COUNSELING PSYCHOLOGY SER HOLD

CHILLICOTHE GEN BALANCE HOLD CHILLICOTHE DEL LOAN HOLD

Y Y

Y Y

Y Y

Y Y

Y Y

DISB

LDS LGTM MISC NSL

HEALTH PROFESSIONS LOAN PROG LOAN FOR DISADVANTAGED STUDENT LONG TERM LOAN MISCELLANEOUS NURSING STUDENT LOAN PROGRAM

Y Y Y Y

Y Y Y Y

Y Y Y Y

Y Y Y Y

Y Y Y Y

239

APPENDIX

PERK SHTM College of Education Approved: Eastern Library Approved: College of Engineering and Technology Approved: Approved: 11/3/2004 Eastern Registration Approved: EGB EIGB ELNS EMD College of Fine Arts Approved: Graduate Appointments Approved: Graduate Student Services Approved:

PERKINS LOAN PROGRAM SHORT TERM LOAN

Y Y

Y Y

Y Y

Y Y

Y Y

EDU

AADV

ACADEMIC ADVISING

ELIB

ELIB

EASTERN LIBRARY HOLD

ENT

AADV KEYS

ACADEMIC ADVISING ENGINEERING KEYS FOR STOCKER

Y Y

N Y

N Y

N Y

N N

ERE G

EASTERN GEN BALANCE HOLD EASTERN INCARCERATED GEN BAL EASTERN DELINQUENT LOAN HOLD MEDIA-ASSISTED COURSES

Y Y Y Y

Y Y Y Y

Y Y Y Y

Y Y Y Y

Y Y Y Y

FAR

AADV

ACADEMIC ADVISING

GAP P

CONT

GA CONTRACT PROBLEM

GSS

AADV ACCD AFEE CONF

Approved: 5/30/2001

CRED FIND I9

ACADEMIC ADVISING ACADEMIC DROP FROM PROGRAM APPLICATION FEE NO CONFLICT OF INTEREST FORMS CREDENTIALS INCOMPLETE FINANCIAL DOCUMENTS EMPLOYMENT ELIGIBILITY

Y Y Y Y Y Y Y

N N N N N N N

N N N N Y N N

N N N N Y N N

N N N N N N N

240

APPENDIX

Approved: 4/29/2005

ICRD NSHO REER RESI SEVI TRAN

INTL CREDENTIALS INCOMPLETE NO SHOW DEPARTMENT REENROLL HOLD RESIDENT DOCUMENTS SEVIS NO OFFICIAL TRANSCRIPT

N Y Y Y Y Y

N N N N N N

Y N N N N N

Y N N N N N

N N N N N N

HHC

Hudson Health Center Approved: MDC O MDTS MDW D MEDICAL CONVERSION MEDICAL TESTING HOLD MEDICAL WITHDRAWAL HOLD Y Y Y N N N N N N N N N Y N Y

HHS

College of Health and Human Services Approved:

AADV

ACADEMIC ADVISING

HOU S

Housing Approved: CONV HOUF HOUS Historic Imaging Project Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 IMAGING CONVERSION HOLD D ATHENS HOUSING FINANCIAL HOLD ATHENS HOUSING HOLD Y Y Y N N N N N N N N N Y Y Y

HSTR

AREG BURS CLIB CREG DISB EREG HHC JUDI LREG

ATHENS REGISTRAR HOLD BURSAR CHILLICOTHE LIBRARY HOLD CHILLICOTHE REGISTRATION DISBURSEMENT/LOAN EASTERN REGISTRATION HUDSON HEALTH CENTER JUDICIARIES LANCASTER REGISTRATION

Y Y Y Y Y Y Y Y Y

Y Y N Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y

241

APPENDIX

Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 Approved: 5/22/2001 Honors Tutorial College Approved: Intercollegiate Athletics Approved: Ironton Library Approved:

SFA SLIB SREG ZLIB ZREG

FINANCIAL AID SOUTHERN LIBRARY HOLD SOUTHERN REGISTRATION ZANESVILLE LIBRARY HOLD ZANESVILLE REGISTRATION

Y Y Y Y Y

Y N Y N Y

Y Y Y Y Y

Y Y Y Y Y

Y Y Y Y Y

HTC

AADV

ACADEMIC ADVISING

ICA

AADV

ACADEMIC ADVISING

ILIB

CONV ILIB

IMAGING CONVERSION HOLD IRONTON LIBRARY HOLD

Y Y

N N

Y Y

Y Y

Y Y

INDS

Independent Study Approved: 5/31/2001 Institutional Equity Approved: 9/4/2001 Center for International Studies Approved: Ironton Registration Approved:

ISGB

INDEPENDENT STUDY GENERAL BAL

INEQ

EQIP

INSITUTIONAL EQUITY EQUIPMENT

INST

AADV

ACADEMIC ADVISING

IREG

CONV IGB ILNS

IMAGING CONVERSION HOLD IRONTON GEN BALANCE HOLD IRONTON DELINQUENT LOAN HOLD

Y Y Y

Y Y Y

Y Y Y

Y Y Y

Y Y Y

IRON

Southern

242

APPENDIX

Campus Approved: International Student and Faculty Services Approved: ISHI SEVI VISA VISR INTERNATIONAL HEALTH INSURANCE SEVIS VISA PROBLEM VISA PROBLEM Y Y Y Y N N N N N N N N N N Y N N N N N BADV ACADEMIC ADVISING HOLD Y N N N N

ISFS

JUDI

University Judiciaries Approved: DIS2 DIS3 DISC Office of Legal Affairs Approved: 5/16/2000 Lancaster Library Approved: CONV LLIB Lancaster Registration Approved: CONV LCC LGB LIGB LLNS IMAGING CONVERSION HOLD LANC CHILD CARE CHARGE LANCASTER GEN BALANCE HOLD LANCASTER INCARCERATED GEN BAL LANCASTER DELINQUENT LOAN HOLD Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y IMAGING CONVERSION HOLD LANCASTER LIBRARY HOLD Y Y N N Y Y Y Y Y Y JUDICIAL-HOLD ALL TRANSACTIONS JUDICIAL-HOLD REGISTRATION JUDICIAL DISCIPLINARY HOLD Y Y Y Y N N Y N N Y N Y Y N Y

LGAF

LGAF

OFFICE OF LEGAL AFFAIRS

LLIB

LREG

M SC

Military Science Approved: 5/18/2000

EQIP

MILITARY SCIENCE EQUIPMENT

243

APPENDIX

Approved: 5/18/2000 NSH O

SCHL

MILITARY SCIENCE SCHOLARSHIP

No Show Approved:

NSHG NSHM NSHU

NO SHOW - GRADUATE NO SHOW - OSTEOPATHIC MEDICINE NO SHOW UNDERGRADUATE

Y Y Y

N N N

N N N

N N N

Y Y Y

OPIE

Ohio Program of Intensive English Approved: OADV OPIE ACADEMIC ADVISING HOLD Y N N N N

OSR C

Osteo Records Approved:

HEAL ODEL

OSTEO HEAL DEFAULT OSTEO DELINQUENT LOAN HOLD

Y Y

N N

Y Y

Y Y

Y Y

OST

College of Osteopathic Medicine Approved:

AADV CONV LOAN

ACADEMIC ADVISING IMAGING CONVERSION HOLD OVERDUE EMERGENCY LOAN

Y Y Y

N Y Y

N Y Y

N Y Y

N N N

PING

Ping Recreation Center Approved: NPIP NREQ VAND Portsmouth Library Approved: PLIB PORTSMOUTH LIBRARY HOLD Y N Y Y Y NON PAYMENT OF ITEM PURCHASE NON RETURN OF EQUIPMENT VANDALISM,MISUSE OF EQUIPMENT Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

PLIB

PRE G

Portsmouth Registration Approved: PGB PORTSMOUTH GEN BALANCE HOLD Y Y Y Y Y

244

APPENDIX

PLNS Regional Higher Education Approved:

PORTSMOUTH DEL LOAN HOLD

RHE

AADV RHEP

ACADEMIC ADVISING PROBATION

Y Y

N N

N N

N N

N N

SEVI

Sevis Approved: Student Financial Aid Approved:

SEVI

SEVIS

SFA

GSL HPL LDS LGTM NEXT NSL PERK QAP RPAY SCON SHTM

GUARANTEED STUDENT LOAN HOLD HEALTH PROFESSIONAL LOAN HOLD LOANS DISADVANT-AGE STUDENTS LONG TERM LOANS NO EXIT INTERVIEW HOLD NURSING STUDENT LOAN HOLD PERKINS HOLD QUALITY ASSURANCE PROGRAM REPAYMENT SFA FUNDS STUDENT FIN AID CONVERSION SHORT TERM LOAN HOLD

Y Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y Y Y Y Y Y Y

TRSS

Transfer Probation Security System Approved: TPR1 TPRO University College Approved: TRANSFER PROB HOLD (SAME DAY) TRANSFER PROBATION HOLD Y Y N N N N N N N N

UNC

AADV SBAD SBB SBOR UNC1

ACADEMIC ADVISING SB 140 ACADEMIC ADVISING SB 140 DID NOT RETURN BOOKS DID NOT ATTEND SB 140 ORIENT UNC 90 OR MORE HOURS

Y Y Y Y Y

N N Y N N

N N N N N

N N Y N N

N N N N N

245

APPENDIX

UNC2 UNC5 UNCP Zanesville Library Approved: ZRE G Zanesville Registration Approved: ZGB ZLNS ZLIB

HOLD UNC 115 OR MORE HOURS HOLD UNC DID NOT ATTEND ORIENTATION PROBATION

Y Y Y

N N N

N N N

N N N

N N N

ZLIB

ZANESVILLE LIBRARY HOLD

ZANSVILLE GEN BALANCE HOLD ZANSVILLE DELINQUENT LOAN HOLD

Y Y

Y Y

Y Y

Y Y

Y Y

246

APPENDIX

18.3 Complete Table Loading Sequence Products Affected AV, HR, SA AV, HR, SA AV, HR, SA AV, HR, SA AV, HR, SA AV, HR, SA AV, HR, SA AV, HR, SA AV, HR, SA Features Affected CS General, HRMS General CS General, HRMS General CS General, HRMS General CS General, HRMS General CS General, HRMS General CS General, HRMS General CS General, HRMS General CS General, HRMS General CS General, HRMS General CS General, HRMS General, US Recruitment Extension CS General, HRMS General CS General, HRMS General, US Recruitment Extension CS General, HRMS General CS General, HRMS General CS General, HRMS General Campus Community, Workforce Administration 247

Setup Task Installation Table Country Table State/Province Regulatory Region Person Object Installation TableSet IDs Record Group Business Unit Company

Description Specify the PeopleSoft applications for your installation. Predefined information by Country as defined by ISO. Add a state, province or equivalent entity for the selected country. Set up a regulatory region. Installation settings for the PERSONAL_DATA component and Person Object Define TableSet ID. Define record group and record name. Define business units. Define and describe companies.

AV, HR, SA

Establishment

An establishment is usually a physical location in the organization.

AV, HR, SA

AV, HR, SA

National ID Type Name Type Name Title Supporting Documents

Define types of national indentification numbers. Define the types of names that can be recorded for a person. Defines titles used by individuals (e.g., Ms., prince, professor). Defines documents used to verify employee information.

AV, HR, SA AV, HR, SA AV, HR, SA AV, HR, SA

APPENDIX

Holiday Schedule Schools

Define a company's paid holidays for a given year. Define schools.

AV, HR, SA AV, HR, SA AV, HR, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA SA AV, SA AV, SA

Visas/Permits Address Usage Table Student Admin Installation Name Type Defaults Name Usage Table Phone Usage Table Salutation Table Name Suffix Location Address Table Student Records Installation Program Action Table Administrative Function Table CIP Code Table HEGIS Code Table Extracurricular Activity Table FERPA Control Building Table Room Characteristics Table Facility Table Unit Conversion

Define visa or permit details and supporting documents for verifying status. Define hierarchies of address types to search for and use in a specific usage. Define installation values required for Student Administration. Define or review the name types that will be created by default when adding a new person ID. Define hierarchies of name types to search for and use in a specific usage. Define hierarchies of phone types to search for and use in a specific usage. Define or review the salutations available in your system. Defines name suffixes such as Jr. and Sr. Define or review campus addresses for your institution. Define installation values required for Student Records. Define program action codes. Review administrative functions. Create a listing of all Classification of Instructional Program codes. Create a listing of all Higher Education General Information Survey codes. Define and update the extracurricular activities your institution tracks. Review or make additional directory data and other information available to FERPA privacy control. Define building information. Define specific room characteristics. Define facility information. Define unit conversions formulas.

CS General, HRMS General CS General, Workforce Administration Campus Community, Workforce Administration CS General CS General Campus Community CS General CS General CS General CS General CS General Student Records CS General CS General CS General CS General Campus Community CS General CS General Student Records CS General CS General 248

APPENDIX

Table Complete Grade Flag Grade Category Define grade flag values and descriptions. AV, SA AV, SA, SG AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA CS General CS General, Gradebook CS General CS General CS General Campus Community Campus Community CS General CS General CS General CS General CS General CS General CS General Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus 249

Create new grade category values to be used for derived lists. Grading Scheme Define all valid grading schemes and grading Table bases for academic careers. Degree Table Define internal and external degrees. Joint Salutation Define salutation types to make available for Type Table joint communications. External Define organization types and related Organization Type navigation. Define North American Industry Classification NAICS Codes System codes. Level/Load Rules Define academic level and load rules by SetID. Table Demographic Define demographic data access for primary Data Access permission lists. Demographic Update demographic data access settings. Data Access Search/Match Search/Match Rule configuration Rules Search/Match Search/Match Parameter configuration Parameters Search/Match Search/Match Result Fields Setup Result Fields Search/Match Search/Match Results configuration Results Selection Tool Application Specific Context Context Definition Equation to Context Mapping Field Conversion Definition Copy Field Value Conversion Context Definition Copy Context Definition File Mapping Configure Population Selection Tools.

Define the application specific keys used to map AV, SA a process to a specific context. Configure Population Selection Context AV, SA Definition. Map Equation Engine Application Prompt AV, SA values to Population Selection Contexts File Parser Field Conversion Definition File Parser Copy Field Value Conversion. File Parser Context Definition Copy Context Definition. File definition and mapping. AV, SA AV, SA AV, SA AV, SA AV, SA

APPENDIX

Definition Copy File Mapping Definition Population Selection File Map Population Update Setup Form Image Text Event Type Table Campus Community Installation Resource Code Table Health Test Table Staff Code Table Event Template Trigger Prompt Table Ext Org Code Type Table EPS Market Code Table Relationship / Marital Status Immunization Table Relationship Table File Parser Copy File Mapping Definition. AV, SA

Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community 250

Population Selection File Mapping Definition Population Update Setup. Forms Engine EPS Image Text. Define type of events to manage. Install tables required for Campus Community. Define resources to be used with events. Define and update the health tests your institution tracks. Define staff codes to use with events. Define event meeting templates. Identify the edit table for a 3C engine trigger to prompt. Define an EPS market code organization code type. View EPS market codes loaded through the EPS load process. Define and update a marital status corresponding to a joint relationship. Define and update the immunization tests your institution tracks. Define and update the relationships your institution tracks.

AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA

Font Names Form Editor Form Groups Out Dest Formats

Font Name Table. Form Editor. Form Group Table. Forms Engine Out Dest Formats.

AV, SA AV, SA AV, SA AV, SA

APPENDIX

Out Dest Types Out Dest Values Postscript Fonts Standard Letter Table CS Academic Institution Table Comment Category Table 3C Update/Inquiry Group Table Comment 3C Groups Tracking Group Table Communication Context Table Institution Publications Iwi Table Legacy Table Communication Category Table Communication 3C Groups Publication Categories Service Impact Table Service Indicator Table Committee Type/Role Checklist Item Table Checklist Item Functions Table Communication Speed Key Table Communication Data Source

Forms Engine Out Dest Types. Forms Engine output dest prmpt. Postscript Fonts. Set up standard letter codes to be used in Campus Solutions communications. Define default and set up values for academic institutions. Set up categories for comments. Define 3C group codes. Include comments in 3C groups for security purposes. Set up tracking groups for checklists. Set up contexts for the communications process. Define and update the publications your institution tracks. Maintain Iwi codes and descriptions for NZ Maoris. Used in SDR Reporting. Define the types of legacy affiliations that individuals can have with your institution. Set up categories to use in the communications process. Include communications in 3C groups for security purposes. Publication Categories. Define service impacts codes to attach to service indicators. Create service indicators code, for both positive and negative service indicators. Define the committee types and member roles. Set up items to be used in a checklist. Set up checklist items by administrative function. Manage Speed Keys for communications. Define communication data source to be used in Campus Solutions communications.

AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA

Campus Community Campus Community Campus Community Campus Community Academic Structure Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community 251

APPENDIX

Checklist Table Checklist 3C Groups Event Definition Trigger Definition Contact Type Table Organization Recipient Usage School Type Table Organization Table Organization Locations Organization Departments Organization Contacts External GPA Type Table Student Special GPA Organization Affiliation External Organization Codes External Subject Table External Education Comments School Subject Maintenance School Course Classification Religious Preference Table

Set up checklists. Include checklists in 3C groups for security purposes. Define events for management of communications, checklists and/or comments. Define triggers for management of communications, checklists and/or comments. Setup the type of contacts your institution wants to track. Define hierarchies of Organization Recipient types to search for and use in a specific usage. Define school types for external education data. Create or update an external organization. Create or update locations for your external organizations. Create or update departments for your external organizations. Create or update contact persons for your external organizations. Define GPA types for external education data. Create and maintain special grade point averages for a student's term records. Create or update an organization's affiliation to the institution. Create or update EPS codes for an organization. Define broad categories of the subjects offered at external organizations. Default comments for external education entry. Create or update school subjects for an organization. Create or update school courses for an organization. Define and update the religious preferences your institution tracks.

SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA SA AV, SA AV, SA AV, SA SA SA

Student Financials Campus Community Campus Community Campus Community Campus Solutions General Campus Community CS General, Admissions & Recruiting CS General CS General CS General CS General Admissions & Recruiting Student Records Campus Community Campus Community Student Records Admissions & Recruiting CS General, Student Records CS General, Student Records Campus Community 252

AV, SA

AV, SA AV, SA

APPENDIX

Residency Exception Table Residency Table Standard Industry Table Standard Occupation Table Define External Systems Athletic Participation Table Citizen Status Term Values Table Field of Study Table Campus Table Academic Career Table Academic Group Table

Define and update the residency exceptions your institution tracks. Define and update the residency information your institution tracks. Define and update the United States standard industrial classifications your institution tracks. Define and update the United States standard occupational classifications your institution tracks. Define external systems for which external system identifiers can be tracked. Define and update athletic participations your institution tracks. Defines citizenship details for specified country. Define the term values and their descriptions. Define values for field of study. Define campus values.

AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA SA AV, SA AV, SA AV, SA AV, SA

Campus Community Campus Community Campus Community Campus Community Campus Community Campus Community CS General Academic Structure CS General Academic Structure Academic Structure Academic Structure Academic Structure Academic Structure Campus Community Academic Structure Academic Structure Student Records Academic Structure Academic Structure Academic Structure Academic 253

Define default and set up values for academic careers. Define course defaults, catalog levels and meeting patterns for academic groups. Define time periods or critical points in time for Time Period Table each academic career. Academic Create a listing of all academic organizations Organization defined in the system. Table Update Security - Link your academic organization security tree to Acad Orgs academic organization security. Academic Subject Create subject areas and define taxonomy and Table workload values. Term/Session Define terms, sessions within terms, and Table session time periods. Enrollment Action Define enrollment action and enrollment action Reason reason values for all academic careers. Define cancel, withdrawal, and drop deadlines Academic along with other term and session landmark Calendar dates. Academic Define default and set up values for academic Program Table programs. Academic Plan Create academic plans, and define plan related Table information for transcripts and diplomas. Academic Create academic subplans as well as define

APPENDIX

SubPlan Table Instructor/Advisor Table Requirement Designation Table Course Equivalencies Course Attributes Course Typically Offered Instruction Mode Dynamic Class Dates Table Weekly Schedule Time Periods Course Catalog Classroom Scheduling Interface Study Agreement Table Honors and Awards Table Milestone Table Milestone Templates Grading Basis Exception Rule Grade Review Career Pointer Exception Rule Appointment Limits Table Appointment Table Student Group

taxonomy and descriptions for transcripts and diploma. Add and modify instructor and advisor records. Define requirement designation values. Define course equivalency groups. Define course attributes and attribute values. Define course typically offered values Define instruction mode values. Dynamic Class Dates Table. Define weekly schedule time periods. Create, view and update courses, course offerings, and course components. Set up classroom scheduling interface. Create study agreements for use with external organizations. Define and update the honors and awards your institution tracks. Define milestone codes, their grading bases and determine the milestone levels. Define milestone templates to be used with milestone values. Define mapping rules to convert grading bases for students enrolling across careers. Define grade review values to be used in the grade review process. Create career pointer exception rules. Define appointment limits ID's and full-time and part-time maximum unit limits. Create enrollment appointments for sessions and terms. Define student groups to track student SA SA SA SA SA SA SA SA SA SA SA

Structure Student Records Student Records Student Records Student Records Student Records Student Records Student Records Student Records Student Records Student Records Student Records Campus Community Student Records Student Records Student Records Student Records Student Records Academic Structure Student Records Student Records Student Records Student 254

SA

SA SA SA SA

SA

SA SA SA

APPENDIX

Table Student Group Table Student Services Center Setup Degree Honors Table Academic Standing Table Academic Standing Rule Honors/Awards Rule Student Attribute Table Global Notes Table Repeat Scheme Table Repeat Rule Test Component Table Test Tables External Test Score Mapping Ethnicity Mapping AMCAS Ethnicity Mapping Test Table Test Transfer Rules Program/Test Equivalency Transfer Subject Area Course Transfer Rules Program/Source Equivalency Gradebook Category

membership within various groups. Define student groups to track student membership within various groups. Define the labels and sections to show for the Student Services Center Define degree honors and print options for transcripts and diplomas. Create academic standing action codes for all academic careers. Define academic standing rules for all academic careers. Define rules to be used in the honors and awards process. Define student attributes for tracking and reporting on different cohorts. Define global notes. Define repeat schemes and repeat codes within each scheme. Define repeat rules for academic careers and academic programs. Define components for external tests. Define Test IDs and score ranges for external tests. Map test IDs to PeopleSoft defined test codes. Map ethnicity codes from the testing agencies to PeopleSoft ethnic group codes. Map ethnicity codes from AMCAS to PeopleSoft ethnic group codes. Define test codes and link test components to them. Define test transfer equivalency rules. Select the academic programs and plans to assign test transfer equivalencies. Define component subject areas for external or internal institutions. Define course transfer equivalency rules. Select the programs and plans to assign course transfer equivalencies. Maintain gradebook assignment categories. SA AV, SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA

Records Student Records Campus Community Student Records Student Records Student Records Student Records Student Records Student Records Student Records Student Records Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Student Records Student Records Student Records Student Records Student Records Student Records Student Records 255

APPENDIX

External Term NQF Field/Subfield Domain NZL Define Statistics Type Define Statistics Period Academic Advising Academic Advising Installation Cum. Grade Point Average

Define or review external terms sessions for external organizations. Define Fields, Subfields and Domains for NZ National Qualifications Framework Unit Standards. Define statistics types for consolidated statistics. Define statistics periods for reporting consolidated statistics. Define parameters and rules for self service academic advising activities. Configure academic advising options at the installation level. Define cumulative GPA values and associated descriptions. Define transcript types, associate service indicators and indicate that a transcript type includes an advising report. Create transcript notes that relate to a student's enrollment record. Set up codes to define where various types of data appear on the transcript. Define transcript type and associate service indicators. Group together similar items, such as plan, for use as a single condition. Create special usage field values for generating alternate report formats. Define and assign valid careers to an advisement report. Establish custom condition processes. Establish exactly which courses comprise the course list and define detail parameters. Enable courses to be shared by more than one requirement group. Create multi-dimensional condition specifications.

SA

Campus Community Student Records Student Records Student Records Student Records Academic Advisement Academic Advisement Student Records Academic Advisement Student Records, Academic Advisement Student Records Student Records Student Records Academic Advisement Academic Advisement Academic Advisement Academic Advisement Academic Advisement Academic Advisement Academic Advisement 256

SA SA SA SA SA

SA

Transcript Type Transcript Notes Table Transcript Print Area Table Define Transcript Type Define an Entity Group Define Requirement Usages Define Advisement Report Define Condition Processes Define Course Lists Define Course Share Sets Define Dynamic Condition

SA

SA SA SA SA SA

SA SA SA SA SA

APPENDIX

Define Academic Requirements Define Requirement Groups CRS Major Codes SAT Math Recentered Values SAT Verbal Recentered Values Referral Source Table Admissions Installation

Create specific types of requirements, defining parameters and controls. Define academic requirement groups that point to conditions, courses, and requirements. Define major codes for CRS search tapes. Define math recentered values for the SAT test. Define verbal recentered values for the SAT test. Define the source of referral for a prospect.

SA SA SA SA

Academic Advisement Academic Advisement Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting 257

SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA

Define installation options for recruiting and admissions features. Define regions for prospect and applicant Region Table recruiting. Admissions Action Define program actions for application Table processing. Teaching Define teaching subject for OUAC processing. Subjects CEGEP Program Define the CEGEP program table for OUAC Table processing. SAT II Test Codes Define SAT II test codes. External Summary Type Table Enrollment Target Population Enrollment Target Division AMCAS GPA Codes Law Categories AP Country Codes AP Subject Test Codes GRE Subject Test Codes Program Action Reason Table Define summary types for external education data. Define populations for enrollment target processing. Define divisions for enrollment target processing. Define GPA codes for AMCAS tests. Define law categories for OUAC processing. Define country codes for AP tests. Define subject test codes for AP tests. Define subject test codes for GRE tests. Define program action reasons for application processing.

APPENDIX

AMCAS Credit Hour Codes Basis of Admission Table ADA Country Codes Extracurricular Activity Map GMAT Country Codes SAT II Test Recentered Values Region Postal Table Religious Preference Map Academic Interests Map Enrollment Target Cohort Admission Comments Table Rating Comp Definition Table Evaluation Status Table TS130/TS131 Setup Material Group Table Application Center Table External GPA Rules Table Recruiting Center Table Admit Type Table Recruiting Category Table Response Reason Table Web Prospect Create Table

Define credit hours codes for AMCAS tests. Define basis of admission codes for application processing. Define country codes for ADA tests. Map external extracurricular activities. Define country codes for GMAT tests. Define SAT II test recentered values. Define postal code ranges for regions. Map external religious preferences. Map external academic interests. Define cohorts for enrollment target processing. Define admissions comment codes for application processing. Define rating components for application evaluations. Define statuses for application evaluation. Set up TS 130 and TS 131 and define contacts. Define materials groups for application and general materials. Define application centers to assign to applicants. Define GPA rules for external education data. Define recruiter centers to assign a prospect.

SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA

Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting

Define admit types for prospects and applicants. SA Define recuiring categories for prospects and applicants. Define reasons an applicant is attending another school. Define the structure for prospect self service Request Information feature. SA SA SA

258

APPENDIX

Rating Tables Evaluation Tables Average Cutoff Table Alternate Average Calculations Alternate Offer Table Student Fin Installation Keywords Define External Award Sources Define External Award Types SF Account Types

Define rating schemes for application evaluation. Define evaluation codes and committees for application evaluation. Define cutoff ranges for alternate admissions offers. Define rules for calculating alternate admissions averages. Define rules for alternate offers of admission. Define number sequencing, maximum row settings, edit tables and commit levels. Define and associate keywords with item types to facilitate searches. Define sources of external awards. Define external award types. Define account types to classify item types into usable account groups. Define attributes, posting restrictions, link account types and map chartfields. Define item type groups to limit the application of credits to certain charge items. Define Value Added Tax transaction types. Create tax authority codes to process taxes attached to charges. Define tax codes to link taxes and tax authorities to charge item types. Define aging sets for credit history processing. Create late fee definitions to identify past due charges and assess late fees. Create late fee definitions to identify unpaid billed items and assess late fees. Define the sorting of eligible charges for payment allocation. Create form for permission to apply restricted credits. Define charge priority lists and rules and link them to item type tree nodes. Create schedules to determine the amount of fees due, the billing and due dates.

SA SA SA SA SA SA SA SA SA SA

Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Admissions & Recruiting Student Financials Student Financials Financial Aid Financial Aid Student Financials Student Financials, Contributor Relations Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials 259

Item Types

AV, SA

Item Type Groups Tax Transaction Codes Tax Authorities Tax Codes Aging Set Late Fees Late Fees - Billing Payment Overall Priority Student Permission Forms Charge Priority List Billing and Due Calendars

SA SA SA SA SA SA SA SA SA SA SA

APPENDIX

Adjustment Calendars Origin Table External File Layouts Group Type Table SF Term Default Security Views Valid Records Valid Fields Credit Card Type Item Reasons Follow-Up Table Reason Out Fee Classes Void Reasons AP Set Controls Vendor Reason In Liability Status Tuition Calculation Controls Invoice ID Number Billing Type Message Categories Billing Scan Line

Define schedules and fees for tuition adjustments for drops and withdrawals. Define sources of receivables posted through group posting. Define the file layout for external charges and payments. Define sets of frequently posted receivables for use in group data entry. Define default terms to populate accounts when term is not used during posting. Review and modify security views for your system. Review valid records used in trigger criteria for tuition calculation. Review valid records, fields and edit tables used in trigger criteria. Define the credit card types the institution accepts for payment. Create codes to provide brief explanations for payment and charge reversals. Create Follow-Up action codes that record the steps needed to resolve accounts. Define codes that identify why the system moved an item out of collections. Define fee classes to enable reporting on specific types of fees. Define codes to provide brief explanations for voided cashiering receipts. Define vendor information. Define codes that identify why the system moved an item into collections. Defines Liability Status Codes as determined by DEST for element 490. Define parameters, rules, errors and warnings used for tuition calculation. Create an unique invoice ID that must appear on your bills. Establish bill types for your institution for students or corporations. Create message categories to be used with billing messages. Create a bill scan line if your bank requires it to track transactions.

SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA

Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials

260

APPENDIX

1098-T TIN Table AP Business Unit Criteria Invoice Layout Waivers Waiver Groups SpeedTypes Billing Messages Provider Table

Set up a tax identification number for filing 1098-T tax forms with the IRS. Define Accounts Payable interface and voucher numbering parameters. Create criteria for tuition groups, fee triggers and waivers. Set of parameters that define invoice information, sorting, and summarization. Define waiver codes to waive or reduce a student's tuition and fee charges. Define waiver groups to attach one or more waivers to class and course fees. Create shortcut keys of chartfields for department receipt entry in cashiering. Create messages that appear on your bills by message categories. Define the International Health Coverage Provider Table. Define ePayment processing rules for different business units, including services performed. Create optional fee codes and values. Define coverage and rates for Providers. Define institutional contact Information. Create a combination period to retrieve consolidated academic statistics. Create templates and delvery schedule of dunning letters for past due accounts. Define ranges for term fees, applications fees and other institutional charges. Define parameters to determine how you identify and bill groups of customers. Bank account information for the business unit is managed from this page. Bank accounts for Exertnal Organizations are managed from this page. Create a group of courses for use with thirdparty contracts or course fees. Define the Per Credit Charge and Hook on fee defaults for NZQA. Define refund, residency and enrollment parameters for the institution.

SA SA SA SA SA SA SA SA SA

SF Merchants

CSS, SA

Optional Fees Coverage and Rates Institutional Contact Combination Period Table Collection Letter Template Minimum / Maximum Fees Billing Standard Request Bank Accounts Business Unit Bank Accounts Corporate Course Lists Per Credit Charge StudyLink Institution

SA SA SA SA SA SA SA SA SA SA SA SA

Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials, Campus SelfService Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials 261

APPENDIX

Defaults StudyLink Posting Parameters Transaction Fees Application Fees Loan Default Optional Fees Terms SF Business Unit HECS Band Fees Collector Corporate Collection Criteria SF Institution Set Rate Tables for Course Fees Corporation Messages Aging Set Messages Customer Message Item and Account Types Identify SA Deduction Codes Term Fees Tuition Groups Deposit Fees Item Type Message Business Unit Message Define posting and refund item types for StudyLink. Create transaction fees for adding or dropping classes as of a specific date. Define rules, item types and fees for enrollment applications. Define parameters for HECS HELP, FEE HELP and OS HELP loans. Also defines status change rules for the HECS Reconciliation. Link optional fee codes to terms and assign date parameters. Define the basic business rules for each business unit. Create and define HECS Band Fees. Define and establish collectors within the system. Create a list of corporate collection criteria defined in your system. Define self service ePayment parameters, rules, and usage for one or more business units. Create student criteria to add to the course fee definition. Link message(s) that appear on a single corporation when the bill is generated. Link billing messages to specific aging sets and aging categories. Link message(s) that appear on a single student when the bill is generated. Define Item Types and Account Types for the Business Unit. Define student administration deduction codes. Define term fee codes to link to tuition groups. Create tuition groups to assign a set of fees according to specific rules. Create admission deposit fees, due dates and status changes for payments. Link billing messages to specific item types or ranges of item types. Assign billing messages to business units. SA SA SA SA SA SA SA SA SA Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials, Campus SelfService Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials 262

CSS, SA

SA SA SA SA SA SA SA SA SA SA SA

APPENDIX

SF Self Service Options Course List Fees Create Deferral Contract Optional Fees per Term Target Keys Class Fees Class Fees Modal Course Fees Course Fees Modal

Define business unit information for self service processing. Create fees for all courses within a given course list. Define deferral contract parameters, administrative fees and eligible charges. Define optional fee amounts. Define which charges receive credit for a given transaction. Create fees for particular instances of a course. Create or update fees for classes through the Schedule of Classes. Create or update course fees.

CSS, SA

SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA

Create or update course fees through the Course Catalog. Define the types of tender used in cashiering Tender Keys transactions. Define the characteristics of each cashiering Cashiering Offices office for the institution. Service Indicator Define sets that automatically attach service Sets indicators during Credit History. Define valid cash registers used in each Valid Registers cashiering office. Define valid cashiers working in each cashiering Valid Cashiers office. Receipt Print Define messages that appear on printed Messages transaction receipts. Financial Aid Define installation values required for Financial Installation Aid. Define Federal Define the aid year using federal guidelines. Aid Years Define Financial Define the valid financial aid years for the Aid Years institution. Valid Careers for Assign financial aid eligible academic careers Aid Year for the aid year. Valid Terms for Define eligible financial aid terms, academic Career and loan periods for careers. Define Commit Define database commit levels for eligible Levels financial aid processes. Define Define how student bio-demographic Demographic information is used by financial aid processes.

Student Financials, Campus SelfService Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Student Financials Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid 263

APPENDIX

Data Use PROFILE-Need Access Controls Maintain ISIR Comment Codes ISIR/SAR Cross Reference Maintain NSLDS Codes INAS Assumption Codes INAS 2004-2005 Global Options INAS 2005-2006 Global Options INAS 2006-2007 Global Options Institutional Cross Reference Loan Fee Setup Aggregate Programs Define Sort Order Fields Define Sort Order Names Maintain CRC Loan Status Codes School Codes for Institution School Code Table Maintain Loan Servicer Codes Define Loan Report Definitions Equation SQL Routines Equation External Subroutines Define PROFILE and Need Access run controls. SA SA Maintain the ISIR comment codes and their database match usage. ISIR/SAR Cross Reference. Review and update the NSLDS status codes. INAS Assumption Setup Pages. Define policies for Federal and Institutional need methodologies for 2004-2005. Define policies for Federal and Institutional need methodologies for 2005-2006. Define policies for Federal and Institutional need methodologies for 2006-2007 Track cross-references of field name to the institutional record field number. Define loan fees which are calculated during the packaging process. Define Stafford, Direct, or HEAL aggregate areas to be linked together to combine loan limits. Update and review Financial Aid Award Notification output Sort Order Fields criteria. Define Sort Order Names criteria for Financial Aid Award Notification output processing. Maintain CRC status and error codes reported by the loan servicers. Define valid school codes for institution. Maintain Title IV school codes by aid year. Maintain a comprehensive list of loan servicer codes. Define field specifications and the output format for loan forms. Create or edit SQL that can be authorized to be called from an equation. Adds an external cobol routine to the list of routines that can be authorized. SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Student Financials, Financial Aid Student Financials, Financial Aid 264

SA

APPENDIX

Equation Data Tables Equation Editor Equation Names Equation Test Data Equation Global Space Equation Application Prompts Budget Tree Address Usage Define EDI Business Unit Maintain EDI Transactions Maintain Loan Edits Maintain Loan Transfer ID Maintain Guarantor Codes Maintain CRC Loan Edits Create CRC Loan Edit Sets Aggregate Level Translation Aggregate Aid Limits Aggregate Area Translation Maintain Loan Action Codes Maintain Lender Codes Create CRC Loan Participants Create CRC Search Match Setup Define School Guarantors

Adds a table or view to the list of tables and views that can be authorized. Create and edit equations. Authorize Equation Access. Set up test data for an equation. Work with Equation Global Variables in Equation Spaces. Add or update the list of applications that use equations. Define which address type is to be used during the budget assignment process. Define the internal financial aid business unit used in EDI Manager processes. Maintain the EDI transactions that can be viewed in the ISIR and Loan Review pages. Maintain CommonLine 4 validation edit list. Maintain loan information used to generate loan files for transmission. Maintain a comprehensive list of guarantor codes. Maintain list of Common Record CommonLine loan edits. Create sets of loan edits to be used in creating CRC loan destinations. Associate aggregate levels with academic level definitions from the Department of Education. Define annual and aggregate aid limits for all sources of funding. Associate aggregate areas with programs from the Department of Education. Maintain loan action codes used by Direct Lending and CommonLine. Maintain a comprehensive list of lender codes. Maintain lender, guarantor, and servicer information for CRC processing. Create search match setup conditions for CRC Certification Request processing. Define the guarantee agencies to be used for processing loans at the institution.

SA SA SA SA SA AV, SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA

Student Financials Financial Aid Student Financials Student Financials, Financial Aid Financial Aid Campus Community Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid 265

APPENDIX

Define School Lenders Define School Servicers Direct Loan Change Rules Hold and Release Equations Reassign Loan Agencies Maintain Loan Report Packages Setup Perkins MPN Options CNAS Messages Create Proration Rules Financial Aid Item Types Item Type Cross Reference Search/Match Rules Fiscal Item Types Define Rules for Return CSL File Load Control Verification Tolerance Setup Award Adjustment Reasons PROFILE Load Parameters Need Access Load Parameters View COD XML Fields Budget Categories Budget Items Create Loan Edit Sets

Define lending agencies to be used for processing loans at the institution. Define loan servicers to be used for processing loans at the institution. Define global change parameters for Direct Loan change, hold and suspense processing. Define the equations used by the CommonLine Hold and Release process. Define instances where one loan agency has been replaced by another. Setup and update Loan Report Packages for Promissory Note processing. Define Perkins MPN Options Define Canadian need analysis messages. Define the criteria for pro-rating awards based on student enrollment. Define item types as financial aid item types for use in awarding various sources of funds. Map external awards to internal award items. Define search/match options to use during external award loadng process. Define fiscal limits for existing financial aid item types. Identify financial aid item types used for Return of Title IV calculations. CSL File Load Setup Page. Update verification tolerance values for Federal and Institutional processing. Define reasons for why an award may be adjusted on the various Assign Award pages. Define PROFILE Data Load Parameters. Define Need Access Data Load Parameters. View Common Origination and Disbursement XML field mappings. Define the individual components that make up the federal, Pell, or institutional budget. Define budget items, term amounts, and Pell annual amounts by budget category. Create sets of loan edits to be used in creating loan destinations.

SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA

Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid

266

APPENDIX

Budget Formulas Create CRC Loan Destinations Reconciliation Periods Application Source Rank Budget Region Table CNAS Setup CNAS Cost Code Budget Trees Setup Financial Aid Term Define Career Types Early Financial Aid Categories Early Fin Aid Categories Self Service Options Aid Processing Rule Setup Term Values Cross Reference Create Loan Destinations Pell Payment CNAS Rule Setup Valid Programs for Aid Year Pell ID Attending Pell Comment Code CNAS Option Table

Define assignment rules for each budget item which are used to calculate the student's budget. Define the processing protocols between the school and the CRC loan servicers. Create reconciliation periods for cash management. Define the application source order for the batch budget assignment process. Define regions to be used during Budget Tree processing. Define Canadian need analysis parameter setup. Define Canadian need analysis cost codes. Define a Tree Node that will be used to assign a particular detailed value to a budget item. Define the valid terms that can be used for building financial aid term records. Define Financial Aid Career Types to combine statistics for FA Terms. Define the types of financial aid considered for an early financial aid offer. Define early financial aid categories. Define self service inquiry options as well as awarding access and processing options. Define aid processing rule sets for use as career and program defaults. Define equivalent terms across aid years for the aid year rollover process. Define the processing protocols between the school and the CL 4 loan servicers. Define Pell payment parameters and options. Define Canadian need analysis rule sets. Assign program specific financial aid processing rule sets. Assign a campus specific Pell ID. Set severity level for edits and comments defined by Department of Education. Define Canadian need analysis options.

SA SA SA SA SA SA SA SA SA SA SA

Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Admissions & Recruiting, Financial Aid Admissions & Recruiting, Financial Aid Financial Aid, Campus SelfService Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid

SA

CSS, SA SA SA SA SA SA SA SA SA SA

267

APPENDIX

ISIR Data Load Parameters Define Serial Promissory Notes Package Rating Components Packaging Equity Item Types Budget Groups Budget Assignment Define Printer Names Define Selection Equations Define Notification Form Types Award Notification Defaults Assign Status to Admit Levels Define Careers for Prospects Related Item Type Group Create Loan Types Set DL Loan Counseling Search Identify Self Service Lenders Define Loan Counseling Options Set Up Disbursement Calendars Restricted Aid Table Budget Assignment Run Control Disbursement

Define the rules used to load ISIRs from the staging to the application tables. Define and update parameters for Direct Loan MPN and Serial Promissory Note processing. Define admissions rating components and GPA types to be available during packaging. Define a group of financial aid item types to act as equity offsets in a packaging plan. Define a group of budget items for use in manually assigning a term budget to students. Define career/aid year/institution combinations to assign budgets to groups of students. Define institution printer names used by the Financial Aid Award Notification Defaults page. Define Forms Engine Financial Aid Award Notification Selection Equations. Define Forms Engine Financial Aid Award Notification Form Types. Update and review award notification defaults. Assign an academic program status for each program admit level. Define the career to assign to applicants based on the student's ISIR. Define related financial aid item types together into similar groups for awarding purposes. Define the loan types that require origination. Direct Loan Search Match Setup for loan counseling data load. Define Lender Select list.

SA SA SA SA SA SA SA SA SA SA SA SA SA SA SA

Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Student Financials Financial Aid Student Financials Financial Aid Student Financials Financial Aid Financial Aid Financial Aid Financial Aid 268

SA

Define Loan Counseling options. Define the parameters for the batch authorization and disbursement processes. Define parameters and conditions for awarding funds with subjective eligibility requirements. Define careers and terms to select for the budget assignment process. Define the different disbursement plans for each

SA

SA SA SA SA

APPENDIX

Plan Table Disbursement ID Table Create User Edit Messages Define Global Rules Disbursement Split Codes Disbursement Split Cd Formula Packaging Plan Repackaging Plan Careers for School Codes Define Loan Institutions Define Item Type Rules Contributor Rel Installation Action Types Action Contact Types Roles Recognition Types Action Results Designation Types Person / Org Relationships Constituent Types Goal Type Table Trust Terms Action Status

career by aid year. Define disbursement IDs for each disbursement in or across terms for a disbursement plan. Create and update user edit messages. Define common authorization rules for students of the same career. Define all disbursement patterns for each disbursement plan in a given aid year. Define percentages of award to be disbursed by disbursement split code. Define award rules and limits for targeted groups of students for use in auto- and mass packaging. Define rules and limits for targeted groups of students for use in auto- and mass repackaging. Define valid careers for school codes. Define the valid loan processes available at the institution. Define common authorization rules for individual Item Types. Install tables required for Contributor Relations. Set up the types of actions that will be tracked for constituents and initiatives. Set up types of contacts that will be used to carry out a constituent or an initiative action. Create Roles for Staff, Volunteers, and Units. Set up the types of donor recognition you wish to track. Set up types of results that will be used to track completion of initiative actions. Institution Type Codes. Set up the types of relationships between a person and an external organization. Set up values to indicate the types of CR constituents being tracked. Set up the types of goals to track for initiatives. Set up the terms for trusts to be tracked for donors. Set up status codes to be used for constituent SA SA SA SA SA SA SA SA SA SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Financial Aid Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor 269

APPENDIX

Codes Credit Card Type Rating Type Initiative Type Table Membership Category Matching Gift Types Gift Types Attribute Type Campaign Donor Phase Table Asset Types Rating Origin Rating Indicators Adjustment Reasons Trust Types Rating Categories Appreciation Items Membership Type Appeal Type Table Method Table Trust Categories Functional Group Security Areas of Responsibility Involvement Types

and initiative actions. Set up credit cards to be used with CR electronic payment processing. Set up types of ratings to track for donor prospects. Set up the types of initiatives to track. Set up the categories of membership to track. Set up the types of gifts to use in matching gift rules. Set up gift types for donor commitments. Set up attributes to use in creating audiences. Set up the donor phases expected to support a campaign. Set up asset types to track for prospects. Set up origin code values for prospect management ratings categories and indicators. Set up values that indicate a rating level for a donor prospect. Define reasons for making adjustments to gift, pledge, and membership transactions. Set up the types of trusts to be tracked for donors. Set up categories of ratings to track for donor prospects. Set up items that will be tracked as tokens of appreciation. Set up the types of membership to track. Set up the types of appeals to track. Set up methods through which actions will be executed. Set up categories of trusts to track for donors. AV Functional Group Categories. Setup the areas of responsibility to which volunteers will be assigned. Set up the types of involvement required to track constituent involvement. AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA

Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations 270

APPENDIX

Budget Table Involvement Categories Involvement Codes Add/Update Matching Rules Audience Criteria Leadership Types Staff Default Comment Categories Giving Vehicles Org Reciprocal Relationships Foundation Types Geographic Areas Support Types Merchant Table

Set up budget items to track for initiatives. Set up the categories required to track constituent involvement. Set up the values to track specific constituent involvement. Enter rules that an external organization uses to determine gifts to match financially. Define criteria to be used in audience selection. Define types of volunteer leadership to track. Identify Contributor Relations staff members. Set up default comment categories for CR components. Giving Vehicles. Set up the types of relationships between two external organizations. Define Foundation Types. Define Geographic Areas. Define Foundation Support Types. Set up merchants for processing credit cards with CR business units.

AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, CSS, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA AV, SA

Acknowledgement Setup gift and pledge acknowledgement rules. Setup Assignment Set up the types of volunteer assignments to Types track. Units Volunteers Tender Types Market Rates Business Unit CR Institution Defaults Define Contributor Relations units. Define Volunteers. Set up the types of legal tender that you wish to track for gifts and memberships. Enter and maintain market rates on the Market Rates Data table. Set up business units for Contributor Relations. Set up institution defaults for Contributor Relations business rules.

Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations, Campus SelfService Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations Contributor Relations 271

APPENDIX

Appeal Code Table Designation Funds Involvement

Appeal Code Setup. Setup designation funds for distribution of gifts, pledge, and memberships. Web Setup. Set up Contributor Relations defaults for an individual user. Define branch codes to be used when reporting enrollment status to the NSC. Set Up Dutch Cluster Codes. GBA Country Codes for the Netherlands. Set up MBO Codes Netherlands. Set Up BRINcodes for Dutch Schools/Campus/Locations. GBA Nationality Code Table. Set up Prior Education for the Netherlands. Define termination reasons for exchange visitors.

AV, SA AV, SA AV, CSS, SA AV, SA SA SA SA SA AV, SA SA SA

Operator Defaults NSC Branch Table Cluster Code Table NLD GBA Country Code Table MBO Code Table NLD BRINcode Table NLD GBA Nationality Code Table Prior Education Table NLD J Visa Termination Reasons Port of Entry Table

SA

Define the SEVIS port of entry values.

SA

Position Code Table

Define SEVIS position code values.

SA

Fee Code Table

Define the fees and expenses for the I-20 form defaults.

SA

US Government Agency Code Tbl International Organization Tbl

Define SEVIS US government agency values. Define SEVIS international organizations values.

SA

SA

Contributor Relations Contributor Relations Contributor Relations, Campus SelfService Contributor Relations Student Records Student Records Student Records Student Records Campus Community Student Records Student Records CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA 272

APPENDIX

Dept of State Post Code Table

Define the Department of State post codes.

SA

Visa/Level of Education Map

Map levels of education to SEVIS visa types.

SA

Country Mapping

Map SEVIS country codes to PeopleSoft countries.

SA

Visa Mapping

Map SEVIS visa code to PeopleSoft visa types.

SA

Suffix Mapping SEVIS Event Types SEVIS File Errors Site of Activity Table

Map SEVIS suffix codes to PeopleSoft suffix values. Define SEVIS event types and form request defaults. Define file errors returned from SEVIS. Define site of activity information reportable to SEVIS.

SA

AV, SA AV, SA

SA

SEVIS Program Sponsor Table

Define SEVIS program sponsor and reporting structure information.

SA

SEVIS School Code Table

Define SEVIS school codes and reporting structure information.

SA

SEVIS Setup

Define processing rules for addresses, names, majors and minors.

SA

I-20 Template

Define default values for the I-20 form by institution, career, program or plan.

SA

Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting Campus Community Campus Community CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting CS USA USA Regulatory Reporting 273

APPENDIX

User Defaults

Define user defaults.

AV, SA

Campus Community

274