How to submit overrides to primary derived fields

This page details the data structure and format for overrides to primary derived fields. These should be submitted only where HESA or ILR data are correct, but there are errors due to problems of fit with our algorithms.

Introduction
Format of override files
Submitting the override file
HEFCE processing
Related links
Further information

Introduction

Where the cause of an error in a derived field is erroneous HESA or ILR data, override files should not be submitted to correct the error – instead the HESA or ILR data should be corrected.

After an action plan has been approved, we will only apply an override where the data submitted on the HESA or ILR return are correct but there is a problem of fit with our algorithms.

Problems of fit occur where the derived field that we generate is based on an assumption which may not necessarily fit with the institution or college's actual position. All known problems of fit with the re-creation algorithms are described in the technical documentation (see the year specific link under funding and monitoring data overview).

Override files should contain the data structure and format described in the Format of override files section below. An example of a typical override file can be found in the year specific link under funding and monitoring data overview. Please note that since overrides can only alter primary derived fields, a record's secondary derived fields may be inconsistent with the primary derived fields.

To allow institutions to check that an override file has had the desired effect, a field is included in the individualised file.

For HEIs 'OVERRIDE' is included which takes the value 1 if an override has been applied to the record; otherwise its value is 0.
For FECs 'HEFOVER' is included which indicates the primary derived field(s) that have been overwritten.

Format of override files

Override files must be given a file name in the form ovrXXXXn.amd for institutions and ovrYYYYYYn.amd for colleges, where:

XXXX is the HESA institution identifier
YYYYYY is the provider number, ST_UPIN (L01) (for colleges)
n is a sequential number, starting at 1.

For example, the first override file submitted by institution 9999 would be called ovr99991.amd. The second file submitted would be called ovr99992.amd.

The override header

The override header should be in the following form:

line 1 – contains the filename (ovrYYYYYYn as described above), with the .amd extension removed.
line 2 – the date on which the override was submitted, in the form ddmmyyyy.
line 3 – a brief description of the purpose of the override.
line 4 – contains the word 'OVERRIDE'. For HEIs, this should be followed by either the word 'TEMPORARY' or 'PERMANENT'. If the override is temporary then the last academic year that it applies to should be entered.
line 5 – the field(s) used to uniquely identify records which should be corrected by the override, comma-separated. These should be named according to the names given in the technical documentation (see the year specific link under see the year specific link under funding and monitoring data overview).
line 6 – the names of the primary derived fields being changed, comma-separated.
line 7 – the number of rows of data (excluding headers) in the override file.
line 8 – the field used to compute the file's check sum.
line 9 – the value of the check sum.
lines 10-11 – these lines may be used for any notes that the college or institution wishes to include.
line 12 – fields included in the override file. The fields should be specified in the same order as in the data part of the file and must be comma-separated.
line 13 – the data must begin on this line. The data must consist of comma-separated fields, corresponding to those specified in line 12 of the header. Each record must be separated by a carriage return. A blank line should be placed after the final record.

Check sum

To ensure that the override file has been received in its entirety, or has not been otherwise corrupted during transmission, we use a check sum. The check sum is calculated by summing the values of the field specified on line 8 over all records in the file. The calculated value should be returned on line 9 of the override file. The field used to compute the check sum must be numeric, and must not contain any values greater than 20,000. If no suitable field is available, then a sequential field called RECNO may be created. For example, RECNO may contain 1, 2, 3, 4, 5 etc.

Saving files

Saving override files in Microsoft Excel usually results in the loss of leading zeros and the corruption of very large values into exponential form (for example, 9.91E+12). To avoid this, we recommend that HDE files are produced, viewed and saved using a text editor, for example Notepad.

Submitting the override file

Overrides to primary derived fields must be uploaded as a comma-separated file via the HEFCE extranet to the ‘FAMD General upload area (GUA)’ area. The group key is as follows:

P699 8C22EF79

Once logged in, navigate to the 'HEFCE resources' page, then under ‘Applications’ click on the ‘FAMD General upload area (GUA)’ link. This will take you to the upload page where override files may be submitted.

HEFCE processing

When we receive a valid override file in the structure and format detailed above, we will produce updated derived statistics outputs which will be made available to the institution or college via the HEFCE extranet. If we are content with the outputs, where appropriate, we will notify the institution or college by e-mail that the outputs are available and ask them to confirm that the amendments have had the impact expected.