NOTE: Items in this section provide additional and in-depth information, and assume good knowledge of COFI and the Student Finance subsystem.

The timeline below is intended as a guide only. It shows typical ways in which the Student Finance subsystem and COFI interconnect, and points out important sequences. The timing of many interface jobs and reports will depend on the work practices of individual institutions, and particularly their management of Fee Assessment and subsequent processing in Student Finance.

Various events relating to a student or sponsor will cause creation of a customer TODO record in the I_FIN_CUSTOMER table in Callista. Records are created when:

• Current students are initially loaded into this table during COFI implementation. A PL/SQL code is provided to initially load the
  I_FIN_CUSTOMER table. See Technical Documentation-Callista (COFI) Technical Summary for more information

• He or she is offered a place in a course through Admissions. That is, a value equivalent to OFFER or COND-OFFER is recorded as an outcome status of their application in ADMF3240
• A Student Course Attempt record is created. This caters for the possibility that a student is enrolled directly through ENRF3000, rather than via the Admissions subsystem
• Changes are made to particular information for a student already identified as a customer. The relevant changes are any updating of their personal details, and adding or changing a correspondence address. These changes are generally made in or through ADMF3000 or ENRF3000. The address involved is that with a correspondence indicator set for its address type in ORGF0116

• Sponsorship of a Student Course Attempt is established in FINF4300, or changes are made to this sponsoring relationship. Possible changes are setting the sponsorship status to CANCELLED and insertion of an end date, a change to the sponsorship limit or a change to the percentage contribution
• Changes are made to any information recorded against a sponsor code in FINF4100
• If the sponsor is a person and already identified as a customer, when personal information is updated or if a correspondence address is added or updated. These changes are normally made through ADMF1213
• If the sponsor is an organisation, when a correspondence address for the organisation is added or changed through form ORGF0141

In an active Fee Period, Student TODO records of type INT_FININV are created automatically whenever the changes listed below are made to the Callista database.

In Person Payment Schedules, when -

• A schedule for a student is created for the first time
• A new entry is created in an existing schedule. This could be for a new fee, or for an additional installment of a fee for which an entry already exists. New entries (installments) can be created -
• Automatically when a fee liability increases and has a different notification date (and therefore a different payment date), or
• Manually by adjusting an existing liability to spread it across more installments
• There is a change to an existing entry in a schedule, normally because for that installment the assessed amount has either increased or decreased. An existing entry is altered (rather than a new entry created) when either the notification date (and therefore the payment date) is the same, or the fee must be paid on a stipulated date, rather than on a date calculated from the notification date. The notification date is set by parameter when running the job to process person payment schedules

In the Enrolment form, when:

• There is a change to a student's Student Status for a course. Student Statuses are changed in ENRF3110 (accessed through ENRF3000). Changes between deferred and upfront options (Government Student Status 110, 111 and 112) are automatically reflected in a student's person payment schedule without needing to run FINJ6111.

In this situation, the relevant person payment schedule is retrieved, and data from the Student Contribution Amount entry written to the Student TODO tables. Relevant schedules are identified by having a Student Contribution Amount entry with a Payment Due Date either on or after the date when INTJ0021 is run.

The Student TODO records discussed above are all created as a direct result of a database change.

Student TODO records are also created:

Payments are likely to be received while invoicing continues. Since payments must be applied (matched) to invoices in Callista, processing of invoices and payments is inter-related. The relationship between particular payments and particular invoices may need to be adjusted both when invoice data changes and when payment data changes.

Note that matches are only made between invoices and payments in the same currency. Should a payment be received in another valid currency, that payment will remain unmatched.

Several different situations may apply to payments:

• One payment may satisfy one or more invoices if a customer makes a single payment for several fees (or fee installments). The likely scenario is where different fees are due at the same time. Conversely, several payments may be made to satisfy one invoice if a customer pays in part on several occasions before the Due Date
• At most times during the interface cycle, there will be outstanding invoices for which payments have not yet been received
• A customer may have made payments for which there are no corresponding invoices. This could be because of an overpayment, either in the current Fee Period or a previous Fee Period, or because a payment is made in advance of fees being assessed for the student in question

A general method for matching payments received to the invoices for Fee Liabilities in Callista is outlined in the three steps below. This method is referred to here and in the technical documentation as 'auto payments' processing:

For each student with debts in the Fee Period:

Two situations fall within the processing of the payment stream, but require an invoice adjustment.

The first is where a payment is received by the institution before the Due Date for payment, but not entered into the External Financial Database until some time later. This is referred to as a 'pre-dated payment'. It is possible that in the interim, an invoice to which this payment would apply has had a discount rescinded because payment appears not to have been received by the Due Date.

The second situation has a similar outcome. This is where a payment is reversed. This might be because a clerical error was made originally (for instance, the payment was credited to the wrong customer) or because a cheque was dishonoured. Here, a discount may already have been awarded and must now be rescinded.

If either case applies, the invoice or invoices involved will need recalculating to reinstate or rescind the discount, as appropriate. To ensure that this re-calculation is done, a Student TODO record is written as input for the next time the invoicing job is run.

NOTE: A loaded payment that has been partially or completely refunded cannot be reversed for COFI.

Invoices are stored in Callista in the invoice history tables, I_INVOICE and I_INVOICE_TRANS, and payments in the I_PAYMENT table. The relationship between a particular invoice and a particular payment at any point in time is recorded in the I_INVOICE_PAYMENT table.

