Purpose

To create debit memo invoices from approved refunds in Callista, ready for transfer to the External Finance System. From this data, the External Finance System creates new invoices.

Depending on an institution's refund policies, may be run (after refund approval in Callista)

• At the end of a fee period or financial year
• Whenever refunds are made on request.

A parameter form is not required for this job, however Message Box (6636) states: No parameters exist for this job. Do you wish to schedule the job to run as soon as possible?

INTJ0023 consists of six major components:

• Create Interface records
• Create Debit Memo Invoices
• Create Refund Customer records
• Apply Debit Memo invoices to payments
• Mark invoices and payments as fully processed

This job completes the refund cycle initiated by creating and approving refund records in the Callista Student Finance subsystem, using the job FINJ6430 and/or the form FINF6420.

The context for this job is described in the overview.

Run Details
INTJ0023 can only run in batch mode, through the Job Control & Scheduling Subsystem.

There are no parameters for this job.

Job Conflict
Conflict records prevent this job from running concurrently with INTJ0020, INTJ0021, INTJ0022, INTJ0024, INTJ0060 and INTJ0065. Nor can several instances of INTJ0023 run simultaneously.

Transfer Statuses
Transfer Statuses in I_REFUND and I_REFUND_CUSTOMER reflect the progress of transferring to the External Finance System. AR_TRANSFER_STATUS and AP_TRANSFER_STATUS apply to the Transfer Status for I_REFUND while TRANSFER_STATUS tracks the progress of transferring to I_REFUND_CUSTOMER.

Values for I_REFUND are:

• PROCESSING, ERROR , READY, SUCCESSFUL

Values for I_REFUND_CUSTOMER are:

• SUCCESSFUL, ERROR, PROCESSING–set by processes under the External Finance System's control;
• READY, TODO –set by COFI processes.

Timing
Refunds will typically be made at the end of a fee period or financial year. This job relies on prior authorisation of refund records in Student Finance (see Payment and refunds documentation in that subsystem).

Error Handling
INTJ0023 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 system error is encountered.
  

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 and S_ERROR_LOG.

Entries in S_LOG_ENTRY have an S_LOG_TYPE of ‘REFND-PREP’ and include details of:

• Interface refund sequence number   
• Customer Number     
• Refund sequence number 
• Person id        
• Sponsor code
• Loan Scheme
• Interface refund customer transaction id     
• Interface invoice payment sequence number
• Interface payment sequence number
• Invoice prefix  
• Invoice number         
• Invoice summary number    
• Related message 

Note: Information only supplied if it is available and appropriate to the processing where the system message or system error was recorded. Otherwise the data element will be NULL.

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)
• 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 ‘REFND-PREP’.

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.

The run log can be checked in JBSF5301 (accessed via JBSF5300). Error details can be viewed in GENF0001.

Create Interface Refund Records

This module first:

• Resets records in the COFI I_REFUND table reported in error by a previous run. AR_Transfer_Status is set immediately to SUCCESSFUL and AP_Transfer_Status is changed from ERROR to READY (see Transfer Statuses).

  This assumes that remedial action has taken place. For example, if the error was that the customer did not exist as a supplier in the External Finance System at the time of the previous run, the expectation is that a supplier record has been created in the interim.

It then:

• Retrieves account code details for the invoice from COFI's  I_INT_CONTROL table,
• Retrieves reference data for APPLIED records from Callista's REFUND_STATUS table,
• Creates a record in the I_REFUND table for each APPROVED refund record in the External Finance System, then sets the record with a Transfer Status of READY,
• Creates a record in the I_REFUND_CUSTOMER table for each APPROVED refund record in the External Finance System, then sets the record with a Transfer Status of TODO, and finally
• Sets the refund records in the External Finance System to the user defined value equivalent to APPLIED.

Rules/Notes

No actual transfer to Accounts Receivable is made from AR_Transfer, hence the AR_Transfer_Status is immediately set to SUCCESSFUL. The External Finance System generates its own Accounts Receivable records from the data extracted from I_REFUND and I_REFUND_CUSTOMER.

Create Debit Memo Invoices

Data from the I_REFUND table is loaded into I_INVOICE and I_INVOICE_TRANS tables.

For each READY record in I_REFUND a record is created in both the I_INVOICE and I_INVOICE_TRANS tables with an invoice number prefix of CDM. This distinguishes it from other invoices (CIN) and credit memos (CCM).

Refer to INTJ2021 - Create Invoice Records for more information.

