This process updates the database

Subsystem

Student Finance

Purpose

To assess the fees and tax due from those students with Student To Do entries recorded on the database. These entries indicate that a student has enrolled or changed their enrolment since the current job was last run. They are automatically created when such a change takes place.

Fee assessment is the central process of the Student Finance subsystem. This job is one of the two methods of running the fee assessment routine - FINJ3001 and FINJ3500 are different 'front ends' to the same process. The present job is the more automated, can only be run in batch mode, and allows minimum selection by parameter.

Normally Run By

A fees administrator

Anticipated Frequency

Nightly

Update Process(es)

Creates transactions reflecting either initial assessments or adjustments to previous assessments for each of the fees for which students recorded in a To Do list are liable, as determined by the relevant structures created in the Student Finance subsystem.

Parameter Sample

Related/Dependent Jobs

The fee assessment routine is the initial process in a fee period cycle. All other fee processes are consequent upon it.

The job may be run with FINJ6111 (to create students' individual payment schedules) as a dependent job. To do so, however, has certain ramifications - see Dependent Jobs below.

Update Process

This section gives a brief outline, in sequence, of the main processing involved in fee assessment.

It assumes a good understanding both of the general approach taken in the subsystem and of the data structures for fee types, fee categories and liabilities, triggers, calculation data and retention schedules. (Please refer to Understanding Student Finance and the Specialist Overview.)

The FINJ3001 process works from student To Do entries types of FEE_RECALC and ADV_RECALC. As long as there is one unprocessed To Do entry for a student (an entry with no logical delete date recorded), that student will be assessed or reassessed by this process. FEE_RECALC and ADV_RECALC entries are created whenever a course or student unit attempt or advanced standing is created, granted or changed for a student, with the exception of changes to their HECS payment option.

The fee assessment routine, when accessing Student To Do entries:

1. Checks the validity of parameter values at the run date (effective date)

   For each financial period specified by parameter.

   For each fee category with a fee period valid at the effective date (and in the financial period, if specified).

   Optionally, for Enrolment Fee Assessments as specified by activating the check box.

   Optionally, for Advanced Standing Fee Assessments as specified by activating the check box.

Note: One or both of the process advanced standing fee assessments and process enrolment fee assessments indicators must be set.

2. Checks today is not past the retro date of the fee period
3. Finds the student course attempts of all students with To Do entries and with a fee assessable status (currently Course Attempt Statuses of ENROLLED, COMPLETED, DISCONTIN, INACTIVE and INTERMIT are fee assessable).
4. Students with a status of DISCONTIN, COMPLETED or INTERMIT may have been enrolled during some part of the fee period. The date on which a student discontinued enrolment is checked to verify this, while a completed enrolment is fee assessable if the census date of its teaching period falls within the fee period.

For each ACTIVE fee liability in the category and fee period:

5. Checks for a match between a student course attempt and/or unit set attempt and/or unit attempt and a trigger
6. For a unit trigger (including a unit within a trigger group), checks that the student's unit attempt is fee assessable (Unit Attempt Status of DISCONTIN, ENROLLED, COMPLETED or INVALID)
7. For a unit set trigger (including a unit set within a trigger group), checks that the effective date is either the same as, or after, the student unit set attempt Selection Date and not after either the End Date or Completion Date (where set)
8. Determines the appropriate load calendar

For each unit for which load is incurred:

9. If a HECS fee, checks that it is not an industrial experience unit (and therefore exempt from HECS)
10. Determines the value of the charge elements represented by the unit in terms of the charge method for the fee, and keeps a running total of charge elements across units

Additionally, for HECS, the EFTSU for a unit is split by discipline group

(Fee assessable statuses for student unit attempts are ENROLLED, INVALID, DISCONTIN and COMPLETED)

11. Calculates the assessed amount for the fee, taking into account that the rate may be determined by -

- different course attributes (course code, version number, location code, attendance type, attendance mode) or payment options (government HECS payment option as at census date, HECS contribution band)

- element range values

- a contract agreement with the student.

For HECS, the calculation is based on the rate for each relevant contribution band if students are liable for differential HECS. Discipline groups match to particular contribution bands, and a running total of the student's HECS fee across different bands is kept

For each fee liability assessed:

12. Writes an assessment transaction record (representing the student's liability for this fee) to the database if this is a first time assessment

Or, if assessments already exist:

13. Checks the student's current debt situation:

- if a more recent assessment exists the student's record is not updated. Otherwise, the effective date is written to the database. This ensures that the correct enrolment details are accessed for statements produced after this run

- if the last assessment was a manual fee assessment no further assessment transaction updates are made for this fee.

Otherwise -

- if the current assessment is different from the previous one, a negative or positive adjustment is made and an assessment transaction record written to the database

- if the adjustment is negative (i.e. the student's debt has been reduced) the retention schedule is accessed to determine if an amount over and above the new assessment should be retained, and a retention transaction record is written to the database if required

Where applicable, after any fee liability assessment, adjustment or retention (including those manually assessed):

14. Checks whether tax applies. If so:

- calculates the tax due on the total assessment amount now stored, including any retention amount (rather than calculating on the individual transaction)

- if this tax balance differs from the previous one stored, a negative or positive tax transaction is written to the database.

15. Deletes processed entries from the Student To Do list.

NOTES

The transaction records created by this process

• can be seen in the form Manual Fee Assessment (FINF3610) or the inquiry form FINF9120, accessed via FINF9100 or FINF9200.
• are the basis for ascertaining a student's assessed debt wherever used in the subsystem.

Commencing Students and Effective Date

Students are generally enrolled in units before the start of their course. For these students, changes in enrolment prior to commencement may create a ToDo record.  

As long as these students are due for assessment in a current fee period, the system will substitute the student’s course commencement date for the effective date of the course attempt (SCA) if the original effective date falls before the commencement date. This ensures that correct enrolment details are recorded for these students and used by subsequent finance jobs. In this scenario, the following applies:

·         Assessment is based on units with an enrolled date on or before the new effective date (the commencement date). Units recorded with an enrolled date later than this are not assessed.

·         For students enrolled in more than one course, the latest of the course commencement dates in the fee period is used.

·         For institution fees, the latest of a student’s SCA commencement dates in a relevant fee period is used. A relevant fee period is one where the institution fee is a liability.

·        When discontinuing units before commencement, the system ensures that students are only liable for retention amounts appropriate to the schedule in effect at the original effective date (if any).

Run Details

Method

This job can only run in batch mode, through the Job Control & Scheduling subsystem. It may be set up to run as a standing request in the JBS subsystem. When run through this job (FINJ3001) a fee trace report is not produced.

Note that running the same process via the other 'front-end', FINJ3500, does not clear entries in the To Do list.

Dependent jobs

FINJ6111 (to create students' individual payment schedules) may be set up as a dependent job. However, note that FINJ6111 sets the dates by which individual students should make payment of fees. It is therefore necessary to produce Statements of Account and Sponsor Summary Statements in a timely manner after running FINJ6111. Refer to documentation about creating person payment schedules for more information.

Timing

It is expected that this job will be run frequently - probably nightly - while students are enrolling and close to major payment due dates and withdrawal deadlines during the fee period.

Job Parameters

NOTES: The % symbol indicates that all values will be selected for that parameter.

A Financial Period and/or Fee Assessment period may be selected.

Activate the Process Enrolment Fee Assessment check box to include these fees in this run.

Activate the Process Advanced Standing Fee Assessment check box to include these fees in this run.