You are on page 1of 19

RELEASE CONTENT DOCUMENT

Release 12 Public Sector University ORACLE STUDENT SYSTEM


Oracle Student System Oracle Financial Aid

Prepared by Student Product Management Team

Last Updated: Version:

03/09/2006 2.0

Copyright 2006, Oracle. All rights reserved.

Table of Contents 1. 2.
2.1. 2.2.

Disclaimer Introduction
Purpose of Document Reference Documents

1 2
2 2

3.
3.1.

Oracle Student System R12


All Modules
3.1.1. New Features 3.1.1.1. Security

3
3
3 3

3.2.

System Wide Services (SWS)


3.2.1. Overview 3.2.2. New Features 3.2.2.1. Security Framework 3.2.2.2. Correspondence Preview and Edit

3
3 3 3 4

3.3.

Admissions
3.3.1. Overview 3.3.2. New Features 3.3.2.1. Automatically Admit Students Based on Criteria 3.3.2.2. Enhancements to Applicant Self Service 3.3.2.3. Re-open Admission Application

4
4 5 5 5 6

3.4.

Program Structure and Planning (PSP)


3.4.1. Overview 3.4.2. New Features 3.4.2.1. Scheduling Enhancements

6
6 6 6

3.5.

Enrollment
3.5.1. Overview 3.5.2. New Features 3.5.2.1. Self Service Enhancements 3.5.2.2. Intermission Authorization to Return

7
7 7 7 9

3.6.

Student Finance
3.6.1. Overview 3.6.2. New Features 3.6.2.1. Tuition Waivers 3.6.2.2. Fee Calc Enhancements 3.6.2.3. 1098T Reporting 3.6.2.4. Automatic Receipt Numbering 3.6.2.5. Convergence of Student Finance and Oracle Accounts Receivable

9
9 9 9 10 10 11 11

3.7.

Financial Aid
3.7.1. Overview 3.7.2. New Features 3.7.2.1. FISAP 3.7.2.2. Student Self Service Enhancements 3.7.2.3. Automatic Repackaging Enhancements 3.7.2.4. Update COA Enhancements

11
11 11 11 12 12 12

3.8.

Academic Records
3.8.1. Overview 3.8.2. New Features 3.8.2.1. Transfer Evaluation 3.8.2.2. NCAA Tracking

12
12 12 12 13

3.9.

UCAS

13
ii

R12 OSS Release Content Document, Rev. 00

3.9.1. Overview 3.9.2. New Features 3.9.2.1. HERCULES Support for Small Systems 3.9.2.2. UCAS Transactions and Conditions Improvements

13 13 13 14

3.10.

HESA
3.10.1. Overview 3.10.2. New Features 3.10.2.1. Load DLHE Target Population 3.10.2.2. Award Outside HESA Reporting Period

14
14 14 14 15

4.

Appendix
4.1.1. Technology Stack

16
16

R12 OSS Release Content Document, Rev. 00

iii

1.

Disclaimer
This Release Content Document (RCD) describes product features that are proposed for the specified release of the Oracle E-Business Suite. This document describes new or changed functionality only. Existing functionality from prior releases is not described. This RCD in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle Corporation. This document is subject to change without notice until such time as details of the release are finalized and should not, therefore, be taken as a commitment to deliver functionality. This Release Content Document is intended to outline new or changed functionality only. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this Release Content Document remain at the sole discretion of Oracle.

R12 OSS Release Content Document, Rev. 00

Purpose of Document

2.

Introduction
2.1. Purpose of Document
The Release Content Document (RCD), produced as part of Oracles Applications Product Lifecycle (APL), communicates information about new or changed functionality in the specified release of the Oracle E-Business Suite. Existing functionality from prior point releases is not described. However, content introduced by Family Packs, MiniPacks or Standalone patches since the prior point release has been included in this document and denoted accordingly. This release consists mostly of features and regulatory updates already released in 11i.IGS.M and RUP1. The Student Finance and Accounts Receivable Convergence feature is the only new item for Release 12.

2.2.

Reference Documents

NOTE: All RDDs are located in the IGS.M JW Public folder.

R12 OSS Release Content Document, Rev. 00

Purpose of Document

3.

Oracle Student System R12


