Top of FIN

Index

Table of Contents

Feedback

Student Finance Overview for the Specialist User

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

• Setting Up the Student Finance Subsystem
• Data Structures
• Outline of Data Setup
  • Fee Assessment - Data setup information:
    • Calendars and Date Aliases
    • Reference Data and Statuses
    • Sponsorship Reference Data
    • Fee Types
    • Fee Categories
    • Fee Liabilities
    • Triggers to Fee Liabilities
    • Calculations (Including Tax)
    • Schedules
    • Contracts/Predictive Fee Assessments at Admissions
  • Fee Disbursement - Data setup information:
    • Reference Data
    • Accounts
    • Fee Disbursement 2
    • Disbursement Formulas
• Finalising Fee Types
• Rollover

See also:

Special Topics which gives more information on levels, rates, course attributes and fee disbursement.

Setting Up the Student Finance Subsystem

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:

• Setting up the data needed to carry out the following:
• Assess and Administer fees in the Student Finance subsystem.
• Establish Fee Contracts for students Pre-Enrolling through Admissions.
• Disburse assessed or received income to Organisational Units in an institution.
• Setting up the processes and reports that are the core of this subsystem, using the Job Control and Scheduling subsystem.
• Managing the database rollover process as it relates to the Student Finance subsystem.

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.

Data Structures

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.

Outline of Data Setup

Fee Assessment - Data Setup Information

• Set up the Financial Calendar, the Fee Periods and the main dates associated with them. These must be set up before data can be entered in the Student Finance Subsystem. See the section below on Calendars and Date Aliases and also the introduction to Fee Periods in Understanding Student Finance.
• Set up general reference data and necessary operational statuses.
• Set up Sponsorship reference data.
• Set up the Fee Types, and assign them to Fee Periods.
• Set up Fee Categories, and assign them to Fee Periods.
• Add the required Fee Types to Fee Categories with matching Fee Periods, creating a set of Fee Liabilities. See also the introduction to Fee Types, Categories and Liabilities in Understanding Student Finance.
• Set up and assign Triggers to Fee Liabilities, as required. Triggers are the mechanism used to levy fees for particular courses, Unit Sets or Units.
• Enter data required to calculate a Fee Liability (and tax, where appropriate) after deciding at which level the data should apply.
• Construct Schedules applying to a Fee Liability after deciding at which level the schedules should apply. Schedules can be created to determine Dates for Payment, Dates after which Fee Retention applies, and Dates at which Penalties should apply for Non-Payment of fees.
• Set up the framework to establish Fee Contracts and make Predictive Assessments through Admissions.
• Run the Fee Assessment routine (FINJ3500) in test mode to check the outcomes of your data setup without updating the database.

  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.

Fee Disbursement 1

1. Set up Disbursement Reference Data, including account classifications.
2. Set up Disbursement Accounts for Organisational Units and assign classifications.
3. Construct sets of Disbursement Formulas for each Fee Type/Fee Period combination for which Disbursement is required.
4. Run and check the Fee Disbursement process, Process Disbursement Snapshot, FINJ7300.

Calendars and Date Aliases

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:

• A Financial Year Calendar (for example FINANCIAL) with a Calendar Category of FINANCE, an appropriate instance such as 1 January 2005 to 31 December 2005, and a status of either ACTIVE or PLANNED.
• Fee Period Calendars to cover discrete periods relevant to Fee Assessment, each with a Calendar Category of FEE, a suitable instance and a Status of either ACTIVE or PLANNED.
• Record alternate codes for Fee Periods and Financial Year Calendars. Alternate codes should be unique and are displayed in the finance applications in Callista Connect. Explanations can also be recorded to Callista Connect users with information on the Financial Year or Fee Period.

Notes

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:

• Link each Fee Calendar as a subordinate of the Financial Year Calendar.

In CALF0410 (Maintain Date Alias Categories):

• Create a Date Alias Category to classify Date Aliases operating in the Student Finance subsystem. For example: FEE.

In CALF0420 (Maintain Date Aliases) create:

• Two Date Aliases to define a Start Date and an End Date for effective Fee Assessment processing (see Notes about instances below). Examples: FEE-ASS-ST and FEE-ASS-EN.
• A Retro Date Alias used as a physical cut off point for assessment processing (see Notes about instances below). Example: FEE-RETRO.
• A set of Date Aliases used in the schedules for Payment, Retention and encumbrances.

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:

