Dynamic

Actions and Dynamic Processing Rules

https://help.sap.com/viewer/c6c3ffd90792427a9fee1a19df5b0925/1909.001/en-
US/0221a3533039cd46e10000000a44538d.html

Spro-> personnel Management -> personnel Administration -> customizing procedures ->
Dynamic Actions
Function character of step
00 for Independent of the current function carried out
02 for Change
04 for Create
06 for Change and create
08 for Delete
10 for Change and delete
12 for Create and delete
Indicator for step
P - Check conditions
I - Maintain infotype record
W - Set default values when creating a new record
V - Reference to another step
F - Call routine
M - Send mail

Introduction
Quy tắc xử lý động (DPR) là sự kế thừa cho các hành động động được sử dụng trong GUI GUI
trong các giao dịch PA30 và PA40. Các phần sau đây mô tả sự khác biệt giữa DPR và các hành
động động.

Trigger
A dynamic action is triggered by assigning it to the infotype and the subtype; in DPRs, this is achieved by
the assignment to the Configuration ID and the subtype (where the Configuration ID represents the
infotype).
When a change of field value is the trigger, this is achieved as follows:
In dynamic actions, the field FAMST, is defined as the field for infotype 0002. In DPRs, this condition is
defined as follows:
P0002_OLD-FAMST <> P0002-FAMST
In dynamic actions, you define multiple fields using the indicator V (Reference to another step) to specify
that changing one of these fields should trigger the dynamic action as illustrated in the following example:
Infotype Field Indicator Variable Function Part
0016 PRBEH V PRBZT
0016 PRBZT ... ...
In DPRs, two conditions are specified in an OR Group (for more information on conditions, see the
section Conditions.)
Field Condition Value OR Group
P0016_OLD-PRBEH <> P0016-PRBEH X
P0016_OLD-PRBZT <> P0016-PRBZT -
The country assignment defines that the rule is only valid for employees belonging to a certain country. In
dynamic actions, this is depicted as the condition T001P-MOLGA as illustrated in the table below:
Infotype Indicator Variable Function Part
0001 P T001P-MOLGA=‘01’
In DPRs, the country assignment is achieved by the Version ID on the rule definition level as illustrated
below:
Config ID Rule Version ID
IT0001 ZMY_RULE 01
The operation defines which infotype operation could trigger the rule. In dynamic actions, the function
character 02 (Change), 06 (Change and Create) is used as illustrated in the table below:
Infotype Function Character Variable Function Part
0001 06 ...
In dynamic processing rules, individual flags mark the relevant operations (Create, Change, Delimit) as
illustrated in the table below:
Config ID Rule Create Change Delimit
0001 06 x x -
In the DPRs, the supported operations are Create, Change, and Delimit, whereas in the dynamic actions,
the operations Create, Change, and Delete are available.
Rule Definition
Elements of Rule Definition
Dynamic Actions Dynamic Processing Rules
P (Check conditions) Conditions View (See the Conditions section below for details)
I (Maintain infotype records) Operations View (See the section Operations below for details)
W (Maintain infotype Default Values (See the section Default Values below for details)
records)
V (Reference to another Achieved by defining conditions linked by OR as described in the
step) section Trigger.
F (Call routine) For value calculations, use calculation methods.
For additional operations (for example database update), use a processing
class.
For dynamically defining infotype operations, use a returning class.
M (Send mail) Not supported but can be realized by a customer-specific processing class.
Access to Infotype Fields
Infotype Field Value Dynamic Actions Dynamic Actions: DPR DPR: Example
Example
Infotype field (Current Pnnnn- P0002-FAMST Pnnnn- P0002-FAMST
Value) <Field_Name> <Field_Name>
Infotype field (Old PSAVE- PSAVE-FAMST Pnnn_OLD- P0002_OLD-
Value) <Field_Name> <Field_Name> FAMST
Additional Field Qnnnn- Q0102-CREAT UInnn-<Field_Name> UI0102-CREAT
(Current Value) <Field_Name>
Additional Field (Old Not supported - UInnnn_OLD- UI0102_OLD-
Value) <Field_Name> <CREAT>
Access to General Fields
In the dynamic actions, the following fields from the following structures can be accessed:
Structure Description
T001P Personnel Area/Subarea
T503 Employee Group/Subgroup
PSPAR Transfer String for HR Infotype Dialog Modules
SY System Fields (for example SY-DATUM)
In the DPRs, a dedicated set of general fields is provided as illustrated in the table below:
Field Description
$MASSN Action recorded in IT0000
$MASSG Reason for action
$PROCESS Name of Roadmap Process (if running in process)
$FORM_SCENARIO Form scenario
$WERKS Personnel area
$PLANS Position
$VERSIONID Employee version ID
$MOLGA Employee MOLGA
$APPL_TYPE SINGLE for Master Data Application
SEQUENCE for Roadmap
$SEQUENCE_BEGDA Maintenance begin date
$SEQUENCE_ENDDA Maintenance end date
$OPERATION Operation performed on the infotype record
$SYSTEM_DATE System date
$USER_NAME User name
Example
Dynamic Actions:
T001P-WERKS = 'DE01'
DPR:
$WERKS = ‘DE01’
Access to General Infotype Fields
The following infotypes are available with the data existing at system date:
Infotype Fields Dynamic Action DPR
Actions P0000 $P0000
Organizational Assignment P0001 $P0001
Personal Data Not supported $P0002
Payroll Status P0003 $P0003
Example
Dynamic Actions: P0001-PLANS = ‘08154711’
Dynamic Processing Rules: $P0001-PLANS = ‘08154711’
Access to Variables Defined in Module Pool
In dynamic actions, variables defined in the module pool can be used. In DPRs, this is not supported.
Access with Offset/Length
In DPRs, a complete offset/length specification is required in the format …+offset (length).
Example
P0000-BEGDA+0(4)-> Year (the “+0” must not be omitted)
P0000-BEGDA+4(2)-> Month
P0000-BEGDA+6(*)-> Day (*indicates everything until the end of the string and must not be omitted)
Conditions
Instead of the single input field used in dynamic actions for conditions, conditions are defined using three
separate fields in DPRs.
Dynamic Actions
Indicator Variable Function Part
P P0002-FAMST = ‘1’
Dynamic Processing Rules
Field Condition Value
P0002-FAMST = ‘1’
In dynamic actions and in DPRs, conditions are linked by a logical AND (this is the default behavior for both
dynamic actions and DPRs). In dynamic actions, OR conditions are defined by adding /X at the end of all
conditions that are part of the OR Group as illustrated in the table below:
Indicator Variable Function Part
P P0013-SVA02 = '20'
P P0013-KVKZ1 = ‚5‘ /X
P P0013-KVKZ1 = ‚6‘ /X
In DPRs, you set the indicator Or Group for those conditions that should be linked with the succeeding
condition by OR (that is the indicator is not set for the last condition of the OR Group). See the table below
for an example:
Field Condition Value OR Group
P0013-SVA02 = ‘20’ -
P0013-KVKZ1 = ‘5’ X
P0013-KVKZ1 = ‘6’ -
Operations
In dynamic actions, everything for the operation definition is specified in one field; in DPRs, the operation
definition is split into separate fields.
Operation Definition in Dynamic Actions
Indicator Variable Function Part
I MOD, 0021,1,,(P0002-BEGDA),(P0002-ENDDA)
Operation Definition in DPRs
Operation Config ID Subtype Obj. Ident Start Date End Date
CHANGE IT0021 1 - P0002-BEGDA P0002-ENDDA
In DPRs, the operations Create, Change, and Delimit are supported, whereas in dynamic actions, the
operations supported are Create, Change, Delete.
Definition of Start Date and End Date
DPR
Start Date and End Date must be specified for the operations Create, and Change to identify the record of
interest. When the operation is Create, the Start Date and End Date must be blank. You define the default
values for the Start Date and End Date in the Default Values View.
Dynamic Actions
It is possible to define the Start Date and End Date even for the operation Create. In this case, the dates are
used for authorization checks and in addition as default values for the newly created record.
To execute the operation in the background without a UI, the process for dynamic actions is as follows:
Add /D at the end of the operation definition as illustrated in the table below:
Indicator Variable Function Part
I INS,0019,21 /D
In DPRs, you set the UI Display to the value Hidden as illustrated in the table below:
Operation Config ID Subtype Obj. Ident Start Date End Date UI Display
Create IT0019 21 - - - Hidden
In dynamic actions, users can always skip an infotype, whereas in DPRs, setting the Required indicator
prevents this from happening.
In DPRs in the field Info to User, you can display an additional text to the end user explaining why another
infotype has to be maintained. This is not possible in dynamic actions.
Default Values
In dynamic actions, everything for the default value definition is specified in one field, whereas for DPRs,
the value definition is split into separate fields as illustrated below:
DPR Default Values
Field Name Field Value
P0021-BEGDA P0002-BEGDA
Dynamic Actions Default Values
Indicator Variable Function Part
W P0021-BEGDA=P0002-BEGDA
Call Routines
In dynamic actions, call routines (Indicator F (ABAP Form Routines)) are used for the following use cases:
1. Calculation of values used in conditions, operations, or default values.
2. Execution of additional operations such as updating an additional database table.
3. Dynamically define the infotype operations to be executed as dynamic actions.
4. Call transaction/application for display purpose or data maintenance.
In DPRs, the use case 4 (these are call transactions with own UIs) is not currently supported; the first three
use cases are supported as follows:
5. Calculation method can be used in conditions, operations, default values.
6. Processing Class can be used as a specific operation type.
7. Returning class can be used as a specific operation type.
Calculation Method
In DPRs you have to define an ABAP-OO class that inherits from the
class CL_HRPAO_DY_BASE_CALC_METH, define method(s) with a returning parameter, and specify the
method call exactly where you need the calculated value as illustrated in the table below:
Field Condition Value
CL_HRPAO_DPR_READ_T51P1->GET_ASSIGNED_WAGE_TYPE() <> ‘ ‘
Calculation methods can directly access all context parameters (such as the current infotype record, old
infotype record, general fields, and so on); in addition, importing parameters can be provided. To this, a
parameter group has to be defined.
In dynamic actions, the calculated value is temporarily stored in the general structure RP50D, field FIELD1.
Infotype Indicator Variable Function Part
0014 F CALL_P0015(RPUDONU0)
0014 P RP50D-FIELD1 <> ‘ ‘
Processing Class
In DPRs, you define the ABAP-OO class so that it inherits from the
class CL_HRPAO_DY_BASE_ANY_OPERATION and implements the interface methods. For more
information, see the system documentation for the class CL_HRPAO_DY_BASE_ANY_OPERATION.
In dynamic actions, you made the following settings:
Infotype Indicator Variable Function Part
0001 F RUECKW_WECHSEL(MP001200)
In DPRs, the processing classes can directly access all the context parameters (such as the current infotype
record, the old infotype record, general fields, and so on). Only background processing can be provided and
no UI is involved. Certain statements such as COMMIT WORK are forbidden because the class has to take
part in the transactional context of the application.
DPR Processing Class
Operation Type Processing Class
Processed by class CL_HRPAO_DPR_UPDATE_T5D2M_DE
Returning Class
In DPRs, you define the ABAP-OO class so that it inherits from the
class CL_HRPAO_DY_BASE_GET_OPERATION and implements the interface methods. For more information,
see the system documentation for the class CL_HRPAO_DY_BASE_GET_OPERATION.
In dynamic actions, you made the following settings:
Infotype Indicator Variable Function Part
0082 F INSERT_0076(MP008200)
In dynamic processing rules, you make the following settings:
Operation Type Processing Class
Returned by class ZCL_INSERT_0076
In both dynamic actions and DPRs, using Customizing alone to define all the conditions and operations
required can be very time-consuming.
For example, to create the infotype Family Members (IT0021) as many times as the value of the
field Number of Children (IT0002) is increased, you need to define many conditions. In such cases,
implementing a returning class might be the easier approach but this requires coding skills. Please see the
system documentation available in the class CL_HRPAO_DPR_MAINTAIN_CHILDREN for more information.
Processing classes can directly access all context parameters (such as the current infotype record, the old
infotype record, general fields, and so on).
Setting Rules to Active/Inactive
In dynamic actions, the table T588Z is a Customizing table (with the delivery class C), and all dynamic
actions delivered by SAP are only available in client 000. Customers have to copy the dynamic actions they
want to use into the relevant clients.
In contrast to this, the DPRs delivered by SAP are automatically available in all clients at customer-side
(tables with the delivery class E are used); SAP decides individually for each rule, whether it is delivered
with the status Active or Inactive. Only active rules are relevant and executed at runtime. Customers should
not delete SAP rules because this would be a modification. Rather Customers should deactivate any DPRs
that they do not need in the Rule Manager as described in Maintaining Dynamic Processing Rules.

From <https://help.sap.com/viewer/c6c3ffd90792427a9fee1a19df5b0925/1909.001/en-
US/0221a3533039cd46e10000000a44538d.html>