3.1. All Modules
3.1.1. New Features
3.1.1.1. Security A Security Framework was delivered for OSS with the IGS.L release, and applied to the Admissions subsystem. In this release this framework is used for other OSS subsystems. The solution provided is architectural in nature. It will maintain the security and integrity of OSS by controlling access to the data and the data within it at greater levels of granularity, e.g. by Organization. That is, the solution is a blueprint for meeting current data security requirements where each module team will identify components (objects and attributes) that are both necessary and sufficient for their respective area. These requirements are entered through an appropriate UI Setup (set of self service screens) that provides the Framework with a default security policy delivered with the release as seed data. These components then get plugged into the Framework, all of which is transparent to the end user. To allow for greater extensibility, OSS also provides appropriate personnel the ability to enter information using self-service screens to extend the default security policy.

3.2.

System Wide Services (SWS)


3.2.1. Overview
The Oracle Student Solution utilizes a common facility (SWS) across all subsystems that enable consistent and integrated features to be enabled for any user in any subsystem.

3.2.2.

New Features
3.2.2.1. Security Framework A security framework is included in the IGS.L release of OSS, which allows access to the OSS data model based on security attributes for users and business objects. In IGS.L, the admission subsystem delivered a security policy using this security framework. These are the enhancements, which address the new security requirements: Additional user attributes are provided for associating Location, Program Type, and Attendance Mode to a user. Function security is provided for business processes, which access other business objects across subsystems. This release includes a mechanism for assigning security roles to a group of users.

R12 OSS Release Content Document, Rev. 00

All Modules

A method for initiating a security check is provided for processes that are launched from a UI. Meaningful messages are used for processes and user interfaces which encounter violations of the security policy. Tthe admission security policy is enhanced to take advantage of the new security framework features listed above. In addition, the person details, enrollment, academic records, financial aid, and HESA subsystems are delivering security policies, which will provide access control to the appropriate business processes and business objects. 3.2.2.2. Correspondence Preview and Edit The IGS.L release of OSS does not provide a means to validate letter production after a correspondence request commences. During the letter production process, this new feature allows users to review the content of the letters to ensure that:

The correct data substitution, text, and layout has been used Printed letters make optimal use of paper The list of recipients includes only those intended for the specific distribution The intended distribution medium will be used (email, print, etc) The correct output format is used for the intended distribution medium (html, pdf, etc) The correct delivery address (virtual or physical) has been used for each recipient During the correspondence review process, users may apply specific changes to one or more letters in the batch (including changes that are applied to all letters in the batch), and will confirm using preview that the edits are applied correctly and that the letters are still well formed. All correspondence requests will continue to preserve the exact copy of the letter sent to a recipient. Correspondence letter production control is used to determine the total number of times a letter should be sent, or the elapsed days between letters.

3.3.

Admissions
3.3.1. Overview
The Oracle Student Admissions module enables quick response to initial inquiries, follow-up requests, and applicant communications. A wide range of admission planning activities and processes are supported through capabilities and user-configurable procedures for different admission categories. Specific sets of program and organizational unit criteria can be applied to different cohorts of applicants across distinct calendars and colleges. Multiple concurrent applications can be managed for a student within and across academic careers (undergraduate, graduate, professional, etc.). Because a person is created one time in the system, a history of all applications is maintained on record, regardless of the campus and the program the student submitted the application.

R12 OSS Release Content Document, Rev. 00

Admissions

3.3.2.

