SAP ABAP IMG Activity OHPSUSNOA011 (Create Subscreen for Nature of Action)
Hierarchy
☛ SAP_HRCUS (Software Component) Sub component SAP_HRCUS of SAP_HR
   ⤷ PY-US-PS (Application Component) Öffentlicher Dienst
     ⤷ P10PA (Package) HR master data: Development Personnel Actions
IMG Activity
ID OHPSUSNOA011 Create Subscreen for Nature of Action  
Transaction Code S_L6B_69000523   (empty) 
Created on 20030404    
Customizing Attributes OHPSUSNOA011   Create Subscreen for Nature of Action 
Customizing Activity OHPSUSNOA011   Create Subscreen for Nature of Action 
Document
Document Class SIMG   Hypertext: Object Class - Class to which a document belongs.
Document Name OHPSUSNOA011    

Use

The default interface used by the Nature of Actions (NoA) tool to display and modify the relevant infotype data is a table control. This table control is an element of a subscreen that is called by default from the main screen of the NoA tool. As an alternative to the table control, the customer is able to develop his or her own screen in an external report, and indicate in the NoA configuration that this alternate screen should be used as the interface for the NoA fields.

The following steps describe the general approach to developing a customer subscreen:

  1. Configure the NoA using the configuration tool.
  2. Create a report to contain the new subscreen.
  3. Within the report, create a screen of screen type subscreen.
  4. In the Details area of the NoA configuration screen, replace the default report name and subscreen number with the customer report name and subscreen number.
  5. Add fields to the subscreen that will correspond to the infotype fields involved in the NoA. In simple cases, one may use the fields from the corresponding infotype structure in the data dictionary. For example, the table P0002 can be declared in a TABLES statement in the report, and then P0002-PERID can be used as a screen field. In more complicated cases where there may be duplicate infotype fields on the screen, such as when more than one subtype of an infotype is used in the action, the user must declare and use distinctly-named screen fields for each duplicate.

Processing the NoA Fields

The external report created by the customer must share some common data with the NoA main program. This data has been declared in the main NoA program as common, and should also be declared globally in the customer program as common:

* Common Data from Nature of Actions 
DATA: BEGIN OF COMMON PART comdata3. 
DATA: locked_action(01) TYPE c, 
      display_mode      TYPE c. 
DATA: END OF COMMON PART. 

DATA: BEGIN OF COMMON PART fields. 
DATA: fields TYPE STANDARD TABLE OF hrpafields 
             WITH HEADER LINE. 
DATA: END OF COMMON PART.

The declarations for the NoA table control processing can be found in the program SAPMPBS0ACTIONS, include MPBS0ACTIONSTOP.

The FIELDS table in the declaration above is used in the NoA program to store the employee's infotype data used for that particular action. Each infotype field included in the configuration of the action corresponds to an entry in the FIELDS table. This table is filled by the main NoA program prior to the call of the customer subscreen, and is also used to update the database with the new values once control is returned from the customer subscreen to the main NoA program. The customer program is responsible for the transfer of data between the customer subscreen and the FIELDS table; the main NoA program is responsible for extracting the infotype data, running the pre- and post-validations, and updating the database with changes. Therefore, the customer subscreen should not include any database updates or commits.

Some of the fields in a line of table FIELDS that might be used in the processing in the customer subscreen are given below (Note that this is only a subset of the fields that define the structure):

Name    Description

ENDDA    End Date

BEGDA    Begin Date

SEQNR    Sequence number of existing infotype record being copied

INFTY    Infotype

SUBTY    Infotype Subtype

TABNAME    Name of table containing field data

FIELDNAME    Technical Field name

FIELDTEXT    Field text from DDIC

VALUE    Current value of the field

OLD_VALUE    Previous value of the field

TEXT_VALUE    Text which may exist for the field in VALUE

TEXTEXISTS    Flag indicating whether text corresponding to the field in VALUE exists

CHANGED    Indicates whether value of the field has changed during screen processing

SCREEN_INPUT    Input or only output field

SCREEN_LENGTH    Input screen length for the field Value

OFFSET    Offset of the field within the infotype structure

LENG    Length of the field in the infotype structure

F4AVAILABL    Flag indicating that F4 help exists for field in FIELDNAME

Two fundamental processes must be programmed in the customer subscreen:

  1. The transfer of infotype field values between the screen fields and the FIELDS table.
  2. The setting of the screen field attributes that correspond to the display attributes set in the NoA configuration. (For example, for an NoA field that is configured to be hidden, the corresponding screen field should also be hidden.)

