INTJ0020 - Prepare Customers For Transfer to External System

Purpose

To prepare Customer records for transfer to an external system.

Subsystem Callista Open Finance Interface
Normally Run By A Fees Specialist
Anticipated Frequency At the start of a Fee Period, and then generally as an integral part of an Invoice job, in a planned cycle.
Structure Block  Process Finance Customers
Tab  Parameters

 

There are two ways to use INTJ0020. With or without the Test for Student and Sponsor Activity. INTJ0020 will always run Prepare Customer Records for Transfer to External System, regardless if the checkbox is selected or not. If the check box is selected, it will ALSO Test for Student and Sponsor Activity. Beware of the extra time required if the check box is selected.

Processes write data to customer records, update transfer statuses and create or update customer information in a customer table (I_FIN_CUSTOMER table)

The modules of this job can be incorporated into the invoices INTJ0021.

The context for this job is described in the overview.

Run Details
INTJ0020 can only run in batch mode, through the Job Control and Scheduling Subsystem. It can be run as a standalone job. But its component modules can also be run from the invoice transfer job, INTJ0021, by selecting a parameter in that job.

Job Conflict
This job has been set up with conflict records preventing it running concurrently with INTJ0021, INTJ0022, INTJ0023 and INTJ0024. Nor can several instances of INTJ0020 run simultaneously.

Transfer Statuses
The set of transfer status values indicating progress in the transfer of each record of I_FIN_CUSTOMER between Callista and the customer external system is:

  • TODO, READY – set by Callista interface processes.

Timing
An initial run might be timed for early in a Fee Period, after student Sponsorships are established. This would normally pick up most new customers and those whose details have changed. Thereafter the job’s modules would generally be run as a part of INTJ0021.

Running Test for Student and Sponsor Activity can be used as a cleanup process. This should only be used if the Target System sets an Inactive status, as the process can take a long time. As such it might be run only once a year, as part of an initial run at the start of a new financial period.

Error Handling
INTJ0020 references the value of the JOB_STOP_FIRST_ERR_IND indicator in the I_INT_CONTROL table, which enables each institution to specify the type of error handling required for all COFI (INT) jobs. The two error handling options are:

  • Continue job processing (JOB_STOP_FIRST_ERR_IND = N) – ignore (& handle) errors as they are encountered and log error details. The job continues and processes the next student’s record.
  • Stop job processing (JOB_STOP_FIRST_ERR_IND = Y) - fail the job when the first error is encountered and record details of the system error in the system error log.

Checking on the Job Run
If the system is configured to continue job processing for COFI jobs (see Error Handling above) then all information, warning and error messages will be logged to S_LOG_ENTRY. The S_LOG_TYPE is FIN-CUST.

If the system is not configured to continue job processing for COFI jobs the job log could be helpful in explaining why, if INTJ0022 FAILED.

Checking on the Job Run

Always check the run log in form JBSF5301 to see that the job ran successfully. Custom built messages in the log indicate the outcomes for each component of the job.

If the system is configured for COFI jobs to continue processing then the job log will contain a Summary which includes:

  • Progressive Processing counts for each part the process. (Where the Processing Count message displays: Total number of records processed, with sub-totals of the number of records processed successfully and the number of records with errors.)
  • Total number of Log Entries created.
  • A message suggesting that the user queries the system log entries for details of all errors and exceptions. Noting that the Log Type for these entries is ‘FIN-CUST’.

Important: Note that in order for this summary information to be included in the run log, the PASS_RJR_ID_IND value for this job, must be set to 'Y' in the S_JOB table.

To view the job log, see JBSF5301 (via JBSF5300). To view system error details see GENF0001.

 

The Process Finance Customers block contains:

Parameters Tab

This job:

Prepares Customer Records for Transfer to External System

Optionally:

Test for Student and Sponsor Activity check box

 

Prepare Customer Records for Transfer to External System

This picks up customer records with a value of TODO in the transfer status field and carries out preliminary tasks to prepare records for transfer.

It is quite possible that several TODO records will exist in the I_FIN_CUSTOMER table for a single student or Sponsor. For example, a record will be created for a new student both on offer of a place and when a student course attempt record is created through pre-enrolment.

Since only one TODO record per customer is needed to prompt action, the first task is to physically delete all but the most recent record with this status from the I_FIN_CUSTOMER table. As a further housekeeping task, the module also logically deletes fully processed records in the table, with the exception of the most recent. These are records where data has been successfully transferred to the external system.