The refund sequence number of the I_REFUND record becomes the invoice number for the record in I_INVOICE and I_INVOICE_TRANS.

For each new CDM record in I_INVOICE:

• The Invoice Due Date and posting period is set to the current System Date;
• The account code is retrieved from the I_INT_CONTROL table (REFUND_ACCOUNT_CD_AR).

For each new CDM record in I_INVOICE_TRANS:

• The refund amount is loaded as the invoice transaction amount;
• The comment DEBIT MEMO is entered;
• The Fully Processed check box is set to N.

Create Refund Customer Records

This module inserts customer details in the I_REFUND_CUSTOMER table for each previously produced TODO record. See Create Interface Records for more information.

This module first cleans up the I_REFUND_CUSTOMER table. It searches the table and for each customer:

• Logically deletes all but the latest record with a Transfer Status of TODO (unprocessed);
• Logically deletes all but the latest record with a Transfer Status of SUCCESSFUL (fully processed).

In I_REFUND_CUSTOMER, for each TODO record that is not logically deleted, the module then retrieves the name, Address and other details of the customer and inserts these into the I_REFUND_CUSTOMER table. The information inserted into the I_REFUND_CUSTOMER table is:

Student Information

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

Sponsor Information

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

If a REFUND Address Type exists for the customer this detail is inserted, otherwise a Correspondence Address is entered. This allows the creation of one-off customers in Accounts Payable in the External Finance System.

Loan Scheme Information

• 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

For both students, Sponsors and Loan Schemes, the module then sets the Transfer Status of the I_REFUND_CUSTOMER record to READY for transfer to the External Finance System.

Prepare Invoices for transfer to External Finance System

The I_REFUND_CUSTOMER_V view of I_REFUND_CUSTOMER and I_REFUND  may be used to access the customer refund details. 

The Transfer Statuses of debit memo records is no longer required and consequently the AR_Transfer_Status is immediately set to SUCCESSFUL.

The External Finance System process would examine I_REFUND records with a AR_Transfer_Status of SUCCESSFUL and I_PAYMENT_CUSTOMER records with Transfer_Status of READY to affect new invoices and vendors in Payables.

The DEBIT_MEMO_SUMMARY_IND check box in the interface table I_INT_CONTROL allows institutions to configure COFI to summarise invoice data  for refunds in I_INVOICE_SUMMARY.

If the I_INVOICE_SUMMARY is set to N then the SUMMARY_STATUS is set as NO_SUMM and the records will be ignored when INTJ0060 is run.

Apply Debit memo invoices to payments

This module applies debit memo invoices to payments in Callista. Refund debit memos are matched to payments in Callista using processing modules in common with those used to match payments to regular invoices. See INTJ0021- Apply payments for more information.

Invoices are stored in Callista in the invoice history tables, I_INVOICE and I_INVOICE_TRANS, and payments in the I_PAYMENT table. The relationship between a particular invoice and a particular payment at any point in time is recorded in the I_INVOICE_PAYMENT table.

This module:

• Accesses those Customer Numbers in the I_INVOICE and I_INVOICE_TRANS tables that have invoices inserted on the last run date of this job. The date is stored in the I_INT_CONTROL table.
• Checks for the last break point at which existing relationships between invoices and payments are valid.
• Applies payments to refund debit memo invoices. In general, the principles to match payments to debit memos are the same as those described for the 'invoice stream' in the Special Topic Applying Payments. However, with the following differences:
  • A debit memo or memos do not necessarily totally satisfy all unmatched payments for a customer—each institution may choose to refund only a part of the total amount of that customer's credit. However, there are always payment records to satisfy refund debit memos (where as there may not be payment records when attempting to match regular invoices).
  • Matching on date is not significant, since the date for debit memos is always the run date.
  • Similarly, matching on payment rank is not an issue, since ranks are recorded against particular fees, but debit memos are not fee specific – they reflect a person's or Organisation's credit in general.
  • A match is made only once; where as in matching regular invoices, adjustments may be made to already matched invoice/payment relationships.
  • For debit memos, no records are written to the fee assessment tables. This means that refund transactions are not shown in the Manual Fee Assessment form, FINF3610, or in the Student Finance inquiry forms.
• Sets the Transfer Status of records in I_INVOICE_PAYMENT to READY.

Mark invoices payments as fully processed

This module sets invoice and payment records in I_INVOICE_TRANS and I_PAYMENT to fully processed for related invoice/payment records in I_INVOICE_PAYMENT that have been transferred to the External Finance System.

For a more detailed explanation of this process, refer to the master job INTJ2024.