Purpose

To create COFI invoices for notified fee debts of students, sponsors and loan schemes; apply payments and create loan discounts.

This job creates invoice data for notified fee debts of students, sponsors and loan schemes. It also applies payments and creates loan discounts.

The Payment Due Date defined in the Person Payment Schedule (PPS) is taken as the Due Date for invoice creation.

The job is normally run by itself. Optionally, modules of the job INTJ0020 can be run as the first processing task within the current job. Be aware of the extra time that will be required to run the process when such check boxes are selected.

Provision for confirmation of the inclusion of a tax code into the invoice and invoice summary records has been made through I_INT_CONTROL.

Whenever there is a new invoice or an adjustment to an invoice, a new I_INVOICE_ADJUSTMENT table entry will be written.

Lamps are used in INTJ0021 (and also in INTJ0060) to highlight record processing status. 'Invoice Summary data contains export errors' is in the colour red, and 'Invoice Summary data ready for export' is in the colour green.

This job will normally follow the processing of Person Payment Schedules (FINJ6111) in Student Finance.

The context for this job is described in the overview when the process of a real discount exists for a student. When it doesn't, another process needs to be considered. See Matching Invoices.

Error Handling: The JOB_STOP_FIRST_ERR_IND indicator in the I_INT_CONTROL table allows each institution to specify the type of error handling for this job and all other COFI jobs.  The two error handling options are:

• Continue job processing (JOB_STOP_FIRST_ERR_IND = N) – ignore (and handle) errors as they are encountered and log error details. Any changes that occurred for that payment are rolled back and the job continues processing the next record.
• Stop job processing (JOB_STOP_FIRST_ERR_IND = Y) – fail the job when the first error is encountered (existing functionality).  Note:. Any failed validations that do not currently cause the job to fail prior to the introduction of the 'continue job processing' option, will not be affected by the selection of this option.

When the JOB_STOP_FIRST_ERR_IND indicator in the I_INT_CONTROL table = N, then details of any validation errors will be written to S_LOG_ENTRY and if an Oracle exception is encountered, details are written to S_ERROR_LOG, and a general message is written to S_LOG_ENTRY - to refer the user to the S_ERROR_LOG for details.

Entries in S_LOG_ENTRY have an S_LOG_TYPE of 'CREATE-INV' and include details of:

• Customer number                                  
• Person id                                                    
• Course code                                         
• Calendar type                                     
• Calendar sequence number               
• Fee type                                        
• Fee category                                      
• Unit code                                          
• Unit offering option id                             
• Payment due date                              
• Sponsor code                                         
• Loan Scheme                                       
• Invoice adjustment id                            
• Invoice prefix                                          
• Invoice number                                        
• Invoice summary number                  
• Census date
• 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.

Checking on the Job Run

If the system is configured to Continue processing, then the run log displayed in JBSF5301 includes a more detailed summary showing the relative success for each part of the job. The form of the log summary is as shown below:
-----------------------------------------------------------------------------------------
Optional processing (process customer indicator):
Started creating processing customer records SYSDATE
-Optional processing (check customer active indicator):
Reset customer export errors for re-processing SYSDATE
           <Processing counts message>
Maintain customer records for export - reduce to most recent for each customer SYSDATE
         <Processing counts message>
Maintain exported customer records - reduce to most recent for each customer SYSDATE
           <Processing counts message>
Started review of customer status SYSDATE
Completed review of customer status SYSDATE
Review status of active customers SYSDATE
Count of customer that have become inactive: 21
           <Processing counts message>
-End of optional processing (check customer active indicator):
<this will not be repeated if already completed in check customer active processing>

Deleting all but the most recent unprocessed customer record SYSDATE
          <Processing counts message>
Retiring all but the most recent processed customer record SYSDATE
           <Processing counts message>
<this will not be repeated if already completed in check customer active processing>
Started preparing customer data for transfer SYSDATE
Completed preparing customer data for transfer SYSDATE
Update customer details to be ready for export SYSDATE
           <Processing counts message>
