Purpose

To create COFI Invoices

INTJ0021 is normally run by itself. Optionally, modules of the job INTJ0020 can be run as the first processing task within the current job.

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.

Note: For unit based Person Payment Schedules associated with loan schemes that have system transaction types of HCSHLPLOAN or FEEHLPLOAN, the invoice due date is the census date of the unit. For all other invoices, the invoice due date is related to the Person Payment Schedule due date.

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 installments 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 installments of the fee, all installments 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:

Example 1 - New Invoice

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

After reassessment, this entry is deleted and a new PPS entry created, with these values:

Below are the three associated entries in I_INVOICE_TRANS_V.

Invoice Prefix and Number	Invoice Due Date	Transaction Amount	Comment
CIN 123 CCM 123 CIN 156	28.05.2003 28.05.2003 15.06.2003	1000 -1000 800	Original Credit Note Original

Example 2 - Replacement Invoice

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

This entry changes, and now has these values:

The I_INVOICE_ADJUSTMENT table entry will have:

Below are the three associated entries in I_INVOICE_TRANS_V.

Invoice Prefix and Number	Invoice Due Date	Transaction Amount	Comment
CIN 123 CCM 123 CIN 156	28.05.2003 28.05.2003 28.05.2003	1000 -1000 800	Original Credit Note Transfer from Inv. 123

Loan Scheme Discounts and Student TODO 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.

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.

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 TODO 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 TODO 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 which 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 installments 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 TODO record is created. This is then processed by the next module in the same way as all other Student TODO 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 TODO 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 TODO 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.