Ansicht
Dokumentation
HRAS_HRASR00FSCN - Create Form Scenario
TXBHW - Original Tax Base Amount in Local Currency General Data in Customer MasterThis documentation is copyright by SAP AG.
In this IMG activity, you perform the following work steps:
- Create form scenario
- Create version
- Define form fields
- Define input helps
- Assign back-end services
- Assign form fields to back-end services
- Define attachment types
- Define scenario steps
- Specify use of form fields in scenario steps
- Define UI attributes
- Specify attributes of attachment types
- Specify additional information (links)
- Define rules
For detailed information about the individual steps, see the relevant sections.
A form scenario is the basis for a form-based process. In the form scenario, you define the basic set of form fields that can be used, configure the default values and value helps, and specify how the backend system is used to check the form data and make it persistent. In addition, you specify how attachments and link lists are used to provide additional information. The ISR scenario, on the other hand, is used to include the interactive form and create the layout. There is always a one-to-one relationship between the form scenario and the ISR scenario. You must define the relationship in the IMG activity Link ISR Scenario with Form Scenario.
- Choose New Entries.
- Enter the form scenario.
- Enter a name.
- Save your entries.
Form scenarios are version dependent, which means that there is at least one version of each form scenario. Versions are linked with processes. Since processes can vary, you must also be able to adjust the associated scenarios. To be able to provide different forms for process variants, you create versions.
You can still process and change an existing version at a later point in time. Once a version has been used to execute a process, you should not make any more changes to this version; instead, you should create a new version.
The form scenario and the (linked) ISR scenario are both version dependent. They must always have exactly the same version numbers. Note that the version number of the ISR scenario is generated and cannot be entered manually. When you create a new version in the form scenario, you therefore have to use the version number generated in the ISR scenario.
If you have already made extensive Customizing settings for the form scenario and want to create a new version based on the settings, you should use the IMG activity Manage Form Scenario.
For the "Birth of a Child" process, you create a corresponding form scenario and ISR scenario named "Birth of a Child", each with the version 0. The form scenario version contains a form in which all relevant data regarding the birth of the child can be entered. Once the process has been used in a production system for some time, the form has to be changed to incorporate an additional field. In this case, you use the IMG activity Manage Form Scenarios to first create a new version of the form scenario and ISR scenario on the basis of the existing version. You then add the new field to the newly created version. You have to modify the process so that it uses the new version of the form scenario in the future.
In this step, you create all the fields that are relevant for the form scenario. This includes both the fields that appear on the form for the input or output of data and the fields that do not appear on the user interface and are used solely to transport data. If you no longer require a form field, you must delete it. Removing it from the form is not enough, since it will still be processed in the background.
Some form fields are mandatory and must always be defined. PERNR (personnel number) and EFFECTIVE_DATE (effective date) are examples of these mandatory form fields. Depending on the backend service used, there can be other mandatory form fields. For an overview of the mandatory fields for the back-end services provided in the standard system, "Personnel Administration Infotypes" and "Time Management Infotypes", see the relevant IMG activities:
You must specify the type of each form field using a data element. You can do this in one of two ways:
- Manually by entering a data element explicitly
- Automatically by linking the form field to a back-end service field
Form fields are generally linked to the fields of one or more back-end services (see the step "Assign form fields to back-end services"). In this way, the data saved in the form field is forwarded to the back-end service where it can be processed. For form fields that are not linked to a field of a back-end service, you have to enter the data element manually.
Form fields can be filled with default values. You specify for each form field whether it is to have a default value (default value type). For fields with default values, you can decide whether the default value is defined manually or determined using a back-end service. In this case, you enter the back-end service sequence number under which you have defined the back-end service in the form scenario.
For each form field, you enter whether or not there is to be a value help (value help type). You can either enter the possible values of the value help manually (see next section), or they can be determined using one or more back-end services.
You can also specify whether a collision check is to be performed for a form field.
On the user interface, the form is defined by the usage and positioning of controls (input fields, dropdown lists, radio buttons, and so on). The controls must be linked to the form fields so that the data entered in the user interface is stored in the form fields. For more information, see the online documentation for HR Administrative Services and choose Editing Interactive Forms in Adobe LiveCycle Designer.
Form fields can also be used as parameters in rules. Rules can be used in the definition of form scenarios to control whether a back-end service is accessed or whether a specific operation of this service is to be accessed.
Activities
- Choose Form Fields in the dialog structure.
- Choose New Entries.
- Create the mandatory fields PERNR and EFFECTIVE_DATE.
- Define all other form fields that you require for the form scenario.
- Save your entries.
In this step, you can define a manual value help for a field. Value helps can currently be displayed only as a dropdown list box. The dropdown list box contains all values that are valid for the input field, whereby the input can only be selected from this list of values. Each entry in the value help consists of a sequence number, the field value, and a field value text. The dropdown list box displays the text for the field value. When the entry is selected, however, the corresponding field value is entered in the field.
If you want to define a manual value help for a form field, you must set Manual Value Help as the value help type for this form field in the Form Fields view.
Only value helps as dropdown list boxes are supported.
Activities
- Choose Input Help in the dialog structure.
- Choose New Entries.
- Enter a number.
- Enter the field value that is to be available in the input help for the form field.
- Enter a text for the field value.
- Repeat the steps for all other field values you want to be displayed in the input help. Enter a sequence number for each field value.
- Save your entries.
Back-end services provide the business logic that can be used in the form scenarios.
In this step, you specify which back-end services are used. To have data transferred to the back-end services, you link the form fields to the backend services. Back-end services are included using sequence numbers that identify them uniquely in the form scenario. You require the sequence number when defining default values and value helps. The number also specifies the sequential order in which the services are called at runtime.
Back-end services can also be assigned a rule. In this case, the service is called only if the evaluation of the rule produces the value "true".
Note
By using sequence numbers when assigning the back-end services, you have the option of using the same service several times in the form scenario. You assign different sequence numbers to the service for this purpose. You should only make use of this option if it is absolutely necessary to split up the processing of a back-end service into several blocks (for example, because there are dependencies between the individual blocks).
The following back-end services are supported in the standard system:
- SAP_PA Personnel Administration infotypes
- SAP_PT Time Management infotypes
- Special Generic Services that are used in the sample processes/form scenarios provided.
- For more information, see the IMG activity Process Form Scenario for Generic Services.
The following services are used for a form scenario:
The standard service SAP_PA, the standard service SAP_PT, and a Generic Service S_MATLEAVE that is required in a Maternity Leave process for determining the time limits. The Customizing settings for this are as follows:
| No. | Service | Service |
|---|---|---|
| 1000 | SAP_PA | Personnel Administration Infotypes |
| 2000 | SAP_PT | Time Management Infotypes |
| 3000 | S_MATLEAVE | Maternity Leave (Determine absence types) |
Activities
- Choose Services in the dialog structure.
- Choose New Entries.
- Enter all required services with a sequence number.
- Save your entries.
In this step, you assign the form fields to the back-end services. A back-end service is called only if at least one field is assigned to it. Only the values of the fields that are assigned to the back-end service are transferred to it. You define how the form fields are processed by the back-end service by configuring the back-end services in the relevant IMG activities:
Activities
- Choose Services in the dialog structure.
- The Change Services: Overview screen appears.
- Select a service.
- Choose Form Fields of Service in the dialog structure.
- Choose New Entries.
- Enter all of the form fields that you want to assign to the back-end service.
- Save your entries.
In this step, you specify which attachment types are to be used in the form scenario. Possible attachment types can be birth certificates, work contracts, or certificates, for example, that the user must add in a process to document the entries in the form.
In the IMG activity Define Attachment Types, you have specified all attachment types that can be generally used.
Activities
Enter the attachment types supported in the form scenario. Then define in which steps you want the attachments to be available and with which authorization (see the step "Specify attributes of attachment types").
You define scenario steps if the form configuration is not to be processed as a whole at the runtime of the process, but rather when different parts of the form configuration are relevant depending on the process step involved.
A form scenario can consist of several steps; however, at least one step must exist. You assign to scenario steps the form fields that are relevant for this step (see the step "Specify Use of Form Fields in Scenario Steps"). A scenario step therefore represents a subset of the defined form fields. As the form fields are assigned to back-end services, a scenario step also represents a subset of the fields and operations defined for the back-end services.
A scenario step is assigned to a workflow step during the process definition. At runtime, only the back-end services and operations belonging to the scenario step are executed.
The attachments and links to additional information are step-dependent, as are the form fields. This means that you have to define for each scenario step which attachments and which links are to be available.
You should use meaningful names for the scenario steps as they are used in the workflow to create the text of the work item and appear under this name in the universal worklist (UWL) of the next agent.
The Transfer form scenario includes the following steps:
- "Request"
- The sending manager requests the transfer of an employee assigned to him or her.
- "Accept/Process"
- The receiving manager receives the transfer request and processes it.
- "Approve"
- The supervisor of the sending manager approves the employee transfer.
- "Complete Processing"
- The HR administrator completes the processing of the transfer, adding any missing data as required.
A separate scenario step containing only the form fields relevant for the step is defined for each of the above steps. For example, because it may be the HR administrator who enters the details about the transfer in the final process step, the fields are assigned only to this step. This prevents checks being run in previous steps for data that has not yet been entered.
Activities
- Choose Steps in the dialog structure.
- Choose New Entries.
- Enter all required form scenario steps and the relevant names.
- Save your entries.
In this work step, you specify which form fields are relevant for the scenario steps. If you do not explicitly assign a form field to a step, then all form fields are understood to be assigned and therefore relevant for the step.
The assignment of form fields is relevant at runtime, but is also enhanced with the following mechanism:
During the processing of the process, it is internally documented for each step which form fields were used in this step. Each form field that was used in a step is then automatically used in all subsequent steps as well. This additive approach means that the following fields are relevant in a scenario step i:
- All form fields that are assigned to the scenario step i in the Customizing of the form scenario
- All form fields that were relevant at runtime in the previous scenario step i-1
Note
The definition of scenario steps or the specified assignment of form fields to steps does not have an automatic effect on the user interface of the form. This means that a form field that was not assigned to a step is not automatically hidden from view in the form. This kind of step-dependent modification of the user interface must be programmed individually.
Activities
- Select a step.
- Choose Use of Form Fields in the dialog structure.
- Choose New Entries.
- Enter the fields that are relevant for the step.
- Save your entries.
In this work step you define the properties of a form field for the user interface.
Meaning that depending on the form scenario, you determine the field attributes for each field that you use in the form. You can choose between the following field attributes:
- Visible, Editable, Not Mandatory
- Not Visible
- Not Editable
- Mandatory Field
The field properties only come into effect when the field attributes are evaluated by scripting in the interactive form.
For detailed information about processing forms and about scripting, see SAP Library and choose HR Administrative Services -> HCM Processes and Forms -> ISR Scenario-> ISR Scenario Configuration -> Creating and Editing an Interactive Form.
Standard Settings
If you have not defined any field properties for a form field of a scenario step, or if you use an existing form scenario for which you could not define any field attributes for the form fields, the system uses the following field properties:
- If you have assigned a form field to a form scenario step, but have not defined any attributes for this field, the Visible, Editable, Not Mandatory attribute is applied to this field.
- If you have not assigned a form field to a form scenario step, and have not used the form field in previous scenario steps, the Not Visible attribute is applied to this field. This allows you to automatically hide form fields that are not relevant for a particular scenario step.
- If you have not assigned a form field to a form scenario step, but have used the form field in a previous scenario step, the field is automatically assigned to this form scenario step. The Not Editable attribute is applied to this field.
Activities
For each scenario step, define the field properties for the form fields.
You have to specify the attributes of each attachment type for each scenario step.
If you select the Not Required setting, it is possible - but not necessary - to add an attachment.
If you select the Required with Warning setting, the system outputs a warning message if there are no attachments.
If you select the Required with Error setting, the system outputs an error message if there are no attachments. In this case, processing of the step cannot be completed.
You can also decide for each attachment type whether the user can make changes to the attachment or only display it.
Activities
- Choose Attributes of Attachment Types in the dialog structure.
- Choose New Entries.
- Enter the attachment types and their properties.
- Save your entries.
In this step, you define which links to additional information are used in which scenario step.
You have defined the links that can be generally used in the IMG activity Define Links for Additional Information.
Activities
- Choose Additional Information in the dialog structure.
- Choose New Entries.
- Enter the links you want to appear in the selected scenario step.
- Save your entries.
Rules can be used in the definition of a form scenario to control whether a back-end service is accessed or whether a specific operation of this service is to be accessed.
Rules are based on form fields and return "true" or "false" as a result at runtime depending on the input values. The back-end service or operation is called only if the result of the rule is "true" at runtime.
To define a rule, a formula editor is provided. The following parameters can be used in a rule:
- All fields of a form scenario, except for fields that contain more than one value at runtime (for example, repeat fields that are supported by the SAP_PA service)
- System fields
- Constants
- Standard features
- Logical operations (AND, OR, and so on)
Note
If you assign the rule to an operation of a back-end service, then all form fields that you use in the rule must also be assigned to the back-end service.
You can only use rules that were defined as so-called Boolean rules, that is, the result of a rule must be either "true" or "false" in each case. Other rules are not supported.
The Entitled to Company Car rule could be defined as follows:
("Annual sales of employee" > 50000) OR ("Hiring date" <= 01/01/2000)
Activities
- Choose Rules in the dialog structure.
- Choose New Entries.
- Enter a name and a description for the rule.
- Select the rule and choose Formula.
- The formula editor appears.
- Define the rule based on the form fields.
- To access the help for the formula editor, choose Formula -> Information.
- Exit the formula editor.
- A dialog box appears. Decide whether to save or discard the formula.
- Save your entries.
Note
If you have created a form field with the name FORM_SCENARIO_STAGE (and data element ASR_FORM_SCENARIO_STAGE), it is automatically filled at runtime with the name of the current scenario step. Using this field in a rule enables you to define the rule for specific steps.
ROGBILLS - Synchronize billing plans General Material Data
This documentation is copyright by SAP AG.
Length: 27334 Date: 20240523 Time: 215416 sap01-206 ( 397 ms )
