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:

Setting up the subsystem
Data structures
Outline of data setup

Fee Assessment - Data setup information:

Fee Disbursement - Data setup information:

Finalising Fee Types

VARPAC - Reporting Higher Education Scheme (HECS) Variations
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

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 the 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
  1. 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.
  2. Set up general reference data and necessary operational statuses.
  3. Set up sponsorship reference data.
  4. Set up the fee types, and assign them to fee periods.
  5. Set up fee categories, and assign them to fee periods.
  6. 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.
  7. 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.
  8. Enter data required to calculate a fee liability (and tax, where appropriate) after deciding at which level the data should apply.
  9. 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.
  10. Set up the framework to establish fee contracts and make predictive assessments through Admissions.
  11. 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. 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.

Setting up 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:

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 January1999 to 30 June 1999.

In CALF0330 (Maintain Calendar Instance Relationships) accessed via a navigation 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. Example: FEE.

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.

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 navigation button in CALF0220:

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 1999 might be set for 1st November 1998.

A census date is needed for each fee period in order to process a student's HECS Payment Option and Differential HECS indicator value for a course attempt as at the census date. For further details, see HECS Payment Options 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).

Setting up assessment reference data and statuses

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

Reference Data

Purpose

Maintenance Form

HECS contributions

To assign government discipline groups to HECS contribution bands.

STAF112H

Currency

To record the currency normally used by the institution in administering fees, and the values of other currencies in relation to it.

FINF1410

Fee posting accounts

To record account codes used in posting Student Finance transactions to an institution's financial system.

FINF1800

External reference types

To record the various kinds of external references documented within the subsystem.

FINF1A00

Fee encumbrance types

To set up encumbrances relating specifically to non-payment or under-payment of fees.

It is suggested that fee encumbrance types be set up with an ADMINISTRATIVE category. Examples of suitable fee encumbrances might be

  • an encumbrance type that has the RVK_SRVC effect
  • an encumbrance type that has either the SUS_SRVC effect or a range of level 1 effects.

See documentation on encumbrances in the Enrolment subsystem for an overview.

ENRF6200

Course groups within a course group type

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.

CRSF11D0
CRSF1180

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.

ORGF0116

Statement of Account, Sponsor Summary Statement Address

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

ORGF0122
(access through ORGF0120)

Correspondence Type

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.

CORF2110

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.

ENRF01B0

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

FINF1K00

 

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.

Setting up sponsorship reference data

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.

Setting up 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:

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 HECS fee is an example of such a fee. Regardless of a student's category, the basis for HECS 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.

Setting up 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:

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 HECS fees, 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.

Creating 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 realize 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, i.e. 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.

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

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)

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:

then 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 SCC111and 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.

Setting up calculation data

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 that 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 EFTSU, 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 indicator is set.

For HECS and institution-wide fees

For all other fees

o        in FINF2800 at FCFL level if this fee is only exempt within this category

o        in FINF2800 at FCCI level if all fees in the category are to be tax exempt (mandatory if the category is tax exempt)

o        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

Setting up 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 at which a student is required to pay an assessed debt

·         for payment by instalments, 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 1999 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/99 - 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 HECS fees, indicators 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/99. 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/99. 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 underpayment of assessed debts due.

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

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, HECS and institution-wide fees must have their schedules set up at FeeType (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.

An 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 instalments, one of 50% by 2nd January, the next of 25% by 25th January, and a final instalment of 25% by 20th February. However, a student notified of his or her debt on 12th January must pay in two instalments; 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.

Setup for fee contracts and predictive fee assessments at Admissions

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

o        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

o        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 HECS Payment Option. 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.

o        FEE-DETAIL - allows access to the form ADMF3660 to set a contract, or run a predictive fee assessment via this form.

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

 Disbursement

Setting up disbursement reference data

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.

ORGF0141

Fee posting accounts

Account codes are used to disburse income to organisational units.

FINF1800

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.

FINF1H00

Disbursement categories

If required, disbursement categories provide a means of aggregating disbursed amounts for reporting purposes.

FINF1I00 

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

Setting up 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.

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:

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.

The formulas and related data for each required fee type are set up in

o        Maintain Fee Category Disbursement Formulae (FINF7220)

o        Maintain Disbursement Categorisation (FINF7230)

o        Maintain Fee Disbursement Formula Rules (FINF7240).

o                                                        The fee disbursement process and subsequent jobs are described in Understanding Student Finance.

Disbursement issues

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:

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, re-assessments 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 11 March 2002