Users Should:

The Callista Open Finance Interface (COFI) is designed to transfer data between Callista (primarily the Student Finance Subsystem) and an External Financial System.

The data transfer is asynchronous. This means that the system does not transfer data immediately to or from an External Finance System. Data is loaded into an import or export table for loading into Callista and the External Finance System. 

Data processing takes place within Callista. The interface processes follow the processing cycle determined by the Fee Assessment Periods in the Student Finance Subsystem.

Whilst seeking to provide an understanding of all work undertaken in the Callista Open Finance Interface, this documentation does not give instructions for accessing information or handling jobs within the External Financial System. For help in that System, please refer to the manuals, online documentation and other reference material provided in your Financial System.

Most finance interface work can be handled by Student Fees Administrators working within Callista. However, ongoing administration relating solely to the institution's Financial System, such as the handling of bank tapes, will generally fall to Financial System Staff. Schedules for COFI processing will generally be worked out between the two sets of administrators, and ongoing liaison is expected.

Interface Processing Overview

Master Jobs

Each one of the processing segments is controlled by a single 'master' job, run from the Job Control and Scheduling Subsystem. Each comprises several processes. For some of these 'master jobs' parameters can be selected at run time to determine whether or not specific constituent processes are included as part of the job.

Data Transfer

The data transfer between Callista and the External Financial System is asynchronous. Each System does not transfer data immediately but loads interim data tables. The transfer of data for Callista is managed by a master job running in Callista's Job Scheduler.

In each processing segment, the table involved in a transfer of data has a Transfer Status field that reflects the progress of the transfer operation.

READY

If the transfer status of a record is set to READY then it is ready to be transferred to the External Financial System.

TODO

If the Transfer Status field of a record is set to TODO this record is marked for later processing by a COFI job.

PROCESSING

Indicates that the transfer process for this record has commenced.

SUCCESSFUL

The Transfer Status of a record may be set to SUCCESSFUL when data has been transferred or processed out of Callista Interface tables. The Transfer Status may be updated by the External Finance System.

ERROR

The Transfer Status of a record is set to ERROR if an error is encountered during data transfer. The External Financial System adds explanatory text to the Transfer Message field when an ERROR status is returned.

The following tables hold Transfer Status information:

When student and/or sponsor information is added or changed in Callista, customer records are created in the I_FIN_CUSTOMER interface table. The customer records contain only a limited amount of data, i.e. Customer Type (STUDENT or SPONSOR), Person ID (if student), loan scheme ci_cd (if loan scheme) or Sponsor Code (if sponsor), Customer Number and a Transfer Status of TODO.

The events causing creation of a customer record are described in the Special Topics section, When are customer records created?

The master job INTJ0020 is run. This retrieves the relevant new and changed information from Callista for each record in I_FIN_CUSTOMER with a TODO status and adds this information to the interface table. The transfer status of each record is changed to READY for transfer to the External Financial System.

INTJ0020 can also optionally check if a student or sponsor status has changed to inactive and prepare this information for transfer to the External Financial System.

For further information about the customer master job, see INTJ0020 documentation.

The diagram below gives the main tables involved in creation and transfer of customer information, shows whether these tables are in the Callista or external financial databases, and indicates the principal data flows between and within the databases.

cofif102

Merging ID's

Where the merging of records is allowed, the interface procedures do not automatically merge a person's financial records. This must be done as a manual process. The basic approach should be to back out of all debt for the obsolete Person_ID in Callista, although this may not always be possible. Similarly in the External Financial System, payments/receipts should be re-allocated to the proper customer number where possible.

It is anticipated that it may not be possible to alter an individual's financial records for past periods to the new Person ID. Historical records will remain under the now obsolete Person ID, with current records held under the new ID.

Students and sponsors are sent account statements after fees have been assessed for a Fee Period. Each Statement of Account indicates the assessed debt for the sponsor or student including the GST (Goods and Services Tax) on some fees. All information required for these statements is produced and handled within Callista.

An 'invoice' contains the same core information, but in a form suitable for importation into an External Finance System using standard database interfaces. The debt is managed by Callista's Student Finance system and by interface processes under Callista's control.

Callista is treated as the Fees Ledger. Invoice data is summarised in preparation for transfer to the External Finance System. Summary invoice data is imported directly to the General Ledger of the External Finance System. Note that invoice detail is not transferred to Accounts Receivable of the External Finance System.

Invoices are created for students and sponsors once a Person Payment Schedule exists for a student in the Student Finance Subsystem. For each fee (in each course, where applicable) for which a student and/or their sponsor or loan scheme is liable in a specific Fee Period, the Person Payment Schedule has an entry for each date on which a payment of that fee is due. This allows a fee to be paid in installments, with several entries existing for a single fee liability, each with a different due date.

In most cases, a single invoice is created for each entry in the Person Payment Schedule. This is so if either a student or a sponsor or a loan scheme is to pay the full amount represented by the schedule entry. The exception is where the amount to be paid is split between student and sponsor or loan scheme. Then, an invoice is produced for the student and another for the sponsor or loan schemer. When the invoice job is run, invoices are created for all existing entries in the schedule, irrespective of their due dates. For taxable fees, the amount of the invoice is inclusive of tax, with the tax component also being held separately as a part of the record.

Fees may be assessed in either the local currency, or any other currency valid in Callista. The invoices are imported to the External Finance System in the assessed currency, and the exchange rate held in Callista is transferred for foreign currency.

Other components of INTJ0021 are:

This diagram shows the main invoicing tables and processes involved in this segment. It indicates which tables are in the Callista database, and the way in which data is transferred between and within the databases.

cofisap03

Payment Advice Numbers

A Payment Advice Number identifies a student or sponsor when a Fee Payment is received through a bank. Callista uses these numbers to match payments received to invoices. Payment Advice Numbers are imported via interface processing into the External Financial System.

Each student and sponsor liable for fees has a Payment Advice Number generated for them the first time a Person Payment Schedule is created. This number remains the same while they are customers of the institution. The intention is to record this as a machine-readable number on a paying-in slip provided as part of the Statement of Account.

INTJ0020 (Prepare Customers for transfer to External System) will probably run initially before Person Payment Schedules are created for new students. INTJ0021 (Create Invoices) is run after the creation of these schedules. Therefore, running INTJ0020 modules at the same time as INTJ0021 enables Payment Advice Numbers for first-time students and sponsors to be available for transfer to the External Financial System. Incoming payments into the External Financial System (particularly by bank transfer) can be identified once the payment advice number is recorded against customers on the finance system database.

When the current debt for a fee liability differs from the total amount already invoiced, the method adopted is to cancel the existing invoice(s) with a credit memo or memos for the full amount of each relevant invoice. A replacement invoice is then created for the total amount of the debt as it now stands. For example, if a student who owed $1000 on one invoice for a course tuition fee drops a study unit and now owes only $750, a credit memo would be raised for minus $1000 (-1000) and a new invoice created for $750 to replace the cancelled invoice. The net effect in the COFI I_INVOICE_SUMMARY table is minus $250 (-250). If a student withdrew from all units for which he had been charged, then only a credit memo would be created.

Credit memos are stored in the same tables as invoices in Callista.

When a discount is offered if certain conditions are met in paying a fee, the invoice amount has the discount already applied. In situations where a student and sponsor share responsibility for a debt, the student will receive the discount. If the discount due is greater than the student's share of the debt, the student will not be invoiced. The sponsor will be invoiced for the full expected amount (total discount already subtracted).

Single customer.

• A tuition fee installment of $500 may have a 10% discount if the whole installment is paid by the due date. The invoice will be for $450

Two customers.

This segment is concerned with the handling of payments accepted into the External Finance System and loaded into the i_payment_load table. Where applicable, the payments include a tax component. The expectation is that these payments will initially be received through an external cashiering system. The segment also includes the process to check the integrity of data within Callista at a point in time (reconciliation).

Payment processing involves:

• The creation of receipts to represent incoming payments in the External Finance System. Receipts can be received by COFI in any valid currency, with the exchange rate recorded in the External Finance System
• Making any payment reversals that may be necessary (for example, because of clerical error or if a cheque is dishonoured)

This diagram shows the main Callista tables involved in payment transactions. It also shows the way in which data is transferred between and within the databases. Note that in this representation, the main data flow is from right to left (from External Finance System to Callista). 

cofif104

Receipts are created and reversed in the External Finance System.

Receipt numbers are inherited from the external cashiering System or the bank remitting payment. It is suggested that where possible these numbers are distinguished by adding a prefix indicating the source. There is also a payment_type column to record the source.

The purpose of reconciliation is to check the integrity of interface data both within and between the Callista and the External Financial Systems. Reconciliation with asynchronous transfer relies on the provision of a snapshot of reconciliation data after each element of payment is loaded into I_PAYMENT_LOAD.

Reconciliation takes place in two stages - an internal check within each System, and an inter-system reconciliation.

Inter-system reconciliation reports are the responsibility of the External Finance System.

Refunds may be available to students, Loan Schemes and Sponsors, if calculations show that they have a credit balance. Unlike most other processing for fees, this available 'system credit' is not tied to a particular Fee Period or Fee Type, but represents a credit balance which has accrued to a person or Organisation across all courses and throughout their association with the institution in the Student System.

Once refund records have been approved, information is prepared for transfer to the External Finance System so that transactions are created to clear credit balances in the financial system and enable refund payments to be made to students and sponsors through the External Finance System.

The job is described in three stages  below:

Master Job (Stage 1) The master job accesses approved refund records in Student Finance, and creates interface records in the I_REFUND and I_REFUND_CUSTOMER tables. It then creates debit memo records in the Callista invoice tables (I_INVOICE and I_INVOICE_TRANS). 

Matching receipts is the final step in an interface cycle. Invoices and payments are matched in Callista. After this, neither invoices nor receipts can be modified, and no further Assessments, Re-assessments or Manual Adjustments for the Fee Period can be made in the Student Finance Subsystem.

Since invoice data is transferred to the External Finance System's General Ledger as a summary only, invoices are not required to be matched to receipts in the External Finance System because invoices do not exist in the External Finance System's Accounts Receivable.

Before information can be transferred for a Fee Type in a Fee Period, the Calendar Instance must be set to finalised at the Fee Type level (FTCI) in the form FINF2100 in Student Finance. Validations (displaying appropriate messages) prevent this from being done until all Student Fee Liabilities for the Fee Type in that Fee Period have a zero balance.

Although finalising must ultimately be done at FTCI level, resolving outstanding balance issues can be done in stages, with a progressive 'closing off' of Fee Liabilities for a Fee Type. This can be done at the level of an individual fee in a single category (FCFL level) or complete categories can be finalised (at FCCI level) as long as all Fee Liabilities for that category are in balance. Finalised statuses for liabilities and categories are set in the form FINF2800.

Last Modified on 16 April, 2007 10:56 AM