Kontakt

Ansicht
Dokumentation

RPUHESG1 - HESA NISR Reporting (Interface to ALV, TemSe or File Server)

RPUHESG1 - HESA NISR Reporting (Interface to ALV, TemSe or File Server)

CPI1466 during Backup   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.
SAP E-Book

Title

HESA New Indvidualised Staff Return.

Purpose

The purpose of this report is to create a file to be sent to the Higher Education Statistics Agency (HESA) for the New Individualised Staff Return.

Integration

Data for this report is taken from HR Master Data, specifically infotype HESA Master Data (0614) and HE Contract Data (0615).

Academic qualification data is taken from infotype Academic Qualification (0618).

Infotype Clinical Details (0617) is required for staff working on medical duty.

Other infotypes used are Personal Data (0002), Basic Pay (0008) and Additional Personal Data (0077). Infotypes Actions (0000) and Org.Assignment (0001) are used to determine employee status and groupings.

Infotype HESA Submitted Data (0616), used for Individualised Satff Return is obsolete.

Prerequisites

Customising for the HESA return (see IMG) has to be carried out. All references to tables, feature etc. are mentioned here for reference only; all customising objects are in IMG.

Data for the employees has to be set up.

If you used SAP HESA ISR, ASR or NASR prior to HESA return year 2003/2004 you should perform data migration to new HESA formats and codes (for more information see documentation of the reports RPUHESA01, RPUHESA02 and RPUHESA03).

If you choose to fill the new field 'Appointment ID' on infotype 'HE Contract Data' atomatically, you should run the report RPUHESA04. Otherwise, this field should be filled manually to generate correct 'Contract Identifier' in the field CONTID of the Contract table.

Mapping of fields

  • Record type indicator (RECID) Generated in program; dependent on year (yy - two last digits from year field): yy025 - NISR Person table standard record, yy026 - NISR contract table standard record, yy027 - NISR Grade table standard record and yy126 - NISR contract table minimum record for atypical staff.
  • Institution identifier (INSTID) Taken from customising there is only one ID per installation possible; check table T5GPBSH_INS holds the higher education institutions' HESA codes; the table also holds information where the institution is located (Scotland, Wales, other)
  • Staff identifier (STAFFID) HESA Master infotype, including checking of number; new numbers generated from number range HR_GB_HEID, using the fiscal year as the HESA year; old USR staff Ids are accepted by the system; the format of USR is 0000xxxxxxxxx with x being a digit

Person Table

  • Date of birth (BIRTHDTE) Field Date of birth (GBDAT) from infotype Personal Data (0002), in format YYYYMMDD
  • Gender (GENDER) field gender (GESCH) on infotype Personal Data (0002), with a hard-coded mapping of 1, 2 -> M, F
  • Nationality (NATION) Fields P0002-NATIO, NATI2, NATI3 are used with mapping table T5GPBSH_NAT
  • Ethnicity (ETHNIC) Field P0077-RACKY is mapped to the HESA code using table T5GPBSH_ETH; HESA ethnicity codes are held in table T5GPBSH_ETC
  • Disabled (DISABLED) P0077-DISAB and infotype Challenge (0004) field challenge group are considered, challenge group can be marked as to be returned as disabled in mapping table T5GPBSH_CHA; only values 1 and 2 are returned, i.e. registration is not taken into account
  • Date first appointed at current HEI (DATEFHEI) The last begin date of continuous service derived from infotype Actions (0000) in format YYYYMMDD is returned. This field is filled for atypical staff.
  • Previous employment(PREVEMP) HESA Master infotype; check table for HESA code is T5GPBSH_PRV2. Default code used for atypical staff is '99' (Not known).
  • Previous HEI (PREVHEI) HESA Master infotype; check table T5GPBSH_INS holds the higher education institutions' HESA codes
  • Highest qualification held(HQHELD) From Academic Qualifications infotype (0618): checked against new level of qualifications table T5GPBSH_QUD2;
  • Academic discipline(ACCDIS1, ACCDIS2) From Academic Qualifications infotype (0618). The Joint Academic Coding System (JACS) coding frame introduced in 2002/03 is used and provides for all subjects to be coded according to a common, four-character subject code; the check table with HESA codes is T5GPBSH_ACD2
  • Regulatory body (REGBODY) Clinical details infotype, field 'Registraiton type' is used with mapping table T5GPBSC_RTB; the check table with HESA codes is T6GPBSC_RBD. Value '00' (Not currently registered) is returned by the report for the staff who are classified as 'Clinical' but do not have a record of infotype 'Clinical details' (0617) valid on the return period.
  • Ability to teach through the medium of Welsh (ABLWELSH) HESA Master infotype (needed in Wales only) (field ABLWE)
  • Date left HEI (DATELEFT) Derived from 'Actions' infotype in format YYYYMMDD. This field is filled for atypical staff.
  • Destination on leaving (LEDEST) HE Contract infotype, the last valid contract (see field 32) will be used; codes are held in a new table T5GPBSH_DES2. Default code used for atypical staff is '99' (Not known).
  • Active in 2001 Research Assessment Exercise (RESACT) HESA Master infotype (field RESAC)
  • Unit of Assessment(UOA) HESA Master Data infotype
  • Total monies paid during this reporting year(TOTSAL) Calculation of the current salary is based on infotypes 8, 14 and 15 only; only certain wage types are used; customising is as for the annual salary calculation on infotype Basic Pay (0008); currency is British Pound
  • Disability 1(DISABLE1) Derived from HESA Master Data(0614) infotype
  • Disability 2 (DISABLE2) Derived from HESA Master Data (0614) infotype