Completed creating processing customer records SYSDATE
End of optional processing (process customer indicator):

Optional processing (Check due dates have lapsed indicator):
Started Identifying schedules where due dates have elapsed SYSDATE
           <Processing counts message>
Completed Identifying schedules where due dates have elapsed SYSDATE
End of optional processing (Check due dates have lapsed indicator):

Started invoice adjustment processing SYSDATE
Create ToDos for unsucessfully processed records SYSDATE
           <Processing counts message>
Reserve ToDos for processing records SYSDATE
          <Processing counts message>
Review ToDos for changed details and when appropriate
Create invoice adjustments SYSDATE
           <Processing counts message>
Completed invoice adjustment processing SYSDATE

Started invoice processing SYSDATE
Update invoice adjustments status for processing SYSDATE
          <Processing counts message>
Update invoice adjustments - transfer amount details SYSDATE
           <Processing counts message>
Update invoice adjustments - invoice details SYSDATE
           <Processing counts message>
Create credit memos SYSDATE
           <Processing counts message>
Create invoice records SYSDATE
           <Processing counts message>
Create invoice transaction records SYSDATE
           <Processing counts message>
Update paired credit memos SYSDATE
          <Processing counts message>
Update paired invoices SYSDATE
           <Processing counts message>
Update processed invoice adjustments to successful SYSDATE
           <Processing counts message>
Completed invoice processing SYSDATE

Started applying payments to new invoices SYSDATE
           <Processing counts message>
Completed applying payments to new invoices SYSDATE

Started updating invoices with external reference details that are related to successfully exported summary records SYSDATE
           <Processing counts message>
Completed updating invoices with external reference details SYSDATE

Started maintaining loan discounts in Callista SYSDATE
           <Processing counts message>
Completed maintaining loan discounts in Callista SYSDATE

Started creating job message run log SYSDATE
            Total number of system log entries created: 130
Please query the system log entries for details of all errors and exceptions. Additional detail on system errors can be viewed in the system error log.
            - Log Type: ‘CREATE-INV’
            - Log Creation Date: SYSDATE
Completed creating job message run log SYSDATE
-----------------------------------------------------------------------------------------

The <Processing counts message> is:
 ‘Total records processed: ‘ || <total_records> || ‘(Successful: ‘ ||  <total_records> - <error_records> || ‘ Unsuccessful: ‘ || <error_records> || ‘)’
For example, Total records processed: 10 (Successful: 5, Unsuccessful: 5)

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

The Create Fee Invoices block contains:

Parameters Tab

This job:

• Creates Invoices
• Applies Payments to New Invoices (if required)

Optionally, the following can be run:

• Prepare Customer Records (Prior to Invoice Creation) - check box
• Test for Student and sponsor Activity
  (Only if preparing customer records) - check box
• Check for Earned Discounts where Due Dates have Elapsed - check box

Rules/Notes:

Create Invoices

The first process of INTJ0021 is to clear out any temporary (TMP) data (for example, temporary adjustments and invoices), before creating invoices.

INTJ0021 creates an I_INVOICE_ADJUSTMENT table entry based on the values in the PERSON_PAYMENT_SCHEDULE table. Whenever there is a new invoice or an adjustment to an invoice (a new amount for example), a new I_INVOICE_ADJUSTMENT table entry will be written.

This table is then used to create the I_INVOICE and I_INVOICE_TRANS tables. Once these are written, the TRANSFER_STATUS of the associated I_INVOICE_ADJUSTMENT will be written as successful.

The I_INVOICE records are created with a SUMMARY_STATUS of READY, that is, they are ready to be summarized.

Part of the INTJ0021 process checks the invoice summary external processing and provides a lamp on the parameter form and a message in the log of the job if there are summary records to be processed or if there are errors with the invoice summary processing.

Types of Adjustment

An adjustment may require:

• A new invoice, where there is a new entry in the Person Payment Schedule (PPS). This may be because the assessed amount due for a particular fee has increased and therefore a new PPS installment (with a different due date) has been created by the system. Or it may be that the amount due has been spread across more instalments by manual adjustment in the PPS form.