New Features
3.3.2.1. Automatically Admit Students Based on Criteria In the IGS.L release of OSS, Admissions provides support for the manual evaluation of admission applications. In addition, support is provided for creating workflows to automate the evaluation process to varying degrees. Business Events and public APIs are provided to enable customers to build localized workflows and record outcomes. The aim is to extend the ability to automatically record an application outcome based on data recorded in the system, which meets or fails the admission criteria specified for the particular application type. E.g., an applicant who has an ACT score >20 or high school rank in the upper third of their class or HS GPA > 2.0 in a core curriculum program will be automatically admitted (KSU example). This enhancement builds upon the existing application processing framework and provides support for: Defining the application evaluation appropriate to each application type Automatic initiation of the evaluation process on application submission Extended capacity for capturing qualifying criteria and recording the outcomes of each step in the evaluation process. System assessment of the evaluation outcomes for the determination and recording of the application outcome. With these additional features customers have greater control over the definition of application evaluation processing, evaluation initiation and acting upon the evaluation outcomes. The ability to record the qualifying or disqualifying outcomes against the evaluation steps also provides greater audit capabilities on application decisions and increased flexibility in reacting to changes in application related data. 3.3.2.2. Enhancements to Applicant Self Service OSS Admission provides support for applicants to enter their applications through WEB based self-service functionality. For some application types completing the application can be a lengthy process and may lead to frustration and confusion for the applicant. Once the applicant has successfully submitted their application they can review or be advised of their outcome through correspondence, but they cannot respond directly to the institution through self-service functionality. The group of enhancements seeks tosimplify and streamline the application entry process. This includes improvements and increased flexibility for administrators configuring application types. These enhancements take advantage of recent additions to self-service framework functionality. Additional functionality assists the prospect in determining which application should be completed, guiding the applicant through the application process, reviewing and updating applications, and responding to admission decisions. Providing more intuitive admissions self-service functionality aids customers in their deployment of web based application processing to prospects. The ability for applicants to respond to offers through self service l greatly reduces the administration overheads and provide applicants with a consistent and streamlined end-to-end admissions process.

R12 OSS Release Content Document, Rev. 00

Admissions

3.3.2.3. Re-open Admission Application The ability for an applicant to change his or her mind about an outcome response and/or the institution changing its mind about an outcome or other application details are legitimate aspects of the admissions business process cycle. The administrator needs the ability to re-open an application in back office or admissions self-service in order to amend it. The reasons for this are: To record a change of response on behalf of an applicant. Error correction

In the IGS.L release of OSS, Admissions does not allow the application to be further processed by the applicant or the administrator once the application has been closed i.e. once an offer response has been entered; certain negative outcomes have been recorded. The current reconsideration functionality does allow for administrators to re-open an application via the back office forms for applications with a system outcome of reject or no-quota. This enhancement allows administrators to re-open and update any aspect of the application in a controlled fashion. It is important to note that once unit attempts have been confirmed (i.e. enrolled), re-opening admission applications will not be possible. During the period post the recording of the initial response but prior to enrollment, administrators will be able to re-open and modify applications to reflect applicants changes of mind and, to a lesser extent, correct any processing or data errors.

3.4.

Program Structure and Planning (PSP)


3.4.1. Overview
Within the Oracle Student System, the PSP module provides an institution the ability to set program attributes that are either tightly defined or freely structured - whether its traditional degree programs, alternative certificates, or continuing education program. Versatility is inherent in the system structure for academic program and unit details (a unit is defined as a learning event, e.g. course, workshop, etc). Unit sets provide further flexibility to define programs of study and cluster requirements in the various ways that colleges across the University structure majors, minors, concentrations, and emphases. Likewise, units can be set up as traditional semester-long classes, to one-time learning events, in unit sections.

3.4.2.

New Features
3.4.2.1. Scheduling Enhancements In the current release of OSS, the scheduling interface has basic functionality to support the importing of logistic information for a unit section occurrence (class). OSS interfaces with third party scheduling software, such as Ad Astra, CollegeNet and Scientia. The basic communication between OSS and the third party scheduling software is established through APIs where data is mapped between OSS and the third party scheduling interface. Customers must create the unit sections and unit section occurrences in OSS prior to importing the logistic information from a third party scheduling software.

R12 OSS Release Content Document, Rev. 00

Program Structure and Planning (PSP)

3.4.2.1.1. Importing Unit Sections and Unit Section Occurrences The interface is enhanced to allow the import of class schedules created in the third party scheduling software into OSS. The interface fully supports the import of unit sections and unit section occurrences. 3.4.2.1.2. Improved Functionality The following enhancements are included to improve the scheduling interface functionality: Allow the rescheduling of a unit section occurrence when information about the unit section or the unit section occurrence has changed Allow users to cancel the scheduling process without having to manually cancel each unit section occurrence Provide the ability to purge cancelled academic records from the interface table The ability to schedule a building without a room is a must for institutions that provide off-campus courses The ability for the same building, room to be assigned to cross listed and meetwith groups are essential to provide the information for the students during enrollment The institutions need to be able to schedule occurrences in meet-with groups

