FINJ6111 - Maintain Person Payment Schedules

Purpose

To create an individual Payment Schedule for a newly assessed student or amend a student's existing schedule after re-assessment.

SubSystem

Finance

Normally Run By Fee Specialist
Anticipated Frequency Weekly during the Fee Assessment cycle.
Structure  Block Person Payment Schedules
Tab Parameters
Buttons Find Person
Calendar Lookup

  

Update Process

This process assesses new transaction records created by the Fee Assessment Routine.

Where the transaction represents an initial Fee Assessment for a student, this process creates one or more 'Person Payment Schedule' (PPS) records for each assessed fee for which the student is liable. This personal schedule for a Fee Liability includes:

  • One or more payment dates for each Fee Type, based on the 'template' Payment Schedule for the Fee Type recorded in the form Define Payment Schedule, FINF2860. Dates based on off-sets in the 'template' schedule are calculated from the Notification Date given as a parameter in this job.
  • The relevant amounts due at each date, taking into account discount information where applicable, and recording any sponsored amounts.

Where the transaction represents an adjustment to a student's debt for a fee, the process amends the relevant amounts in the student's personal schedule.

  • Assessment transactions accessed by the process are updated to include the Notification Date (see Job Parameters, below). In future runs of the job, transactions with a Notification Date are ignored.
  • The records created and maintained by this process can be seen in the form, Maintain Person Payment Schedules (FINF3800).
  • Serve as input to the invoicing extracts (Statement of Account FINJ6120, Reminder Notice FINJ6121, Sponsor Summary Statement FINJ6130).

For Govt. Loan Schemes (for example, FEE-HELP and HCS_HELP), when creating Person Payment Schedules the job also considers PPS Payment Due Dates that have been altered as these can influence payment matching. The process amends the Due Date details up until the last date configured to the expected payment in the Fee Payment Schedule.
For all other Fee Types, the existing PPS Payment Due Date is used. If there is no PPS Payment Due Date, the Notification Date is used as the Payment Due Date.

If a Fee Type has a Government System Loan Scheme type, then FINJ6111 derives and uses the last Fee Payment Schedule configured for the Fee Liability Calendar Instance (ordered by the Fee Payment Schedule Start Date).

Run Details

Method

This job can only run in batch mode, through the Job Control and Scheduling subsystem.

It can be set up to run as a dependent job of the Fee Assessment routine either when run via FINJ3500 or FINJ3001.

Notable Effects

Since this process creates records with actual dates for payment, it is important that statements containing these dates should be created and sent to students and sponsors as soon as possible after it runs.

If there is a delay between running this job and creating or posting statements, a further job, Add Grace Period to Person Payment Schedules (FINJ6112) enables Payment Dates to be extended by a set number of days.

  • For details in the Maintain Person Payment Schedule form (FINF3800) to remain up-to-date, this process needs to run frequently. However, be aware of the proviso about statements, as above.
  • Entries shown in FINF3800 can be edited. However, the current job cannot then further amend these particular records.

See diagrams below for description of 'Different Lowest Level', and 'Get Student Configured Sponsorship Details'.

Job Error Handling

This job allows processing to continue when an error (other than 'System' type errors as described below) is encountered . 
The first error encountered for a particular record will stop processing of that record. Errors or exceptions are captured and logged to S_ERROR_LOG and/or S_LOG and the job continues processing the next student.

Run log details also display the following summary information:

  • Number of records processed,
  • Number of records in error, and
  • Message text that points users to S_LOG and/or S_ERROR_LOG for details of errors / exceptions encountered during processing.

The Run log will contain details like those shown below:

Number of New Debt records successfully processed: 212
Number of New Debt records in error: 8
Number of Reconcile Debt records successfully processed: 515
Number of Reconcile Debt records in error: 87
Number of Tax Details records successfully processed: 45
Number of Tax Details records in error: 78
Number of Sponsorship Details records successfully processed: 889
Number of Sponsorship Details records in error: 4
Please query the system log entries for details of errors and exceptions.
System Log:
            - Log Type: PYMNT_SCHD
            - Log Creation Date: 08/03/2008 18:36:10

Note: 'System' type errors will still cause the job to fail. These might be technical errors relating to the management and operation of the database that would normally be dealt with by a DBA or Oracle - for example, errors that relate to size or a rollback segment, and any errors in the Oracle product itself.

Sponsorship

  • Sponsors can undertake to pay all or a proportion of every fee for which a student is liable in specified periods of a Course Attempt. This is achieved by entering details in the Student Course Attempt Fee Sponsorship and Fee Category Calendar Instance Sponsorship blocks only.
  • Sponsors can also undertake to pay only specific fees (in part or in full) for the Course Attempt and specified period. This is achieved by additionally entering details in the Fee Liability Sponsorship block.