Actual discounts are calculated, and the FEE_ASS and FEE_ASS_EXTERNAL_REF tables updated so that payment and discount transactions are reflected in the Manual Fee Assessment form (FINF3610), the Person Payment Schedule form (FINF3800) and the Student Finance inquiry forms (FINF9100, FINF9200 and related forms).

Once payments have been matched to invoices for a particular student's Fee Liabilities, the following occurrences may mean that the current relationships have to be broken, and some new matches made between invoices and payments:

Both invoices and payments for a student are organised in payment rank order within date. Any of the situations above may cause a 'break' in the previous logical matching of invoices and payments, so that more recent dates and/or lower ranking matches are not now valid. Re-matching must then occur.

Note: HECS-HELP and FEE-HELP invoices are based on the Census Date not the Invoice Due Date.

The method of doing this is to determine the 'break point', and logically delete all invoice/payment matches after that point. Then payments and invoices are re-matched, taking into account whether they are auto payments or designated payments.

The diagrams below indicate how re-matching is done in each of these situations. In each case, the box on the left shows the original match made. The original situation is repeated in each diagram for ease of reference. The dotted line represents the 'break point'.

cofif110 

The invoice D has an earlier Due Date, or a higher ranking, than invoice C. Therefore all invoices below invoice B must be re-matched. Payment 3 is now applied to the newly introduced invoice D, and invoice C no longer has an applied payment.

cofif111

A credit memo has effectively 'cancelled out' invoice B, and therefore payment 2 has been re-applied to the next invoice, invoice C. Payment 3 is now unapplied, and may be a candidate for refund.

cofif112

Payment 2 has been reversed (perhaps because a cheque has not been honoured) and therefore the next payment received (3) is now applied to invoice B, which is due earlier, or ranks higher, than invoice C. A debt still exists for invoice C.

cofisap13

Payment 4 was received by the institution at an earlier date than payment 3, but not recorded on the system until after payment 3. Now it has been recorded, and re-matching occurs so that this earlier payment satisfies the earlier or higher ranking invoice. Depending on circumstance, payment 3 may satisfy a future invoice, or the customer may be eligible for a refund for payment 3.

In Callista, it is Mandatory to have a General Ledger REVENUE Account Code recorded for each Fee Type in a Fee Period. When creating Fee Invoices in the External Financial System, these Account Codes are used in allocating the revenue side of the fee invoice general ledger journal entry. For taxable fees, use of a corresponding TAX Account Code is recommended to distinguish the tax component in revenue distribution. Account Codes are recorded in FINF1800, and allocated to fees in the Maintain Fee Type Calendar Instance Accounts form, FINF2110 (accessed from Maintain Fee Types, FINF2100).

More than one Account Code can be allocated to each Fee Type/Fee Type Calendar Instance combination. These Account Codes are specified for different periods of time through the use of date aliases. This allows for the accurate reporting of 'unearned' income, which occurs where the student or sponsor is invoiced for a service that will not be provided in the current Financial Period.

For example, in the table below, account 123 may represent a Balance Sheet account 'Future Year Income' while account 456 would be revenue account 'Fee Income'. Invoices created between July and December 2003 for the Semester 1, 2004 general service fee will be allocated to account 123. Invoices created between January and June 2004 for the same fee and applicable to the same Semester will be allocated to account 456.

It is expected that as a part of the accounting process to open a new accounting period, the opening balance of the 'Future Year Income' Account(s) will be transferred to the relevant Income Accounts for the current (new) Financial Period. This will normally be the responsibility of the Financial System Administrator.

A change to a student debt results in a complete reversal (credit) of the relevant invoice (for the installment of a Student's Fee Liability due on a particular date in that Fee Period) and creation of a new invoice for the new amount. Both the credit and the new invoice will be created simultaneously and allocated to the account number valid when they are created.

In the example given above, if an invoice is created on the 1 December 2003 it will be allocated to account 123.

On the 1 January 2004 the balance of account 123 is transferred to account 456.

An adjustment made to the debt will result in an entry to account 456 to reverse the original invoice, and another entry to account 456 to post the fee income for the new invoice.

Specifying Account Codes for different time periods is not restricted to the concept of reporting current and future year income. For example, a different account may be specified for each month, though it is recommended that such an implementation is approached with caution.

The handling of Student Contribution Amounts differs from that of other fees in these key ways:

At Enrolment or Re-Enrolment, a Commonwealth Supported student selects a Student Status equivalent to the Government Student Status 110, 111 or 112.

Note: For Commonwealth Supported students enrolling after 2005, the Government Student Status will be 201, 202 or 203.

For a particular Fee Period, as long as the student –

• Does not change their selected Student Status within the Fee Period, and
• Pays – or does not pay – in accordance with their selected option.

this is reflected in interface processing as shown in this table:

*More than one invoice may be involved if the debt is shared between student and sponsor, and/or if invoice adjustments are made over the Fee Period.

Processes in Student Finance and COFI access the Student Status current at the Census Date. In COFI, if a Census Date is missing for the Fee Period, or if the student does not have an option current at this date, COFI assumes a value of 112 (upfront, no discount) for Student Contribution Amounts. This would normally only occur if either the date or the option had been changed since the student was assessed.

As well as switching options, a second function of the FINJ6231 job (optionally set by parameter), is to create transactions of type DEFERRED so that balances may be correctly calculated from the transactions held in core Callista Fee Assessment Tables. These DEFERRED transactions can be seen in the Manual Fee Assessment form, FINF3610, and in the Student Finance Inquiry forms.

Last Modified on 06 July, 2006