Purpose

To transfer payment information received from an external finance system into Callista, and in Callista, to match the payments to invoices according to payment application criteria.

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?

INTJ0022 consists of two major components:

• Create payment data in Callista
• Apply new payments to existing invoices

This job runs independently, but accesses invoices created by INTJ0021.

The context for this job is described in the overview.

Run Details

INTJ0022 can only run in batch mode, through the Job Control & Scheduling Subsystem.

Job Conflict

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

Transfer Statuses

The complete set of transfer status values indicating progress in the transfer of each record of I_PAYMENT_LOAD between Callista and the external finance system and between I_PAYMENT_LOAD and I_PAYMENT in Callista is:

For I_PAYMENT_LOAD:

• READY, PROCESSING, SUCCESSFUL, ERROR, DELETED

For I_PAYMENT:

• TODO, ACTIV, FULL

Timing

This job should be run in a timely manner after payments are received. This will keep person payment schedules (shown in FINF3800) and the assessment transaction shown in FINF3610 up to date, and ensure that current information is available for statement extracts

A nightly run may be advisable to process any payments made through a cashiering system. Special runs could be organised after a bank tape is received and processed.

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

Entries in S_LOG_ENTRY have an S_LOG_TYPE of ‘PYMNT-TRNS’ and include details of:

• Customer number                                     
• Receipt number                                       
• Invoice payment sequence number              
• Person id                                                       
• Census date                                                 
• Fee type                                                       
• Fee calendar type                                        
• Fee calendar instance sequence number  
• Fee category                                              
• Course code                                                
• Unit offering option ID                                  
• Related message                                           

Note: Information is 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 ‘PYMNT-TRNS’

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.

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.

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

Create Payment Data in Callista

This module finds records in I_PAYMENT_LOAD with a Transfer Status of READY. Then:

• For each READY record it checks if the Customer exists in Callista. (Customer number or check payment advice number in I_FIN_CUSTOMER table).
• If the customer does not exist then the transfer status for the record changes to ERROR and a message appears in the Transfer Message field.
• For each designated payment the module checks that an invoice exists (I_INVOICE_TRANS table) that matches the payment record. If an invoice does not match the Payment record then the transfer status of the payment record changes to ERROR.
• For reversal (payment type) records, the module checks if a payment record (receipt) already exists in Callista in I_PAYMENT_LOAD. If the original receipt does not exist then an ERROR Transfer Status and Transfer Message appears for this record in I_PAYMENT_LOAD.
• Any remaining READY records are then loaded into the I_PAYMENT table with a Processed Status of TODO. The transfer status in I_PAYMENT_LOAD for these records changes to SUCCESSFUL.
• Ext_transfer stauts of I_PAYMENT_LOAD is set to READY if the transfer staus is SUCCESSFUL.

Rules/Notes:

Payment is received in the external financial system and the system needs to know about each receipt.

Payment should not be matched to invoice at the source of receipts. The system will calculate what invoices should be paid by which receipt.

The table I_PAYMENT_LOAD should be populated by the external finance system.

Processing Of Import Data

The payments job (INTJ0022) will:

• Read I_PAYMENT_LOAD tables entries with a TRANSFER_STATUS of READY.
• Call INTK_INS_PAYMENT and INTP_INS_PAYMENT with various input parameters. This procedure loads the I_PAYMENT table.
• Apply new payments to old invoices and write to the FEE_ASS table with new payments.
• Call the discount procedure to award discounts in FEE_ASS where required.
• Where the I_PAYMENT record has been successfully loaded its sequence number (IP_SEQUENCE_NUMBER) is written to the I_PAYMENT_LOAD table.
• The transfer_status of I_PAYMENT_LOAD is updated to SUCCESSFUL and the EXT_TRANSFER_STATUS is set to READY.
• Should the load of I_PAYMENT be unsuccessful, the TRANSFER_STATUS of I_PAYMENT_LOAD will be set to ERROR and the TRANSFER_MESSAGE written.

Apply New Payments to Existing Invoices

The way in which payments are matched to invoices is more fully documented in the Special Topic Applying Payments.

This module navigates the 'payment stream' and is called once payments have been transferred to Callista and loaded into the I_PAYMENT table. Processes in the payment stream perform the tasks below before applying or re-applying payments as discussed in the Special Topics section.

• The module checks if the payment record is a reversal of payment. If so it deletes the appropriate I_INVOICE_PAYMENT, writes a new record to I_INVOICE_PAYMENT with a zero amount indicating a reversed relationship, and reverses out the original payment transaction in the fee assessment table.
• If a discount may have been awarded on the basis of an original payment that has now been reversed, a process creates a Student ToDo entry to check if the invoice should be recalculated when the invoicing job INTJ0021 is next run.
• If it is a pre-dated payment, the details are retrieved and written to the Student ToDo tables.
• The module checks for the last point at which existing relationships between invoices and payments are valid.

External Financial System tasks - import table creation

• Establish which receipts have been received since the last transfer to Callista.
• Write entries to the I_PAYMENT_LOAD table with a TRANSFER_STATUS of READY and an EXT_TRANSFER_STATUS of TODO.

The form INTF1000 displays I_PAYMENT_LOAD details.

Creation of Export table

The I_PAYMENT_LOAD table may be used as an export to the finance system.

• The above job (INTJ0022) also updates the I_PAYMENT_LOAD column ext_transfer_status to READY. The I_PAYMENT_LOAD table has been loaded successfully and is ready to be loaded to the GL.

External Financial System Tasks - payment export table processing

• Read the I_PAYMENT_LOAD record with an EXT_TRANSFER_STATUS of READY.
• Create the GL entries in the external financial system to match the data in the system.
• Write a reference of the GL loading procedure in the EXT_BATCH_DT.
• Write a SUCCESSFUL EXT_TRANSFER_STATUS to the I_PAYMENT_LOAD table.
• Where there are errors that are related to the source data write ERROR to the EXT_TRANSFER_STATUS and write a message to EXT_TRANSFER_MESSAGE of the I_PAYMENT_LOAD table.
• If it is useful to the external finance system the following columns in the I_PAYMENT_LOAD table are available for update by the external processing for record keeping purposes; Ext_Batch_Number, Ext_Batch_Dt, Ext_Posting_Dt, Ext_Attribute_1, Ext_Attribute_2,
  Ext_Attribute_3, Ext_Attribute_4, Ext_Attribute_5, Ext_transfer_status, and Ext_transfer_message
  

Rules/Notes:

This process may be used (or not) at the discretion of the institution. COFI will not process the success or otherwise of this process.

The status referred to is the EXT_TRANSFER_STATUS (at left) and EXT_TRANSFER_MESSAGE that refers to the transfer to the external transfer of payments (to Finance system) as opposed to the TRANSFER_STATUS and TRANSFER_MESSAGE that refers to the internal transfer of payments