Sponsor Priority

Student fees are processed in the following order when it comes to sponsorships:

1. Sponsor Priority (set in FINF4300)
2. System Fee Type in following order :

  • Tuition Fees with Loan Scheme
  • Tuition Fees without Loan Scheme
  • COMMSUPPORT
  • OTHER e.g. SAAF
  • VET
  • Graduation
  • Advanced Standing

3. Fee Type code asc
4. Due Date asc
5. Unit Code asc

The priority and calculation of sponsor debts, including multiple sponsors, is described in detail in FINF4300.

Note: The Generate XML File from System Log (GENJ1100) job can be utilised to access logged exceptions for FINJ6111.

 

The Person Payment Schedules block contains:

Parameters Tab

  • Fee Assessment Period
  • Person ID
  • Fee Type
  • Fee Category
  • Notification Date
  • Days to Notification
  • Schedule Next Business Day (check box)
  • Initialise Schedules on Increase in Debts (check box)
  • Initialise Schedules on Decrease in Debts (check box)

Buttons

  • Find Person
  • Calendar Lookup

Rules/Notes:

May be run as a dependent job of the Fee Assessment Routine (FINJ3500 or FINJ3001).

The Person Payment Schedule (PPS) represents expected payment amounts for loan schemes. In particular, the sponsor amount is the maximum amount the sponsor will be required to pay.

The PPS Due Date is used as the initial means to determine which liabilities will be paid first when a payment is received, or if sponsorship is to be allocated.

Parameter Details:

Fee Assessment Period parameter:

The job must be run for each Fee Period in which it is required to create or modify person Payment Schedules. Select the period from the list of active Fee Assessment Periods presented in the first parameter.

Person ID, Fee Type and Fee Category parameters:

The next three parameters control the range of students for whom schedules are created or updated. The % symbol indicates that all values should be included for that parameter:

  • Enter a Person ID if the job is to be run to create or update a single student's schedule.
  • Select or type in a Fee Type and/or Fee Category to create/update schedules only for those students liable for a particular fee and/or those included in a particular category.

Notification Date, Days to Notification, Schedule Next Business Day parameters:

The next three parameters specify data required for processing.

Where offsets are used in the 'template' Payment Schedule, actual dates for payment are calculated from the Notification Date:

  • Record either a Notification Date or a number of days to notification. The first sets an absolute date, while the second specifies the number of days to add to the run date in order to arrive at the Notification Date.
  • When person Payment Schedules are created by this job, some calculated payment dates may not be business days. By setting the Schedule Next Business Day to Y, these payment dates are adjusted to fall on the next business day.

The final two parameters enable Person Payment Schedules (PPS) to be initialised for increased or decreased debt or both.

Initialise Schedules on Increase in Debt parameter:

Set this parameter to N when the Notification Date is altered and an extra PPS entry for a particular Fee Type is required in the PPS to indicate an increase in debt.

Set this parameter to Y to initialise the PPS and create a new PPS entry for a particular Fee Type that includes the increase in debt. The original PPS entry for this Fee Type is then logically deleted. The result is a single PPS entry for this Fee Type that includes the debt increase.

If the Notification Date is unchanged and this parameter is set to Y a new single entry is created that includes the increased debt amount. The original PPS entry for this Fee Type is logically deleted. If the parameter is set to N, the relevant PPS amounts are updated.

Initialise Schedules on Decrease in Debt parameter:

Set this parameter to N to decrease the assessed amount of the last entry in a set of PPS entries for a particular Fee Type. Multiple PPS entries are set up in the Payment Schedule template (FINF2860). The ratio originally defined in the Payment Schedule template between each entry in the set is not maintained.

Set this parameter to Y to initialise the PPS and proportionally decrease the assessed amount of each entry of a multiple PPS entry set. The ratio originally defined in the Payment Schedule template between each entry in the set is maintained.

Exceptions:

  • A COMSUPPORT (HECS) Fee Type debt is always represented as a single entry in the PPS. Therefore, the PPS will always be initialised for a change in the Student Contribution Amount debt regardless of the settings of these parameters. A new PPS entry is created that includes the increase or decrease in the Student Contribution amount debt and the original Student Contribution Amount entry is deleted.
  • If a manual edit has been made to an entry in a Person Payment Schedule in FINF3800 this entry will not be updated when this job is run. Any new entries are entered according to the original Payment Schedule template date. For decreases in debt this job will logically delete entries even if manually edited to maintain the level of debt. The latest entry will be deleted first.

Rules/Notes:

Fee Type job parameter is irrelevant to sponsorship processing. It will always do all Fee Types to maintain the order of sponsorship.

