Top of INT

Interface Index

Index

Table of Contents

Feedback

Callista Open Finance Interface (COFI) Special Topics

This page provides the following information:

• A Sample Work Flow
• When are Customer Records Created?
• When are Invoicing TODO Records Created?
• Applying Payments
• Payment Hierarchy
• Auto Payments
• Pre-dated and Reversed Payments
• Method of Applying Payments
• Adjusting Invoice/Payment Relationships
• Account Codes
• Tax Codes
• Handling Student Contribution Amounts
• Deferred and Upfront Options
• Switching Student Status
• Loan Schemes
• Loan Scheme Discount Transactions

A Sample Work Flow

This outline represents a fee processing and interface cycle for a single Fee Period defined in the Student Finance subsystem. For more details of the Student Finance processes, see the work flow documentation in Understanding Student Finance. The assumption is that initial setup of COFI (for example, the initial customer load) has already been done.

*Note:For institutions using the COFI Designated Payment Model, INTJ3021 and INTJ3022 will be run in place of INTJ0021 and INTJ0022 respectively.
For more information, see COFI Designated Payment Model.

When are Customer Records Created?

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.
  For more information, see the technical information in the Callista Product Centre (Callista wiki).

For a student:

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

For a sponsor:

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

For either student or sponsor:

• A customer record is created when a payment advice number is generated.
• For a loan scheme a loan_scheme_ci_cd is inserted or updated.

When are Invoicing TODO Records Created?

Processing of invoices, and all subsequent processing in the Finance Interface, is directly related to assessment and payment scheduling activity in the Student Finance subsystem. Activity can continue for Fee Liabilities in a particular Fee Period, and therefore for related interface processing, until the Fee Period is finalised (see Matching Receipts).

a) When the Callista Database Changes

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 (instalments) 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 instalments.
• 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.

If by any chance a change was made from an equivalent of 110, 111 or 112 to an option other than one of these (for example, from option 110 to option 119), then the student would be liable for a different Fee Type, and would probably be assigned a different fee category. He or she would need to be re-assessed (by running FINJ3500 or FINJ3001) and the job to process person payment schedules (FINJ6111) rerun, in order for the person payment schedule to reflect the change. Because the student would no longer be liable for a Student Contribution Amount, a credit memo would accordingly be created to offset any existing Student Contribution Amount invoice.

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

b) When Interface Jobs are Run

Student TODO records are also created:

• By a module in INTJ0021*, the master job for invoice creation (see INTJ0021*, Check discounts).
• By a module in INTJ0022*, the master job for payment processing, when pre-dated payments or payment reversals are identified.

*Note:For institutions using the COFI Designated Payment Model, INTJ3021 and INTJ3022 will be run in place of INTJ0021 and INTJ0022 respectively.
For more information, see COFI Designated Payment Model.

Applying Payments

This section includes:

Payment hierarchy
Auto payments
Pre-dated and reversed payments
Method of applying payments
Adjusting invoice/payment relationship

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 for institutions that use the COFI Designated Payment Model, then payments will not be automatically unmatched. For more information, see COFI Designated Payment Model.

Applying payments to invoices, then, does not fall neatly into one segment area. Modules used to apply payments can be called from either the Invoice segment (INTJ0021) or the Payments segment (INTJ0022). The processing is not identical, but takes account of which segment initiates the processes. In the documentation, therefore, there is reference to an 'invoice stream' and a 'payment stream'.

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 instalments). 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.
• If an institution uses the COFI Designated Payment Model (i.e. The DESG_PAYMENT_MODEL_IND is set to Y in the I_INT_CONTROL table) then, a student's payment can be allocated to a particular fee. or a sponsor's payment can be allocated to a particular student at the time of payment. These actions can be maintained via INTF3054.
• 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.

SPECIAL NOTE ON REFUNDS: An overpayment may need to be refunded (see the Refunds segment of the overview). In interface processing, the Prepare Refund Data for Transfer to External Finance System, INTJ0023, also uses the 'invoice stream' to match refund amounts to payments. Such amounts are recorded as debit memos, and while these are stored in the 'invoice' interface tables and matched like invoices, the context of their matching is simpler than for the matching of payments to invoices, and varies in some particulars. For a discussion specifically of refund debit memo matching, refer to the Apply Payments section of INTJ0023.

To view payments in a query-only view, see the form COFI Payments (INTF0052), or the Fees/COFI Customer Inquiry form (INTF0056).

Payment Hierarchy

In the Student Finance forms that maintain Fee Types and Fee Liabilities, a rank number is assigned to place each fee liability in a payment hierarchy. Details are given in the documentation for FINF2100 and FINF2800. When a payment is received via COFI, this ranking is one of the things which determines which of a student's fee debts are to be paid first. A liability of rank 10 would be paid before one of rank 20. Using the payment hierarchy rankings is described further in the next section, and in Adjusting invoice/payment relationships.

Auto Payments

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 as 'auto payments' processing:

For each student with debts in the Fee Period:

• The invoice records in I_INVOICE and the payment records in I_PAYMENT are placed in date order from earliest to latest date. The relevant date for an invoice is the Due Date, and for a payment, the date the payment was received by the institution. Payments are applied to invoices in the same order, so that those invoices with the earliest Due Dates are paid first.
• For all invoices that are due on the same date, payment amounts are applied to invoices according to the payment hierarchy ranking of the fee liability for which the invoice was raised.
• If the payment is made by a sponsor responsible for the debts of more than one student, payments are applied to invoices according to the two criteria above, and then according to the PERSON_ID code of the student, working from lowest to highest. If the debt is associated with a loan scheme, the UOO_ID is used instead of the PERSON_ID code. Note that for institutions using the COFI Designated Payment Model, sponsor payments can be allocated to particular students using INTF3054.
  For more information, see COFI Designated Payment Model.
• Loan schemes have loan and loan discount invoices. Loan discount invoices are always paid first.

Pre-dated and Reversed Payments

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

Method of Applying Payments

The principle applied to matching payments to invoices is that the earliest payments will satisfy the earliest invoices that meet the requirements of the payments hierarchy rankings, as outlined in Auto Payments.
Note that for institutions using the COFI Designated Payment Model, payments can be allocated to particular invoices using INTF3054 and existing payment allocations can be deleted using INTF3053.
For more information, see COFI Designated Payment Model.

The Processed Status in the I_PAYMENT table reflects the progress of applying payments. It has statuses TODO, ACTIV, ERROR, FULL. (The FULL status indicates that this record has been fully processed in the final matching of invoices to receipts - refer to Finalise Fees.)

Adjusting Invoice/Payment Relationships

• A new invoice is created with an earlier Due Date than existing invoices, or with a higher payment ranking than existing invoices for the same Due Date. (Example 1)
• An invoice is cancelled by a credit memo. (Example 2)
• A payment is reversed. (Example 3)
• A payment with an earlier date than recorded payments enters the system. (Example 4)

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 that for institutions using the COFI Designated Payment Model: When invoices are cancelled or payments reversed, only those payments are re-allocated to other invoices, however other payments can be matched using INTF3054 or deleted using INTF3053.
For more information, see COFI Designated Payment Model.

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.

Examples:

Example 1

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.
See note above if your institution uses the COFI Designated Payment Model.

Example 2

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.
See note above if your institution uses the COFI Designated Payment Model.

Example 3

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.
See note above if your institution uses the COFI Designated Payment Model.

Example 4

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.
See note above if your institution uses the COFI Designated Payment Model.

Account Codes

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

Credit Memo Example

Tax Codes

Some Finance systems have a requirement for a specific code relating to GST to be associated with each transaction. If this is required, the I_INT_CONTROL table should be configured to allow this; by setting the tax_codes_ind to Y.

When the tax rule is specified for a taxable fee in the FINF2100 form for a particular fee liability, the description of the rule chosen is used as the tax_code. The form RULF2001 that establishes the rule can be used to modify the description (tax_code).

The tax_code for fees that are not taxable, and for refunds, are stored in the I_INT_CONTROL. For more information, see the technical information in the Callista Product Centre (wiki.callista.com.au/display/CPC).

Handling Student Contribution Amounts

In part, this section summarises information presented elsewhere for finance interfacing and the Student Finance subsystem. Documentation of the Payment Schedule form (FINF2860) provides the fullest details about setting up Student Contribution Amount payment schedules, and about Student Contribution Amount discounts. Setting Student Contribution Amount rates (including differential Student Contribution Amounts) is included in the Rates section of Student Finance Special Topics.

• A Student Contribution Amount due in a particular Fee Period can only ever have one entry per Student Course Attempt in a student's person payment schedule.
• Student Contribution Amount discounts are not rescinded when the Payment Due Date for Student Contribution Amount has passed. An implication of this for interface processing is that the 'Check discounts' module in the Invoice master job does not apply to Student Contribution Amounts. This module normally sets up a check to see if a discount should be rescinded once a Due Date has passed.

Deferred and Upfront Options

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

Switching Student Status

Students may switch their option. Alternatively, a job normally run in Student Finance after the Census Date (FINJ6231, Process Student Status) will automatically change their option if this is indicated by their Payment History in the Fee Period. For example, a student recorded as upfront, but for whom no payment has been received, will be switched to deferred by the routine as long as they have provided a TFN or Tax File Certificate Number.

The implications for interface processing are outlined in the table below. In some cases, invoices need to be 'reversed out' by credit memo or adjusted to reflect the new situation. In others, an invoice must be created for the first time. This interface processing is prompted by creation of a Student TODO record, as documented under 'Enrolment form' in the section 'When are invoicing TODO records created?', above.

Loan Schemes

Loan schemes (for example, FEE-HELP, HECS-HELP or SA-HELP) become finance customers by being associated with a Fee Period in the table loan_scheme_ci_cd (FINF4500). Invoices are created by standard COFI modules. A key element of loan scheme processing is the draw-down process. This is roughly equivalent to the deferred job for Commonwealth Supported Places. An output of the draw-down is a consolidated amount of debt that is expected to be paid by the loan scheme customer into COFI. A payment to the loan scheme finance customer must be made to the i_payment_load table. When the COFI payments job (INTJ0022) is run, this payment is allocated to the student's COFI and Fee Assessment records.

Loan Scheme Discount Transactions

If a change in value for a Loan Scheme Discount occurs, the original transaction (HCSHLPLN_D) is logically deleted and a new transaction for the actual amount is added.

For more information on Loan Scheme (HECS-HELP) discounts and how they are applied, please see Understanding the Callista Open Finance Interface (COFI).

History Information