This job creates invoice data for notified fee debts of students, sponsors and loan schemes. It also matches any processed unapplied payments to new or existing invoices after new invoices have been processed.

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

Lamps on the parameter form are used 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.

The context for this job is described in the COFI Overview help page 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:
For details about how this job handles errors and reports on its progress, see COFI Error Handling.

INTJ0021 or INTJ3021?
Note: If your institution uses the COFI Designated Payment Model (DESG_PAYMENT_MODEL_IND is set to Y in the I_INT_CONTROL table) then INTJ0021 will not be available. In that case you should look at the help for INTJ3021, which takes its place in your system. For more information contact your System Administrator.

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:

Prepare Customer Records check box
If this check box is selected, then parts of INTJ0020 are run as the first processing task in the job. Be aware of the extra time that will be required to run the process when such check boxes are selected.

Test for Student and Sponsor Activity check box
If this check box is selected, then each new TODO record, the process determines the students or sponsors involved. and for each one, a check is made to decide if this is the first time this instalment 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 instalment 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.
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, and 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.
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.

The date on which it starts processing is used 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. For example:

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.

Creating 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.
• The Payment Due Date defined in the Person Payment Schedule (PPS) is taken as the Due Date for invoice creation.
• 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.

Adjusting Invoices

A). New Invoice
This is necessary when, for instance, a new entry in the Person Payment Schedule (PPS) is created when the assessed amount due for a particular fee has increased requiring a new PPS instalment (with a different due date) to be created by the system. Or it may be that the amount due has been spread across more instalments by a manual adjustment in the PPS form.

Example

• Payment Due Date = 28.05.2115
• Expected Payment = 1000

• Payment Due Date = 15.06.2003
• Expected Payment = 800

B) The reversal of an existing invoice with a credit memo.
This is necessary when, for instance, the debt for an instalment 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 instalment is reduced), or
• Only creation of a credit memo where a customer is no longer liable for a particular fee instalment. 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 example below.

To distinguish invoices from credit memos,different prefixes are used, i.e. CIN for an invoice and 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.

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.

• 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

Changes to invoices

When a student has a change in their fee liabilities, INTJ0021 may reallocate existing payments according to payment rankings. Such allocations will follow the same guidelines as described in INTJ0022.

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.

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.