• The reversing of an existing invoice with a credit memo. This will be necessary when, for instance, the debt for an installment of a fee liability is reduced or a discount proves not to be earned. It may involve:
• Creation of both a credit memo record and a replacement invoice record in the invoice history tables (where the debt for the installment is reduced), or
• Only creation of a credit memo where a customer is no longer liable for a particular fee installment. A likely example is where a student has withdrawn from all units in a course for which a fee has been charged. If, in this example, there were several instalments of the fee, all instalments would be reversed.

The Comments field of the I_INVOICE_TRANS_V indicates a new invoice as an 'Original' and a replacement invoice as being a 'Transfer from Invoice <9999>'. Refer to the examples in Notes (at right).

To distinguish invoices from credit memos, invoice number prefixes are recorded in the invoice history tables and appear as prefixes of transaction numbers as follows:

• CIN for an invoice
• CCM for a credit memo

As part of the invoice processing Credit Memos and their original invoices (with prefixes of CCM and CIN respectively) will have their CCM_PAIR_IND set to Y. Only invoices that do not have a credit memo pair will be matched against the payment table (I_PAYMENT) to create the I_INVOICE_PAYMENT and the Payment records in FEE_ASS. The discount procedure to award discounts in FEE_ASS is called where required.

Rules/Notes:

The invoice Due Date for unit-based Person Payment Schedules associated with Govt. Loan Schemes that have a system Transaction Type of HCSHLPLOAN or FEEHLPLOAN, is the Person Payment Schedule (PPS) Due Date.

Example 1 - New Invoice

For a student's liability for a tuition fee, relevant data in the Person Payment Schedule (PPS) is:

• Payment Due Date = 28.05.2003
• Expected Payment = 1000

After re-assessment, this entry is deleted and a new PPS entry created, with these values:

• Payment Due Date = 15.06.2003
• Expected Payment = 800

Below are the three associated entries in I_INVOICE_TRANS_V.

Example 2 - Replacement Invoice

For a student's liability for a tuition fee, relevant data in the Person Payment Schedule (PPS) is:

• Payment Due Date = 28.05.2003
• Expected Payment = 1000

This entry changes, and now has these values:

• Payment Due Date = 28.05.2003
• Expected Payment = 800

The I_INVOICE_ADJUSTMENT table entry will have:

• Previous invoice = 123
• Adjustment Amount = -200
• Transfer Amount = 800

Below are the three associated entries in I_INVOICE_TRANS_V.

Loan Scheme Discounts and Student TO DO Records

Student TODO records are used to determine whether a $500 or 80% payment has been made against all of a student's HECS-HELP units with the same Census date.

Any discounts applied will have a HCSHLPLN-D record (Fee Assessment) with a transaction category of LOAN_DSCNT created.

Rules/Notes:

VET-TUIT fee types are processed in the same way as TUITION fee types.

Loan scheme discount calculations calculate the correct discount amount by considering the amount paid and invoiced in the context of the census date of the units being paid.

SA-HELP loans are not included in the discount process.

Apply Payments to New Invoices (if required)

The way in which payments are matched to invoices is discussed in detail in the Special Topic Applying Payments.

This process navigates the 'invoice stream' and is called immediately after loading details into I_INVOICE and I_INVOICE_TRANS. The invoice stream performs the tasks below before applying or re-applying payments as outlined in the Special Topics section.

The I_INVOICE_TRANS_V view of I_INVOICE and I_INVOICE_TRANS is used to access invoice data.

• It accesses those customer numbers in the above tables which have had invoices inserted or updated since the last time INTJ0021 was successfully run. The data is stored in the I_INT_CONTROL table.
• It checks for the last 'break point' at which existing relationships between invoices and payments are valid, and if valid, applies payments to new invoices.

Rules/Notes:

Prepare Customer Records (Prior to Invoice Creation): check box

This module resets I_FIN_CUSTOMER record set to ERROR from previous runs to READY.  This assumes that remedial action has taken place. 

Rules/Notes:

The new summary status column in I_INVOICE will be the key driver for the Invoice Summary status.

The column will be READY – ready to be summarised.

Any type of payment by a customer, whether refund required or payment owed, always keeps the customer ACTIVE.

Test for Student and Sponsor Activity (Only if preparing customer records): check box

Student TO DO records are created when certain changes are made affecting the database, especially the person payment schedule, (refer to Special Topics) or if a provisionally applied discount may need to be rescinded. Some payment processing also causes Student TODO records to be created to prompt invoice adjustments.

A TO DO record represents a single entry (installment of the debt due) in the person payment schedule. Since invoices are based on these schedule entries, the presence of a TODO record indicates that an adjustment may be necessary to an existing invoice for a student's fee liability, or that a new invoice is required because there is a new schedule entry.

This module accesses each new TODO record in turn. New TODO entries are identified by the absence of a 'logical delete' date. For each record, the process makes the following evaluations:

• It determines the customer(s) involved. A customer may be:
• The student to whom the fee debt relates,
• A sponsor who is totally liable for the debt incurred by the student, or
• Both student and sponsor as separately invoiced customers sharing the debt.
• For each liable customer, a check is made to decide if this is the first time this installment has been invoiced.
• If it is, the total amount (including tax, where applicable) is recorded as an adjustment entry in the I_INVOICE_ADJUSTMENT table.
• If the installment has already been invoiced, the process compares the current debt and the debt already invoiced. If different, the difference is recorded as an adjustment amount in the I_INVOICE_ADJUSTMENT table, representing an increase or decrease on the existing invoiced amount.

An invoice adjustment entry also carries information required when payments are received for the fee in question - notably payment ranking and account code information. The source of this information is data recorded against a fee, which is displayed in the Maintain Fee Types form, FINF2100. Once processed, the transfer status of an adjustment record is set to READY.

Rules/Notes:

The job INTJ0024 was previously called Match Receipts. Much of its former functionality is now defunct and the job has been renamed Finalise Processing.

The Finalise Processing job (INTJ0024):

• Takes the READY status I_INVOICE_PAYMENT records and changes them to SUCCESSFUL where the fee calendar liability has been finalised.
• Updates the associated I_PAYMENT and I_INVOICE_TRANS records and, if appropriate, marks them as being fully processed (processed_status of I_PAYMENT = FULL, fully_processed_ind in I_INVOICE_TRANS = Y).

Check for Earned Discounts where Due Dates have Elapsed check box

A choice can be made about whether to include this module in any specific run.

When initially creating an invoice, the assumption is that discounting conditions will be met for any fee that attracts a discount. Accordingly, invoices are created for an amount with discount already subtracted.

This module is run as preparation for a later check that, for those instalments in the Person Payment Schedule (PPS) that have now passed their Due Date, the discount is in fact 'earned'. To be earned, all debt, or a specified minimum amount or percentage, must be paid by the Due Date, as explained in documentation for FINF2860.

The exception is the HECS or HECS-HELP Contribution Amount, where discounts are not rescinded and the check does not apply.

Processing method:

The module operates with the date on which it starts processing as its initial reference point. From this date it subtracts one day to arrive at a control date. The entries of interest in the PPS are those (other than Student Contribution Amount) where the Payment Due Date falls between the actual date when the process was last run and the control date of the current run, inclusive of both dates. If a Due Date is within this span, a Student TO DO record is created. This is then processed by the next module in the same way as all other Student TO DO records.

If the module is run more than once on the same day, there is special provision in the module to ensure that the actual processing day is still not considered.

Rules/Notes:

Examples:

Previous run = 5 April
Current run starts on 8 April

• Student TO DO records are created for entries involving discounts in any person payment schedule where payment due dates fall on the 5^th, 6^th or 7^th April.

Module run twice on one day:
Previous run = 8 April
Current run starts on 8 April

• Student TO DO records are created for entries involving discounts in any person payment schedule with a payment due date of 7^th April. Entries may be picked up for a second time, but will prove not to need invoice adjustment when the TODO record is processed by the next module.