3.5.

Enrollment
3.5.1. Overview
The Enrollment module includes options for pre-enrolling students at the time of admission, for simultaneous enrollment and admission, for batch enrolling continuing students, and registration for both credit and non-credit classes across multiple locations. Students can be assigned to defined enrollment sessions (time slots) based on multiple selection criteria. Using self service enrollment, users have the ability to search for units, add and drop units, view a student schedule, and view all eligibility restrictions, special permissions and enrollment overrides, and timeslots assignments. Institutions will be able to set up a workflow process for unit sections requiring special permission easing the request and approvals processing.

3.5.2.

New Features
3.5.2.1. Self Service Enhancements The current student enrollment self service consists of several business flows that allow students to manage their term schedules. They can search for available unit sections and as needed add and drop unit sections. If a class requires special or audit permission they can submit the necessary request for permission. If a class is full the student can elect to waitlist for the class. These enrollment flows contain validations (e.g., pre-requisite, co-

R12 OSS Release Content Document, Rev. 00

Enrollment

requisite) defined by the institution that inform the student whether they are eligible to enroll in selected unit sections. 3.5.2.1.1. Ease of Navigation and Usability The student enrollment self service is enhanced to simplify the navigation for all business flows and to provide a more intuitive user interface. Information is provided to students as early in a business flow as possible. The business flows are made more consistent and simplified to provide a clear path for the student and to provide them with relevant information when they need it. Validation messages are improved so that the students are clear on what actions need to be taken. 3.5.2.1.2. Schedule Planning In the IGS.L release of OSS, students can only access enrollment activity once the enrollment period has been opened. Any planning must be done manually outside of the student system. A new feature is introduced to provide students with an easy to use enrollment interface to plan a schedule in advance of actual enrollment. This planning sheet functionality will be similar to the schedule. It includes validations that will provide students with the information they need to build a sound plan. These will include the following: Provide advanced notice regarding whether the student is eligible to enroll in a unit section (e.g., pre-requisites) Provide advanced notice regarding actions the student needs to take to be able to enroll in a unit section (co-requisite, special or audit permission).

The planning sheet does not reserve seats, however it does provide the student with information about available seats and waitlist seats, allowing them to assess their chances of successfully enrolling. This feature allows proactive students to plan their schedules in advance of open enrollment and increase their chance of getting the schedule that they desire. 3.5.2.1.3. Audit Grade It is common practice for a student enrolled in a non-audit attempt to change to an audit attempt, and vice versa. Currently, the system requires users to add a unit attempt as an audit attempt, if the audit is desired. The student is required to drop the current unit section and create a new unit attempts with the desired change. The process for changing the audit status is modified to allow students to move between receiving an audit grade and receiving a non-audit grade for the same unit section without requiring the student to drop and re-add the unit section. This allows the student to move from an audit attempt to a non-audit attempt or vice versa, without the risk of losing the seat in the unit section. 3.5.2.1.4. Conditional Add/Drop A student changing one unit section for another is a common practice in enrollment. The student may identify a unit section that has a more desirable meeting time or instructor. While swapping unit sections a student will want to ensure that they can obtain a seat in
R12 OSS Release Content Document, Rev. 00 Enrollment 8

the new unit section before giving up their seat in the old unit section. If a student is at their maximum credit point level they will be prevented from adding any new unit sections without first dropping an existing unit section. The current system provides a workaround to address this situation. During an enrollment session, a student can add a new unit section (seat is reserved) to their enrollment cart. While holding the new unit section in their cart they can navigate to their schedule and drop the old unit section. Once the old unit section is dropped they would process the new unit section from their cart. A new business flow is introduced that will simplify this process by allowing the student to select existing unit section(s) they are willing to change, identify the new unit section(s), and process the exchange. This allows the student to use a straightforward flow to ensure that they will be successfully enrolled in the new unit section before giving up their seat in the old unit section. 3.5.2.2. Intermission Authorization to Return Institutions have intermission policies whereby conditions applied to their particular type of intermission must be met before a student can be authorized to return from intermission and be eligible to undertake enrollment activities. Provide administrators with a means to indicate that the student has successfully met conditions required to return from intermission.

