Screen Layout

Screen layout is defined in control tables. Applications from downstream development stages can extend and reconfigure existing screens. The BDT supports the following entities in screen layout

Field groups

Fields whose readiness for input was defined collectively are collected in a single field group. You create settings for each field group with in the Field Grouping .

A field group may only contain fields from one application. Customers should neither change nor extend the definition of standard SAP field groups, as this would amount to a program modification. As an alternative, customers can define their own field groups to which they also assign their own views.

Menu path:  Control <Object > Screen layout Field groups

Procedure: To define your own field group, proceed as follows:

The name of a field group is language-dependent and appears when a field grouping is maintained.

If fixed logical dependencies exist, a program can be used to change field groupings set up by customers.

If Required entry is set for a field group, the BDT checks automatically whether the fields have entries before the data is saved. If this is not the case, an error message is displayed. A different kind of required field check is necessary for some field groups. For these field groups, the automatic check can be turned off and an individual check used instead. One example of this is bank details for a business partner. The individual check will only trigger an error message if no bank details were entered. A specific check for required fields does not take place on the field level.

Enter the name of the screen fields that are to be assigned to the field group. Besides input fields, you also need to specify the field names of help texts, work fields, etc. For each field, specify whether it is ready for input or not.

Naming convention: Values from 1 to 1750 are permitted for field groups. While groups 750-1000 are reserved for development partners and groups 600-749 for customers, areas within SAP should be discussed with the development group responsible for the application object. The Business Partner development group is responsible for the business partner (application object BUPA) as well as business partner relationships (application object BUPR).

Views

One or more field groups constitute a view. All attributes that are displayed and checked together are grouped in one view. The fields of a view cannot be separated in screen layout since they are located on the same subscreen.

A view may only contain fields from one application. A downstream application may not extend a view; instead, it should create its own views for its attributes and assign its own subscreens to these views. The same applies to customers as extending a view amounts to a modification.

Menu path:  Control <Object > Screen layout Views

Procedure: The following steps are necessary for defining a view:

Use the Screen Painter to create a screen. But take note of the following when doing so:

Mark the screen type ‘subscreen’

Generally, you won’t need to put a frame around your data. The BDT automatically inserts a frame around the fields of a section (see Sections).

The field name of a pushbutton positioned on the subscreen should adhere to the following naming convention: PUSH_<Menu option>. If this is the case, the BDT’s field grouping automatically hides the pushbutton if the menu option is not active.

Create a PBO module that calls function module BUS_PBO ; call the PBO module from the PBO of each of your subscreens. If your subscreen contains a table control, transfer the data relating to the table control to the BDT using parameter C_TC1 when calling BUS_PBO .

Create a PAI module that calls function module BUS_PAI . Call this PAI module from the PAI of each of your subscreens.

Do not carry out any field checks within the flow logic, neither in a module nor in any of the sub-programs called from a module. Checks on a view should generally be carried out in a separate function module whose name is stored in the after-input field (see below).

Text tables for displaying check texts should be read and other actions related to PBO should be carried out within the function module whose name is to be defined in the prior-to-output field (see next section).

This event is triggered by the BDT for all views of a screen if another event is used to reach this screen. Views with step-loop or table control usually need a function module at this point. The developer makes sure that when a screen is re-called,

Example: The view ‘Address overview’ exists in a business partner. A function module was defined for this view at the event Prior to Screen Call .

Naming convention: <Application>_<Application object>_PBC_<View>

(Customer: Function module name has the prefix Y_ or Z_).

This event is triggered for all views of the current screen before the subscreen is called in PBO. Text tables for outputting check texts can be read at this point.

Example: The Industry field exists within a business partner. Examples of valid industries are stored in a Customizing table. If an industry ID is entered in the input field, the text table belonging to the Customizing table is selected in such a way that the name of the industry can be displayed behind the input field in the logon language.

Naming convention: <Application>_<Application object>_PBO_<View> (Customer: Function module name has the prefix Y_ or Z_).

This event is triggered for all views of the current screen after all the subscreens involved are called in PAI. Carry out your field checks on the view at this point. You can find tips on the procedure for field checks in the sections Views.

Naming convention: <Application>_<Application object>_PAI_<View>

(Customer: Function module name has the prefix Y_ or Z_).

Description: The program name and screen number of the subscreen, as well as its name, must be specified here. The names of the function modules for the events listed above are also defined here.

Naming convention: <Application><n>

The ID for a view should always have 6 places. It should start with the application ID followed by a set of numbers.

Define the field groups which belong to the view.

Other Checks on Views

The owner application can store the name of its check function module in the After input field within the definition of a view. If other applications add their own checks to this view, they can add the name of their check function module in the sub-node Other checks . These modules are called in PAI directly after the function module stored by the owner application. More information on data checks is given in the next section.

Naming convention: <Application>_<Application object>_PAI_<View>