• Date Aliases to define a Start Date and End Date for each kind of time-span during which revenue and Tax Accounts are effective (see Notes about instances below). Examples: CUR-YR-ST and CUR-YR-END, FUT-YR-ST and FUT-YR-END.

These Date Aliases must be given a Date Alias Category (e.g. FEE) and may be linked to a Calendar Category of FINANCE.

Notes

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:

• Create instances for Fee Assessment Date Aliases and schedule Date Aliases in each Fee Period (Fee Calendar instance).
• Create one instance for the Census Date in each Fee Period (Fee Calendar Instance), using the institution assigned name recorded in the Enrolment Calendar Configuration form, ENRF01F0. This Instance can be defined as a 0 (zero) offset from a Census Date already recorded for another Calendar – most commonly, the appropriate Teaching Calendar.
• Create instances for revenue account Date Aliases in each Financial Year (Finance Calendar Instance).

Notes

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 1^st 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).

Reference Data and Statuses

The following Reference Data should be created and maintained for Fee Assessment.

System Statuses providing functionality within the Subsystem must be given names defined by the institution using the forms identified below.

• The Fee Structure Statuses recorded in FINF1200 are used to determine the activity of Fee Types, Categories and Liabilities.
• Sponsor Statuses are recorded in FINF1G00 and Sponsorship Statuses in FINF1B00.
• Statuses of Fee Encumbrances indicated for a student who defaults on payment are recorded in FINF1D00.
• Statuses which show the progress of authorising refunds are recorded in FINF1J00.

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.

Sponsorship Reference Data

Setup information about Organisations and/or individuals undertaking to sponsor students for one or more of their fees involves:

• Recording statuses, as shown in the previous section.
• Creating a record of the different kinds of sponsors associated with the institution, using the form Maintain Student Fee Sponsor Types (FINF1C00). Examples of Sponsor Types might be FACULTY or CORPORATE.
• Adding details of an organisation to the database using the Maintain Organisational Units form (ORGF0141), and of a person using the Maintain Person Details form (ADMF1213), where this information has not already been recorded. Note that the Find Person facility (ADMF1211), which can be accessed via ADMF1213, enables a detailed search of the database for people already recorded there.
• As an ongoing task, recording as sponsors those organisations or individuals already existing on the database, using the Record Sponsor Details form, FINF4100.

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

Fee Types

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:

• Data which cannot be defined anywhere else, and which governs major functionality. An important example is to distinguish a fee that must be reported to the Australian Government from one that is not. A second example is to classify a fee as being charged either institution-wide or only for specific courses, Unit Sets or Units.
• The association of a fee with a Fee Period (or Calendar Instance). This limits the period over which the Fee Type can operate. Dates relating to the Fee Period are also assigned here. (See the introduction to Fee Periods in Understanding Student Finance.)

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

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:

• A Postgraduate and an Undergraduate Category for international students - for example, INTRNTL-PG and INTRNTL-UG.
• A postgraduate and an Undergraduate Category for domestic students - for example, DOMESTC-PG and DOMESTC-UG.

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.

Fee Liabilities

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.

Triggers to Fee Liabilities

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:

• A Trigger Category must first be recorded for each Fee Type in the form Maintain Fee Types (FINF2100).
• The triggers themselves are associated with Fee Liabilities by accessing one or more of the trigger forms described below. (Access is from the second screen of the Maintain Fee Categories form, FINF2800.)

Trigger Forms

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

• Maintain Course Fee Trigger (FINF2222).
• Maintain Course Group Fee Trigger (FINF2221).
• Maintain Course Type Fee Trigger (FINF2220).

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:

• Maintain Unit Fee Triggers (FINF2223)

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:

• Maintain Unit Set Fee Triggers (FINF2225)

Using this form, fees can be levied if particular Unit Sets are studied.

COMPOSITE trigger category:

• Maintain Fee Trigger Groups (FINF2224)

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.

• The COMPOSITE Trigger Category can also be used to record triggers to operate concurrently for a single liability in more than one of these forms: FINF2222, FINF2223, FINF2225, FINF2224.

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:

• A Trigger Group comprising the Course Bachelor of Commerce and Computing Units SCC111, SCC222, SCC333, SCC555.
• A Course, Bachelor of Computing.
• A Unit Set - the Major Multimedia Technology.

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.

Institution Fees

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.

Calculations (Including Tax)

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.

• Where the same calculation components are to apply to a fee in any of the categories to which it belongs, set up the Calculation Data at Fee Type (FTCI) level, in and via form FINF2100. This is generally the recommended option, and is Mandatory for Student Contribution Amount and institution-wide fees.
• Where the calculation components are to apply to a fee only when it is in a specific category, set up the data at Fee Liability (FCFL) level, in and via form FINF2800.

For each fee, the following data must be selected in one of the main forms, FINF2100 or FINF2800:

• A Charge Method, used to decide the value of an element in a calculation. It is the Charge Method that indicates that, for example, one element is equal either to one unit or to one credit point. The Charge Methods are System defined, and are CRPOINT, EFTSL, PERUNIT and FLATRATE.
• Arule, which is a more detailed formula based on the one shown above. Rules are currently predefined within the System, but individual institutions are able to modify these (based on the 'elements * rate' formula) via the rules interface. For more information, refer to Understanding Rules.

For each fee, additional data must be entered in forms accessed from one of the two main forms, depending on the level desired:

• The standard rate at which a fee is charged is set up in the form Define Fee Assessment Rates (FINF2853). Rate distinctions can be made depending on the course and method of studying the course, or on the unit, or on the Student Contribution Amount option and Discipline Band for each unit assessed. (A more detailed discussion on these aspects of Rates, relying on an understanding of the form, is given in the Special Topics section.)

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

• The Charge Method Apportionment equates Fee Calendars to Load Calendars, in order to determine the proportion of a student's load that should be taken into account in each Fee Period. With the exception of a flat rate charge, the load translates into the number of elements used in the calculation. The form used is Maintain Charge Method Apportion (FINF1720).

  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 calculation example

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.

 Tax Calculations

Any fee is assumed to be taxable unless the Tax Exempt check box is set.

For Student Contribution Amounts and institution-wide fees:

• The check box value (set or not set) at Fee Type (FTCI) level in form FINF2100 is the value which always applies to the fee.
• Student Contribution Amounts are always Tax Exempt, but institution-wide fees may or may not be Tax Exempt.

For all other fees:

• The value of the check box at Fee Liability (FCFL) level is the Operational Value.
• For Tax Exempt Fees, the check box can be set.
• In FINF2800 at FCFL level if this fee is only exempt within this category.
• In FINF2800 at FCCI level if all fees in the category are to be Tax Exempt (Mandatory if the category is Tax Exempt).
• In FINF2100 at FTCI level so that this value is the default for all corresponding Fee Liabilities.

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:

• The Tax Rule at the level required – either in FINF2100 (FTCI level) or FINF2800 (FCFL level).
• The Tax Reference (in Australia, the ABN) at Fee Category (FCCI) level in FINF2800. 

Schedules

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:

Payment Schedule

This is perhaps the most important schedule. It controls:

• The date or dates on which a student is required to pay an Assessed Debt.
• For payment by installments, the percentage of the payment due at each date, and
• Any discounts that apply (including reductions on tax due as a result).
• It is the 'template' for the creation of students' individual Payment Schedules.

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:

• Payment Schedules are set up in the form Define Payment Schedule (FINF2860).
• For Student Contribution Amounts, check boxes must be set in ENRF0161 to distinguish those Payment Options that are entitled to a discount.

Retention Schedule

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 LOAD Method is effectively a levy each time a student reduces their study load, and therefore their Debt Liability. A Percentage is retained of the amount by which the debt is reduced.
• The DEBT method is intended to maintain a level of debt independent of load. This may be a fixed amount, or a percentage of the student's maximum Debt Liability.

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

Encumbrance Schedule

The final schedule sets up a framework for the application of certain penalties or 'encumbrances' in the event of non-payment or under-payment of Assessed Debts Date.

Further documentation about Encumbrance Schedules is found under the Define Fee Encumbrances form (FINF2890).

Schedule Levels

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:

• At both FTCI and FCCI level, or
• At both FCCI and FCFL level.

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.

Common Features of Schedules

Schedules have two important concepts in common with regard to their operation:

• All schedules use Derived Dates, which demarcate periods during which certain conditions apply.
• All schedules allow for several entries, with each record representing a Demarcation Date. Where there is more than one entry in a schedule, each one represents an increment in the effect of the preceding entry for the period in question. Because of this incremental organisation, in most instances of using a schedule the processes involved can 'enter' the schedule at any date, and the effect appropriate to that period will apply.

For example, to illustrate, here is a simple case based on the Payment Schedule. On or before 2^nd January, a student is required to have paid 50% of an assessed fee. At 25^th January, payment of 75% of the fee is required. At 20^th February, the full amount, 100%, must have been paid.

A student notified before the 2^nd of January is able to pay in three installments, one of 50% by 2^nd January, the next of 25% by 25^th January, and a final installment of 25% by 20^th February. However, a student notified of his or her debt on 12^th January must pay in two installments; one of 75% by the 25^th January, and a second of 25% by 20^th February. A student notified after 25^th January must pay the full amount by 20^th February.

Contracts/Predictive Fee Assessments at Admissions

Fee Contracts can be established in three ways:

• For individual applicants, a contract can be created within the Student Finance Subsystem, using form FINF2900 (Maintain Contract Fee Assessment Rates). In this case, a rate is established for each applicant/student.
• For an identified group of applicants, contracts can be established automatically when they are pre-enrolled through Admissions. This can either be online and person-by-person from ADMF3240 when an offer is made, or as a batch job (ENRJ3100).
• Contracts can also be set on a person-by-person basis through Admissions (process initiated from ADMF3660, itself accessed through ADMF3240) once Pre-Enrolment has taken place.

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:

• Fee information must have been set up for the relevant future Fee Periods.
• Applicants must have been Pre-Enrolled.
• Default EFTSL for full time and part-time Attendance Types must be recorded in CRSF1170 to create contracts and make Predictive Assessments for fees with an EFTSL or CRPOINT Charge Method.

Admissions Subsystem Setup

• Admission categories are associated with default Fee Categories and a set of Student Statuses in ADMF2M20.
• Admission process steps are recorded against Admission Categories in ADMF2M30. The following steps affect 'Admission' contracts and Predictive Assessment.

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.

 Fee Disbursement - Data Setup Information

Reference Data

The following reference data should be created and maintained for fee Disbursement.

 Accounts

Fee Posting Accounts are of two kinds:

• Those used to hold income received from the payment of fees (including tax if applicable), and
• Those used to hold income received by budget centres (Organisational Units) as a result of the Disbursement of such fees.

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

Fee Disbursement 2

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

Disbursement Formulas

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:

• A Formula Type determining whether it is Assessment or Retention Income that is to be disbursed.
• An Allocation Method of either STUDENT, PERCOURSE, PERUNIT, CRPOINT or EFTSL (EFTSU is still retained) which determines the nature of the Elements used in the Formula Calculation.
• A fixed (predetermined) Currency Amount, or a Percentage of either a gross, net or balance amount.
• A Disbursement Method which indicates how amounts calculated should be distributed - either to the account of a single Organisational Unit, to the accounts of 'owners' of a course, or to the accounts of departments or other Organisational Units with teaching responsibility for study units.

Formula Operation

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:

• Maintain Fee Disbursement Formulae (FINF7210), and the three forms accessed from it.
• Maintain Fee Category Disbursement Formulae (FINF7220).
• Maintain Disbursement Categorisation (FINF7230).
• Maintain Fee Disbursement Formula Rules (FINF7240).
• The Fee Disbursement process and subsequent jobs are described in Understanding Student Finance.

Disbursement Issues

• Amounts levied as tax on particular Fee Types (e.g. Goods and Services Tax - GST) are not disbursed.
• Occasionally assessed or paid amounts cannot be disbursed where the student is not incurring load at the time of Disbursement. Situations where this might happen are discussed in the documentation for the Disbursement Exception Report.

Finalising Fee Types

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:

• Payments recorded in Callista match those recorded in the interface tables for both students and sponsors who are liable.
• The debt recorded in Callista matches that in the interface tables.
• Payment equals debt recorded for the Fee Type in Callista.
• There are no potential changes to interface debt (requiring an interface job, INTJ0021, to be run).
• There is no un-notified debt (requiring Process Person Payment Schedules, FINJ6111, to be run).

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

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 30 May, 2012 8:55 AM

History Information