Dynamic ACTIONS
Dynamic ACTIONS
Dynamic ACTIONS
[Hide TOC]
1 Dynamic Actions
o 1.1 A dynamic action has the following components
1.1.1 Infotype Number (INFTY)
1.1.2 Subtype (SUBTY)
1.1.3 Field Name (FIELDN)
1.1.4 Function (FC)
o 1.2 Dynamic actions are only applicable in maintenance operations
1.2.1 Examples
1.2.2 Sequence Number (NO)
1.2.3 Step (A)
1.2.4 P
1.2.4.1 Note
1.2.4.2 Examples
1.2.5 I:
1.2.5.1 Examples
1.2.6 W
1.2.6.1 Examples
1.2.7 F
1.2.8 F:
1.2.8.1 Example 1
1.2.8.2 Example 2
1.2.9 V
1.2.9.1 Examples
1.2.10 M:
1.2.10.1 Example
That program contains routines for calling dynamic action functionality. Each time you
press the save button on the maintenance screen of an infotype, the PAI (process after
input) section of the screen calls these routines. This is to check the table T588Z for
starting any dynamic action relevant to the current infotype.
The maintenance of dynamic actions is done via the view V_T588Z.
Specifies the infotype for which you want the dynamic action triggered.
Subtype (SUBTY)
Function (FC)
This controls for which types of processing (create, change and/or delete a data record) a
dynamic action should be carried out. The processing type is indicated by a two-digit
numeric value. These values can be added up; in other words, you can enter several
processing types for each infotype, subtype or field. A dynamic action can also be carried
out independent of the current processing type.
Examples
If you enter 06, an action is carried out if the specified infotype was created or changed.
If you enter 00, an action is carried out irrespective of whether the specified infotype was
created, changed or deleted.
You can enter values for specific infotype fields. Field names must be entered in full.
Literals and constants can serve as comparison values. These must be enclosed by
inverted commas. Variables can also be used.
The old value of a field can be used for comparison; the field name must be preceded by
PSAVE-.
If fields of other infotypes are used for comparison, these must be stored in the module
pool of the current infotype.
o = equal to,
o < less than,
o <= less than or equal to,
o > greater than
o >= greater than or equal to and
o <> not equal to.
Consecutive checks must be linked by a logical AND. Logical OR links must also be
indicated by a /X.
Note
Note that all checks with OR links must have a /X. If the result of the comparison
operation is not "true", then the following commands (I, F, W etc.) are skipped over until
a field is reached or a new comparison operation takes place.
Examples
I:
Enter the step, infotype, subtype, object ID, start and end dates of the record and an
indicator which defines whether the step is to be run in the background. The possible
actions are INS, COP, MOD, and DEL.
Use commas to separate selection criteria just like the separator in the matchcode. If an
entry is missing, the system inserts a comma.
Separate the indicator for suppressing dialog from other entries by a slash D (/D). A slash
S (/S) will also supress dialog.
Constants, such as those for subtypes, are not enclosed in inverted commas. Variable
entries are also permitted. Fields containing such values must be put in brackets.
Examples
.... I INS,19,01/D
.... I DEL,14,M559
Step: Delete Rec. Payments/Deds. record with subtype (wage type) M559.
Step: Create a Basic Pay record (0008) without subtype and object ID. The start and end
dates are the same as those in the current Planned Working Time record (0007); specify
these two fields only if they are filled because the dynamic action was triggered by this
infotype.
Set the defaults for the infotype, subtype, object ID, start and end dates using an I step
and not a W step.
Do not set defaults for Q fields of an infotype because the values for these fields are
derived from the corresponding P fields.
Examples
When a Family/Related Person record (0021) record with subtype 2 (child) is created, an
Additional Payments record (0015) with a default amount of 100.00 is created.
Call a routine
F:
Calls a FORM routine (subroutines in ABAP) during your action. The routine may reside
in or out the module pool MPNNNN00.
You can call internal (module pool) as well as external routines.If you call external
routines, type the program name in brackets after the routine name. Do not specify 'using'
parameters. When calling an external routine, all data must be declared in a common part.
You can use the fields of structure RP50D to return values from the routine. These are
not used in the standard system and can only be populated via the routine and then can be
used for defaults (W-Commands). This allows customer-specific routines to be
formulated with all the above steps.
Example 1
Module pool MP001600 contains the PROBATION routine. This routine uses the entries
in the fields P0016-PRBZT and P0016-PRBEH to determine the end of the probation
period which it stores in the field PRBEND.
The system creates a new 'Dates' record with the reminder date = PRBEND.
Example 2
The GET_DATE routine in program ZPUDYN01 calculates a date and enters this date in
the RP50D-DATE1 field via "TABLES RP50D" in ZPUDYN01. This date can be user-
defined in GET_DATE: if necessary, user-defined infotypes can be read afterwards.
Lets you treat collectively a number of fields for which you want to define a common
dynamic action Here, you can combine fields to groups. The variable function part
contains the value in the field which follows the "field" column. Steps which are
specified only for the following field are also triggered for each of the other fields.
Examples
Infotype 0019, subtype 01 is deleted in the background when the field PRBZT or PRBZH
in infotype 0016 is changed or created (function code 06).
M:
Enter the name of the feature which defines the characteristics of the mail.
Example
A mail is sent when the field SACHP is changed. The characteristics of the mail are
defined in feature M0001. In the standard system, feature M0001 is provided as a model.
The documentation on feature M0001 explains how to define the characteristics of a mail.