(Customer: Function module name has the prefix Y_ or Z_).

Example: A customer request for business partners was to be able to check the last name of a person for the existence of at least one vowel. However, this check could not be implemented as a matter of course as there are names in some countries that have no vowels. The solution for this customer problem is to realize this kind of query using the check for an SAP standard view.

Procedure: In the check function module, the application gets the table content from the application that owns the table. To do this, the application uses the function module defined for the table in the Read data field. Then the check is carried out and, in some cases, a message displayed via the Message Handler (function module BUS_MESSAGE_STORE).

Note: In contrast to a check within event DCHCK, other checks for a view take place immediately after input. Event DCHCK is processed prior to saving.

Procedure for Field Checks

One of the goals for development with the BDT is a strict separation between interface and program logic. This ensures that all checks can be carried out even if you are using direct input and an external interface. Special rules apply to the following checks that are usually carried out by the screen:

To avoid this check by the screen deselect the field ‘Foreign key’ in the field attributes. As a substitute, program the foreign key check in the function module After input for view.

Alternatively, you can also use the foreign key check in dialog. However, you then have to program this check in function module After input for direct input (call up indicator for direct input whose value can be determined for event ISSTA).

These checks are carried out automatically by a screen if there are fields of a certain type on the screen. Examples include CURR (currency-dependent amount field), DATS (date field), INT* (integer) and NUMC (character field only with numbers). You can only get around the data type check by copying a CHAR field of the same length as the original field onto the screen instead of the original.

The following procedure is one way of dealing with these fields:

Example: The following examples can be found within function group FBU0 (application FI for application object BUPA).

As with foreign key checks, you also have the option with data types of letting the screen perform the check in dialog. However, you still have to use the procedure outlined above for direct input.

Never display messages directly using the message statement. This leads to problems with direct input and external interfaces. Call function module BUS_MESSAGE_STORE instead. You can enter the following information in this module:

Sections

One or more views are grouped together as a section. The BDT automatically puts a frame around each section. The only exception to this rule is the first section of a screen in which the header data appears. According to SAP ergonomic guidelines, a frame should not be put around this data. In addition to the description, you also define a language-dependent title for the section, which is displayed in a dialog in the upper left-hand corner of the frame.

Menu path:  Control <Object > Screen layout Sections

Procedure: The following steps are necessary for defining a section:

For each section, fill in Description and Title. . Both are language-dependent. In dialog, the title appears in the upper left-hand corner of the frame.

Naming convention: <Application><n>

The ID for a view should always have 6 places. It should start with the application ID followed by a set of numbers.

Define the views here which belong to the section. The sequence of views within a section is defined by the position number.

Naming convention: The position number has 7 places. Each development stage has one place of its own. The places from the left up to your own place are freely assignable. The application uses them to determine the position of the view within a section in relation to the views of the upstream development stages. The numbers to the right of your own place must be ‘0’.

The following places are reserved for the development stages:

Screens

The screen represents the largest unit in screen layout. One or more sections are grouped together as a screen. In addition to screens created with BDT, you can integrate screens that were not created with BDT by using the External screens selection.

Menu path:  Control <Object > Screen layout Screens

Procedure: The following steps are necessary for defining a screen:

In addition to the description, you also specify the screen-dependent part of the title as an additional language-dependent text. This is included in the determination of the complete screen title (see Screen Title ). You can also decide whether the screen is to appear as a full screen or a dialog box (popup).

Screens not configured using the BDT can also be integrated into the process. To do this, mark the ‘External screen’ indicator and enter the name of the function module for calling this screen. This module is called automatically by the BDT as soon as you start to navigate in the external screen. One example of this is the BP relationships of a business partner, whose overview was integrated as an external screen.

Naming convention: <Application><n>

The ID for a screen should always have 6 places. It should start with the application ID followed by a set of numbers.

Define the sections here which belong to a screen. The sequence of sections within a screen is defined by the position number.

Naming convention: The naming convention for the position number corresponds to that for the position number in the section→view assignment (see section).

Customizing Screen Layout/Screen Sequence with Drag&Drop

Description: Using the Visual Configuration Tool (VCT), customers can change standard SAP screens in the main screen sequence as well as the sequence itself in Customizing by drag&drop. These changes, like all other Customizing activities, connected to transports. Changes made by customers are fully maintained - that is, they are not overwritten by SAP in an upgrade.

The following functions are available for customers:

If an application object uses divisibility, you can set screen layout and screen sequence for each object part. If divisibility is not used, only one screen configuration can be created by the customer.

Action required: If you want to use configuration for your application object, you have to define just one setting transaction for setting activity 0104 (see Basic Settings , setting transactions).

Future plans: Functionality in VCT is to be extended progressively in Releases to come. The next steps include configuration of all screen sequences and/or the additional screens, integration of field grouping as well as the use of VCT by developers.