Show TOC

 Screen Structures

Definition

As discussed in the topic Programming User Interfaces in the De-Coupled Framework , screen structures are Data Dictionary structures that contain all of the infotype fields that should be part of the user interface. Therefore, the sole purpose of a screen structure is to display on the user interface data that is derived from, but not stored in, the corresponding database.

Perhaps the most important attribute of any screen structure is determined in its technical name, which reflects whether the screen structure is either international (with entry XX ) or country-specific (with any entry other than XX ). The majority of screen structures are country-specific, and country-specific screen structures only contain the fields that are valid for the country version in question – for example, FR for France, UP for the United States Public Sector and US for the United States. International screen structures in turn contain fields that are suitable for display in any country version.

A second fundamental attribute of any screen structure is whether it is an infotype screen structure (belonging to type MAIN ) or a repeat field screen structure (belonging to type LINE ). All screen structures must belong either to one type or the other. Type MAIN screen structures (introduced in the next topic) and type LINE screen structures (introduced in the topic thereafter) each observe their own corresponding naming convention. The naming convention of each screen structure type is explained in the corresponding subsequent topic.

A third and final important consideration of any screen structure is the conversion class that is assigned to it, which in turn determines the manner in which data from the infotype structure will be converted into a format suitable for display in the screen structure. For additional information on the relationship between conversion classes and screen structures, consult the topic Assigning Conversion Classes to Screen Structures .

Use

The specific use of type MAIN and type LINE screen structures is described in detail in the corresponding subsequent topic. However, without regard to a screen structure’s type, it is important to remember the enhancement concept of standard infotypes when using any screen structure. In accordance with this concept, the screen structure of any standard infotype delivered by SAP contains the component .INCLUDE , which enables the inclusion of customer-specific user interface elements on any standard infotype, much as the component .INCLUDE enables the processing of customer-specific business logic in tandem with any standard infotype.

Example Example

Examples of component .INCLUDE in the standard Basic Pay infotype (0008) are visible in its infotype structure (P0008) – where the system uses this component to account for data in component type CI_P0008 – as well as its international type MAIN screen structure (HCMT_BSP_PA_XX_R0008) – where the system applies this component to consider data in component type CI_XX_R0008 . By the same token, in the international type LINE screen structure (HCMT_BSP_PA_XX_R0008_LIN_A) of the standard Basic Pay infotype (0008), the system applies this component to consider data in component type CI_XX_R0008_LIN_A .

End of the example.

Thus, if a customer for example wishes to enhance the standard Basic Pay infotype (0008) by creating new fields in component type CI_P0008 of infotype structure P0008, then he or she must also remember to create corresponding new fields in the corresponding component type of the affected screen structure – for example, in component type CI_XX_R0008 of screen structure HCMT_BSP_PA_XX_R0008 – to ensure that these fields are represented on the user interface.

Aside from this important consideration, no additional action is necessary for such customer-specific fields when they are identically named in the infotype structure and screen structure; the de-coupled framework will ensure that identically named fields are automatically filled, that input help values and descriptive texts are automatically retrieved (if Customizing has been performed), and that field attribute information is automatically provided.

Where customer-specific field names bear different field names in the infotype structure and screen structure, corresponding manual coding is required. However, in contrast to customer-specific infotypes – which require the implementation of methods OUTPUT_CONVERSION and INPUT_CONVERSION in the corresponding conversion class – neither method requires implementation when standard infotypes delivered by SAP are enhanced. To this end, Business Add-In (BAdI) HRPAD00INFTYUI must be implemented instead.