| Top of FIN | Index | Table of Contents | Feedback | |
Overview for the Specialist User
This section of the user manual should be read in conjunction with the technical documentation supplied with the relevant release of Callista.
This documentation assumes knowledge of information given in Understanding Student Finance.
In this section:
Fee Assessment - Data setup information:
Fee Disbursement - Data setup information:
See also:
Special Topics which gives more information on levels, rates, course attributes and fee Disbursement.
Specialist fees administrators are expected to have the major responsibility for setting up and maintaining the Student Finance Subsystem. This section is intended to aid them in this task, which encompasses:
The information presented here builds on the introduction to the Subsystem given in Understanding Student Finance. Links to required forms are given in the text, or can be selected from the Subsystem Table of Contents, while a Special Topics section gives more in-depth information about some aspects of the Subsystem.
The list below maps out the data required to administer student finances over a single Financial Year. Links are provided to more detailed information about each step, both in this specialist overview and elsewhere in the introductory material.
The sequences given here have been chosen as a logical way in which to gain an initial understanding of the scope of the Subsystem. They are not necessarily recommended as the most efficient way to enter data once the Subsystem and the institution's data requirements are known.
Fee Assessment - Data Setup Information
Warning: A change to the data structure for a particular Fee Period, after fee processing of Student Course Attempts in that period has started, is not advised. Such a change might lead to unpredictable results, and make it impossible to trace the derivation of a student's assessment.
The following Calendars and Date Aliases must be created in the Calendar Subsystem before key data can be entered in the Student Finance Subsystem. The section on Fee Periods in Understanding Student Finance gives a preliminary introduction to these calendars.
In CALF0220 (Maintain Calendar Types) create:
Fee Periods normally follow the pattern of standard Load Calendars, reflecting Semesters. In addition, some fees may be charged only once a year, and these would be attached to a year-long Fee Calendar. In their case, it is necessary to use Aggregate Load Calendars to group the standard Load Calendars applicable to the Fee Period.
A typical set of Fee Calendars might be named FEE-SEM1, FEE-SEM2, FEE-SUMMER, FEE-YR. An instance for FEE-SEM1 might run from 1 January 2005 to 30 June 2005.
In CALF0330 (Maintain Calendar Instance Relationships) accessed via a button in CALF0220:
In CALF0410 (Maintain Date Alias Categories):
In CALF0420 (Maintain Date Aliases) create:
Each of these Date Aliases must be given a Date Alias Category (e.g. FEE) and may be linked to the Calendar Category of FEE.
Also create in CALF0420:
These Date Aliases must be given a Date Alias Category (e.g. FEE) and may be linked to a Calendar Category of FINANCE.
Schedule dates are further explained in the section on Schedules, which also provides links to related forms.
In CALF0512 (Maintain Date Alias Instances) accessed via a button in CALF0220:
Fee Assessment Date Alias Instances
While theoretically more than one set of Start Date, End Date and Retro Date Alias Instances can be created for each Calendar Instance, this is not recommended for initial setup.
When running the Fee Assessment routine (FINJ3500) for a Fee Period, its 'Effective Run Date' must fall between the Start and End Dates represented by the two aliases. A 'Retro Date', by comparison, is a physical cut-off point, after which the Fee Assessment routine cannot run at all for the related Fee Period.
The Start Date can be before the start of the Fee Period. For example, FEE-ASS-ST attached to Fee Period FEE-SEM1 for 2005 might be set for 1st November 2004.
A Census Date is needed for each Fee Period in order to process a Student's Status and Differential Student Contribution Amount (HECS) indicator value for a Course Attempt as at the Census Date. For further details, see Student Status in Special Topics.
Account Code Date Alias Instances
Revenue and Tax Account Codes established in Callista provide references used in Callista's interface to an External Financial System. The Date Alias Instances, indicating an account's effective time-span, are linked to accounts in the form FINF2110 (accessed via FINF2100). These accounts are linked to Fee Types within Fee Periods in the same form. Account Codes are linked to Financial Year Calendars (Calendars with a FINANCE Category) in FINF1800.
More detail is given in the documentation for FINF2110. (Account Codes are also documented as a part of the Callista Open Finance Interface, COFI).
The following Reference Data should be created and maintained for Fee Assessment.
| Reference Data |
Purpose |
Maintenance Form |
| To assign Government Discipline Groups to Discipline Bands. |
||
| To record the currency normally used by the institution in administering fees, and the values of other currencies in relation to it. |
||
| To record Account Codes used in posting Student Finance transactions to an institution's Financial System. |
||
| To record the various kinds of external references documented within the Subsystem. |
||
| Fee Encumbrance Types |
To set up Encumbrances relating specifically to non-payment or underpayment of fees. It is suggested that Fee Encumbrance Types be set up with an ADMINISTRATIVE Category. Examples of suitable Fee Encumbrances might be:
See documentation on Encumbrances in the Enrolment Subsystem for an overview. |
|
| To set up Course Group Triggers, if required (see documentation on Triggers, below). It is recommended that a specific Course Group Type - for example, FEE-ASS - is established as a USERDEF type to distinguish fee-related groups. |
||
| Statement of Account, Sponsor Summary Statement Address Types |
To record an Address Type or types (for example, STATEMENT) specifically used to print the institution's address in the format required on Statements of Account and Sponsor Summary Statement. |
|
| To record the institution's address details to be used for Statements of Account and Sponsor Summary Statement. Once details have been established, the Address Type should be closed to prevent its appearing in general Address Type lists of values (for example, those signifying different types of address for students). |
||
| To establish a Correspondence Type or types (for example STMNT-ACC, RMNDR-SOA) for Statement of Account, Reminder Notice, and Sponsor Summary Statement, and link this to the extract job to produce statements (FINJ6120, FINJ6121, FINJ6130). Only students/sponsors with a matching type recorded against their Correspondence Category are selected to receive statements. |
||
| Person ID Type |
To record a Person ID Type against the PAY_ADV_NO System Person ID Type in order to store Payment Advice Numbers as students' Alternate Person IDs (see documentation for ENRF3010). It is recommended that only one Person ID Type is mapped to the System ID Type. |
|
| Tax Reference |
To record a Tax Reference (in Australia, an Australian Business Number (ABN) of the issuing body) to be shown on Statements of Account and Sponsor Summary Statements (Tax Invoices). |
System Statuses providing functionality within the Subsystem must be given names defined by the institution using the forms identified below.
It is recommended that statuses be named using the System defined term unless it is particularly important to retain a term already in use within the institution.
Setup information about Organisations and/or individuals undertaking to sponsor students for one or more of their fees involves:
The ongoing work of associating sponsors with those students to whom sponsorship applies is done in the form Direct Assignment of Sponsorships, FINF4300.
If an inquiry on sponsorship details is required, see Sponsor Inquiry (FINF9300).
The relationship between Fees, Categories and Liabilities is introduced in Understanding Student Finance.
Fees (or 'Fee Types', to use the database term) are set up independently of Fee Categories, using the form Maintain Fee Types, FINF2100. This form is one of the two central forms of the Subsystem, allowing access to many other forms.
One purpose of the form is to record information intrinsic to a fee in all circumstances. This type of information is of two important kinds:
A second purpose of the form is to record data - specifically calculation data and schedules - when that data is required to operate for a fee in any Fee Category to which it belongs.
A Student Contribution Amount is an example of such a fee. Regardless of a Student's Category, the basis for Student Contribution amount Calculations and the timing of Fee Payments (controlled by schedules) must be the same for all. (See the introduction to Fee Types, Categories and Liabilities for an understanding of the interconnection of fees and students via categories.)
When such data is recorded in this form or in forms accessed through this one, the data is said to be operating at Fee Type level, or FTCI level. In different circumstances, calculation and schedule data can be recorded at a different level. See the section on Levels in Special Topics for more details.
Fee Categories are set up in the first screen of the second major form in the Subsystem, Maintain Fee Categories (FINF2800).
Like a Fee Type, a Fee Category must be associated with a Fee Period and assigned a set of dates, as discussed in the introduction to Fee Periods in Understanding Student Finance. The category can only operate in the period and with the dates with which it is associated.
It is suggested that a minimum set of Fee Categories would be:
Although not invariably the case, schedule data will normally be associated with categories. To achieve this, the schedules forms are accessed from the first screen of FINF2800. These schedules are intended to apply to all the fees in a particular category, and are said to be operating at Fee Category level, or FCCI level.
Be aware, however, that overrides may apply for some fees in the category. One such important exception is Student contribution Amount, which must have schedules set up at Fee Type level, not at Fee Category level. For more information, see the sections on Schedules; also the section on Levels in Special Topics.
The second screen of the same major form used to create categories, Maintain Fee Categories (FINF2800), is also used to assign fees to Fee Categories. Fees can only be included in categories with the same Fee Period. Once a fee is assigned to a category, the term for a single fee in a category is a Fee Liability.
Calculation and schedule data can be set up against a Fee Liability. When set up at this level, the data is said to be operating at Fee Liability level, or FCFL level, and applies to the fee only when it is operating within a specific category.
While it is recommended that Calculation Data should normally be set up at Fee Type level, and schedules at Fee Category level, setting such data at Fee Liability level allows a single fee to be levied in a particular way only for one category of student. For more information, see the sections on Calculations and Schedules. See also the section on Levels in Special Topics.
It is important to realise that, whatever the level at which a set of calculation or schedule data applies, a student can only ever be assessed for a Fee Liability. For example, a fee in a category matching the category assigned to them.
Some fees are charged only for some Courses, Unit Sets or Units. The forms to associate these with fees are accessed via FINF2800, and discussed in the next section on triggers.
A 'trigger' is the name given to one or more Courses, Units, or Groupings of Courses and/or Units (including Unit Sets), when they are recorded against a Fee Liability - that is, a fee within a specific Fee Category. For students in that category, if the Fee Assessment routine is able to match a particular student's Course and/or Unit Set and/or Unit Attempt(s) to a trigger, the student will be assessed for the corresponding fee.
To set up triggers:
These are the forms used to select the appropriate trigger or triggers for a Fee Liability:
COURSE Trigger Category (a single Fee Liability can have triggers set using any or all of these three forms)
Using the first COURSE form implies that only a single course (or even a single way of studying a course) or a small number of individual courses are associated with a fee. The next two forms allow various sets of courses to be associated with a fee in one operation. These sets of courses are defined in the Course Structure and Planning Subsystem, using form CRSF11D0 for course groups and CRSF1110 for course types.
UNIT trigger category:
Triggers can be set up to associate a fee with an individual unit or units. If required, making the association can depend on when and where the unit is studied.
UNITSET trigger category:
Using this form, fees can be levied if particular Unit Sets are studied.
COMPOSITE trigger category:
This form allows a fee to be associated with a Trigger Group comprising a Course and/or Unit Set(s) and/or Unit(s). All members of the group must match the student's Enrolment for the trigger to take effect (an 'AND' relationship).
To set up a Trigger Group, record the group in FINF2224, and then record the number of the group against triggers for a course (in FINF2222) Unit Sets (in FINF2225) and Units (in FINF2223), as required.
When set up in this way, a trigger will take effect if any one of the components is present (an 'OR' relationship).
Composite Example
If a computer access Fee Liability has a COMPOSITE Trigger Category and the following triggers:
Students will be charged the fee if they are taking either a Commerce degree with all the computing units in the Trigger Group (i.e. Bachelor of Commerce and Unit SCC111 and Unit SC222 and Unit SCC333 and Unit SCC555) or a Computing Degree or the Multimedia Technology Major as a part of any course.
A note on Triggers and Calculations is given in the next section.
One Trigger Category is an exception. The 'institution' category has no triggers, since fees of this category apply throughout the institution to any eligible student. For further information about institution fees, see the notes in the Summary of Level Information in Special Topics.
This section deals firstly with calculations used to assess a fee, and then with calculations related to the tax due on taxable fees.
Assessment Calculations
The calculation performed by the Fee Assessment routine to arrive at an amount for each fee for which a student is liable has this formula as its basis:
CHARGE ELEMENTS multiplied by CHARGE RATE.
In order to support this calculation a good deal of data must be set up, both in one of the two main forms already mentioned and in forms accessed through them. This involves choosing the level at which the data should apply.
For each fee, the following data must be selected in one of the main forms, FINF2100 or FINF2800:
For each fee, additional data must be entered in forms accessed from one of the two main forms, depending on the level desired:
One further form allows for a finer adjustment of a rate for fees with certain Charge Methods. This is the form Define Element Ranges (FINF2852).
It is also possible for an individual student to have a contract with the institution for a different rate than the standard one, and this is specified in the Maintain Contract Fee Assessment Rates form (FINF2900).
Note: If a FLATRATE Charge Method is used, the number of elements always equals 1, irrespective of a student's load.
Triggers and Assessment Calculations
Triggers only determine whether or not an assessment is made. They do not influence the Calculation Method. To illustrate briefly: if a Fee Calculation were to be set up with a Unit Trigger and an amount charged PERUNIT, the assessment would be 'triggered' by a single matching unit, but the calculation would be based on all relevant units the student is studying. (Relevant units are those studied as part of a Course Attempt with a Fee Category matching the Fee Category of the Liability.) Since this multiplying effect is generally undesirable, a FLATRATE Charge Method is commonly used for a fee with a Unit, Unit Set or composite trigger.
A Tuition Fee with a Charge Method of PERUNIT and a rate of $500 per element has been set up. It has a trigger for the Course A300. The Fee Assessment routine finds that a particular student is studying 3 units of A300 - all incurring Load - in the Fee Period under consideration. The value of 'Elements' is therefore 3, and using the base calculation 'Elements * Rate', the assessment for the fee is recorded as $1500.
If the Charge Method were EFTSL, the same three units might have EFSTU values of 0.125, 0.2 and 0.3 respectively. The value of 'Elements' would be 0.625, and the assessment would be 0.625*500 = $312.50.
Any fee is assumed to be taxable unless the Tax Exempt check box is set.
For Student Contribution Amounts and institution-wide fees:
For all other fees:
For all Taxable Fees, the tax due on a fee is calculated each time a student is assessed or reassessed. Tax is a specified percentage of the assessed amount, this percentage forming a part of the tax rule.
For all Taxable Fees, select:
Information is given here on the three kinds of schedules (Payment, Retention and Encumbrance Schedules), the Levels at which schedules can be defined and the common features of schedules. See also the information about Levels in Special Topics.
Once an assessment of the fees due from a student has been made, there are three different schedules used in handling the resulting debt incurred by the student. These are:
This is perhaps the most important schedule. It controls:
An example of how this schedule works is this. In the first Semester 2005 Fee Period, a student may be required to pay 50% of an assessed amount 10 days after being notified. The balance is due on or before a specified date - say 31/3/2005 - with a 10% discount if the full payment is made by the Due Date. This would require two entries:
This schedule covers that part of the assessed amount (whether paid or unpaid) that the institution wishes to retain, before load is incurred, should a student withdraw from units or courses for which he or she has been assessed. Where payment has been made, any amount not so retained is available for refund, less administrative charges if specified.
There are two Retention Methods:
The following examples apply Retention to a Tuition Fee with one Retention Schedule entry.
Example of LOAD Method
The institution could set up a Retention Schedule for a Tuition Fee with 20% retention applying on and after 15/3/2005. For students who have already paid this fee, and then reduce their liability after this date, 20% of the difference between the previous assessment and the new assessment will be retained, with eighty percent of the reduction potentially available for refund. For those who have not paid, the retention amount will be added to their adjusted debt.
Example of DEBT Method
Here the Retention Schedule is set up with 20% retention applying on the highest debt, on and after 15/3/2005. For students who have already paid and then reduce their liability below the retention amount after this date, 20% of the previously assessed amount for the fee will be retained with 80% potentially due for reimbursement. Those who have not paid remain in the institution's debt for 20% of the previously assessed amount.
Retention Schedules are set up in the form Define Retention Schedule (FINF28A0).
The final schedule sets up a framework for the application of certain penalties or 'Encumbrances' in the event of non-payment or underpayment of Assessed Debts Date.
Further documentation about Encumbrance Schedules is found under the Define Fee Encumbrances form (FINF2890).
Schedules can be set up at all three levels (FTCI level, FCCI level and FCFL level). But for a single fee they can only exist at two levels simultaneously - they can be set up:
An override principle applies if two schedules exist at different levels for the same fee. For that fee, a schedule at FTCI level or FCFL level will always override the one at FCCI level.
The benefit of setting schedules at Fee Category (FCCI) level is that the majority of fees in the category are covered by one schedule. The dates are therefore the same for most of the fees for which a student is liable. However, Student Contribution Amounts and institution-wide fees must have their schedules set up at Fee Type (FTCI) level.
It is therefore recommended that the dates of the different schedules for fees included in the same category are kept in line as far as possible.
Setting a schedule at Fee Liability (FCFL) level caters for exceptional circumstances in administering a particular fee in a particular category, and is not recommended in initial set up unless a compelling reason exists.
Schedules have two important concepts in common with regard to their operation:
For example, to illustrate, here is a simple case based on the Payment Schedule. On or before 2nd January, a student is required to have paid 50% of an assessed fee. At 25th January, payment of 75% of the fee is required. At 20th February, the full amount, 100%, must have been paid.
A student notified before the 2nd of January is able to pay in three installments, one of 50% by 2nd January, the next of 25% by 25th January, and a final installment of 25% by 20th February. However, a student notified of his or her debt on 12th January must pay in two installments; one of 75% by the 25th January, and a second of 25% by 20th February. A student notified after 25th January must pay the full amount by 20th February.
Fee Contracts can be established in three ways:
A provisional or predictive Fee Assessment for an applicant can also be initiated from the Admissions Subsystem, whether or not a contract has been established for that applicant. Predictive Assessment can be online through ADMF3660, or by running the Fee Assessment routine (FINJ3500) as a stand alone job, either batch or online.
In all cases:
Admissions Subsystem Setup
PRE-ENROL - causes Pre-Enrolment to be performed when the outcome status of a course application changes to either COND-OFFER or OFFER in ADMF3240
FEE-ASSESS - allows access to the Fee Assessment T-list item in ADMF3240 to view and optionally change the Fee Category for an applicant, and to select a Student Status. A Payment Option must be chosen if a contract is to be set or a Predictive Assessment made for a Fee Rate where the payment option is a selection criteria for the rate.
FEE-DETAIL - allows access to the form ADMF3660 to set a contract, or run a Predictive Fee Assessment via this form.
FEE-CNTRCT - causes a Fee Contract to be established automatically for relevant Tuition Fees when Pre-Enrolment is run either from ADMF3240 or as a batch job.
The following reference data should be created and maintained for fee Disbursement.
| Reference Data |
Purpose |
Maintenance Form |
| Organisational Units |
Organisational Units (budget centres) are recipients of disbursed income. Check that all Organisational Units due to receive such income are recorded in Callista. |
|
| Fee Posting Accounts |
Account Codes are used to disburse income to Organisational Units. |
|
| Account Classifications |
Account Classifications provide the link between the Disbursement Accounts of Organisational Units and the formulas used to disburse income for a Fee Type. |
|
| Disbursement Categories |
If required, Disbursement Categories provide a means of aggregating disbursed amounts for reporting purposes. |
Fee Posting Accounts are of two kinds:
The first have already been established as a part of setting up Fee Types for Fee Assessment.
The second kind - accounts to receive Disbursed Income - must be set up for each Financial Period in FINF1800. They must then be recorded against Organisational Units and given classifications. This is done either in the form Maintain Disbursement Accounts (FINF7100) or in the form in which account classifications are maintained (FINF1H00).
In Maintain Services (ENRF01Y0), the Fee Assessable check box has a unique function. It allows a fee to be charged for a specific service to a student. For example, a fee attached to a mail out to a student requesting the institution send a Student Union Membership form. Institutions may set their own disbursement service. Remember, if the 'Fee Assessable' check box is not selected, users cannot associate this service with a Fee Type Calendar Instance (FTCI).
Fee Disbursement is based on records of assessed debt or paid amounts incurred as a liability for either an institution-wide or a course based fee. For institution-wide fees, Disbursement Calculations are based on each student's liability for the fee at student level. For fees other than institution fees, Disbursement Calculations are done independently for each Course Attempt for which a student is liable for the fee.
For further information on Alternative Disbursement, see the heading 'Special Note on Alternative Disbursement' in FININTR3 - Understanding Student Finance.
Formula Components
Sets of formulas for each required Fee Type can be set up to provide great Disbursement flexibility.
The following components make up a formula:
For each Formula Type, formulas must be ranked in the order in which they are to be resolved, and each assigned a classification code linking it to one or more Organisational Units. Disbursement Categories can be assigned to each formula to allow aggregation of formula amounts for reporting purposes.
In addition, Rule and Fee Category overrides allow further refinement of the group of students to whom any particular formula may apply. Org Unit overrides are also available for disbursement overrides. See 'Special Note on Alternative Disbursement' in FININTR3.
The formulas and related data for each required Fee Type are set up in:
Disbursement Issues
The Student Finance Subsystem is designed to interface with an External Financial System. One reason for this is to transfer fee information to the external system for accounting purposes. Transfer of information normally takes place throughout the processing cycle for a Fee Period. At some point after the end of the Fee Period, a remaining task is to finalise Fee Types in Student Finance.
In the case of the Callista Open Finance Interface (COFI) this must be done before final information for the fees can be transferred, via the interface, to the External Financial System, in order that related accounts may also be finalised in that system.
Before this last transfer can take place, Fee Period Calendar Instances for each Fee Type must be set to a status of finalised at the Fee Type Level (FTCI) in the form FINF2100. Validations prevent this from being done until all related student Fee Liabilities have a zero Net Balance.
Before Finalising
When attempting to finalise a Fee Type, validations are made to ensure that there is no outstanding debt for students liable for the fee in this period, and that processing of potential debt is complete. Checks are made that:
Error messages are displayed if any of these validations are failed. (These validations are also reflected in an exception report (INTR0108) provided with the Callista Open Finance Interface, COFI).
Method
Although finalising must ultimately be done at FTCI level, resolving outstanding balance issues can be done in stages, and the Fee Type progressively 'closed off'. This means that, if desired, individual Fee Liabilities can first be finalised at the lowest liability level (FCFL) or complete categories can be finalised at FCCI level if all their liabilities can also be finalised. Statuses for these interim stages are recorded in the form FINF2800.
When attempting to finalise directly at Fee Type (FTCI) level, related liabilities can be finalised by the System as long as validations permit.
After a Fee Period has been set to Finalised, no further Assessments, Reassessments or Manual Adjustments for the period can be made.
Rollover facilities allow Reference, Structural and Operational Data created in one period to be automatically re-created in a subsequent period. After rolling, Fee Data can be altered where necessary to reflect the requirements of the new Fee Period. Normally rollover is on a yearly basis.
The rollover of Student Finance Fee Structures depends on a prior rollover of Financial and Fee Calendars and associated Date Aliases. Calendar rollovers are initiated from form CALF0320 (via Maintain Calendar Types, form CALF0220). The dates defining each rolled Calendar Instance can be checked in the Rollover Calendar report (CALR0320) and adjusted where necessary, as can related Date Alias Instances.
Within the Student Finance Subsystem, the job FINJ2A00 allows for the rollover of fee structures once Financial and Fee Calendars have been rolled over for the target year.
Calendars are rolled over into a planned state, and will need to be altered to active statuses if it is intended that fee structure data for related Fee Calendar Instances are to be rolled into an active state.
Last Modified on 29 January, 2008 4:02 PM
History Information
| Release Version | Project | Change to Document |
| 10.1.0.0.0.0 | 1346 - Extended Fee Functionality | Added Fee Disbursement - 2 |
| 9.0.0.0.0.0 | 1094 - Sponsorship Percentage | Under Sponsorship Reference Data, added sentence at end on FINF9300 |
| 8.0.0.0.0.0 | 0976 - DEST - Load EFTSU EFSTL | Replace EFTSU with EFTSL |