Infotype Screen Structures (Type MAIN )

Definition

Type MAIN screen structures contain all fields that require representation on the user interface, with the exception of repeat fields, which are to be displayed on the user interface in table format. Therefore, if no repeat fields are to be contained within the screen structure, then a type MAIN screen structure should be applied. If repeat fields are to be contained in the screen structure, then a type LINE screen structure should be applied instead.

No more than one type MAIN screen structure can exist per combination of infotype and infotype version.

Type MAIN screen structures observe the naming convention HCMT_BSP_PA_yy_Rnnnn , where:

  • yy

    denotes the Version ID – for example, FR for France, UP for the United States Public Sector, US for the United States, and XX for the international version, and

  • nnnn

    denotes the four-digit number that is assigned to the infotype.

As with other customer-specific objects that observe a naming convention with the initial letter Z… , type MAIN screen structures for customer-specific infotypes observe the naming convention ZHCMT_BSP_PA_yy_Rnnnn .

Note Note

If a name range prefix is desired, then the name of the screen structure must be shortened accordingly. Therefore, customers should observe the naming convention /custcust/ZHCMT_yy_Rnnnn if they wish to apply a name range prefix to customer-specific type MAIN screen structures.

End of the note.

Structure

Type MAIN screen structures are composed of the following elements:

  • Component OBJECT_KEY

    In the de-coupled framework, component OBJECT_KEY is strictly reserved for internal use, and is not relevant for user interfaces. Never change or clear the value of this component!

  • Include HRPAD00SCREEN_HEADER

    This include contains header columns similar to those found in the infotype structure and is composed of the following fields:

    • Personnel Number (PERNR),

    • Changed On (AEDTM),

      which indicates the date on which the infotype record was changed,

    • Name of Person Who Changed Object (UNAME),

      which reflects the user name of the party who changed the infotype record,

    • Lock Indicator for HR Master Record (Text) (SPRTX),

      which indicates whether or not the infotype record is locked, and

    • Start Date (BEGDA) and End Date (ENDDA),

      which indicates the validity period of the infotype record.

  • Fields to be represented on the user interface, including editable fields (for data entry) and read-only fields.

  • Include CI_yy_Rnnnn (for standard infotypes only)

    … where yy and nnnn adhere to the naming convention explained above.

    As discussed in the topic Screen Structures , this include enables customer-specific fields to be represented on standard infotypes that customers wish to enhance.

To reiterate, the fields contained within type MAIN screen structures are essentially intended for representation on the user interface. In some cases, these fields and the corresponding PSnnnn fields may be identical. In other cases, additional fields may exist, or fewer fields, or different fields altogether, as discussed in the topic Programming User Interfaces in the De-Coupled Framework . As also discussed in that topic, many screen structure fields are filled or otherwise processed automatically. Fields that cannot automatically be processed require handling in the corresponding conversion class by implementing methods OUTPUT_CONVERSION and INPUT_CONVERSION . Once these methods are implemented, the conversion class must be assigned to the screen structure, as explained in the topic Assigning Conversion Classes to Screen Structures .