| Top of STA | Index | Table of Contents | Feedback | |
Understanding Revisions
This page provides an overview of the Revisions process in the Statistics subsystem and its use for the production of revisions submissions.
This is a highly specialised part of Callista, intended for use by statistics specialists only. It is expected that the statistics specialist will have knowledge of the reporting requirements outlined in the Scope document(s) for the Revisions (RF) File.
Topics covered in this page include:
The Revisions file reports details of additions, deletions or changes due to administrative error and remissions. Revisions are reported for a unit(s) of study that has a unit of study census date on or after 1 January 2005. Details of revisions to units of study with a census date prior to 1 January 2005 cannot be reported on the Revisions file and are to be reported to Government and the ATO as per pre 2005 instructions.
Records in the Revisions file must either relate to a record previously submitted to the Government in a Student Load Liability file or be additional records for a previously reported Person ID, Course Code + Course Version Number and Unit of Study Census Date, or relate to a record previously submitted to the Government in an OS-HELP file. If the value for the concatenated key Person ID, Course Code + Course Version Number and Unit of Study Census Date has not been previously reported to the Government in a Student Load Liability file, and as such is not present in the GOVT_STUDENT_LOAD_LIABILITY table, then the Government regards this record as a new previously unreported record to be included in the next submission of the Load Liability file.
The Revisions process differs from the Submission process in so far as it creates its own Revisions snapshot based on the data in Callista and that which has been previously reported in the GOVT_STUDENT_LOAD_LIABILITY and GOVT_EXTRNL_STUDY_LOAN_SNPSHT tables. Once the Revision snapshot has been compiled an Enrolment Statistics Snapshot is usually required to compile details for the Revised Load Liability, Revised HELP Due, and Revised OS-HELP files.
The VET FEE_HELP Revisions Process
VET FEE-HELP Revisions processing is run after a standard VET FEE-HELP Snapshot submission is completed to check that everything in the system has been reported correctly. For more information see the VET FEE-HELP Revision Submission Snapshot (STAJ8055). This job records identified changes and remissions in a Revisions file (VSR) that is sent to Government.
The STAJ8055 job uses a similar process to HE Revisions but differs in that it uses the same three tables that the VET FEE-HELP Submission Snapshot job (STAJ8050) uses (i.e. GOVT_SNAPSHOT_VET_PE, GOVT_SNAPSHOT_VET_SCA and GOVT_SNAPSHOT_VET_SUA) to store the revised data. The original data remains unchanged and the revised data is stored with a different snapshot type (VS_REV) in the same tables. This Revisions file is sent to the Government, as required, although usually it is submitted with the next VET FEE-HELP submission files.
The job STAJ1610 can be used to create revisions data for all types of submissions except for scholarship submissions, VET FEE-HELP submissions (which uses STAJ8055) and Past Course Completions. The job STAJ1610 was designed with maximum flexibility in mind. It was envisaged that some institutions may wish to compile revision data for a whole year, a particular submission number, or even down to the course code, unit code or person ID group level. The important issue here is that relating to the reporting of remissions, a special revision type with its own variation reason code. The Revisions (RF) File Scope defines a remission as:
A practice whereby a student's FEE-HELP or HECS-HELP debt is removed because of special circumstances (see section 64 of the Administrative information for providers). What constitutes 'special circumstances' for the purposes of remission is detailed in the Act (see section 65.4 of the Administrative Information for Providers).
The designed flexibility within STAJ1610 was also to cater for processing of remissions and is discussed further below in relation to Input Parameters and Remissions. It should be noted that remissions can be processed at any stage while revisions are being compiled by STAJ1610, first, last or in the middle if so desired. Precise information about the data included in the Government Snapshot is contained in How the Revision Statistics Process Works.
Input Parameters
There are two tabs of input parameters that can be used to delimit the data that STAJ1610 looks at when identifying revision records. The first tab includes the Revision Submission Year and Number, and the original Submission Year, Number, and System Submission Type. The Revision Submission Year and Number and the original Submission Year are required as minimum input parameters. These input parameters are configured in Government Snapshot Control (STAF1350). Only an original Submission Year and associated Number, and System Submission Type that has the completion date set in Government Snapshot Control (STAF1350) can be selected for comparison.
The second tab contains optional input parameters and includes Person ID, Person ID Group, Unit Code, Administrative Unit Status, and Course Code. This tab also includes the Authorising Officer, the Person ID of which is included in the GOVT_STUDENT_REVISION table, and the Determine Revision Reason Code Pop List. As STAJ1610 can not tell the difference between a deletion and a remission, these optional input parameters are intended to be used when the Determine Revision Reason Code Pop List is set to Assign Remission in order to assign the variation reason code of 1 to records that were remissions. (See Determine Revision Reason Code below for details on the actions that these Pop List options perform). It should be noted that these optional parameters can be used at anytime to delimit that data that STAJ1610 looks at in identifying revisions. This can be particularly useful if specialists wish to confirm a subset of data during or prior to revisions processing.
The Revisions Processing is Split into Three Sections
The first two sections deal with revisions to previously reported Load Liability file data, and the third and last section address revisions to previously reported OS-HELP file data.
The First Section
The first part derives current data and compares it to reported data to identify information that has not yet been reported or is an addition (Variation Reason Code of 5) to what has been reported.
If a combination of Person ID, Course Code + Course Version Number and Unit of Study Census Date has not been previously reported in the GOVT_STUDENT_LOAD_LIABILITY table then this is a new previously unreported record.
If a combination of Person ID, Course Code + Course Version Number and Unit of Study Census Date has been previously reported in the GOVT_STUDENT_LOAD_LIABILITY table but there is no match for the current Unit Code and/or Teaching Responsibility, then this is an addition (Variation Reason Code of 5).
Government requirements stipulate that records in the Revisions file must either relate to a record previously submitted to the Government in a Student Load Liability file or be additional records for a previously reported Person ID, Course Code + Course Version Number and Unit of Study Census Date. If the value for the concatenated key Person ID, Course Code + Course Version Number and Unit of Study Census Date has not been previously reported to the Government in a Student Load Liability file, and as such is not present in the GOVT_STUDENT_LOAD_LIABILITY table, then the Government regards this record as a new previously unreported record to be included in the next submission of the Load Liability file. If the value for the concatenated key Person ID, Course Code + Course Version Number and Unit of Study Census Date HAS been previously reported to Government in a Student Load Liability file, and as such IS present in the GOVT_STUDENT_LOAD_LIABILITY table, but values for Unit Code and/or Teaching Responsibility have not been previously reported then the Government regards this record as an additional record to be included as part of the Revisions submission.
STEP ONE
First unreported records are identified by comparing current data to that in the GSLL and GSLR.
STEP TWO
It then validates this current data ensuring that valid values are present and/or that there is no missing data. If a validation fails or data is not present a message is written to the Exception Report.
EITHER STEP THREE
At this point STAJ1610 performs one of two actions:
If there is an existing GSLR record, it checks if any of the values in this record have changed. If there has been a change, the existing record in the GSLR is deleted and a new one is inserted. If there is no change, STAJ1610 continues on to the next record.
OR STEP FOUR
STAJ1610 now checks if the student/course/unit census date has been previously reported. If ‘YES’, then it inserts a record in the GSLR, with the New Record check set to ‘N’ and a GSTR (Variation Reason = 5). If ‘NO’, then it inserts a record into the GSLR with the New Record Indicator set to ‘Y’.
The Second Section
The second part of the processing starts with the reported information and then derives current data to see if the reported data is still current or has changed.
If there is no match to current data for a previously reported combination of Person ID, Course Code + Course Version Number, Unit Code, Unit of Study Census Date and Teaching Responsibilities then this is a deletion (Variation Reason Code of 4).
If there is a match for a previously reported combination of Person ID, Course Code + Course Version Number, Unit Code, Unit of Study Census Date and Teaching Responsibilities but there has been a change in the value for Citizen/ Resident Indicator, Permanent Residency, EFTSL, Amount paid up front, Total amount charged, Loan Fee, Student status code, Discipline code, Maximum student contribution indicator, Work experience in industry indicator or Summer School indicator then this is an administrative error (Variation Reason Code of 2). If nothing has changed then there will be no revision.
STEP ONE
STAJ1610 retrieves the most recent information from the GSLL, checked for any more recent records in the GSTR and GSLR (if they exist) and compares these records to current data.
EITHER STEP TWO
If there is no current data, then a check is made to see if there is an existing GSTR record with a Variation Reason = 4. If ‘YES’; it continues on to the next record. If ‘NO’, then it inserts a GSTR record with a Variation Reason = 4 or 1 depending on the Determine Variation Reason Code parameter. (See Remissions and Determine Revision Reason Code below for further details.)
OR - STEP THREE
If there is current data then it is validated against records in the GSTR and GSLR.
STEP FOUR
A check is made to see if the reported values are the same as the current data. If there are any records that have the same values as the current data then; if what was reported in the GSLL is the same as the current data, any existing GSTR and/or GSLR are deleted and STAJ1610 continues on to the next record.
If what was reported in the GSLL is different to the current data and there is a GSTR and GSLR and they match current values, then continue on to the new record. Otherwise, there is a change between current data and that record in the GSTR and GSLR, delete any existing GSTR and GSLR records and insert a new record with a Variation Reason = 2 and the old and new values.
The Third Section
If all Submission Types have been included as an input parameter, the third part of processing derives revisions to OS-HELP details.
STEP ONE
STAJ1610 compiles current external study loan data and compares this to reported OS-HELP data to identify information that has not yet been reported.
STEP TWO
If previously unreported records are found, then a record is inserted in the GESLR with the New Record Indicator set to ‘Y’.
STEP THREE
STAJ1610 then gets the most recently reported information from the GESLS and any current data (if it exists).
EITHER – STEP FOUR
If there is no current data, then it checks if there is an existing GELSR record. If ‘YES’, it updates the GESLR record. If ‘NO’ then it insets a new GESLR record (Variation Reason = 4).
OR – STEP FIVE
If there is current data and the values in the GESLS match the current values, then STAJ1610 checks if there is an existing GESLR record and if there is one it is deleted as no revision needs to be reported. If there is a difference, then it will check to see if there is a GESLR. If not, it will insert a GESLR record. If there is, it will update the values in the GESLR record.
Once processing has completed the Run Log should be consulted. If there were no problems during processing, an entry similar to the following will be displayed:
Start processing - derive revisions (new records and additions), 06/10/200615:20:50
Completed processing - derive revisions (new records and additions), 06/10/200615:21:17
Start deleting revision entries no longer required 06/10/2006 15:21:17
Completed deleting revision entries no longer required 06/10/2006 15:21:19
Start processing - derive revisions (changes and deletions), 06/10/200615:21:19
Completed processing - derive revisions (changes and deletions), 06/10/200615:21:26
Start deleting OS-HELP revision entries no longer required, 06/10/2006 15:21:26
Completed deleting OS-HELP revision entries no longer required, 06/10/2006 15:21:26
Start processing - derive OS-HELP revisions (new records), 06/10/200615:21:26
Completed processing - derive OS-HELP revisions (new records), 06/10/200615:21:26
Start processing - derive OS-HELP revisions (changes and deletions), 06/10/200615:21:26
Completed processing - derive OS-HELP revisions (changes and deletions), 06/10/200615:21:26
The Exception Report should also be run to identify any errors or problems during processing. This report will identify missing or invalid data.
Remissions would otherwise be reported as a deletion (4), however, a special administrative unit status or other input parameter allows the processing to distinguish which students received a remission. Remissions are processed separately as the parameters do not allow the job to do both revisions and remissions processing in the same run.
When remissions are being assigned, the Determine Variation Reason Code option should be ‘Assign Remission’ and either an Administrative Unit Status or a combination of Unit Code and Person ID or Person ID Group must be entered as Optional Parameters.
Determine Revision Reason Code
If the Determine Revision Reason Code option is set to ‘Derive Revisions’ then STAJ1610 will derive the variation reason code for new and existing records and in the case of existing records will update the variation reason code to the derived value for ALL records EXCEPT those with an existing Remission assigned (a variation reason code of 1).
If the Determine Revision Reason Code option is set to ‘Assign Remission’ then STAJ1610 will check to ensure that the new total amount charged, new amount paid upfront, new loan fee and new unit of study HELP debt is zero for the records that are to have a remission assigned to them. If they are zero, then the variation reason code will be set to 1 for these records in the GOVT_STUDENT_REVISION table. If the amounts are not zero, then STAJ1610 will log an exception but will still update the selected records based on the Optional Parameters in the GOVT_STUDENT_REVISION table with the variation reason code of 1.
If the Determine Revision Reason Code option is set to ‘Override Remission’ then the same process as that described for ‘Derive Revision’ will be followed except that existing remission records where the variation reason code is set to 1 in GOVT_STUDENT_REVISION are also updated with the derived variation reason code value.
Processing Outcomes
Previously unreported data (included in next submission) will have an entry in the GOVT_STDNT_LIABILITY_REVISION table and a value of ‘Y’ set in the LOAD_LBLTY_NEW_REC_IND column. If the previously unreported record relates to OS-HELP there will be an entry in the GOVT_EXT_STUDY_LOAN_REVISION table and a value of ‘Y’ set in the GOVT_EXT_STDY_LOAN_NEW_REC.
Remissions and deletions (1 & 4) will have an entry in the GOVT_STUDENT_REVISION table. If the deletion relates to OS-HELP data, there will be an entry in the GOVT_EXT_STUDY_LOAN_REVISION table.
Changes and additions (2 & 5) will have an entry in the GOVT_STUDENT_REVISION and GOVT_STDNT_LIABILITY_REVISION tables. Changes or additions to OS-HELP data will have an entry in the GOVT_EXT_STUDY_LOAN_REVISION table.
Data that fail validations for required information will be reported in the exception report and in most circumstances will not have any revisions created until the error is resolved.
Revisions processing can include many submissions. The parameters limit the processing of a single job to within a year however many jobs can be scheduled in order to collate the require revisions.
If revisions were required for 2005 and 2006 then you would need to schedule at least two jobs.
Government Revisions Submission Report
The Government Revision Submission Report (STAR1630) contains information about the Revision records identified and can be ordered by Person ID, Course Code and Unit Code. It also contains details of the number of expected Revised Load Liability and OS-HELP records as well as details regarding previously unreported records. In each case it also identifies what year the Create Enrolment Statistics Snapshot (STAJ0100) needs to be run in order to ensure that current data is available to compile Revised Load Liability file and for the capture of previously unreported records.
When this report should be run, is discussed below under Suggested Revisions Processing Order.
Creating the Revisions Extract Files
Once the revisions data has been identified for submission (STAJ1610) then an Enrolment Statistics Snapshot (STAJ0100) needs to be run to ensure that the current information that the revision process has been based on is available to Government Submission Snapshot (STAJ0110).The 'current' information created in the ENR_STATISTICS_SNAPSHOT table created by the Enrolment Statistics Snapshot is required so that the Government Submission Snapshot (STAJ0110) can match the revisions information from the GOVT_STDNT_LIABILITY_REVISION table to the new enrolment information. The Government Submission Snapshot job then compiles the 'current' details for the revision records in the GOVT_STDNT_LIABILITY_REVISION table and creates entries in GOVT_STUDENT_LOAD_LIABLITY table with a system submission type of REVISION, for the submission of the Revised Load Liability file.
Once the Government Submission Snapshot job has been run for the system submission type of REVISION then the Create Student Load/Liability File (STAJ0140) and the Create HELP Due File (STAJ0050) jobs are ready to be run. These jobs also need to be run with the system submission type of REVISION in order to create the Revised Load Liability (RL) and Revised HELP Due (RD) files. STAJ0140 and STAJ0050 select from the GOVT_STUDENT_LOAD_LIABLITY table using the system submission type of REVISION to create these files.
Create Revisions File (STAJ1620) can be run at any time after Create Government Revision Submission Snapshot (STAJ1610) has been run and Remissions assigned. It selects from the GOVT_STUDENT_REVISION table to create the Revision (RF) file.
| Job Name | Description | Details |
STAJ1620 |
Create Revisions File | Details |
| STAJ0050 | Create (Revised) HELP Due File | Details |
| STAJ0140 | Create (Revised) Student Load/Liability File | Details |
| STAJ0160 | Create (Revised) OS-HELP File | Details |
Finalising the Revision Submission
The final step in the Revision Submission process is finalising the Revisions Submission. This is done by setting the Completion Date for the Revisions Submission in the Government Snapshot Control Form (STAF1350). A logical date to use would be the date the Revisions submission was forwarded to the Government.
If the Completion Date is not set against the Revisions Submission, data from this Revisions Submission will not be included in subsequent Revisions Submissions.
Suggested Revisions Processing Order
The following sequence of steps is suggested for Revisions processing:
Last Modified on 21st November, 2006
History Information
| Release Version | Project | Changes to Document |
| 20.0.0.1 | 2262 - Compliance | Removed reference to SLE for STAJ1620. |
| 13.0.0.2 | 1323 - Online Help Consolidation | Added information about VET FEE-HELP Revisions. |
| 12.0.0.3 | 1646 - Skills VIC FEE-HELP Reporting | Added link to -VET FEE-HELP Revisions. |
| 12.0 | 1628 - Release 12.0 Preparation | Added first point in Suggested Revisions Processing Order |
| 11.1 | 1505 - Compliance 2008 | Added 'and Past Course Completions' to Revisions Submission Snapshots section. |
| 9.1.0.0.0.0 | 1230 - Compliance 2007 | New Introduction (split STAINTR3 into two files) |