When re-assigning sponsorship for the person, fee calendar, course and sponsor, the sponsorship is applied to system Fee Types in the following order:

1. TUITION or VET-TUIT (with loan fee rule attached to context fee period)
2. TUITION or VET-TUIT (with no loan fee rule attached to context fee period)
3. COMSUPPORT
4. HECS (for fees prior to 2005)
5. OTHER
6. VET
7. GRADUATION
8. ADVSTND

And within system fee_type by fee type ASC, unit_cd ASC and payment due dt DESC person payment schedule sequence_number ASC.

Sponsorship of Students Attempting Multiple Courses

  • If a sponsor sponsors a student in two courses with the same institution fee, the first course sponsorship (course cd Ascending) will sponsor the institution fee, unless a sponsor limit prevents this.
  • If a limited amount is assigned to the institution fee, this sponsorship will stand even though the second course sponsorship may be able to sponsor the fee to a greater amount.
  • If no sponsorship is assigned to the institution fee from the first course sponsorship, the second course sponsorship may sponsor that fee. Where the first sponsorship sponsors the fee. If the second sponsor has a sponsorship limit defined, the amount of the first sponsor’s sponsorship may also appear to be applied from the second sponsorship.
  • For example, the institution fee sponsorship may also be deducted from the second sponsorship. This is due to the fact that when processing the second sponsorship it cannot determine which course sponsorship has been allocated to the institution fee. This will only be an issue where:
    • One sponsor sponsors a student for two courses in the same fee period.
    • A sponsorship limit applies to the second course.
    • For institution fees.
    • Where there are other fees lower in allocation priority than the institution fee.
  • This issue is remote and a work-around is achieved by manipulation of the sponsorship at the fee_liability sponsorship level. i.e. excluding the institution fee type from the sponsorship of the second course.
  • If different sponsors sponsor a student in two courses with the same institution fee the first sponsor (sponsor_cd Asc) will sponsor the institution fee unless a sponsor limit prevents this. If a limited amount is assigned to the institution fee this sponsorship will stand even though the second sponsors sponsorship may be able to sponsor the fee to a greater amount. If no sponsorship is assigned to the institution fee from the first sponsor the second sponsor may sponsor that fee.
  • If a student is in two courses and has two fee categories, and the job is run for a specific fee category. So long as one of the students fee categories matches the job parameter, the student will be processed and sponsorship for BOTH fee categories will be removed and re-assigned.

SA-HELP Fees

The Person Payment Schedule determines which course attempt created the student's SA-HELP fee. Once the course is determined, the Person Payment Schedule looks at ENRF3240 for that course attempt and if the Declaration Date and End Date straddle the fee period census date and load is incurred, then the student's SA-HELP debt is assigned to the loan scheme.

This will occur unless:

  • A record found in the ENRF3240 SA-HELP Payment Option overlay and its Start and End Dates straddle the fee period census date and its Elect Payment Indicator is checked.
    In this case the SA-HELP debt is assigned to the student.
  • A record found in the ENRF3240 SA-HELP Payment Option as above but with a Maximum Payment Amount specified.
    In this case the SA-HELP debt is assigned to the student up to the amount recorded in the Maximum Payment Amount field, and the balance is assigned to the loan scheme.

VET Student Loans

To be eligible for VET Student Loans, the student's Student Status (in ENRF3110) must be VET Student Loan eligible (VET Student Loan Eligible check box selected in ENRF0162) and not have paid all their fees up front.
To determine any loan caps that apply this job uses the Loan Cap Amount in ENRF3000, if populated; otherwise it uses the Loan Cap Amount for the Course Version in CRSF12L0.
In determining loan payment amounts, the Person Payment Schedule calculates the amount of VET Student Loan already used and allocates only the remaining amount for payment of the student's fees (up to the loan cap). The balance of the fee amount with be allocated to the student and/or their sponsor.

 

Last modified on 15 March, 2018 10:19 AM

History Information

Release Version Project Change to Document
20.0.0.2 2310 - Multiple Sponsors Added note about Sponsorship Priorities and a link to FINF4300.
19.0.0.3, 19.1.0.2 2262 - Compliance VET Student Loans Added note about VET student loans.
19.1 2197 - Incremental Improvements Added note for SA-HELP fees that load needs to be incurred
13.0.0.3, 14.0.0.2, 15.0 1834 - Service and Amenities Added note about SA-HELP fees.
13.0 1577 - Unit Fee Payment Matching Added information re: altered Payment Due Dates for Loan Scheme fee types, and a note about GENJ1100.
12.0.0.2 1617 - VU - SV Fee-Help Added VET_TUIT in the list of system fee types in the Rules/Notes section.
10.1.0.0.0.0 1348 - Job Error Handling Part 1 Added details re Job Error handling and Run Log details.