Contract table

  • Campus identifier (CAMPID) Derived from new feature 08HCI (In: Org.assignment, out: ID), displayed on HE Contract infotype (if necessary this field can be on the infotype and if filled will be used instead of the value from the feature; but at this stage it is expected that the campus identifier is in some direct way related to the org.assignment)
  • Contract identifier(CONTID) Constructed by concatenating Personnel number and 'Appointment ID' assigned to the record of HE Contract infotype at the start date of the contract.
  • Terms of employment (TERMS) Derived from field contract type on infotype HESA Contract-infotype; atypical contracts are returned with '3'.
  • Mode of employment (MOEMP) Derived from infotype basic pay (0008); part time: Capacity utilisation level < 100; if staff is atypical in field 'Terms of employment ', staff is also considered atypical in this field. field contract type on infotype HESA Contract-infotype is used to determine 'term-time' contracts.
  • Academic employment function (ACEMPFUN) HE Contract infotype
  • FTE during reporting year (CONFTE) Derived from infotype Basic pay (0008), field Cap.utility level , pro-rated across the period of active employment within the year; if there is no infotype 0008 for atypical staff, salary is divided by a notional amount (determined from customising).
  • Teaching through the medium of Welsh (TCHWLH) HESA Master infotype (needed in Wales only) (field TCHWL)
  • Grade structure (GRADE) Derived from infotype Basic Pay (0008) and mapped to the HESA code using feature 08HGR (payscale grp/lvl/type/area-> code); HESA code is held in table T5GPBSH_GRA
  • Senior management post holder (SMPH) HESA Master infotype (field SENPH)
  • Source of basic salary (SOBS) HE Contract infotype
  • Proportion of basic salary charged against general income (PSCAG) HE Contract infotype
  • Secondary source of basic salary (SSOBS) HE Contract infotype
  • Salary point (SALPOINT) Derived from infotype 0008: there is feature 08HSP mapping payscale (level = TRFST) to salary point
  • Basic salary at reference date (SALREF) Calculation of the current salary is based on infotypes 8, 14 and 15 only; only certain wage types are used; customising is as for the annual salary calculation on infotype Basic Pay (0008); currency is British Pound
  • NHS contracts (NHSCON) From infotype Clinical Details; fields 'A+B appointment', 'NHS Joint' and 'Honorary NHS type'. Value '0' (Not NHS contract) is returned by the report for the staff who are classified as 'Clinical' but do not have a record of infotype 'Clinical details' (0617) valid on the contract period.
  • NHS contract grade (NHSCONGR) field 'Honorary NHS type' is used with mapping table T5GPBSC_NHS. Value 'XX' (Not applicable) is returned by the report for the staff who are classified as 'Clinical' but do not have a record of infotype 'Clinical details' (0617) valid on the contract period.
  • Healthcare professional speciality(HSPEC) Clinical Details infotype, field 'Clinical specialty'. Value 'XX' (Not applicable) is returned by the report for the staff who are classified as 'Clinical' but do not have a record of infotype 'Clinical details' (0617) valid on the contract period.
  • HEI joint contracts(HEIJOINT) HESA Contract details infotype
  • Primary cost centre (CCENTRE) Derived from Org.assignment: infotype External Key (1038) subtype HEFC holds the HEFCE cost centre; if this is not filled, the HE Contract infotype is used;
  • Activity codes(ACT1, ACT2, ACT3) HESA Contract details infotype
  • Cost centres (CCENTRE1, CCENTRE2, CCENTRE3) HESA Contract details infotype
  • Proportions in cost centres(CCPROP1, CCPROP2, CCPROP3) HESA Contract details infotype
  • Grade Identifier(GRADID) Derived from feature 08HG2
  • Clinical Status (CLINICAL) Derived from Clinical Details(0617) infotype
  • Professor(PROFE) Derived from HE Contract Data (0615) infotype

