| Top of FIN | Index | Table of Contents | Feedback | |
Understanding Student Finance
In this section:
Inquire on Individual Students
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 Contribution Amount, 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 Callista 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
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: The receipt of payments is dependent on a cash receipting system external to the Student Finance Subsystem.
Individual Sponsorship and Contracts
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:
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.
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:
Sponsor Inquiry (FINF9300)- This form enables users to query on a single sponsor code and check details connected with the sponsor’s sponsorships, including debts, credits, payments, refunds, etc. The information is broken down by student and fee period. The user can view a complete list of all students that the sponsor is sponsoring, or restrict this list by fee period. The data displayed can be downloaded to a csv file.
Assessment and Invoicing
Fee Assessment
The central process in the Student Finance Subsystem is the Fee Assessment routine, with its associated trace report (FINJ3500). 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 reassessment.
The Fee Assessment routine can be run in four ways:
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 Student Contribution Amount (System Fee Type = COMSUPPORT (HECS)) or for fees with a PERUNIT charge method. Institution fees are only considered if no other Course Attempts are liable:
Note: 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, FINJ6120a, FINJ6121, FINJ6130, FINJ6200) 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).
Maintain Person Payment Schedules
This 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:
There may be a requirement for an institution to charge a fee for a service provided to students. An example might be a student wanting an institution to send them an application to join the Student Union. Other examples could include sending out a parking sticker or student access card.
Under these circumstances, a fee associated with a Service Code can be set set up using various forms and jobs. Below are steps required when creating a Fee Assessment or printing a Fee Assessment Trace Report for a Fee Type.
The forms and jobs associated with a Fee Assessable Service Code, in order, are:
Payment and Refunds
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: 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 recalculated 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.
Action on Non-Payment
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 Student Status
For Commonwealth Supported Places Fee Types (HECS), non-payment may in some cases be covered by a change in the Student's Status. The Process Student Status routine (FINJ6231) makes the necessary adjustments to the student's record.
Check for Payment
Fees can be paid in installments. 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
Statistical data, including that pertaining to fees, is documented in the Statistics Subsystem.
The Process Student Status 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 Student Contribution Amount Due file (STAJ0050) and the Commonwealth Supported Student's Status file (STAJ0060).
Reports
This extract supports reporting to Government:
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:
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:
Special Note on Alternative Disbursement
An alternate mechanism exists for establishing Fee Disbursement Formulae, whereby multiple Fee Types can be linked to a formula. Fee Types and be associated with a formula in the context of a Fee Type Calendar Instance, if the above functions do not met the need of an institution.
Institutions can either set up formula using the existing method using FINF7210 - Fee Disbursement Formulae, or using the alternative method using FINF7510 - Maintain Fee Type Disbursement Formula. If an institution tries to use another method from that configured, a warning will be given when the user tries to enter the form.
The alternative function of this form enables the user to use the enhanced Override Formula functionality, the additional Formula Rule options and the Disbursement of retained amounts by Teaching Unit responsibility. For example, a institution that has many Fee Types associated with the same formulae may elect to use the alternative function to set up formulae. This option will be indicated in the Disbursement Configuration table. The Process Disbursement Snapshot function will then use the alternate method to calculate the Disbursement Snapshot.
New forms to cater for the alternative Disbursement mechanism are:
Alternative Disbursement Formula Example
When the Disbursement Formula Type is RETENTION and the Disbursement Method is UNITTEACH and the Fee Type is managed at the UNIT level, the Transaction Amount that exists in the Fee Assessment table for the System Transaction Type of RETENTION and for the Unit for which the retained amount exists will be used at the basis for the Disbursement Amount.
| Fee Type | System Transaction Type | Transaction Amount | Unit Code |
| TUITION | RETENTION | 150.00 | ABC123 |
In the example above, $150.00 is the basis of the Disbursement Amount. Typically, 100% of the Transaction Amount will be disbursed to the Organisational Unit responsible for teaching. If however, 50% is defined as the Disbursement Percentage, then $75.00 will be calculated as the Disbursement Amount (50% of $150.00). The Base Balance associated with a Formula Item has no impact on the calculated Disbursement Amount as the Disbursement Amount will always be based on the Transaction Amount for the System Transaction Type of RETENTION and Unit Code combination.
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, COMSUPPORT (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:
For 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 COMSUPPORT (HECS) and will not include a Health Benefit Levy.
Two time spans are particularly important to operations in the Subsystem.
For example, a Fee Period (or 'Fee Calendar') might be called FEE-SEM1. In 2003, the FEE-SEM1 Fee Period might run from 1st January 2003 to 30th June 2003 (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.
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:
These screens are accessed from FINF9100 and FINF9200:
These are accessed from FINF9100 only:
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 Commonwealth Supported Place, 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.
A changed Fee Category for a student can be traced through the Student Course Fee Inquiry form, FINF9100.
A 'CHANGED FEE CATEGORY' lamp is displayed in Maintain Contract Fee Assessment Rates (FINF2900) when the Fee Category value of the context student Course Attempt record is different to the Fee Category value of the Fee Category Calendar Instance Contact (overlay) record.
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
. Fee Assessments
for the Fee Period will continue to be made under this current Fee CategoryOnce 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 on 26 November, 2007 11:42 AM
History Information
| Release Version | Project | Change to Document |
| 10.1.0.0.0.0 | 1346 - Extended Fee Functionality | Added 'Introduction' paragraph and Validation |
| 9.0.0.0.0.0 | 1094 - Sponsorship Percentage | Under Sponsorship, add 'Sponsor Inquiry' details |
| 8.1.0.0.0.0 | 1147 - Disbursements Formulae Changes | Add 'Alternative Disbursement Formula Example' and 'Special Note' on 'Alternative Disbursement' |
| 8.1.0.0.0.0 | 1211 - Contingency Product Change | Changed Fee Category information added to Changing Fee Categories heading |