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 Reassessment

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' 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 offsets 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)

Run Details

Method

This job can only run in batch mode, through the Job Control & 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. E
rrors 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 & operation of the database that would normally be dealt with by a DBA or Oracle - e.g. errors that relate to size or a rollback segment, and any errors in the Oracle product itself.

 

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 represents expected payment amounts for loan schemes. In particular, the sponsor amount is the maximum amount the sponsor will be required to pay.

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.

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

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

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

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:

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 (with loan fee rule attached to context fee period)
2) TUITION (with no loan fee rule attached to context fee period)
3) COMSUPPORT
4) OTHER
5) VET
6) GRADUATION
7) ADVSTND

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

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

Fee type job parameter is irrelevant to sponsorship processing. It will always do all fee types to maintain the order of sponsorship.

 

 

 

Different Lowest Level

If the SCAFS level sponsorship limit is null and percentage contribution is 100% (i.e. the default values), the sponsorship limit/percentage contribution at the lowest levels at which data is entered are used and the sponsorship limit and percentage contribution at other levels are ignored. For example:

Note that there may be more than one ‘lowest level’, for example if two fee types TUITION and SERVICE are specified, and units are specified for the TUITION fee type, then the lowest level is the unit level for TUITION fees and fee type level for SERVICE fees. This is illustrated in the following diagram:

 

 

Get Student Configured Sponsorship Details

The following process takes into account the assignment of sponsors.

 

 

 

Last modified on 11 December, 2007 11:44 AM

History Information

Release Version Project Change to Document
10.1.0.0.0.0 1348 - Job Error Handling Part 1 Added details re Job Error handling and Run Log details.