99/02 - November
Dear Colleagues
The 1999/00 (Dec) HESA Student Record Collection (Ref C99011A)
This Circular sets out the plans for the C99011A
data collection.
Timescales for Collection
The critical dates in the collection are as follows:
| Return date | Institutions are required to send complete and valid data to HESA no later than Saturday 15 January 2000. |
| COMMIT target date | Institutions are encouraged to attempt a COMMIT transaction no later than Monday 24 January 2000 (institutions are reminded that more validation is performed on a COMMIT request and that the return can be rejected as invalid at this stage). A successful COMMIT will trigger the generation of check documentation. |
| Last submission of data files | In order to meet obligations for hand-over of data to customers, HESA has to have all data files by Monday 6 March 2000. |
| Database closure | In order to meet obligations for hand-over of data to customers, HESA has to stop processing student returns on Friday 10 March 2000. |
Student Record Validation
As with previous recent data collections, two stages of validation
take place; 'Submission level' validation and 'COMMIT-stage' validation.
Validation kits for the submission level validation rules are
available from the Validation section of the HESA WWW server (http://www.hesa.ac.uk/valid/1999/00html.htm).
These kits contain all of the validation checks that are run when
files are submitted to HESA.
COMMIT-stage validation checks are only run once
a COMMIT request has been received by the data collection system.
These checks can only operate within a database-type environment
and, therefore, cannot be included in the submission level validation
kits. Institutions are reminded that any return that fails
COMMIT-stage validation will require a resubmission to be made.
Institutions are therefore advised to attempt to COMMIT their
data as soon as they have sent the entire return in and have received
the appropriate frequency counts and status report.
COMMIT-stage validation checks in the C99011A
collection
| Check | Severity | |
| If multiple occurrences of INSTID, HUSID and NUMHUS appear then fail | Error | |
| Incorrect INSTID in data | Error | |
| If 2 records have the same HUSID then the Date of Birth and Gender must be consistent | Error | |
| If (RECID=YY011 and If FESTUMK = 1 or 3 and GLHRS = 0 or blank) | Error | |
| If FE student (QUALAIM codes 53-55, 71-83, 99), qualification obtained cannot be at PG or UG level (QUAL1 or QUAL2 codes less than or equal to 52) | Error | |
| If multiple occurrences of INSTID, HUSID and QUALAIM appear in cases where QUALAIM in (02 - 52) and MODE in (01, 23, 24, 52, 53) and DATELEFT is blank then fail (Type 1) | Error | |
| If multiple occurrences of INSTID, HUSID and QUALAIM appear in cases where QUALAIM in (61, 62, 97, 98) and MODE in (01, 23, 24, 52, 53) and DATELEFT is blank then warn (Type 2) | Warn | |
| If multiple occurrences of INSTID, HUSID and QUALAIM appear in cases where QUALAIM in (02 - 52, 61, 62, 97, 98) and MODE not in (01, 23, 24, 52, 53) and DATELEFT is blank then warn (Type 3) | Warn | |
| If multiple occurrences of INSTID, HUSID and QUALAIM appear in cases where QUALAIM not in (02 - 52, 61, 62, 97, 98) and DATELEFT is blank then warn (Type 4) | Warn | |
| If multiple occurrences
of INSTID, HUSID and QUALAIM appear in cases where QUALAIM in (02 - 52,
61, 62, 97, 98) and DATELEFT is blank then warn (Type 5) [See technical spec below] |
Warn |
The Decision tree for the Type 1, Type 2, Type 3 and Type 4 commit stage validation rules is :
Start : Duplicate INSTID, HUSID, QUALAIM, DATELEFT where DATELEFT is blank.
QUALAIM 02 - 52 MODE 01, 23, 24, 52, 53 result = Type 1 Otherwise result = Type 3 61, 62, 97, 98 MODE 01, 23, 24, 52, 53 result = Type 2 Otherwise result = Type 3 Otherwise result = Type 4When reporting back the duplicates, code in another report that slots in before the duplicate 4 report that identifies and reports the occurrence of a single type 1 and single type 3 error record for the same student (type 5).
COMMIT checks continued:
| If multiple occurrences of BIRTHDTE, GENDER, soundex(SURNAME), soundex (FNAMES) and different HUSIDs and RECID is not YY21x, YY31x, YY41x then | Warn | |
| Age as at 1 August 1998 is less than 16, and not '##' | Warn | |
| Report as warning any records where XDOMCT01 not in (2826, 3826, 4826, 5826, 6826, 7826, 8826, GREU) and FUNDCODE=1 | Warn | |
| If (RECID=YY011 and If FESTUMK = 4 and GLHRS = 0 or blank) | Warn | |
| If FESTUMK = 1, 3 or 4 and FEQAIM not in (FE Qualaim DBF) | Warn |
Check Documentation
Once a return has successfully passed the COMMIT stage, check
documentation will be automatically printed and despatched. HESA
will begin scrutiny of the return at this point and may wish to
raise quality issues with the Student Record contact.
A copy of the check documentation template, along with the definitions
used in the analyses can be found on the HESA WWW site at (http://www.hesa.ac.uk/datacoll/check.htm)
shortly.
Responses from the Data Collection System
Institutions are reminded that all submission level
transactions (CREATE, REPLACE, APPEND, COMMIT) generate responses
to the email address quoted in the relevant control file. All
return level transactions (DE-COMMIT, data checking and sign-off)
generate responses to the email address of the record contact
as held on the HESA contacts database.
Who to Contact During Data Collection
Institutions should consider Institutional Liaison
as a general first point of contact for any HESA issue.
The liaison team cover the following specific areas as well as being a first point of contact for any HESA issue, e.g.
|
Alison Berry (alison.berry@hesa.ac.uk)
Overall responsibility for data collection operations
Helen Skitt (helen.skitt@hesa.ac.uk)
General mailbox: liaison@hesa.ac.uk |
Further Guidance on Submitting Data to HESA
The HESA WWW site contains guidance on submitting data to HESA. This covers file naming, file structures, FTP transmission and an overview of the data collection process. This document can be found in the Data Collection section of the HESA web site (http://www.hesa.ac.uk/datacoll/home.htm).
Further Guidance on the Student Record 1999/00
Field 15 Disability Allowance
Field 16 Disabled
The guidance for completing these fields for a student
receiving Disabled Student Allowance (DSA), but who has not advised
the institution of the nature of the disability is that Field
15 Disability Allowance should be coded 4 'The student has a disability
and is in receipt of Student Disability Allowance' and Field 16
Disabled should be coded as 09 'A disability not listed above'.
Field 68 Major Source of Tuition Fees
For the academic/financial year 1999/00, the Student
Loans Company will be paying
the public contribution of fees for those students who had their
assessments for eligibility and financial support towards their
fees carried out by English and Welsh LEAs, DENI or in the case
of EU students in England and Wales, by the DFEE.
For the purposes of coding Field 68 Major source
of tuition fees, students for whom a public contribution to fees
has been assessed as payable should be coded according to which
body carried out the assessment. English and Welsh LEAs should
be coded 02, DENI should be 04 and EU students in England and
Wales assessed via
DFEE should be coded 33.
The Student Loans Company will be sending to institutions
Fee Notification Reports which notify the public contribution
towards student tuition fees which has been assessed. The first
four characters of the student support number which appears in
these schedules will allow the assessing body to be identified.
Students who have been assessed by DENI will
have one of the following codes: NBFT, NEST, NSET, NSTH, NWES,
NDAN. EU students in England and Wales will have the code EURS.
All other students on the SLC schedules will have been assessed
by English or Welsh LEAs.
Tuition fees for Scottish domiciled students [and
EU students in Scotland] will
still be distributed by SAAS and so will not appear on the SLC
schedules. These should be coded 03 in Field 68.
Institutions are reminded of the general guidance
for completing Field 68 'that
code 01 should include students who have
applied to an LEA, DENI or SAAS and been refused
any support and have to pay the complete £1025, as well as
those students who decide not to be assessed by the LEA and pay
the complete £1025 themselves i.e. code 01 should only
be used where the student pays all the fees themselves and there
is noelement
of support. Codes 02 - 97 should be used
where somebody other than
the student pays the total or a proportion of the tuition
fees i.e. where there is some element of support, however small.
Analysis of the December 1998 Student Record showed that some
institutions were using code 02 'English or Welsh LEA award (Student
Award Agency)' for their home domiciled full-time undergraduate
students in much higher proportions than expected.
Field 159 Vocational qualifications at Level 3/Advanced
Code 97 'Combination of 1 or more of above' should
be used for students who hold NVQ/SVQ (Level 3) or GNVQ/GSVQ but
were the amount of modules is not known/not elsewhere specified.
Code 98 'None of the above' should be used for students who do
not hold NVQ/SVQ (Level 3) or GNVQ/GSVQ.
ERAMUS Exchange Out Students
The guidance for ERASMUS Exchange students, out for
the whole year, is that they should be returned as Field 67 code
99 No fee band, Field 68 code 98 No fees and Field 71 code 5 Exchange
out.
Further Information
If you have any queries on the issues raised in this
Circular, please contact the Institutional Liaison office (Helen
Skitt, Alison Berry or Janet Earl) at HESA, or email (liaison@hesa.ac.uk).
Yours sincerely
C Jane Wild
Director of Operations