Grade table

  • Institution identifier (INSTID) and Grade Identifier (INSTGRAD) Derived from the field INSTID and GRADID in the Contract Table (PAPBSGB_HESA_C)
For each record in the Contract Table (PAPBSGB_HESA_C), the system checks whether the corresponding entry for the field INSTID and GRADID exists in the Grade table (PAPBSGB_HESA_GR). If the entry exists, it does not perform further processing. Else, the system creates a new entry with the value of the fields INSTID and GRADID fields from the Contract Table respectively.
  • Grade Name(GRADNAME) Derived from the TRFRG field of the Payscale Group Identifier table (T510)
  • Minimum spine point and Minimum salary at reference date (MINSPINE, MINSAL) Derived from the lowest ordinal payscale level for the grade. The TRFST and BETRG fields of the Payscale Group Identifier table (T510) hold the Minimum spine point and Minimum salary at reference date values respectively. The system multiplies the value in the BETRG field by 12 to get to an annual figure.
  • Maximum spine point and Maximum salary at reference date(MAXSPINE, MAXSAL) Derived from the highest ordinal payscale level for the grade. The TRFST and BETRG fields of the Payscale Group Identifier table (T510) hold the Maximum spine point and Maximum salary at reference date values respectively. The system multiplies the value in the BETRG field by 12 to get to an annual figure.
  • Spine point of contribution related pay threshold(CONSPINE) Stores the default value XXX. You can maintain the value of this field.
  • Salary at contribution related pay threshold (CONSAL) Stores the default value XXXXXXX. You can maintain the value of this field.

Selection

Inclusion of an individual in the record will depend on the existence of one or more contracts of employment between the institution and an individual and/or the liability of the institution to pay Class 1 National Insurance contributions for that individual.

However the range of data required about an individual and the contract(s) that they hold will depend on the nature of those contracts and also the classification of the activity for which the contract exists.

The report will perform the following three processing steps:

  • Generation
  • Delete archive records
  • Maintenance
  • Maintain GRADE only - If you select this checkbox, the system allows you to maintain only the Grade Table (PAPBSGB_HESA_GR)

  • Extraction

The report will allow Generation and Extraction to be performed in test mode (without DB up-date) and in live mode (with DB update).

The step 'Delete archive records' should be used only if some records where generated in HESA NISR archive tables by mistake (e.g. for an employee who should not be returned to HESA). If you simply need to re-generate an employee's records, you do not need to delete the archive records beforehand. The report will automatically update the archive with new records in 'Live' mode of Generation step.

In maintenance mode the report will not provide any checks for fields manually modified by cus-tomers.

Extraction in the live mode should be run by the customers only when the data has been sub-mitted to HESA, validated by HESA and must not be change any further, as such a run will lock records of NISR (in control table T5GPBSH_CONTROL) from any further change - manual as well as through report generation.

Coverage

For those individuals with contracts of employment and/or for whom the institution is liable to pay Class 1 National Insurance contributions but whose relationship for all contracts held with the institution during the reporting period would be defined as 'atypical' there is a requirement to return only a minimum data set. The term 'atypical' is used to describe working arrangements that are not permanent, involve complex employment relationships and/or involve work away from the supervision of the normal work provider.

For those individuals whose relationship with the institution, for one or more of the contracts held during the reporting period, cannot be defined as 'atypical' there is a requirement to return a wider range of data. For many staff, those who have contracts to undertake activities classified in SOC groups 4-9, this additional requirement relates mainly to grade and salary information and start and end dates of employment and contracts.

