Ansicht
Dokumentation
OHPSUSNOA011 - Create Subscreen for Nature of Action
Addresses (Business Address Services) BAL Application Log DocumentationThis documentation is copyright by SAP AG.
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:
- Configure the NoA using the configuration tool.
- Create a report to contain the new subscreen.
- Within the report, create a screen of screen type subscreen.
- 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.
- 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.
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:
- The transfer of infotype field values between the screen fields and the FIELDS table.
- 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:
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
* Assign the value of the infotype field to the field-symbol
IF
* Transfer data from fields table to screen field.
MOVE ls_fields-value TO
UNASSIGN
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
IF
* Update value in fields table
MOVE
MODIFY fields FROM ls_fields INDEX sy-tabix TRANSPORTING value.
UNASSIGN
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 defined in the screen.
Example of modifying screen field attributes:
MODULE adjust_screen OUTPUT.
DATA: l_tabname TYPE tabname.
LOOP AT SCREEN.
* If the display mode is '1', then we select the display for each
* field from the screen_input field in the fields table.
IF display_mode = '1'.
* Determine the table name and fieldname for the field
* under consideration. Create the associated screen field
* name.
CLEAR: l_tabname, l_fieldname.
SPLIT screen-name AT '-' INTO l_tabname l_fieldname.
* Read the fields table for this entry to determine the display
READ TABLE fields INTO ls_fields WITH KEY tabname = l_tabname
fieldname = l_fieldname.
IF sy-subrc = 0.
* Set screen output status
CASE ls_fields-screen_input.
WHEN 'O'. "Output only
screen-input = 0.
screen-required = 0.
screen-invisible = 0.
WHEN 'H'. "Hidden field
screen-input = 0.
screen-required = 0.
screen-invisible = 1.
WHEN OTHERS.
screen-input = 1.
screen-required = 0.
screen-invisible = 0.
ENDCASE.
* Switches input help button on for fields with
* F4 help available from dict.
IF ls_fields-f4availabl = 'X'.
screen-value_help = '1'.
ELSE.
screen-value_help = '0'.
ENDIF.
MODIFY SCREEN.
ELSE.
screen-input = 0.
MODIFY SCREEN.
ENDIF.
ELSE.
* Display Only.
screen-input = 0.
MODIFY SCREEN.
ENDIF.
ENDLOOP.
ENDMODULE. " adjust_screen OUTPUT
In some cases the programmer may wish to display the value text associated to certain NoA fields. This can be obtained from the TEXT_VALUE field in the FIELDS table. If text exists in the data dictionary for a particular NoA infotype field, it is retrieved by the main NoA program and placed into the TEXT_VALUE field. This is done in the PBO for all fields when the FIELDS table is first initialized, and thereafter only for those fields for which the value has changed. If one intends to use the value text from the FIELDS table to populate text fields on the subscreen, one must maintain the field FIELDS-CHANGED in the PAI of the customer subscreen. Continuing with the aforementioned example, code to do this could be added to the module SCREEN_TO_FIELDS:
* Update value in fields table
MOVE
IF ls_fields-value <> ls_fields-old_value.
ls_fields-changed = 'X'.
ELSE.
ls_fields-changed = ' '.
ENDIF.
MODIFY fields FROM ls_fields INDEX sy-tabix TRANSPORTING value
changed old_value.
Note that one may also program the retrieval of the value text using the function module RH_TEXT_GET, rather than obtaining the text from the FIELDS table. In either case, the user must define screen fields to hold the text and declare them as data elements in the program.
Below is sample code for the case that the text is obtained from the FIELDS table:
MODULE text_fields_to_screen OUTPUT.
CLEAR: ls_fields,
l_fieldname.
LOOP AT fields INTO ls_fields.
* Get the name of the field in question.
* In this example the names of the text fields are
* (pnnnn)_(fieldname)_TEXT.
CONCATENATE ls_fields-tabname '_' ls_fields-fieldname '_TEXT' INTO
l_fieldname.
* Use a field symbol to refer to the field in the structure
ASSIGN (l_fieldname) TO
IF
MOVE ls_fields-text_value TO
UNASSIGN
ENDIF.
ENDLOOP.
ENDMODULE. " text_fields_to_screen OUTPUT
To handle OK codes generated by selecting buttons or tabstrips in the customer subscreen, there must be a form in the report with the following interface:
FORM okcode USING p_code TYPE syucomm.
The function codes used on the customer subscreen should begin with a letter 'Z' to avoid conflicting with function codes used by the main NoA screen. Because the customer subscreen is a subscreen that is called by the main NoA screen, the customer subscreen does not have access to the OK Code screen field. Therefore, the main NoA screen does the processing of the OK Code, in the PAI.
The function module HR_NOA_REMARK_F4 is available to be used in the customer subscreen for F4 help functionality for NoA Remarks fields. This functionality restricts the list of possible remarks to only those valid for the relevant Nature of Action code. In addition the remarks text corresponding to the remarks code is displayed. The functionality is processed at the PROCESS ON VALUE-REQUEST event:
PROCESS ON VALUE-REQUEST.
FIELD p0656-remark01 MODULE get_f4_remarks.
Module GET_F4_REMARKS could be defined as below:
MODULE get_f4_remarks INPUT.
DATA: l_prog_name LIKE sy-repid,
l_scrn_num LIKE sy-dynnr.
DATA: l_dynprofield TYPE help_info-dynprofld,
l_value TYPE help_info-fldvalue.
l_prog_name = sy-repid.
l_scrn_num = sy-dynnr.
CALL FUNCTION 'HR_NOAREMARK_GET_F4'
EXPORTING
dynprog = l_prog_name
dynpnr = l_scrn_num
dynprofield = l_dynprofield
value = l_value
* CALLBACK_PROGRAM = ' '
* CALLBACK_FORM = ' '
TABLES
fields = fields
* EXCEPTIONS
* PARAMETER_ERROR = 1
* NO_VALUES_FOUND = 2
* OTHERS = 3
.
ENDMODULE. " get_f4_remarks INPUT
For more information for this function module please refer to its documentation.
ROGBILLS - Synchronize billing plans General Data in Customer Master
This documentation is copyright by SAP AG.
Length: 22723 Date: 20240523 Time: 231722 sap01-206 ( 237 ms )