3.6.

Student Finance
3.6.1. Overview
The Student Finance module allows versatile definition and maintenance of discrete student tuition and fee charges and payments, and provides a set of tools to establish the rules controlling their application. It enables you to establish multiple tuition rates based on student type, program, and residency and also based on non-credit and continuing education fees and user-defined fee types and fee. The ability to make a fee assessment of students prior to registration is also available. Tuition and fees may be structured by teaching period, units, unit sections, credit points, locations, or combinations of these. External or third-party charges (such as from housing or dining), or charges which are optional, can be incorporated into the student system charges. Thus, all student charges are accommodated by the system.

3.6.2.

New Features
3.6.2.1. Tuition Waivers Some higher education institutions provide the students tuition benefits through Tuition Waiver Programs by "waiving" off tuition and fees based on certain eligibility criteria. All the recipients of waivers would owe only those fees that are not covered by the waiver. In the IGS.L release of OSS, the schools use the existing financial aid functionality to create a fund for the waiver and then manually award the students from that fund. In a

R12 OSS Release Content Document, Rev. 00

Student Finance

large school where a large number of students have fee or tuition waivers, manually awarding the students would be cumbersome and time consuming. This enhancement l provides the ability to identify individual students (or groups of students) that would have a tuition waiver associated with them and to calculate the value of each students waiver based on the actual amount of the fees for the student. For example, if the student were to receive a 100% waiver of tuition only, then the system would, upon calculation of tuition for the student, create an offsetting credit in the same amount as tuition and post it on the student's account. The student would then owe only those fees not covered by the waiver. The system responds to change in enrollment status or other factors that may cause the waived fee to change, recalculate the waiver and make the appropriate adjustments. The financial aid module is also aware of these amounts so they can be taken into account as part of the students' financial aid awards. 3.6.2.2. Fee Calc Enhancements There is a need for institutions to use student unit attempt attributes such as Unit Level and Unit Location in charge rate and charge element calculation respectively to assess tuition and fees for students. The first fee assessment enhancement will provide the ability to assess fees for Units associated to a Student Program Attempt, where rates are based on the Unit Level e.g. graduate, undergraduate etc. As an example, if a non matriculated student, takes 3 graduate level units and 2 undergraduate level units, the tuition would be charged for the graduate units at the graduate rate and for the undergraduate units at the undergraduate rate. A second enhancement enables the institution to charge fees using the attributes of the individual units in the charge element calculation. As an example, schools need the ability to group the student unit attempts by location of the unit and use that in the element range equation for fee assessment. Consider a student that takes 3 units (9 credits) at Location A and 2 units (6 credits) at Location B. The student is charged separately for the 9 credits (Location A) using a different rate and element range calculation in comparison with the 6 credits (Location B) using a different rate and element range. 3.6.2.3. 1098T Reporting Internal Revenue Service (IRS) regulations under section 6050S, enacted through the Taxpayer Relief Act of 1997, amendments, as well as the Final regulations issued through the Federal Register update in Dec-2002, defines information reporting requirements for qualified tuition and related expenses by eligible educational institutions. This enhancement provides the institution with the ability to comply with the information return requirements of federal U.S. tax Form 1098-T, Tuition Statement, related to reporting qualified tuition and related expenses to the Internal Revenue Service (IRS) and to Students. The initial release of the 1098T reporting functionality is included under the reporting method of Box 2 Amounts billed for qualified tuition and related expenses. The functionality provides the Institution the ability to prepare a file using standard ASCII code for electronic submission to the IRS and to furnish the 1098-T statements to students.

R12 OSS Release Content Document, Rev. 00

Student Finance

10

3.6.2.4. Automatic Receipt Numbering Institutions receive payments from students through a variety of methods that include over-the-counter receipts, lockbox, financial aid, sponsorship credits, self-service credit card payment and other external sources. In order to maintain accurate record keeping and to satisfy audit requirements, the current design ensures that on receipt creation, the receipt numbers are unique for a student. Currently, for over-the-counter receipts, the user is expected to enter a receipt number manually. This enhancement ensures automatic assignment of a system generated, sequential receipt number for an over-the-counter receipt. 3.6.2.5. Convergence of Student Finance and Oracle Accounts Receivable In the IGS.L release of OSS, all student related receivable functions are managed in the student finance module. As part of the R12 Financials initiative, OSS and AR teams are evaluating the convergence of student finance functions to the Oracle Receivables module. The OSS and AR teams provide a solution, which delivers all the current Student Finance features and functions using the Oracle Receivables module as the backbone. This facilitates the management of Receivables (student and non-student related) in a central Receivables system.

