|
|
|
|
|
Understanding
Student Finance
In
this section:
General
introduction
Working
with this subsystem
Important
terms
Inquire on individual students
See
also:
VARPAC - Reporting Higher Education Contribution Scheme
(HECS) Variations
An
overview for the specialist user gives information
about setting up the subsystem and the concepts that underpin this task. The
section Special Topics deals with some aspects
of the subsystem in greater depth. Individual documentation for all forms,
reports and processes can be accessed from the subsystem's Table of Contents. Links to all these references
are given as appropriate throughout the documentation.
Introduction
to Student Finance
Callista's
Student Finance subsystem is designed to manage fees incurred by students
when they apply for admission and enrol in courses of study at an institution.
It covers fee assessment, payment scheduling, the invoicing of students or
sponsors, penalties for non-payment, and revenue distribution. Typical fees
handled by the subsystem include a student's HECS, tuition, and general service
fees. Charges might also apply for items such as laboratory use, the dispatch
of materials and computer access.
In
certain areas, the subsystem is designed to interface with an external financial
system via a separate interface. This is the Callista Open
Finance Interface (COFI) that can be supplied with Callista. COFI allows student
fee information to be integrated with the institution's accounts receivable
and accounts payable applications and recorded in the general ledger. It also
allows payments to be received and refunds provided through the financial
system. Information about the COFI component is available through Deakin Software
Services.
Working
with this subsystem
The
majority of Student Finance forms are used in setting up the data framework
within which fee processing operates. Once data structures are established,
very little subsequent data entry is required. Day to day work consists mainly
of running and monitoring jobs and reports, and using a small number of forms
to satisfy queries and make fee related adjustments to individual student's
records.
A
data structure is created for each fee period within the institution's financial
year (see fee periods in a later section). This framework
can be 'rolled over' from year to year, and modifications made as required.
Fee processing also follows a cycle based on a fee period.
User
responsibilities
Creating
the data framework in conformity with government and institution policy is
expected to be handled by specialist staff such as student finance
or fees officers, in conjunction with specialists in other subsystem areas.
Accordingly, a very brief summary of the data structures is given here, with
more information in the Specialist Overview section.
The
section on processing and reports provides an outline for specialist and general
staff alike.
The
responsibilities of general staff, either in student records, faculty
or elsewhere, may include answering individual student's queries, monitoring
scheduled student finance jobs and reports, and running jobs and reports on
an ad hoc basis. The current section aims to give an initial insight and reference
point for these tasks.
Data
structures
To
provide a framework for fee processing, it is necessary to
- establish time periods and
dates relevant to the administration of fees, using the Calendar subsystem
- record fees, and whether
they apply
- only to particular courses
or units or are institution-wide
- only to particular groups
of students - for example, only to international or only to undergraduate
students
- determine schedules for
payment, retention/refund and penalties
- set up the patterns of disbursement
for particular fees.
See
details in the Specialist Overview section.
Processing,
reports and work flow
With
a data framework established, day to day work in the subsystem revolves around
the processing outlined below. More detailed information about the jobs and
reports involved can be accessed through the links given here.
This
description represents a fee processing cycle for a single fee period. It
covers individual sponsorship and contracts, assessment and invoicing, payment and refunds, action
on non-payment, statistical data and fee
disbursement.
Note
that the receipt of payments is dependent on a cash receipting system external
to the Student Finance subsystem.
Some students have sponsors who undertake to pay
all or some of their fees. Once sponsorship reference details have been recorded in the subsystem,
Students or their sponsors may have contracts
with the institution regarding the rate at which particular fees are charged.
These contracts are of two kinds:
- Contracts established for
particular categories of applicants at admission time. For tuition fees,
such contracts can be created automatically as a part of the pre-enrolment
process. For certain other fees, they can be set individually after pre-enrolment.
These contracts are agreements by the institution to peg the relevant fees
at the standard rates in effect when the contract commences, and for a specified
period. Normally this is for the duration of the course to which the fee
applies.
Automatic creation of tuition contracts is achieved by
running job ENRJ3100. This job can be run in batch mode, or initiated by
making an offer in the form ADMF3240. Documentation on pre-enrolment gives background information.
To set fee contracts individually through Admissions,
the form ADMF3660 (Establish Fee Contracts) is used.
- Contracts created directly
in the Student Finance subsystem. Such contracts represent a rate negotiated
individually between the student or sponsor and the institution. The negotiated
rate may differ from student to student, and its effective duration can
be open-ended. These contracts are created in FINF2900 (Maintain Contract
Fee Assessment Rates).
For either kind of contract, any maintenance must be
done in FINF2900.
Contract arrangements should be recorded on the database
before the fee assessment cycle begins.
Report and job supporting
sponsorship:
- Sponsored Students (FINR0140)
Fee assessment. The central process in the
Student Finance subsystem is the fee assessment routine, with its associated
trace report. This routine determines the fees applicable to individual students,
calculates the relevant amounts (including tax amounts due on taxable fees)
and stores this information as a debt for which the student, or his or her
sponsor, is liable. If a student's enrolment alters, this routine also handles
re-assessment.
The fee assessment routine can be run in four ways:
- as a predictive assessment
of course-related fees for individual applicants being processed through
the Admissions subsystem. The assessment can be initiated for individual
applicants from a button in the form ADMF3660, and further details are
given there.
- from the Course Attempt
screen of ENRF3000, which will run FINJ3500
directly for a single student course attempt. The effective date defaults
to the current date, but can be set to an earlier date.
For course attempts with a status of UNCONFIRM,
the fee assessment routine will be run in predictive mode. Predictive fee
assessments cannot be made for HECS fees (System fee type = HECS) or
for fees with a PERUNIT charge method. Institution fees are only considered
if no other course attempts are liable.
- by processing database
entries (known as 'student To Do entries') which identify each student
who has enrolled or changed their enrolment since the last fee assessment.
The job accessing To Do entries (FINJ3001) runs in batch mode. It
is suggested that FINJ3001 is the initial assessment run for a fee period,
and that it is scheduled to run nightly thereafter.
- by running as required
in either immediate mode or batch mode for one student, a group
of students or all eligible students, with selection by parameter. Further
parameters allow great flexibility in using the routine. Note particularly
that this mode allows a test run without updating the database. Run the
routine in this way using the job FINJ3500. This method can also
be used to run predictive assessments for one or more Admissions applicants,
as long as they have been pre-enrolled.
Note that predictive assessments can be reversed should
the applicant not take up the offer of a place in the relevant course. This
is achieved by running job ADMJ3850 (Clean Up Unconfirmed
Student Course Attempts).
For students starting a course who are assessed for fees
within a current fee period but before their course commencement date, the
effective date used by the fee assessment routine is taken to be the commencement
date of the student course attempt. This ensures that for these students,
statements requesting payment and fee disbursement journals reflect the correct
fee and enrolment information.
Manual fee assessment. The form FINF3610 can be used, in exceptional circumstances, to make a
first assessment or to adjust an existing assessment by means of manual transactions.
Once a manual assessment exists for a fee, the student cannot be assessed
further via the fee assessment routine for that particular liability.
Although there are screens designed specifically for
fee inquiry – FINF9100 (Student Course Fee
Inquiry FINF9200 (Student Fee Calendar
Inquiry) and related screens – the manual fee assessment form also gives details
of an individual student's assessment, tax debt and payment details.
Create person payment schedules. At regular intervals
after fee assessments have been made, a further process (FINJ6111) is run to create a personal
schedule for each student not previously assessed, determining a date or dates
on which their fees should be paid, and the amount due (plus the tax due,
where applicable) at each date. This routine also updates personal schedules
after reassessment.
Invoicing. The person payment schedule records are used
in turn by routines (FINJ6120, FINJ6121, FINJ6130) that provide extract
files (Statement of Account, Reminder Notice, and Sponsor Summary Statement)
requesting payment of fees. The printing of these statements in whatever format
is required is the responsibility of individual institutions.
A process can be run to make bulk amendments to the dates
held in the person payment schedules should there be a delay in processing
statements. This is the job Add
Grace Period to Person Payment Schedules (FINJ6112).
The Maintain Person Payment Schedules form
(FINF3800) enables inquiry on an individual
student's schedule and the amounts for which they are liable. It is also possible
in this form to amend payment dates and discounting.
Reports. Validation reports for assessment and invoicing
are:
and for reference,
The receipt of payments is handled by an external financial
system, and the information returned to Callista via an interface to that
system. Payment information is shown in the Person Payment Schedule (FINF3800),
the Manual Assessment form (FINF3610) and in Student Finance inquiry forms.
The Student Finance subsystem handles debt management
in the event that students or their sponsors fail to pay by the due date(s),
as outlined in the next section.
It also handles the authorisation of refunds. Students
and sponsors can be refunded up to the amount of their available credit. Note
that available credit and refund information is not tied to a particular fee
period, but relates to fees paid throughout a student or sponsor's association
with the institution. This credit is re-calculated on query in the relevant
forms:
For groups of students selected by parameter, the job
Process Student Refunds (FINJ6430) can be run to create
pending refund records for subsequent approval in the Maintain Refunds form
(FINF6420), or it can be run to approve refunds automatically.
Once approved, refund records are available for transfer
to an external financial system for payment.
Reports. The following report gives detailed information
of all refund records created.
- Fee Refund Status Report
(FINR0280)
The functionality documented here relies on payment information
being obtained through an external financial system.
Reminder notices. The Reminder Notice extract
process (FINJ6121) can be used to create
reminder notices.
Check HECS payment options. For HECS fee types, non-payment
may in some cases be covered by a change in the student's HECS payment option.
The Process Student HECS Payment Options routine (FINJ6231) makes the necessary adjustments
to the student's record.
Check for payment. Fees can be paid in instalments.
After the dates on which payment is due, the Process Overdue Payment Penalties
routine (FINJ6230) allows a check for
non-payment, and marks defaulting students as potential candidates for particular
penalties by creating 'pending fee encumbrances'
for them. These students will be listed in
the report FINR0210 for further action.
Apply penalties. A student's enrolment may be
discontinued using ENRF3000 in the Enrolments subsystem, and/or a penalty
applied by confirming a 'pending fee encumbrance' through the Authorise Fee
Encumbrances form (FINF6311).
Writing off debts. Provision is made to write
off minor debts for students no longer studying at the institution. To do
so, run the job FINJ3700.
Reports. The following reports deal with non-payment:
Statistical data, including that pertaining to fees,
is documented in the Statistics subsystem.
The Process Student HECS Payment Option routine (FINJ6231) must be run in the Student
Finance subsystem before the final Enrolment Statistics Snapshot (STAJ0100)
is taken. This in turn is used to create the Government Submission Snapshot
(STAJ0110) and then the HECS Due file (STAJ0050) and the HECS Liability Status
file (STAJ0060).
Reports. This extract supports reporting to government:
- HECS Notice of Liability
extract (FINJ6190)
Income from fees, whether projected or actual, can be
allocated to different budget centres such as faculties and administrative
divisions. Formulas reflecting the required distribution are recorded for
each fee type. Setting up the formulas, and the data structures that support
them, is outlined in the Disbursement section of the Specialist
Overview.
The disbursement process is based on the relevant amounts
due from, and the amounts paid by, each student for each fee for which they
are liable. This includes any amounts retained when a student reduces their
study load or withdraws from a course.
A typical disbursement processing cycle would be as follows.
Create disbursement snapshots. The system produces
point in time snapshots of the disbursement pattern for fee types when the
job Process Disbursement Snapshot (FINJ7300) is run. Disbursement details
are recorded for each fee and income type (i.e. for both assessed or debt
amounts, and received or payment amounts for a fee). Three levels of
detail are recorded: a disbursement total for the fee; totals for each budget
centre (organisational unit); and allocation details at student, course attempt,
and unit attempt level as appropriate.
Check the disbursement process. These facilities
are available:
- The Fee Disbursement Snapshot
Exceptions Report (FINR7320) reports the
error messages from the run log (Inquire On Run Log - JBSF530 - in the
Job Control and Scheduling subsystem) and indicates situations where disbursement
was not possible for individual students.
- A set of browser scripts
giving access to the three tables holding calculated disbursement information,
though not part of the delivery set, can be made available through Deakin
Software Services.
If it proves necessary to amend data or disbursement
formulas, the snapshots can be deleted using the Delete Disbursement Snapshots
job (FINJ7310), and the cycle started
again.
Create journal entries. Once the disbursement snapshots
are satisfactory, journal entries can be created for all or a proportion of
the amounts available for disbursement, based either on assessed debt or payment
received, by running the Process Disbursement Journal (FINJ7400). If journal entries exist for
a particular snapshot, the first level of the snapshot can no longer be deleted
unless the journal entries are themselves deleted. To do this, run Delete
Disbursement Journals, (FINJ7410).
Authorise journal entries. Information from the first
two levels created in the snapshot can be seen in the form Authorise Fee Disbursement
Journal (FINF7400). Journal entries must be authorised before being available
to an external finance system.
Report. The following report supports disbursement:
- Fee Disbursement Snapshot
Exceptions Report (FINR7320)
Important
terms
The
terms given here provide a basis for understanding forms and reports used
in the day-to-day running of the subsystem. For other terms used as field
or block labels on the database, see the relevant form documentation or the subsystem glossary.
Fee
types, categories & liabilities
The
relationship between fee types and fee categories is central to the subsystem.
A
fee type is the database term describing the name of a fee or charge.
TUITION, HECS, GSF (general service fee) and LAB-FEE
are all examples of fee types.
A
fee category describes both a group of students, and a set of fees
for which those students may be liable, and provides the first link between
them. (A second link is that fees can be associated with particular courses,
and therefore with particular student course attempts.) The link is created
by the subsystem as follows:
- Either when applying for
admission to the institution or enrolling to study, a student is assigned
a fee category through the Admissions or Enrolment subsystem.
- In the Student Finance subsystem,
a fees administrator sets up fee types and fee categories independently,
and then assigns fee types to the categories. One fee type can be included
in many categories. Only fees assigned in this way are available for assessment.
A single fee type within a fee category is known as a fee liability.
- The fee assessment routine
makes the link between student and fee by matching fee categories. Students
are only potentially liable for a fee if it is included in their fee category.
An
example. An international science
undergraduate might be in the fee category INTERNATNL. This category
includes fees for tuition, general service, health benefit levy, laboratory
and computer access fees. A local student with the fee category DOMESTIC
may also be liable for general service and course related fees, but their
category will include a fee type for HECS and will not include a health
benefit levy.
Fee
periods
Two
time spans are particularly important to operations in the subsystem.
- The first is the fee
period, which you will see labelled in database forms as the fee
calendar instance and in some parameter collection forms as the fee
assessment period. Fee types, fee categories and liabilities, together
with the majority of other subsystem data, are set up to be effective only
within specific fee periods. Only students who are, or will be enrolled
in the same period will be liable for the fees set up in that fee period.
An example. A fee period (or 'fee calendar')
might be called FEE-SEM1. In 1999, the FEE-SEM1 fee period might
run from 1st January 1999 to 30th June 1999 (an 'instance'
of the fee calendar). Fee categories INTERNATNL and DOMESTIC
are set up for this period. Students in these categories, and with an actual
or prospective enrolment between these two dates, are potentially liable for
the fees in their respective category.
- The second
important time span is the time during which the fee assessment routine
can be effectively run for a particular fee period. This time span is defined
by a start date and an end date (also sometimes shown as a
start date alias and an end date alias) that are linked to
the fee period, but need not be the same as the beginning and end dates
of the fee period. Where required, the start date can be before teaching
begins.
While the start date alias and end date alias impose
limits on the effective assessment run date for a fee period, a third,
optional date can be set as an absolute cutoff point. This is the retro
date (also shown as the retro date alias). Once the retro date
has passed, the assessment routine cannot be run at all for the related
fee period, no matter what effective date is given in the fee
assessment parameter form. The retro date may also control the writing off
of minor debts incurred as a result of fee assessment.
In the absence of a retro date, it will not be possible
to physically run the fee assessment routine or write off minor debts after
the date defined by the end date alias for the fee period.
These
are the main time periods used in the subsystem, but other start and end dates
can also be set for different operations. These should be clear from the context.
For example, a start and end date can be stored on the database to indicate
a period during which a sponsor undertakes to pay the fees of a student.
All
fee periods are connected to a finance calendar representing the institution's
financial year.
Inquire on individual
students
To
inquire on fee information for an individual student – including fee assessments,
payments made, the individual transactions involved, debt and payment balances,
credit available or refunds made – access screens specifically designed for
fee inquiry, using the Inquiry facility:
- Student Course Fee Inquiry (FINF9100) and
Student Fee Calendar Inquiry (FINF9200) provide
different access orientations to the same data.
These screens are accessed from FINF9100 and FINF9200:
- System Credit Inquiry (FINF9130)
- Student Refund Inquiry (FINF9140)
- Student Fee Summary (FINF9900)
These are accessed from FINF9100 only:
- Student Course Fee Statement (FINF9110)
- Fee Transaction Detail Inquiry (FINF9120)
Changing
fee categories
It
is possible to change a fee category for a student. This might be to rectify
an error, or because a student's circumstances change and they are liable
for a different set of fees. For example, at some point in their course a
full fee paying student might become eligible for HECS, and therefore need
to be assessed under a different category.
Changing
fee categories is done in the Student Course Attempt screen of the Record
Enrolments form, ENRF3000.
No
debt. As long as a student
has no assessed debt under the existing category in the current fee period,
the change can be made by selecting the Fee Category item in the T-list, and
the new fee category from the list of values. Until this change has been saved,
an UPDATE lamp will show.
Debt
exists. If a student has assessed debt for the category and fee period, there
are two possibilities –
- If the change needs to take
effect immediately, then generally the debt must first be written down to
zero for the current fee period in the Manual Fee Assessment form, FINF3610 (see documentation
of that form for details). This is so even where the debt is fully paid.
The category can then be changed. The student will be assessed for fees
associated with the new category when the fee assessment routine (FINJ3500
or FINJ3001) is next run.
- Alternatively, the change
can be recorded, but to take effect only in subsequent fee periods. In this
case, a FUTURE lamp indicates that the fee category shown against the T-list
item is not currently in effect. The current fee category is displayed in
FINF9910, Student Course Fee Category Details, accessed via the history
icon
. Fee assessments for
the fee period will continue to be made under this current fee category.
Once the 'current' fee period is past, fee assessments
for the course attempt in subsequent fee periods are made under the fee category
recorded as a T-list item in the student course attempt screen. The first
time an assessment is made in a new fee period, the lamp changes from FUTURE
to CURRENT.
FINF9910
provides a history of all fee periods in which extant assessments have been
made under a category other than the one displayed as a T-list item in the
Student Course Attempt screen. Assessments that have been cleared via FINF3610
are not shown.
Assessment
details of changed fee categories for a student, including cleared assessments,
can be traced through the Student Inquiry forms, FINF9100 or FINF9200.
Last
Modified 11
March 2002