Student collection
To access the data collection system you will need to register for the Student collection (C11051) on the HESA submit website. For assistance with registration please view the Registering for the system help page.
Stages of data submission:
1. Sending and validating data
The diagram below demonstrates the data submission process.
Stage 1: Submitting and validating data
A. Sending data
Send data by clicking on ‘Send some or all of submission to HESA' in the ‘What can I do now?' box.Browse your computer to locate the file you wish to submit, and upload the file to the data collection system. Click on the 'submission status' link to navigate back to the transaction history page to view the outcome of submission.
Tips:
- Files can have any name
- Files must be in XML and conform to the relevant XML Schema Definition (XSD) file
- Files can be compressed
using PKZip/WinZip which will significantly reduce
the upload time
- Complete data can be sent in one or more files (all files must pass validation)
B. Validation
Insert-stage validation checks will now run.
Further details on the checks included in INSERT-stage validation can be found within the field details of the record descriptions.
In addition to schema and business rule checks, an Entry
Profile (EP) check will also be carried out as part of INSERT-stage
validation. This report lists any incoming instances submitted without Entry Profile
data that do not link to instances returned in previous collections. If errors are found with the submitted entry profile data
the file will fail validation. Click on this
icon to review the errors triggered by the file. Make any necessary
amendments to the data and resubmit the file to the system.
To pass insert-stage validation the file must not trigger any validation errors.
i. What to do if the file fails validation
If the file fails validation the system will show the below status and reports. You should review errors (and warnings if any). Make any necessary corrections to the data and resubmit.
| Transaction result | Reports |
 |
    |
*Note: Corrections cannot be made online to the file submitted to the data collection system and instead must be made to the file held locally, and the file then resubmitted.
This is the validation error icon. You will encounter this icon if the file fails
validation. Click on this icon to review the errors triggered by the
file. To pass INSERT-stage validation you will need to resolve all errors listed within the report.
ii. What to do if the file passes validation
If the file passes INSERT-stage validation the system will show the status and reports below. You should review any validations warnings relating to the file to ensure that the submitted data is genuine or correcting and resubmitting the file where necessary.
| Transaction result | Reports |
 |
 |
You can also run insert-stage validation checks through the validation kit before submitting data to the submit site.
The kit enables institutions to test their data locally against the
INSERT-stage validation ahead of the main collection opening in the
summer. Institutions are strongly encouraged to use the validation kit
as part of their data preparations.
Remember
that you need to process and pass the INSERT-stage validation in order to meet
the requirements of the return deadline of 15 September 2011.
Stage 2: Committing data
To proceed to commit-level validation a valid file needs to have been submitted and passed INSERT-stage validation checks. The data will then be classed as committable and the option to process TEST_COMMIT and COMMIT transactions will be made available in the ‘What can I do now?' box.
A. TEST_COMMIT
Click on ‘TEST_COMMIT this submission' in the ‘What can I do now?' section. The HESA data collection system assumes that all the submitted files that have passed validation represent the institution as a whole and as such, stacks up all files that have passed INSERT-stage validation and runs COMMIT level checks.
Check through the frequency counts displayed before clicking 'OK' to ensure that the data to be committed contains all expected records.
i. What to do if the file fails TEST_COMMIT?
If the file fails TEST_COMMIT level checks the system will show the status and reports below. You should review the error report produced, make any necessary corrections to the file and resubmit it.
| Transaction result |
Reports |
| |
 |
You will encounter this icon
following COMMIT-stage
validation. Click on this icon to review the errors triggered by the
file. Make any necessary amendments to the data and resubmit the file
to
the system. To assist institutions with their amendments the exception
report
features the option to download the totality of records failing
exception
checks. Exception reports are retained for all commit transactions
enabling you to assess variations in levels of exception errors and
warnings between transactions.
ii. What to do if the file passes TEST_COMMIT?
If the file passes TEST_COMMIT it will generate the suite of commit reports (See Student report key for details). These reports should be reviewed to ensure that the submitted data is an accurate reflection of the institution's profile. Help on how to analyse the check documentation can be found in the C11051 Check Documentation Guide.
| Transaction result |
Reports |
| |
         |
What is the difference between TEST_COMMIT
and COMMIT? In terms of the validation processes run by the system there is
no difference between these
transactions. The only difference between the two transactions is that
the
reports generated from the TEST_COMMIT transaction are for institutional
use only. The facility enables institutions to view the commit
reports and assess submitted data for anomalies before processing a full
COMMIT transaction
to be scrutinised by HESA.
Following a successful TEST_COMMIT transaction institutions do not have to contact HESA to 'DECOMMIT' the return; changes can be made to the submission by inserting and/or deleting files in the normal way.
Deleting files
Where you need to make amendments to data you will need to delete the older version of the file. If files that previously passed validation and are subsequently replaced are not deleted they will be combined within the COMMIT transaction and cause the file to fail due to duplicate records. To delete a file select the 'delete' option in the 'What can I do now?' box. This will display a listing of all live passed files submitted to the system in chronological order. Select the file you wish to delete.
Why can't failed files be deleted?
Where a file fails INSERT-stage validation the records contained within it are not uploaded to the HESA database and so will not be counted as part of the return.
B. COMMIT
Once your file has passed TEST_COMMIT and you are content with the data contained within, you should process a COMMIT transaction. This transaction will then send a copy of the submission to the HESA Data Quality Assurance team for HESA to undertake analysis of the return in parallel with the institution conducting their own analysis.
| Transaction |
Result |
| |
   |
The
data collection system will provide a second version of the check
documentation for every re-commit/test-commit processed by an
institution. This version of the check documentation presents a colour
shaded version of the Excel spreadsheet with variances being
highlighted.
Decommitting
A passed commit transaction will lock the system to prevent the data from being amended, in order to allow the HESA Data Quality Assurance team to undertake analysis of the submission. To unlock the system you will need to request a DECOMMIT transaction from HESA. This will reverse the current commit and allow you to delete, resend and recommit data.
I need to amend my data, how do I get it decommitted?
You will need to contact Institutional Liaison either by emailing liaison@hesa.ac.uk or calling on 01242 211144 to request a decommit transaction.
Remember
that you need to process and pass a COMMIT transaction in order to meet
the requirements of the commit deadline of 22 September 2011. A passed
test-commit will not satisfy the requirements of this deadline.
Stage 3: Credibility checks
Once HESA has undertaken their analysis of the committed return data quality queries will be posted onto the Minerva DQ database. Record contacts, and any others users signed up to Minerva, will be notified by email when these queries are available to view. The Minerva user guide provides help on using the database.
Stage 4: Sign-off
Once the data has passed
all the stages of validation, and any issues highlighted during
credibility checking have been addressed, HESA will set the return to
CREDIBLE; this produces the sign-off form.
A link to the sign-off form will automatically be emailed to the Head of the institution when data is set to CREDIBLE. The form should be completed and signed by the Head or Acting Head of the reporting institution and posted to HESA. This verification offers both the institutions and HESA assurances regarding onward use of the data. Sign-off completes the data collection process.
