INTJ3022 processes payments made by an external payment portal which have been created as records in the i_payment_load table. It verifies the payment data, creates a payment record and also matches and applies those payments to any existing invoices.
It runs independently, but accesses invoices created by INTJ3021. The context for this job is described in the COFI Overview help page.

INTJ3022 uses a hierarchy to determine which invoices to match. This hierarchy has the following order:

• Invoice Due Date
• Payment hierarchy rank
• (invoice) Created_on date
• UOO_ID
• Person_id
• Loan_discount_inv_ind - DESC

When automatically matching and applying payments to invoices, it does not re-match parts of payments that have already been allocated to an invoice in i_invoice_payment.
To see how matching of payments occurs in INTJ3022 see Matching Designated Payments.

Credit Memos and New Invoices
When processing unprocessed payment allocations, INTJ3022 looks for current i_invoice_trans records for an existing invoice which have a prev_invoice_num matching the invoice number of the unprocessed payment match. If it finds one, it applies the payment to the new invoice as required.
In the cases where an invoice is fully credited and a new invoice is created without reference to the original, this match cannot occur and the unprocessed payment allocation will remain unprocessed

Sponsor Payments
A sponsor payment may be directed to a particular student (in INTF3054) and when payment matching is run, these will only be matched to invoices with that person ID.
A sponsor payment may also include a refereence to an invoice. In which case it will be matched with that invoice.

Loan Scheme Payments
Loan Scheme processing is the same as for sponsors, however these will never be directed to a specific students or invoices.

Run Details
INTJ3022 must be scheduled to run through the Job Control & Scheduling Subsystem. If scheduled to run ASAP, a message displays to indicate that no parameter form is required.

Job Conflict
This job has been set up with conflict records preventing it running concurrently with INTJ0020, INTJ0021, INTJ0023, INTJ0024, INTJ0060 and INTJ0065. Several instances of INTJ0022 cannot be run simultaneously.

Error Handling
For details about how this job handles errors and reports on its progress, see COFI Error Handling.

INTJ3022 or INTJ0022?
Note: If your institution does not use the COFI Designated Payment Model (DESG_PAYMENT_MODEL_IND is set to N in the I_INT_CONTROL table) then INTJ3022 will not be available. In that case you should look at the help for INTJ0022, the job which takes its place in your system.

Statuses

The 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

Creating Payment Data in Callista

The table I_PAYMENT_LOAD is populated by the external finance system and the system needs to know about each receipt.
Payments are not matched to invoices at the source of receipts. The system calculates what invoices should be paid by which receipt.

This job finds records in the I_PAYMENT_LOAD table with a Transfer Status of READY and then performs the following:

• 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 payment, it checks that an invoice exists in the 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, it 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 the I_PAYMENT_LOAD table.
• Any remaining READY records are then loaded into the I_PAYMENT table with a Processed Status of TODO. The transfer status in for these records in the I_PAYMENT_LOAD table is changed to SUCCESSFUL.
• EXT_TRANSFER_STATUS inthe I_PAYMENT_LOAD table is set to READY if the transfer staus is SUCCESSFUL.

Processing Import Data

The job performs the followingl:

• Reads I_PAYMENT_LOAD tables entries with a TRANSFER_STATUS of READY.
• Loads the I_PAYMENT table.
• Applies new payments to old invoices and write to the FEE_ASS table with new payments.
• Calls 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.
• If the load of I_PAYMENT is 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 job 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 INTJ3021 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 (INTJ3022) 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
  
• This process may be used at the discretion of the institution. The job will not indicate its success or otherwise.
• The status referred to is the EXT_TRANSFER_STATUS 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