3.7.

Financial Aid
3.7.1. Overview
The Financial Aid module of the Oracle Student System (OSS) provides features and data views for managing financial aid, beginning with initial application receipt, and continuing through all of the necessary processing steps including eligibility processing, awarding, disbursing, monitoring, and reporting for all types of financial aid awards. Financial aid applicant data management and processing functions l provide for the timely electronic exchange of financial aid data from the Federal Central Processing System (CPS), Common Origination and Disbursement (COD) system, the College Board, and student loan lenders using the CommonLine industry standard.

3.7.2.

New Features
3.7.2.1. FISAP The Fiscal Operations Report and Application to Participate (FISAP) is required annually for schools participating in the U.S. Department of Educations Campus Based Programs. OSS will provide the ability to produce data to complete Part II (Information on Eligible Aid Applicants for Award Year) and Part VI (Program Summary) of the FISAP. Part II is the Application to Participate and provides detailed breakdown of the number of eligible aid applicants in each income category. Part VI is the Fiscal Operations Report (Program Summary) and reports the distribution of campus-based aid recipients by type of student (undergraduate dependent, undergraduate independent, and graduate/professional). Within each "type," recipients are further broken down and reported on the basis of income level.

R12 OSS Release Content Document, Rev. 00

Financial Aid

11

3.7.2.2. Student Self Service Enhancements OSS currently provides a student self-service, view-only capability for Financial Aid Awards and Student To Do list information. In addition, OSS provides functionality for acceptance of Financial Aid awards and selection of student loan lender. Students will also be able to respond to requests for information in self-service mode. 3.7.2.3. Automatic Repackaging Enhancements Students may often have changes in circumstances that require a reconsideration of their financial aid award packages. In addition to existing award repackaging functionality, OSS provides the ability to produce Award Notification Letters in an Awarding Period context, and administrator access to the student self-service view of financial aid awards. 3.7.2.4. Update COA Enhancements The award year based setup for determination of student cost of attendance (COA) uses a COA Rate Table that allows the setup of COA rates based on student attributes. OSS provides the ability to roll over the COA from one award year setup to the next.

3.8.

Academic Records
3.8.1. Overview
The Academic Records module enables detailed setup and tracking of academic assessment items (e.g. papers, exams, portfolios, oral presentations, etc.), either for patterns of study or for individual students. Assessment management is provided through recording requirements, expectations, and due dates; recording outcomes and extensions; and administering examination details such as timetables, allowed and supplied materials, attendance, assignment of supervisors and proctors, and allocation of provisions for individualized student needs. Always current class lists are available to faculty and staff through self-service, and students on the class list may be selected (e.g. include or exclude dropped) and sorted as the user desires.

3.8.2.

New Features
3.8.2.1. Transfer Evaluation The transfer evaluation component was deferred from the original Degree Audit Interface design. This feature completes the automatic articulation process of creating advanced standing records based on a students academic history using external software such as DARS or DAG to provide the articulation results. Currently, the system can link to external systems to get a report of articulated classes, but the advanced standing entry is a manual process. The system needs to be able to automatically provide an articulation for transfer students so that external coursework can be matched against OSS program requirements and have

R12 OSS Release Content Document, Rev. 00

Academic Records

12

the advanced standing automatically created. As part of the degree audit process, an automated articulation process provides a higher level of service to the student, especially in the case of feeder school relationships where articulation agreements exist. 3.8.2.2. NCAA Tracking Schools participating in intercollegiate athletics have to report to the NCAA on a regular basis as defined in the bylaws of the NCAA. Schools that participate in intercollegiate athletics need to be able to track a student athletes eligibility at the student unit attempt level. Not all of the units that a student athlete is enrolled in may count towards the athletes academic eligibility, and a unit that may count towards one student athletes eligibility may not count towards another athletes eligibility. A course may or may not be considered eligible for the student based on what program a student is enrolled in, and in some cases, a student might complete a repeatable unit where the first unit is considered eligible but later completions of the unit are not considered eligible. The student unit attempt eligibility is used to calculate academic statistics for the student athlete. Schools need to report how many hours a student athlete is eligible and how many hours an athlete has completed of eligible units for both term and cumulative periods. This NCAA tracking enhancement provides the foundation for the required NCAA reporting.

