| Top of INT | Interface Index | Index | Table of Contents | Feedback | |
In this section:
Users Should:
Reference data and setup information is outlined in the Specialist Functions section. The section Special Topics deals with some aspects of the interface in greater depth. Individual documentation for processes can be accessed from the Table of Contents. Links to all these references are given as appropriate throughout the documentation.
Process descriptions and diagrams in this help page assume that the institution does not use the COFI Designation Payment Model.
For institutions using the COFI Designated Payment Model, INTJ3021 takes the place of INTJ0021 and INTJ3022 takes the place of INTJ0022.
For more information about the COFI Designated Payment Model, see below.
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.
This guide describes some of the central terms used in Callista and COFI. These items may be named differently in the External Financial System. The Glossary gives a more complete list of terms.
|
Callista Term |
Explanation of Relationship |
|
Sponsor, Student or Loan Scheme |
Those students and sponsors responsible for paying student fees may be recorded as customers in the External Financial System. A customer number is created in Callista by prefixing a student number with ST, and a sponsor or loan scheme code with SP. |
|
Statement of Account / |
A Statement of Account (produced as an extract) is a request for payment from a student. It provides details of all a student's Fee Liabilities for a Fee Period. A Sponsor Summary Statement provides a summary of this information for all students' debts for which the sponsor is liable. The major source of these is the Person Payment Schedule in Student Finance. |
| Invoice | An
invoice, as used by COFI is a means transferring invoice detail of a debt
for a single fee in a Fee Period to the External Financial System in a format
that can be received by that System. It is not used as a request for payment.
Invoice detail may be transferred in summarised form to the External Financial
System.
The major source of invoices is the Person Payment Schedule in Student Finance. |
|
Payment |
Incoming payments are received into the External Financial System and are recorded in that System as receipts. When this data is transferred to Callista Student Finance, via the i_payment_load table and COFI, it is termed a payment. |
The Callista Open Finance Interface has five major processing segments. These are:
1. Customers2, Invoices
COFI creates invoice records and invoice adjustments, based on Fee Assessment
information from the Student Finance Subsystem. The invoices include any discounts
that may apply. New invoices are applied to existing payments.
3, Invoice
Summary
The invoice information is summarised for transfer to the General Ledger of
an External Financial System.
4. Payment
Notification
Handles the transfer of payment data from an External Financial System to
Callista. New payments are applied to existing invoices in Callista.
5. Refunds
Takes refund data from Callista, creates debit memo invoices then optionally
summarises them ready for transfer to the External Financial System to effect
payment of refunds. Debit memos are matched to receipts in Callista.
6. Finalise
Fees
This final process finds
invoice payment matches that are finalised. Invoice or payment details that
are related to a finalised Fee Period are marked as fully processed. The data
cannot be changed after this point.
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.
Note: The Callista Job Run Log (via JBSF5300 and the Run Log button) should be checked after any of these COFI master jobs are run.
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.
Note: A
TODO Transfer Status should not be confused with the Student ToDo entries
used in several Callista Subsystems, including the Invoice segment of COFI.
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:
|
Processing Segment |
Table |
Database Location |
Online Help |
|
Customers |
I_FIN_CUSTOMER |
Callista |
|
|
Invoices |
I_INVOICE_ADJUSTMENT |
Callista |
|
|
Invoice Summary |
I_INVOICE_SUMMARY |
Callista |
|
| Payments | I_PAYMENT_LOAD | Callista | INTJ0022 or INTJ3022 |
| Refunds |
I_REFUND I_REFUND_CUSTOMER |
Callista | INTJ0023 |
| Matching Receipts | I_INVOICE_PAYMENT | Callista | INTJ0024 |
Note: All interface tables are prefixed with the letter 'I', for example I_FIN_CUSTOMER.
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.
It is possible for a person to be recorded on the Callista database under two identification codes. The System prevents data for that person from being consolidated under one ID (in form ENRF5900) while the person still has any outstanding debt.
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 instalments, 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.
For full details about the Person Payment Schedules, refer to documentation for the Maintain Person Payment Schedules form, FINF3800, and the job to process schedule entries, FINJ6111. For the context in which Person Payment Schedules are created, see Assessment and Invoicing in Understanding Student Finance.
Student ToDo Records. Whenever information relevant to invoicing changes in Callista, a Student ToDo entry is recorded in the tables STUDENT_TODO and STUDENT_TODO_REF. These tables are used by various Subsystems within Callista to initiate action. For COFI invoicing purposes, entries are those with a value of INT_FININV as their student ToDo type. For further information, refer to the Special Topic, When are invoicing ToDo records created?
Master Job. The master job INTJ0021 accesses the ToDo entries and checks whether an initial invoice is to be created, or if already invoiced, whether the current debt differs from debt already invoiced for the same instalment of the fee liability. In either situation, it creates a record in the interim table I_INVOICE_ADJUSTMENT. It then creates records in the Callista invoice history tables (I_INVOICE and I_INVOICE_TRANS). These records are finally summarised into the I_INVOICE_SUMMARY table ready for the finance system to process.
Other components of INTJ0021 are:
For more detailed information about the invoice master job, see INTJ0021 documentation.
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.
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 credit 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.
The above process is when a real discount exists for a student. When a real discount doesn't exist another process is followed. This process and the difference between the two is explained in Matching Invoices.
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).
Discounts and conditions are recorded in the 'template' payment schedule for the fee (in FINF2860). Processes run as a part of INTJ0021 to check whether discount conditions have been met, and make invoicing adjustments if they have not been met. Note that Student Contribution Amount discounts are never rescinded. More detailed information about checking discounts is given in the documentation for INTJ0021.
Single customer.
Two customers.
Example 1
A HECS-HELP student is undertaking two units with the same Census Date. These units are:
The student makes a payment before the census date of $1000. This payment has a value of $1250 ($1000 plus $250 HECS-HELP discount) in respect to the student's assessed $2000 HECS-HELP liabilities for the specified census date. The distribution of the payment would be:
Example 2
A HECS-HELP student is undertaking two units with different Census Dates. These units are:
The student makes a payment before the census date of $1000. Only 80% can be received for unit A. Matched payments for 31/03/2005 will be:
The system credit available for payment matching for the debt on the 01/04/2005 unit is $200. As this is neither $500 nor 80% of the unit cost, there is no discount available.
Matched payment for 01/04/2005 will be:
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).
An important part of payment processing is the application and re-application of payments to invoices in Callista. Because this processing is a part of both this Payments segment and the Invoices segment, applying payments to invoices is documented as a Special Topic.
Within the External Finance System the payment processing involves:
Within COFI the payment processing involves:
The transfer of payment information from the External Finance System must be performed by external processes and therefore is not under the control of COFI. Inter-system reconciliation between Callista and the External Finance Systems is not available via COFI, therefore reconciliation reports are the responsibility of the External Finance System.
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.
The majority of the preparation for refunds processing takes place in Callista. The Student Finance Subsystem handles the calculation of available credit, creation of refund records, and their approval. For a brief outline of this processing, and links to more detailed information, see the Payment and refunds section of Understanding Student Finance. The Unmatched Credits Report (INTR0110) supports refund processing.
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.
This processing is under the control of the master job INTJ0023. Note that components of other segments (Invoices and Matching Receipts) are also used in this job.
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).
The tables used to store debit memo records in Callista are the tables that also hold invoices and credit memos (see the diagram for the Invoice segment).
Note: If the Debit Memo Summary Indicator in the COFI table I_INT_CONTROL is set to Y then the job summarises tax and fee amounts separately for each debit memo record. See INTJ0023 for more information. Otherwise, the summary status is set to NO_SUMM and is therefore not summarised.
Master Job (Stage 2) The External Finance System then accesses the interface tables and processes the customer and refund details. A view of the refund tables I_REFUND_CUSTOMER_V may be used to access the refund data.
Master Job (Stage 3) Debit memos are matched to payments. The method is the same as for normal 'applying payments' processing, but records are not created in the Fee Assessment Tables. Finally, matched debit memos and payments in Callista are marked as fully processed.
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.
For more detail on finalising Fee Type Calendar Instances, refer to Finalising Fee Types in Student Finance documentation.
As a part of COFI, the Finalise Calendar Exception Report, INTR0108, is provided to list students whose situation would prevent a Fee Period from being finalised. See documentation of this report for recommended actions to prepare for finalising.
Once Calendars are finalised, the job INTJ0024, Process Finalised Application Payments, can be run. This job makes Payment and Invoices related to Finalised Fee Periods as fully processed. The data cannot be changed after this point.
By setting the DESG_PAYMENT_MODEL_IND to Y in the I_INT_CONTROL table, your institution can elect to use the COFI Designated Payment Model when processing invoices and payments.
The COFI Designated Payment Model allows the system to accept and process manual payment allocations, including sponsor payments for specific students. It also ensures that automatic payment matching and application does not affect any existing payment allocation for specific students.
To enable this, for the COFI Designated Payment Model, two new jobs (INTJ3021 and INTJ3021) are used, and two new forms (INTF3053 and INTF3054) are also available.
The diagram below shows the difference in processing steps available via the Standard COFI and Designated Payments COFI arrangements.
Last Modified on 27 October, 2015 12:38 PM
History Information
| Release Information | Project | Changes to Document |
| 18.0.0.2 | 2146 - VU - Payment Matching | Added COFI Designated Payment Model section and references to new forms and jobs for the Designated Payment Model. |
| 10.0.0.0.0.0 | 1338 - PDS - Payment Matching - Part 1 | Under the heading 'Invoices' added sub heading 'Matching Invoices' |