Where individuals have contracts to undertake activities classified in SOC groups 1- 3 there is a requirement for an additional range of data for example about qualifications and previous employment/destination on leaving information. This information is required for those who have contracts in administrative and professional posts, for example in planning, libraries and registraries, whose activities are likely to be coded in SOC groups 1, 2B and 3 - areas that mean that they are likely to have careers within the HE sector that involve them moving between institutions. There is also a requirement for institutions to track the use of staff identifiers when SOC 1, 2B and 3 staff move between institutions.

For all other staff with contracts where any of the activity code fields (24, 27, 30) are coded 2A, there is a requirement for a further additional range of data. There is also a requirement for institutions to track the use of staff identifiers when SOC 2A staff move between institutions.

Amongst the SOC 2A group of staff some information is only needed for Health and Social Care professions, i.e. where any of the cost centres fields (25, 28, 31) are coded 1 to 9 or 29.

Finally, only in the case of those staff who hold NHS contracts are field 19, NHS contract grade and field, 20 Healthcare professional specialty in the Contract Table additionally required.

Standard Variants

Output

In generation mode, the program will generate records of HESA NISR based on Master Data stored in a customer SAP system and display them in ALV. In live generation mode, the records are displayed in ALV and stored on the database on personnel number basis for modification, extraction and for customer use in 2 database tables:

  • Person Table (PAPBSGB_HESA_P)
  • Contract Table (PAPBSGB_HESA_C)
  • Grade Table (PAPBSGB_HESA_GR)

The data are generated based on categories of staff as specified in HESA specification. Only information required by HESA for a category of staff is generated by the report for each personnel number, even if more information is available in the system. Aggregation of the information in Person table will be performed only at the extraction stage.

Validation of single person and contract table records will be performed at generation stage, while validation across different reference personnel numbers and across contract and person table will be performed at extraction stage.

In maintenance mode, all fields of the return tables will be available for maintenance, except Personnel number, return year and institution ID. There is no checks performed by the report on data manually changed by a user.

In the Extraction mode (and only in this mode), it is possible to select output options either than ALV output, i.e. TemSe output and File Server output. One file is generated for each of the return tables. The ALV output allows export to spreadsheet programs like MS Excel.

For submission to HESA you should run the program in extraction mode for all your employees in one run.

After the live extraction of the return for given return year, it will be no longer possible to modify the Person and Contract table for this return year neither manually, nor by report generation. This restriction is put in place in order to prevent accidental corruption /overwrite of the return once it was submitted to HESA.

Report RPUHERG0 should be used to extract the results from TemSe file.

There is a comprehensive error log.

Some of the errors come up as warning in test mode. This is to allow other errors of those employees to show up during early testing. The long text of the warning/error states whether the problem is handled differently during test mode.

During test mode some errors come up as warnings to give an overview of all problems rather than to stop processing of a personnel number with the first minor error.

HESA Validation Checks

During "Generation", the HESA validation checks are performed and warning messages are created for any checks that fail AND the records have the error field set to 'X'.

These must be corrected in one of three ways.

1) Master Data correction and re-running the generation

2) Maintenance of generated records

3) Reporting the problem/validation code to SAP via an OSS message if you believe the validation check is incorrect or if there is no way for the problem to be corrected manually.

During "Extraction", the HESA validation checks are performed and error messages are created for any checks that fail AND the records will not be included in the interface files to be submitted to HESA.

Activities

To submit HESA NISR, proceed in the following sequence of steps:

  • 1.,,Test generation of the return.
  • 2.,,Record verification, correction of the Master Data if necessary.
  • 3.,,Live generation of the return (update of the database tables PAPBSGB_HESA_P and PAPBSGB_HESA_C).
  • 4.,,Maintenance of the generated records, if necessary.
  • 5.,,Test extraction of the return for submission to HESA into ALV, TemSe or application server files.
  • 6.,,Live extraction of the return after it was validated by HESA (update of the database table T5GPBSH_CONTROL).

Note

The system validates if the file path entered by the user aligns with the file system configurations authenticated for the report.

The file system configuration includes a logical File Name HR_GB_DIR_RPUHESG1 and Logical File Path HR_GB_DIR_FILEPATH , associated with the report. You should maintain the physical file path that you need to use in this report, against the Logical File Path HR_GB_DIR_FILEPATH using transaction FILE.

For further information on maintaining the physical file path, refer FILE.

Example






PERFORM Short Reference   ROGBILLS - Synchronize billing plans  
This documentation is copyright by SAP AG.

Length: 24702 Date: 20240601 Time: 115155     sap01-206 ( 420 ms )