3.9.

UCAS
3.9.1. Overview
The Oracle Student System provides full support for processing UCAS Applications. Support is provided for the UCAS Full Time Undergraduate Admissions system via both the Hercules and Marvin Interfaces. Support for the two small systems (NMAS, and GTTR) is provided via the Marvin Interface.

3.9.2.

New Features
3.9.2.1. HERCULES Support for Small Systems In the UK, University Applications are processed by the University and Colleges Admissions Service (UCAS). Processing of Applications is controlled at UCAS by three systems: UCAS Full Time Undergraduate Applications (FTUG) GTTR Graduate Teacher Training Registry NMAS Nursing and Midwifery Admissions Service GTTR and NMAS are collectively known as Small Systems.

In preparation for UCAS decommissioning the MARVIN system at the end of the 2007 application cycle, the Hercules interface is extended to incorporate full application processing for GTTR and NMAS applications.

R12 OSS Release Content Document, Rev. 00

UCAS

13

3.9.2.2. UCAS Transactions and Conditions Improvements During the processing of applications, UK institutions need to communicate their actions to UCAS, the central body in the UK for processing university applications. This communication is performed via UCAS Transactions that contain details of the decisions made, the conditions included in conditional offers, change of course information, etc. The transactions are automatically generated within OSS Admissions and the UCAS Interface Modules or they can be manually created if necessary. These transactions are then transmitted to UCAS. When a conditional offer is made to an applicant the conditions associated with an offer are recorded, this can be done by either selecting a condition from the condition library or by entering an ad-hoc condition as a coded string. The condition library is enhanced to allow users to identify the library conditions more easily and the ad-hoc condition entry is extended to enable users to be able to construct an ad-hoc condition in a structured manner similar to that used to build the conditions within the condition library. The functionality to allow users to review transactions on hold is improved and the processing of transactions on hold is streamlined by providing functionality to allow users to automatically release a block of transactions on hold.

3.10. HESA
3.10.1. Overview
Oracle Student System enables institutions to generate the student based HESA returns; Combined, Student and Module and reduced individualized student returns can be produced as either fixed format or comma separated files for submission to HESA. Institutions can also define internal returns as a subset of the HESA fields for internal reporting. A powerful full time equivalent calculation process is provided to enable institutions to calculate student FTE according to funding council guidelines for both internal and external reporting.

3.10.2.

New Features
3.10.2.1. Load DLHE Target Population The Higher Education Statistics Agency (HESA) requires all UK Higher Education Institutions to submit an annual return on the destination of selected students as a supplement to the Student Record, the Destination of Leavers from Higher Education (DLHE) survey. This DLHE survey records the employment and further study situation of (1) selected graduates on a census date approximately six months after completion of studies and (2) selected research students who are surveyed approximately fifteen months after their research council funding has finished. In the IGS.L version of OSS, the HESA DLHE target population can be identified using the Identify Target Population concurrent process but users must manually reconcile the target population with the target population HESA are expecting. With this new feature, institutions are able to import the HESA target population file, the POPDLHE file, and to automatically reconcile the POPDLHE file with the target population identified by the Identify Target Population. The Identify Target Population process is amended to reflect the recent changes to the rules defining whether a research student should be included in the target population.

R12 OSS Release Content Document, Rev. 00

HESA

14

3.10.2.2. Award Outside HESA Reporting Period Allow institutions to specify the award period for undergraduate and post graduate taught courses so that awards for programs completed in a particular HESA reporting period but which are conferred after the end of the HESA reporting period are reported in the reporting period in which the program was completed.

R12 OSS Release Content Document, Rev. 00

HESA

15

4.

Appendix
4.1.1. Technology Stack
Uses the standard E-Business Suite 11i technology stack.

R12 OSS Release Content Document, Rev. 00

HESA

16