Purpose

To prepare Customer records for Transfer to an External System

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

Checking on the Job Run

If you require to read through an action log of events, see form JBSF5300 and JBSF5301. This could be helpful, especially if a FAILED message is returned. The log would then give information on what parameters caused INTJ0020 to fail.

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