| Top of STA | Index | Table of Contents | Feedback | |
Statistics Subsystem Data Pre-Requisites
This document describes the HE and VET data that must be established, assumptions that must be met, and actions that must take place prior to using the Statistics Subsystem snapshot processes.
[Vet only] - To assist in the process of VET pre-requistes, the following sequence should be followed:
For details of the tables and fields, see Understanding HE Statistics and Understanding VET Statistics.
Note: After any of the Statistics jobs have been run, the Job Run Log should be checked. It will identify the reasons for a job failing, and missing and incorrect data.
| Title: | Description: |
| Advanced Standing | Configuration (ADVF1110), institution (ORGF0120) and HE Provider data (ORGF0115) must be set up correctly. |
| Articulated Courses |
Articulated courses (Undergraduate Courses from which students can continue directly into a related Undergraduate Honours Course or Masters Courses from which students can continue directly into a related Masters Honours Course) should be defined using the Articulated Course Rule (CRSF1700). |
| Attendance Types |
The load ranges applying to full-time and part-time Attendance Types must be specified (in CRSF1170). |
| Calendar Structure |
Calendars of type ACADEMIC, TEACHING must exist in (CALF0220). TEACHING must be related to the relevant ACADEMIC Calendar Instances (CALF0330). Student
Unit Attempts are included in the Enrolment Statistics Snapshot based
on their Unit of Study Census Date. For the defined Collection Year (1/1
to 31/12, not 1/9 to 31/8) the process will identify all Teaching Periods
with a Census Date within the Year and return all enrolments (excluding
SUA’s with a status of UNCONFIRM, INVALID or DUPLICATE) for the Teaching
Periods. LOAD 100% load for a unit is attributed to a unit at the Unit Of Study Census Date. Load is no longer split by Load Calendars and Default Load Apportionment. Load will continue to be split by Teaching Responsibility, Organisational Unit and Discipline. |
| CHESSN | CHESSN is used to manage the:
There is a requirement for all students who are:
to have a Commonwealth Higher Education Student Support Number (CHESSN). CHESSNs are maintained in ADMF32W0 - Maintain CHESSN Number and are required in Record Enrolments - ENRF3000 and Direct Admissions - ADMF3000. Other related CHESSN files are: |
| Course Categories |
Course Versions that are always Government reportable should exist in a user-defined Course Category called 'GOVT-RPT'. Course Versions that are never Government reportable should exist in a user-defined Course Category called 'GOVT-NORPT'. Types of Course Versions that should never be reported are ELICOS (English Language Intensive Courses for Overseas Students). Existence of a Course Version in either of the above user-defined Course Categories overrides any other System logic, except Unit Categories, to report/not report a Course Version. Course Categories are maintained in CRSF1130. |
| Course Field of Education |
Every combined course (e.g. double degree) should have a major and supplementary field of Education recorded for it (in CRSF1260). If no supplementary field of education is recorded for a combined course, the major field of Education is reported in the Government statistics against both the Field of Education Code (element 461) and the Field of Education Supplementary Code (element 462). |
| All combined courses (e.g. double degrees) should be included in a Course Group with a System Course Group Type of 'COMBINED'. Where
students are able to (or must) move between courses considered to be equivalent,
the equivalent courses must all belong to the same Course Group of System
Type EQUIV. The statistics Subsystem uses course equivalence in determining
whether or not a student is a commencing student. All courses which are 'related' for purposes of statistical reporting (including COMBINED courses) should belong to a Course Group of System Course Group type 'GOVT-RET' (Government Return). This is required for derivation of the commencing student check box. Course Groups are maintained in CRSF11D0. |
|
| Course of Study |
Different Course Versions which are essentially the same course are reported as being a particular course of study (DIISRTE element 394). Course of study must be recorded for these 'like' courses using the course reference code function. Create an institution defined Reference Code Type mapped to the System Reference Code Type CRSOFSTUDY, using CRSF11C0. It is recommended that the Reference Code Type also be called CRSFOFSTUDY. Add the course of study to 'like' Course Versions using CRSF1290, accessed via CRSF1210. It is recommended that the Course Code of one of the 'like' Course Versions be used as the course of study code. |
| Courses |
The Course Code reported to the Government is the Course Code concatenated with the Version Number of the course. For a course to be included in the Course file there needs to be a Course Offering Instance of the course within the submission year. |
| Data from prior submissions |
It is assumed that data from prior submissions is converted from Legacy Systems to Callista. Data for the GOVT_STUDENT_ENROLMENT is all that is required. Institutions may want to transfer data to other table (e.g. GOVT_STUDENT_LOAD_LIABILITY) in order to have a complete set of data in Callista. Data should be transferred from as far back in time as possible in order to make the statistics more accurate. The routine to determine whether a student is a commencing student or not requires this data. Also, specific files, such as the Past Course Completions file, require this data. |
| Government Snapshot Details |
The Government Snapshot Details will need to be set up before the Enrolment Statistics Snapshot is run (STAF1350). |
| Government Admissions Snapshot Control | The Government Admissions Snapshot Control (STAF1360) must be set up first before running the Govt Admissions Statistics Snapshot job (STAJ0500). (STAF1360 is used to configure the parameters and admission calendars that are used in the Govt Admissions Statistics Snapshot job.) |
| Government Values |
It is assumed that Government values reported to DIISRTE are set up according to the definitions in the DIISRTE manual. |
| Institution Address |
The institution address is reported to the Government in the Student Contribution Due file. An address of type 'GOVT-CNTCT' must be created for the institution so that DIISRTE address elements can be identified. On the Address Type table (ORGF0116) create an address type of 'GOVT-CNTCT'. The following components of the address type are mandatory -
Create an Institution Address of address type 'GOVT-CNTCT' (ORGF0122). On the Institution Address table the Contact Person will map to DIISRTE element 424 - Institution Contact Name. Ensure the institution address is effective as at the semester date of the Student Contribution Due File (DIISRTE element 421 - Semester Date). |
| Organisational Units |
Local Organisational Units are those belonging to the local institution. If the Govt Org Unit Code field in ORGF0141 contains a value then that value will be reported to the Government, however if there is nothing in this field then a value derived from the Org Unit Code is reported. ( If the Org Unit Code value is less than 4 characters in length then it is reported, however, if it is 4 characters or more in length then the 2nd, 3rd and 4th characters are reported. ) |
| Person Addresses |
Student address details (postal and permanent) are reported to the Government in the Student Contribution Due file. Two views have been created to be able to determine the student address details - PERSON_ADDR_GOVT_POST_V (Permanent Address) Columns are -
PERSON_ADDR_GOVT_PERM_V (Postal Address) Columns are -
These views are based on user-defined address types and they will need to be customised for each institution. (This will require assistance from your MIS/IT specialists.) For example, the student's permanent address is represented by the address types 'HOME' or 'OS-HOME' and the student's postal address is represented by the address types 'POSTAL' or 'OS-POSTAL'. The local address will be used in preference to an overseas address. Ensure addresses for student's are effective as at the semester date of the Student Contribution Due File (DIISRTE element 421 - Semester Date). |
| Research Units |
Research Units may or may not be set up with an Enrolled Credit Point value (CRSF2210). These units are put into the GOVT-RPT Category to ensure that they will be reported to Government. If a student undertakes a Research Unit in a research Teaching Period, the credit point value is not considered. If a Research Unit is undertaken in an 'ordinary' Teaching Period, the credit point value is considered and must be recorded for the unit. |
| Submission Census Dates |
A Census Date is no earlier than 20% of the way through each Unit of Study Teaching Period. If required, submissions for government reporting normally take place six weeks after the Census Date, or if required, following SLE/HELP Revisions File (STAJ1620). |
| TAC Applications | The 'Include TAC Applications in Admission Snapshot' checkbox (in Maintain Statistics Configuration (STAF1000) must be checked if the institution wishes to report TAC applications itself. All applications made directly by the institution or via a TAC will then be reported in the institution's Govt Admissions Statistics Snapshot (STAJ0500). |
| Teaching Calendar Census Date |
The user-defined Census Date Alias that will be used as the Census Date for each Teaching Calendar must be defined on the System General Calendar Configuration table (ENRF01F0). |
| Unit Categories |
Unit versions that are always Government reportable should exist in a user-defined Unit Category called 'GOVT-RPT' (unless EFTSL = 0). Unit versions that are never Government reportable should exist in a user-defined Unit Category called 'GOVT-NORPT'. Types of unit version that should never be reported are complementary units, continuing units. Existence of a unit version in either of the above user-defined Unit Categories overrides any other system logic to report/not report a unit version. Unit categories are maintained in CRSF2120. |
| Advanced Standing Sources | Advanced Standing that has a recognition type of CREDIT, a granting status of GRANTED, a source of RPL, CRDT-TRNS or EXMPT-CRDT, and has been granted during the Submission Year will be included in the Government Submission. Advanced Standing Sources should be mapped to a Provider Outcome Identifier using ADVF1140. |
| Scheduled Hours | Scheduled hours are reported to the Government in the Enrolment File (NAT00120). When calculating scheduled hours for Advanced Standing, institutions can either apply the AVETMISS formula, or ignore the AVETMISS formula and simply use the Supervised Hours recorded against the Unit Version. Institutions can customise this functionality. Refer to the stats_vet.doc documentation in the Techdoc directory. |
Outcome Identifier |
A government-defined Outcome Identifier that represents the value of Continuing Enrolment must exist. The government value is 70. The value must be open, must be marked as the system default and must be mapped to an institution-defined Provider Outcome. This value will be used for continuing Enrolments. Government-defined Outcome Identifiers can be defined in STAF112T. Institution-defined provider outcomes can be defined in ASSF01P0. |
Calendar Structure |
Calendars of Type ACADEMIC, TEACHING and LOAD must exist (CALF0220). Both Teaching and LOAD Calendar Instances must be related to the relevant ACADEMIC Calendar Instances (CALF0330). Teaching Calendars must be related to LOAD Calendar Instances, including a percentage value, via the Default Load Apportion structure (ENRF01K0). Note that it is Calendar Types that are linked to LOAD Calendars, not Calendar Instances. The following logic is used to determine the Teaching Periods to be considered for inclusion in the VET Enrolment Statistics Snapshot:
|
| Course Categories | An institution-defined Course/Unit Category of VET-RPT will force a Course/Unit to always be reported. An institution-defined Course/Unit category of VET-NORPT will force a Course/Unit to never be reported. Course/Unit Categories can be used to override the system logic for determining whether or not a Course/Unit is Government Reportable. These categories should only ever be used when an institution wants to always prevent a Course/Unit from being reported or to always force a Course/Unit to be reported. It is anticipated that the need to use these categories would be low, and that institutions should rely on the system logic to determine if a Course/Unit is Government Reportable. These categories should be used with caution, as they will override the system logic. Unit Categories will be checked before Course Categories. The exception to the check of Course/Unit Categories is to always ensure that the Government Outcome Identifier is specified, and to always ensure for an Advanced Standing Unit that it has a source of RPL, CRDT-TRNS or EXMPT-CRDT. Course Categories are maintained in CRSF1130. |
Courses |
If a Qualification Reference Code is recorded for a Course Version, then the Qualification Reference Code will be reported as the Course Identifier. However, if a Qualification Reference Code is not recorded for the Course Version, then the Course Code of the Course Version will be reported as the Course Identifier. If there is more than one version of a Course, then the details from the maximum version will be included in the VET Government Submission Snapshot tables. |
Enrolment Information - Vet sector only
Enrolment Activity Dates Information
Enrolment Activity Start and End Dates are data elements collected as part of the AVTEMISS national data collection in the Enrolment file (NAT00120). They provide information about the patterns of activity and participation within a collection year.
The Enrolment Activity Start Date is the date that training activity starts for a unit of competency or module enrolment. The Enrolment Activity End Date is the date that training activity ends for a unit of competency or module enrolment.
In Callista, a student unit of competency or module enrolment is represented as a student unit attempt. The Enrolment Activity Start and End Dates reported in the enrolment file are sourced from student unit attempt activity dates.
Student unit attempt activity dates may be manually recorded for individual unit attempts or they may be derived from higher levels. If activity end dates do not normally vary from student to student or unit to unit, they are typically derived.
A flexible structure of Enrolment Activity Start and End Dates has been created to enable the derivation of student unit attempt activity dates from a variety of levels, depending on the business practices of the institution. For example, if dates are normally common within a teaching period, then overarching institution-wide teaching period based dates can be defined. If dates vary from unit to unit, different dates can be specified at the unit offering, unit offering pattern or unit offering option levels.
The table below summaries the hierarchy of Enrolment Activity Start and End Dates. The levels are listed in order from highest to lowest.
| Teaching Period Start and End Dates | In the absence of dates, Date Aliases or Date Alias Instances specified at lower levels, Teaching Period Start and End Dates are used as the default Enrolment Activity Start and End Dates. If Enrolment Activity Start and End Dates typically equate to Teaching Period Start and End Dates, there is no need to override at lower levels unless required in individual cases (e.g. specific Unit Offering Options). Teaching Period Start and End Dates are defined using CALF0511 and CALF0512. |
| Enrolment Calendar Configuration Date Aliases | If the Enrolment Activity Start/End Dates in Teaching Periods are typically common across the institution, then the Enrolment Calendar configuration can be used to define the Date Alias for each. Activity Dates. Enrolment Calendar Configuration Date Aliases are defined using ENRF01F0. |
| Unit Offering Date Aliases | If the Enrolment Activity Start/End Date for particular offerings of a unit differs from the standard institution-wide date/s, then they can be overridden at the Unit Offering level. Unit Offering Date Aliases are defined using CRSF2310. |
| Unit Offering Pattern Date Alias Instances | If the Enrolment Activity Start/End Date for particular Offering Patterns of a unit differs from the standard institution-wide date/s or the standard Unit Offering Date Alias, then they can be overridden at the Unit Offering Pattern level. Unit Offering Date Aliases are defined using CRSF2310. |
| Unit Offering Option Date Alias Instances | If the Enrolment Activity Start/End Date for particular offering options of a unit differs from the standard institution-wide date/s or the standard Unit Offering Date Alias or the standard Unit Offering Pattern Date/s, then they can be overridden at the Unit Option level. Unit Offering Option Date Aliases are defined using CRSF2500. |
| Student Unit Attempt Dates | If the Enrolment Activity Start/End Date for student unit attempts differs from the standard institution-wide date/s or the standard unit offering date alias or the standard unit offering pattern date/s or the standard unit offering option date/s, then they can be overridden at the Student Unit Attempt level. Student Unit Attempt Date Aliases are defined using ENRF3000. |
| Participation Rule | An institution will be given the opportunity to develop their own Participation Rule, which will be used by the government reporting process to ascertain whether or not a student has undertaken active participation in their Unit Attempts. The Participation Rule exists in the Rule Group ENROLMENTand the Rule Sub-Group SYS-WIDE. The rule description is System Wide Participation Rule. Use RULF2001 to locate the Participation Rule, and RULF2000 to define the Participation Rule. The following points describe the functionality associated with the participation rule, as it pertains to the Callista Statistics processes:
This means that if future dated Proof Of Participation records or Student Unit Attempt Assessment Item Outcomes exist for the student, then they will not be recognised when running STAJ8000. However, they will be recognised when running STAJ8005 (assuming they are on or prior to the 31st December of the Submission Year). |
Organisational Unit Information
| Training Organisation Address | The Training Organisation Address is reported to the Government in NAT00010. An address of Type 'VET-GOVT' must be created for the Training Organisation so that AVETMISS address elements can be identified. On the Address Type table (ORGF0116) create an address Type of 'VET-GOVT'. The following components of the address Type are mandatory: The first section covers National requirements:
The second section covers State requirements:
Create a Training Organisation Address of Address Type 'VET-GOVT' (ORGF0142). See the stats_vet.doc documentation in the Techdoc directory for latest information to assist in further insights into Statistics Subsytem Date Pre-requisites. |
| Govt Training Country Code | The Govt Training Country Code can only be defined when the Location Type maps to a System Location Type of ‘CAMPUS’ The Govt Training Country Code must not be 1100, 1101, 1102, 1199 if the location address has a current overseas postcodeThe Govt Training Country Code must be 1100, 1101, 1102, 1199 if the location address has a current Australian postcodeThe Country Code must not be closed. The Govt Training Country Code must not be ‘0000’ or ‘@@@@’ if the user tries to define the value manually. See ORGF0131 - Maintain Locations for further information. |
Training Organisation Delivery Location Address |
The Training Organisation Delivery Location Address is reported to the Government in NAT00020. An address of Type 'VET-GOVT' must be created for the Training Organisation Delivery Location so that AVETMISS address elements can be identified. On the Address Type table (ORGF0116) create an Address Type of 'VET-GOVT'. The following components of the address Type are mandatory:
Create a Training Organisation Delivery Location Address of Address Type 'VET-GOVT' (ORGF0132). See the stats_vet.doc documentation in the Techdoc directory for latest information to assist in further insights into Statistics Subsytem Date Pre-requisites. |
State Specific Data Information
| State Specific Data | Callista allows State Specific Data to be appended to each AVETMISS file. The data is appended to the end of each line in the file. This is achieved using a number of customisable PL/SQL routines, which are called by STAJ8800. The Source Code for these routines is provided – refer to the Callista Oracle Database Installation Guide. |
| Data from Prior Submissions | It is recommended that new VET clients convert data from their legacy system to Callista for the VET Government Snapshot Qualification table. This is because the process that populates the VET Government Snapshot Qualification table needs to look at data on this table from prior Submissions to determine whether or not a Student Course Attempt should be reported in the current Submission. |
| Government Submission Snapshot Details | The VET Government Submission Snapshot Details need to be set up before the VET Enrolment Statistics Snapshot can be run (STAF8005 - Maintain VET Government Submission Snapshot Control). |
| Government Values | It is assumed that Government values reported to AVETMISS are set up according to the definitions in the AVETMISS manual. |
| Statistics VET Technical Document | See the stats_vet.doc documentation in the Techdoc directory for latest information to assist in further insights into Statistics Subsytem Date Pre-requisites. |
| Delivery Type | A government-defined Delivery Type that represents the value of Not Applicable must exist. The government value is 09. The value must be open and must be mapped to an institution-defined Delivery Type. This value will be used for Advanced Standing Units. Government-defined Delivery Types can be defined in STAF112O. Institution-defined delivery types can be defined in CRSF11L0. |
| Unit Categories | Unit Versions that are always Government Reportable should exist in a user-defined Unit Category called 'VET-RPT'. Unit Versions that are never Government Reportable should exist in a user-defined Unit Category called 'VET-NORPT'. Unit Categories of VET-RPT and VET-NORPT should only be used when an institution wishes to override the system logic for determining whether or not a Unit is Government Reportable. See Course Categories above for further information. Unit categories are maintained in CRSF2120. |
| Units | If a Unit Of Competency Reference Code is recorded for a Unit Version, then the Unit Of Competency Reference Code will be reported as the Module Identifier. However, if a Unit Of Competency Reference Code is not recorded for the Unit Version, then the Unit Code of the Unit Version will be reported as the Module Identifier. If there is more than one version of a Unit, then the details from the maximum version will be included in the VET Government Submission Snapshot tables. |
Last Modified on 10 January, 2005
History Information
| Release Version | Project | Change to Document |
| 13.1 | 1323 - Online Help Consolidation | Updated all VET links |
| 12.1 | 1636 Callista Wiki | Merged VET page content into this Help page. |
| 11.0.0.3, 11.1.0.0.3, 12.0.0.2 | 1573 - Uni Applications and Offer Data Collection | Added TAC Applications row and Govt Admissions Snapshot Control row. |
| 11.1.0.0.0.0 | 1505 - Compliance (E566 - Derivation) | Added Advanced Standing information and changed DEST to DIISRTE. |