Information for transfer is retrieved from the Student Finance database and written to the appropriate records in I_FIN_CUSTOMER.

For a Student, these are the details written to the record:

  • The Customer Number - the student's Person ID code is prefixed with 'ST' and becomes the Customer Number.
    For example, Student ID '98754511' becomes 'ST98754511'.
  • The Person's Name, Title, Sex, and Address details .
  • Their Payment Advice Number, held as an alternative ID (see ENRF3010).
  • The Customer Type, with a value of STUDENT .
  • The Customer Status, recorded as Active or Inactive (the checks for inactivity are run again in this module).
  • The Customer_Cat is populated with the following information:
    • STUDENT
    • LOANSCHEME
    • SPON_PERSN
    • SPON_EXTNL
    • SPON_INTNL

For a Sponsor, these are the details written:

  • The Customer Number - the Sponsor code is prefixed with 'SP' and becomes the Customer Number.
    For example, Sponsor code 'GRANT001' becomes Customer Number 'SPGRANT001'
    .
  • The Sponsor code, Name of person or organisation (held in shortened form in the Given Names field, and in full in the Display Name field) and Address.
  • A Phone Number and a contact person if the Sponsor is an Organisation.
  • The Sponsor's Payment Advice Number (see FINF4100).
  • The customer_type, with a value of Sponsor.

For a Loan Scheme, these are the details written:

  • The Customer Number - the loan_scheme_ci_cd is prefixed with 'SP' and becomes the Customer Number.
    For example 'PELS0401' becomes 'SPPELS0401'
    .
  • The Surname is loaded with the loan_scheme_ci_cd.
  • The given_names is loaded with the loan_scheme code.
  • The display_name is loaded with the loan_scheme description.
  • Sex is loaded with U.
  • The contact_person is load with '# LOAN SCHEME #'.
  • The customer_status is always set to ACTIVE.
  • If it is configured to load the customer_cat is set to 'LOANSCHEME'.
  • The customer_type is set to Sponsor.
  • Other address columns are left blank.

Rules/Notes:

A person that is a Student and a Sponsor is recognised as a Student by their Person ID and as a Sponsor by their Sponsor code.

Payment Advice Number is generated for them the first time a person payment schedule is created.

Batch number and batch date columns are added to the transfer table of I_FIN_CUSTOMER table to support the batch loading of export data. In addition, columns for generic attributes are added for future development.

SPON_PERSN are for Sponsors who are persons in the system.
SPON_EXTNL are for organisations external to the institution.
SPON_INTNL are for organisations that are part of the institution structure like a department or faculty.

Test for Student and Sponsor Activity check box

This is typically run at the start of a new interface cycle to perform a 'cleanup operation' for customers who have been active in a previous cycle, but are now inactive.

For all active customers in the I_FIN_CUSTOMER table, the process checks Student Finance data for student or Sponsor activity, as appropriate. If either is discovered to be no longer active, a TODO customer record is created in I_FIN_CUSTOMER.

Conditions

A Student is regarded as inactive if all the following conditions are met:

  • All their student Course Attempts have a status of either COMPLETED, DISCONTIN or DELETED.
  • All debts for which they have been assessed are matched by payments (regardless of whether they, or a Sponsor, is liable for the debt).
  • No refund is due to the student.
  • There are no Student To Do entries with a FEE_RECALC type (signifying a student due for fee assessment).
  • All Invoice records and Payment records are fully processed.

A Sponsor is regarded as inactive if these conditions are met:

  • Both the status for the Sponsor (shown in FINF4100), and the statuses for all their current Sponsorships (in FINF4300) are set to an equivalent of INACTIVE. The test for Currency is that the run date falls within the period defined by the Sponsorship's Start and End Dates.
  • All debts for which they are liable are matched by payments.
  • No refund is due to the Sponsor.

A Loan Scheme is always reported as Active

  • The Loan Scheme is not assessed for Activity status

If a currently inactive customer becomes active again in Student Finance, this triggers another TODO record, and the customer reverts to Active on the database.

Rules/Notes:

A student reverting from Discontinued to an Active status will trigger a new TODO record.

For the latest TODO record details are written to the file. TRANSFER STATUS of this record is set to READY.

If the checkbox is not selected, the Customer_cat column in I_FIN_CUSTOMER file will be null

 

Last Modified on: 11-Oct-2010 4:29 PM

History Information

Release Version Project Change to Document
11.0.0.0.0.0. 1350 - Job Error Handling Added details relating to error handling and log entries