1. Transferring infotype field values between the screen fields and the FIELDS table:

The element of the FIELDS table corresponding to the value of the infotype field is FIELDS-VALUE. The transfer of FIELDS-VALUE from the FIELDS table to its corresponding screen element should be programmed in the PBO. The transfer of the value of the screen field back to the FIELDS table should be programmed in the PAI, where FIELDS-VALUE should be updated with the new value from the screen. The general approach is to loop through the FIELDS table, and for each entry, transfer the data between the FIELDS-VALUE field and its corresponding screen field. It should be noted that for certain data types, such as date or currency types, a conversion from external to internal format should be done prior to passing the field from the fields table to the screen field. This could be done by calling method EXT_TO_INT of class CL_HRPBSUS_FIELD_CONVERT. Please refer to the IMG step that references the customer subscreen programs to see how this would be called.

Example of transfer of values from FIELDS table to screen fields

MODULE fields_to_screen OUTPUT. 
  DATA: ls_fields TYPE hrpafields, 
        l_fieldname TYPE fieldname, 
        l_subrc TYPE sysubrc. 
  FIELD-SYMBOLS: <field_value> TYPE ANY. 
  LOOP AT fields INTO ls_fields. 

*   Create the name of the infotype field in question. 
*   In this example this name is also the name of the corresponding 
*   screen field. 
    CONCATENATE ls_fields-tabname '-' ls_fields-fieldname INTO 
      l_fieldname. 

*   Use a field symbol to refer to the field. 
    ASSIGN (l_fieldname) TO <field_value>. 

*   Assign the value of the infotype field to the field-symbol 
    IF <field_value> IS ASSIGNED. 
*     Transfer data from fields table to screen field. 
      MOVE ls_fields-value TO <field_value>. 
      UNASSIGN <field_value>. 
    ENDIF. 
  ENDLOOP. 
ENDMODULE.                 " fields_to_screen  OUTPUT

Example of transfer of screen fields to FIELDS table:

MODULE screen_to_fields INPUT. 

  LOOP AT fields INTO ls_fields. 
*   Construct the name of the infotype field in question. In this 
*   case it is also the name of the corresponding screen field. 
    CONCATENATE ls_fields-tabname '-' ls_fields-fieldname INTO 
      l_fieldname. 

*   Use a field symbol to refer to the field. 
    ASSIGN (l_fieldname) TO <field_value>. 

    IF <field_value> IS ASSIGNED. 

*     Update value in fields table 
      MOVE <field_value> TO ls_fields-value. 
      MODIFY fields FROM ls_fields INDEX sy-tabix TRANSPORTING value. 

      UNASSIGN <field_value>. 
    ENDIF. 
  ENDLOOP. 

ENDMODULE.                 " screen_to_fields  INPUT

2. Setting screen field attributes:

The element FIELDS-SCREEN_INPUT indicates whether an NoA field should be an input field, output field, or hidden on the screen. The translation of this field to the SCREEN table is defined below:

FIELDS-SCREEN_INPUT    Meaning    SCREEN-INPUT    SCREEN-REQUIRED    SCREEN-INVISIBLE

O (the letter, not zero)    Output only    0 (zero)    0    0

H    Hidden field    0    0    1

All other values    Input field    1    0    0

The element that indicates whether an NoA field has F4 help available in the data dictionary is FIELDS-F4AVAILABL. The value of this field is 'X' if F4 help is available, and ' ' if not. To ensure that the F4 help button appears on the screen for fields that do have F4 help available, SCREEN-VALUE_HELP must be set equal to 1.

The process of setting the screen field attributes should be done in the screen PBO and will override the default values that have been def

Business Attributes
ASAP Roadmap ID 151   Design interfaces 
Mandatory / Optional 3   Nonrequired activity 
Critical / Non-Critical 2   Non-critical 
Country-Dependency I   Valid for countries specified 
Customizing Attributes Country Key Country Name
OHPSUSNOA011 US USA
Assigned Application Components
Documentation Object Class Documentation Object Name Current line number Application Component Application Component Name
SIMG OHPSUSNOA011 0 I511000001 Öffentlicher Dienst 
Maintenance Objects
Maintenance object type C   Customizing Object 
Assigned objects
Customizing Object Object Type Transaction Code Sub-object Do not Summarize Skip Subset Dialog Box Description for multiple selections
IMGDUMMY D - Dummy object SE80  
History
Last changed by/on SAP  20030404 
SAP Release Created in 470