Table of Contents

REPORTING LINE CHANGE FORM PART1.......................................................3

PERSONNEL CHANGE REQUEST (PCR): .....................................................................4
HCM PROCESS AND FORMS (HCM P&F):.................................................................4
HCM PROCESS & FORM FRAMEWORK: .....................................................................4
HCM P&F CONFIGURATION.................................................................................6
DESIGN TIME ENVIRONMENT.............................................................................7
Purpose..................................................................................................................8
Prerequisites..........................................................................................................8
Process Flow..........................................................................................................9
Result....................................................................................................................14
TECHNICAL DETAILS OF TRANSFER..............................................................15
PROCESS ORG_CHANGE.......................................................................................15
Workflow..............................................................................................................15
Role Assignment...................................................................................................16
FORM SCENARIO ATTACHED TO THE PROCESS ........................................................16
Fields:..................................................................................................................16
Form:...................................................................................................................17
Fields for scenario step SENDING_MANAGER.................................................17
Operations for scenario step SENDING_MANAGER.........................................18
Back End Services................................................................................................19
Attachments..........................................................................................................19
Rules.....................................................................................................................19
Message Mapping................................................................................................19
DESIGN.......................................................................................................................20
THINGS TO CONSIDER DURING THE DESIGN/PLANNING PHASE:................................20
ROLES........................................................................................................................21
PROCESS DESIGNER .................................................................................................21
FORM UI DEVELOPER...............................................................................................21
ABAP DEVELOPER (OPTIONAL)...............................................................................21
WORKFLOW DEVELOPER..........................................................................................21
PORTAL ADMINISTRATOR.........................................................................................21
REPORTING LINE CHANGE FORM PART2.....................................................22
SEQUENCE TO BUILDING HCM P&F................................................................23
BUILDING FROM SCRATCH:.......................................................................................23
COPYING FROM AN EXISTING SCENARIO...................................................................23
STEP BY STEP..........................................................................................................24
STEP 1: PLANNING....................................................................................................24
Scenario differences:...........................................................................................24
Form differences:.................................................................................................24
Workflow differences:..........................................................................................25
STEP 2: COPY FORM SCENARIO SOC1 TO ZRLC.....................................................26
1

STEP 3: REVIEW ZRLC.............................................................................................27

STEP 4: DEFINE A GENERIC SERVICE.......................................................................29
Step 4A: Define Generic Service for Form Scenario...........................................31
Step 4B: BADI: Implement Generic Services......................................................31
Coding..................................................................................................................33
method IF_HRASR00GEN_SERVICE~GET_OPERATIONS..............................33
Method IF_HRASR00GEN_SERVICE~GET_FIELD_INFO..............................34
Method IF_HRASR00GEN_SERVICE~DO_OPERATIONS...............................35
Generic Service Notes (from SAP Interface Documentation)..............................35
PART 2B.....................................................................................................................37
STEP 4.2: DEFINE A GENERIC SERVICE (MANAGERS POSITION).............................37
Step 4.2.A: Define Generic Service for Form Scenario.......................................38
Step 4.2.B: BADI: Implement Generic Services..................................................38
Step 4.2.C Coding................................................................................................41
Method GET_MGRS_POSITIONS......................................................................42
PART 3........................................................................................................................43
Scenario Steps......................................................................................................44
Rules.....................................................................................................................44
Step 5A: Assign generic services ZHR_USER_NAME........................................45
Step 5B: Assign generic services ZHR_MGRS_POSITIONS..............................46
Assign the field properties...................................................................................47
STEP 6: DEFINE HCM PROCESS..............................................................................50
STEP 7 UNIT TESTING GENERIC SERVICES...............................................................53
STEP OPTIONAL. CREATE START APPLICATION........................................................55
PART 4........................................................................................................................57
HR Admin Library UI Controls...........................................................................57

Reporting Line Change Form

Part1
This document is aimed for anyone new to HCM Process and Forms (P&F).
This document will cover the following:
1) Difference between PCR and HCM P&F
2) Design time environment and configuration for HCM P&F
3) Walkthrough of the International Transfer Process delivered as a sample
scenario from SAP
4) Walkthrough of the technical details of the International Transfer Process
5) Tips and pointers for HCM P&F development designs
6) Different skill set and roles required by developers involved
It has been identified that the requirement for Reporting Line Change form is quite
similar to the standard HCM P&F sample scenario for International Transfer.
Therefore we need to spend some time understanding the International Transfer
scenario delivered as a sample from SAP.
For more details, please see
SAP Help
http://help.sap.com/erp2005_ehp_03/helpdata/en/43/1d639b3fce3566e10000000a114
66f/frameset.htm
SAP Market Place
http://service.sap.com/erp-hcm
Go to navigation tree (on the left):
SAP ERP > SAP ERP Human Capital Management > Workfore Process Management
> HCM Processes and Forms > Media Library

PCR and HCM P&F Compared

It is important to understand the difference between PCR and HCM P&F.

Personnel Change Request (PCR):

SAPs Personnel Change Request (PCR) is a workset thats part of Manager SelfService (MSS) in SAP NetWeaver Portal 5.0-6.0. The workset is a group of web
applications built using the ISR framework.

HCM Process and Forms (HCM P&F):

"As customer needs are evolving beyond the classical area of operational process
execution to the centralized delivery of services within a shared services centre,
customers need a very flexible framework that can adapt to their particular HCM
processes.
HCM is a new framework delivered by SAP as a part of ECC 6.0. It has a lot more
functionality that PCR or any previous ISR frameworks. It focuses on business
modelling aspect, where development is significantly reduced.

HCM Process & Form Framework:

An extension to the ISR Framework, but with lot more functionality such as:
1. Support for Adobe Interactive Forms
2. Display of involved roles/users
3. Role-specific links
4. Role-specific attachment handling
5. Saving as draft
6. Withdrawal of a process
7. Automatic back-end support:
8. Save to back end in every step
9. Error-tolerant step and message customizing
10. Automatic update of digital personnel files

It is important to know that:

1. The ISR/PCR BADIs are no longer used in HCM. (This statment is actually
not true, because deep down technically it is still used but invisible to the user
and developer, so well can consider it not being used)
2. SAP delivered PCR with a few sample workflow templates (e.g.
WS50000041) that are based on the notification object. HCM no longer uses
the notification object, but rather based on the class object
CL_HRASR00_WF_PROCESS_OBJECT. A brand new set of workflow
templates, task groups are provided.
3. Design time is completely different.
HCM uses Adobe forms where as PCR allows the user to use many different types of
user interfaces, such as JSP, BSP, WebDynpro, ITS templates etc.

HCM P&F Configuration

Configuration can be accessed in the IMG under Personnel Management > HR
Administrative Services > Configuration of Forms/Process.

Design Time Environment

Transaction: HRASR_DT
Or via IMG

Transfer (International)
(Reference to Standard SAP Help Document)
This is a standard SAP sample scenario. As we are planning to copy this scenario, we
must first understand what it does.

Purpose
The Transfer process supports an employee's organizational reassignment to a new
position outside of the current manager's area of responsibility. After the process is
run, the employee's master data is up to date. The business roles of Sending
Manager, Receiving Manager, Supervisor of Sending Manager, and HR
Administrator are actively involved in performing the process. The affected
employee is kept informed about the process by e-mail.
Using the Transfer process accelerates and optimizes the transfer procedure, since
the system integration of all roles guarantees that work items are forwarded as soon as
possible, and that all parties are informed at all times.

Prerequisites
To be able to use this sample process for test purposes, you must have performed the
Customizing activities for HR Administrative Services as described in
Configuration of Forms/Processes Sample Processes for HCM Processes
and Forms.
Technical Objects for Implementing and Executing the Process
Object Type

ID

Name

Process

ORG_CHANGE

Transfer

Workflow Template

WS17900427

Transfer

ISR Scenario

SOC1

Transfer

Interface

ISR_IF_SOC1

Transfer

Form Scenario

SOC1

Transfer

Form

ISR_HRASR_SOC1

Transfer

Scenario Steps

SENDING_MANAGER
RECEIVING_MANAGER
APPROVE
HR_ADMIN

Request
Accept/process
Approve
Complete processing

Attachment Types

SFREEATTM

General attachments

Standard Service

SAP_PA

Personnel Administration infotypes

Generic Services

S_MGRS_POSITIONS

Positions reporting to manager

S_USER_NAME

Functions for system user names

Back-End Services

Process Flow

...

1. Sending manager initiates transfer

The manager, from whose area the employee is to be transferred, initiates the Transfer
process by selecting the relevant employee and the Transfer process. The manager
then completes the appropriate form. In the form, the manager enters the date of the
transfer, the receiving manager's system user name, and the reason for the transfer.
After entering and checking the data, the manager sends the request.

A. Manager logs into the portal. Manager clicks on Manager Self-Service (this is the
new MSS BP 1.3.1) > Team > HCM Processes and Forms > Start Process

B. The HCM start application is launched in the new window. The manager chooses an
employee reporting to him that he wishes to transfer away.

C. The manager then chooses the Transfer form. These are the process scenarios
configured for the manager role HRASRB. (more on this later)

10

D. Now the manager fills in the form. He inserts the username of the receiving
manager, and the transfer reason.

E. Clicking on the Derive Data Button triggers a call back to the backend
system

11

The name of the receiving manager is now populated.

F. If an invalid username is entered, an error is returned.

G. Correct this back to MSSUSER02.

Click on Check and Send, then click on Send, and the process has started.

2. Receiving manager accepts the request or requests for it to be revised

The transfer request appears in the universal worklist (UWL) of the receiving manager.
On accessing the work item, the manager receives the form filled out by the sending
manager in step 1. If all data is correct, the receiving manager enters the new position
in the form and sends it on. If the receiving manager wants the sending manager to
revise or change the form, he or she chooses Back to Author. The author (the sending
manager) returns the form to the receiving manager after revising it.

12

A. The receiving manager logs into the portal. He clicks on MSS > Work Overview and
the UWL is visible. The manager then clicks on Tasks, and hell see the work item in
the list.

B. Clicking on it opens the form in a new window. The information filled in by the
sending manager is still visible.

C. The receiving manager chooses a new position:

13

The list of new position is populated by the backend service S_MGRS_POSITION

(more on this later)
D. The receiving manager now submits the form.

3. Supervisor of sending manager processes the request

The request for transfer appears in the universal worklist of the receiving manager's
supervisor. The supervisor can select the following:
a. Request Revision - In this case, the form is sent back to the requester.
b. Approve Transfer - In this case, the form is sent on to the HR Administrator
(see step 4).
c. Reject Transfer - In this case, the process is complete, therefore step 4 is
not executed.
4. HR Administrator completes data
The transfer request appears in the HR Administrator's universal worklist. The
administrator adds data about the employee's organizational assignment.
5. End of process
After the HR Administrator has sent the form, the system transfers the data from the
form to the master data. If you are using the Digital Personnel File (DPF) and have
made the relevant Customizing settings, the system stores the form in the employee's
DPF.

Result
The process has the following results:

Transfer Carried Out: The employee's master data has been updated according to the
entries on the form.
Transfer Rejected: No changes have been made to the employee's master data.

14

Technical Details of Transfer

Each HCM P&F must have the following building blocks:
1) Process
2) Form Scenario
3) Form
4) Backend Services
5) Workflow template
6) ISR Scenario

Process ORG_CHANGE

Multiple versions can be defined for a process. You can define different start and end
dates for different versions, and they can automatically be active during the period.
Permit Parallel Run > should be activated in development/testing environment. This
will allow the same process to be triggered many times.
You can define process group and group different scenarios together. You can attach
this process to the process group defined.

Workflow
Link the workflow to the process.

15

Role Assignment
Who can start the process?

Form Scenario attached to the Process

Form SOC1
Fields:
These are all the fields to be interacted by the scenario, and to be edited or display
information in the form.
Input Help can be defined from backend services or manual. You can enter a manual
list in here.
Default values can also be entered in here, or in reference to a backend services.
Data binding are like calling functions. The value of this field is passed to the input of
the backend service, or the reverse.

16

Form:
The form attached to the form scenario.
Clicking on the icons can preview / change / display the form.
Ensure this is Active.

Fields for scenario step SENDING_MANAGER

This is where we define what should happen in each scenario.
Click on the Fields column in the scenario step line.
You can restrict the view, by hiding sections, hiding columns, hiding fields, editable,
mandatory, read-only etc.
You can also make the field properties scenario specific.

17

Operations for scenario step SENDING_MANAGER

This is where you define when the backend services are triggered. It will only be
triggered if the rule(s) attached to it is satisfied.

18

Back End Services

Attachments
Define if attachments are allowed and what attachment types are allowed.

Rules
You can define the rules. These are just Boolean conditions. They are attached to the
operations mentioned above.

Message Mapping
Show or hide messages.

19

Design
When building HCM Process and Forms, the planning process is very important.
HCM P&F development is indeed quite complex. Everyone involved with
configuring/developing the process and forms must have good understanding with the
entire bespoke scenario. It is difficult to isolate the development components as they
are tightly coupled.
For example:
It would be difficult for the workflow developer to build the workflow without
knowing how the form scenario was defined. Everything is controlled from workflow.
They need to know how the scenarios steps are defined, what functionality the user
can do, such as review, edit, reject etc.
It would be difficult for the form developer to build the form without understanding
the form scenario and scenario steps involved, as they have to be aware of who will
be using the form, when fields are switched on or off. This will impact layout of the
form.
Finally, the person responsible for the portal configuration must know who will be
doing what before he can decide what roles/iViews to assign. Fortunately the portal
administrator will only be required during the initial configuration.

Things to consider during the design/planning phase:

Define all the fields that are going to be variable to the scenario. If a field is to
be edited by a user, it is best to create two separate fields, one <VARIABLE>
and another <VARIABLE>_NEW in order to distinguish between the two.

Define the number of users involved with this scenario. In the sample
scenario, we have (1) original manager (2) receiving manager (3) approval
manager (4) HR Admin, a total of 4 users involved in the whole process. As
such we have to define 4 different scenarios.

Who can edit and see what? Should the fields be automatically populated? Etc.

Understand the backend services available and delivered by SAP. If they are
not adequate for the bespoke scenario, then we have to define generic services
to meet the requirement.

Workflow templates. Are there standard scenarios we can copy from? Do we

require withdrawal? Revision process? Attachment functionalities?

20

Is one single form adequate for the whole scenario?

Roles
Process Designer
This role is normally by functional consultants who understand the business
requirements. They should be able to picture and design how the overall process
should work, both from a system perspective and from an end-user perspective.
This role requires good understanding of HCM P&F, with a bit of ABAP (preferable
but not a must), good workflow understanding, and portal understanding to put this
together. Good functional knowledge is assumed.
They should have a good understanding of the backend generic services delivered
by SAP.
With the assistance of a developer, they should be able to define the form scenario
and process scenario in the design time.

Form UI Developer
This role is responsible for building the actual form. They must have good
understanding of the form scenario, and the users who will be using this form.
The forms are built using the Adobe Life Cycle Designer.

ABAP Developer (optional)

An ABAP developer might be required to implement the BADI to build the generic
services. This is discussed in the next Part.

Workflow Developer
This is probably one of the most important roles. Workflow controls the entire
process, what happens behind the background, who the form should go to next, what
functionality the next user can get, etc etc. You can consider this as the brains of the
process.
This role will be responsible for building the actual workflow. Once again they must
have good understanding of the form scenario, how the overall business process
should be modelled, and who will be interacting with the form.

Portal Administrator
This role is responsible for configuring the portal for end user to access the forms.
They also need to know who needs to do what. There are three main streamlines of
users: employee, managers, HR administrators. They need to be aware of how to
configure the start process iView to restrict the process group or the initiator role.

21

They also need to have good understanding of Universal worklist configuration and
administration.

Reporting Line Change Form

Part2
Part 1 covered basic introduction to HCM P&F, brief walkthrough of design time and
configuration, and going through the standard SAP sample scenario for International
Transfer.
We are now ready to start developing the HCM P&F for Reporting Line Change.
In part 2, we are going to cover the following topics:
1. Sequence to building HCM P&F
2. Planning -- Analyse the difference between the TWUL scenario and the SAP
Transfer scenario
3. Copy form scenario
4. Defining Generic Services

22

Sequence to building HCM P&F

The design time (transaction HRASR_DT) is the main tool in building HCM P&F. In
theory you should be able to do most things in the design time.

Building from scratch:

After analysing the business scenario, you cannot locate a sample SAP scenario that
you can reference. In this case youll have to build a scenario from scratch.
1) Form scenario Process designer (normally the functional consultant), with
the help of a developer, should carry out this step. This will also help you
generate the ISR scenario and Form so there is no need to manually create
them You will define the fields used by this form, either via the use of
backend services, or by the manually input. The scenario steps are also
defined, along with other attributes of a form scenario.
2) Develop Generic Services (if necessary)
3) Revise the form scenario (developer with the help of the functional consultant)
4) Develop the form. After step 1, the form and form interface would be
generated automatically. The form developer will need developer the form and
activate it. (SAPGui plugin Adobe LifeCycle is a pre-requisite for the
developers machine)
5) Define Process Scenario
6) Portal configuration (if necessary)
7) Test the forms/generic services
8) Workflow Template by workflow developer
9) Test the whole scenario

Copying from an existing scenario

1) Copy the form scenario this will copy everything, including the form, form
interface, ISR scenario. Process designer (normally the functional consultant),
with the help of a developer, should carry out this step. Note that during this
process it will prompt for workbench transport request as well as customizing
request.
2) Develop Generic Services (if necessary)
3) Revise the form scenario (developer with the help of the functional consultant)
4) Edit Form. After step 1, the form and form interface would be copied and
generated automatically. The form developer will make changes to the form
and activate it.
5) Define Process Scenario
6) Portal configuration (if necessary)
7) Test the forms/generic services
8) Workflow Template by workflow developer
9) Test the whole scenario

23

Step by Step
Step 1: Planning
As mentioned before, planning is one of the most important aspects of HCM P&F
development.
First we examine the difference between the standard Transfer scenario and TWUL
Reporting Line Change scenario.

Scenario differences:
Forms are slightly different, but almost identical.
There is no need for process approval by manager of sending manager.
There is no need for automatic update of infotypes as a result of the process.
The form is sent to the HR Administrator for review and will call transaction PA40
with parameters.

Form differences:
Standard SAP scenario:
Process scenario: ORG_CHANGE
Form scenario: SOC1
ISR Scenario: SOC1
Form: ISR_HRASR_SOC1
The forms are almost identical, with some cosmetic changes involved.
Cosmetic changes involves:
Renaming texts
Hiding/Deleting texts
Hiding fields
Replacing logo
Replace text in the button
Removing HR Admin section
The main change I see is
1) Input help required for locating the receiving managers username
2) Ensuring the receiving manager is a chief position
3) There is no need for automatic update of infotypes as a result of the process.
Well be requiring a new generic service for the managers username search help.
Remove the SAP_PA generic services for some of the fields.
Remove the scenario step APPROVE
24

Workflow differences:
TWUL Scenario
Line Manager
completes
form via MSS

No

The form is sent

via workflow to
the Receiving
Manager

Are there any

suitable positions?

Yes

The form is sent

via workflow to
HR Admin for
processing

Workflow: WS17900427
TWUL scenario is a lot simpler compared to that delivered by the SAP sample
scenario. (See workflow template WS17900427)
Changes:
There is no need for manager of sending manager to approve the process.
There is no need for automatic update of infotypes as a result of the process.
The form is sent to the HR Administrator for review and will call transaction PA40
with parameters.
We require the following scenario steps
1) Sending Manager
1. Sending manager will pick the employee to transfer (same)
2. Sending manager can fill in form for the transfer dates, receiving
managers username or name. (different)
2) Receiving Manager (identical to the standard scenario)
3. Receiving manager will action on the item in UWL. (same)
4. Receiving manager can pick the position to move the employee into.
(same)
5. The receiving manager can reject the request. (same)
3) HR Administrator
6. HR Administrator gets the work item in the UWL. (same)
7. He can view the form, or click on a action which takes them to PA40
with the relevant information (different)

25

Step 2: Copy Form Scenario SOC1 to ZRLC

Reason

Now we have established that the TWUL scenario is very similar to the standard
SOC1 scenario, we have to copy SOC1 into our bespoke scenario before we can start
editing.
A form scenario is required for every HCM P&F.
Form scenario defines the fields involve, as well as different scenario this form can be
used. In maintaining the properties of this form, the form behaviour can be dictated
for example, what fields are enabled/disabled, which fields are mandatory, which
fields are visible etc. We can also dictate the default values for some of these fields.
Form scenario is the backbone to the whole process.
Person Responsible

The process designer should carry out this step, with the help of developers if
necessary.
Details

26

Remember to save the form scenario! This will create a customizing request.

Step 3: Review ZRLC

Reason

This is a follow-on step to Step 2 to ensure step 2 is carried out correctly.

It helps you to understand how powerful the copy function does, and making sure that
everything we wanted is copied appropriately.
Person Responsible

The process designer should carry out this step, with the help of developers if
necessary.

Details

You should find everything is copied across from scenario SOC1:

ISR Scenario ZRLC created (check it in QISRSCENARIO). It should be
defined as a HCM form automatically.
Version 0 is created in the form
All fields and configuration of the fields are copied across
27

The form Z_ISR_HRASR_ZRLC is created and activated. (This form is

actually a copy of ISR_HRASR_SOC1) The interface of the form is also
created.
Scenario steps
Backend Services
All attributes

Now the process designer can pass the information to all relevant developers to start
their developments.

28

Step 4: Define a Generic Service

Generic Services are required for the following scenarios:

Providing a particular value help that is not available in the standard system
Determining default values that do not originate from the business logic of the
infotype
Executing any additional checks and outputting error messages
Calculating values that are to be transferred to the form
Writing to additional database tables outside the standard functions
In any of these cases, you have the option of providing these functions by
creating a Generic Service.
From a technical point of view, Generic Services are implementations of the
enhancement spot HRASR00GENERIC_SERVICES.
For simple Generic Services, it suffices to implement the BAdI
HRASR00GEN_SERVICE_BASIC.
Reason

There is a requirement to be able to search for managers. The user can either enter the
receiving managers username or the name, and the form should automatically find
the right manager and populate the correct values.
The standard form uses backend services S_USER_NAME at the moment, which is
linked to the fields RCV_MGR_FORMATTED_NAME and RCV_MGR_UNAME.
As the user enters the managers username in the form and click on the button
Derive Data, the backend service S_USER_NAME is triggered, which will
29

populate the RCV_MGR_FORMATTED with the name of the manager. Should the
username not be found, it will return an error.
*NOTE: Generic services defined and delivered by SAP are known as Back End
Services. All custom back end services are known as generic services.
Personal Responsible

ABAP Developer
Details

We need a generic service that can determine who the receiving manager is using the
input data.
Process Designer: You should treat the generic service as a black box. It will take in
some fields and output the result. You have to know when this generic service will be
triggered. You also need to define the operation are you going to trigger, and the
fields/field group you want to pass in and out.
ABAP Developer: You should make this generic service as generic as possible, so that
it can be reused by other scenarios. Notice that the generic services are all changing
parameters. It does not have a concept of import/export.
CHANGING PARAMETERS:
1. Receiving Managers username (pattern)
2. Receiving Managers full name (we know this is for output only)
Logic

Using the input (username, first, last), determine the actual username, first, last and
full name of the receiving manager.
In IMG:

30

Step 4A: Define Generic Service for Form Scenario

In this step we define the name for the new generic service.

Type in ZHR_USER_NAME as the new name for the generic service.

Step 4B: BADI: Implement Generic Services

In this step we define the BADI implementation for our generic service
Click on the create button.

31

Define the Enhancement Implementation

Define the BADI Implementation

I picked the naming convention ZCL_HRASR00_<GENERIC_SERVICE_NAME>

32

Coding
Go to SE19

Enter the filter value ZHR_USER_NAME = SERVICEID.

This is the ensure this particular BADI implementation is triggered when the generic
service ZHR_USER_NAME is used.

Now implement the methods inside the implementation class. (See the next section
for details of the methods)
A good starting point would be to try to understand the standard backend service
S_USER_NAME. I start by copying all methods and attributes of the implementation
class CL_HRASR00_GS_USER_NAME to my newly created implementation class
ZCL_HRASR00_ZHR_USER_NAME.
Now we start changing it:

method IF_HRASR00GEN_SERVICE~GET_OPERATIONS.
First of all we have to add some code to this method. It is used to define what
operations are supported by this GS. Youll also need to specify the fields (just field
names) being used by this operation. This is effectively defining the import/export
interface of this GS (but remember above GS only deals with changing parameters).
Therefore in our case, we are going to have one operation
GET_FORMATTED_NAME, and four fields
USER_NAME
FORMATTED_NAME
How to test this:

Test this with the next step.

33

Method IF_HRASR00GEN_SERVICE~GET_FIELD_INFO.
For each of the fields of operation we have defined above, now we need to define the
properties for each field. Properties are:
Field name
Data Element of field
Supports Value Help?
Supports default value?
List of dependent fields for default value
List of dependent fields for value help
For operation GET_FORMATTED_NAME, the fields will have the following
properties.
USER_NAME of type UNAME
FORMATTED_NAME of type AD_NAMTEXT
How to test this:

The way to test this is go into the designer (HRASR_DT) and try to add a service.

Double click on Back-End Services.

Add the new service as a new line in the table.
Click on the button Service Fields.

If you see your operation in here, and the associated fields, it means your code works!

34

Method IF_HRASR00GEN_SERVICE~DO_OPERATIONS
Note: This method is called on every round-trip, whenever an event is triggered from
the form.
We want to implement our logic in here.
Logic

1) Loop at the service operations.

2) Check that the operation name equals to your operation.
a. If yes, implement your logic
b. Extract USER_NAME from the input (entered by the user).
c. Raise an error if it is blank.
d. Call function RH_USER_SEARCH_VIA_NAME to search for the
user.
e. Return the FORMATTED_NAME and the actual USER_NAME
found.
f. Raise an error if the user cannot be found
g. Data is stored in the SERVICE_DATASETS table input.
How to test this:
Unfortunately it is not easy to test this without the form, so test this when the form is
complete.
Remember to activate your BADI!
Generic Service Notes (from SAP Interface Documentation)
Determine Supported Operations (GET_OPERATIONS)
This method is optional. Only implement this method if you use operations. If
the Generic Service does not support any operations and is only to be used to
prove default values and input help, you do not need this method.
The method defines which operations the Generic Service supports.
Note: Operations are self-contained sub functions of the Generic Service.
Each operation has parameters that are required for the execution and that can
return error messages. The operations of a Generic Service can be used when
you define form scenarios. You can use either all operations or just a subset of
operations. Operations must be implemented in such a way that they can run
independently of each other.
The parameters of the operations are also specified in the
GET_OPERATIONS method. They correspond to fields of the Generic
Service. The parameters must be categorized in the GET_FIELD_INFO
method.

35

Determine Service-Specific Fields (GET_SPECIAL_FIELDS)

This method is optional. You only implement this method if the Generic
Service requires special fields. "Special fields" are further parameters that are
generally important for the Generic Service and that should, therefore, always
be available. For processes that involve the employee, this could be the
personnel number (field PERNR), for example.
Determine Information for Supported Fields (GET_FIELD_INFO)

This method is mandatory. You must always implement it. It defines the
properties of the fields that the Generic Service uses.
Initialize (INITIALIZE)

This method is optional. Only implement this method if you want to provide
default values for fields when forms are initialized. If the default value of a
field is dependent on the value of a different field, the method must also
provide this information.
In contracts to the DO_OPERATIONS method, this method is not called for
every roundtrip.
Perform Operations (DO_OPERATIONS)

This method is optional. Only implement this method if you define operations
for the Generic Service. If the Generic Service does not support any operations
and is only to be used to prove default values and input help, you do not need
this method.
In the method, you define the corresponding coding for each of the operations.
This is called repeatedly when a form scenario is run - that is, for every
roundtrip to the back end.
Determine Values for Input Help (GET_HELP_VALUES)

This method is optional. Only implement this method if you want to provide input
help for fields. If the input help of a field is dependent on the value of a different
field, the method must also provide this information.
The first three methods specify the scope of the functions of the generic service and
communicate this to the calling framework. The last three methods then implement
this function scope.

36

Part 2B
Part 2A covered building a generic service to search for the managers username.
There is an additional requirement to enhance the drop down for the new position
used by the receiving manager.
This document will cover this new generic service.

Step 4.2: Define a Generic Service (Managers

Position)

Reason

Currently when the receiving manager selects the drop down for the new position, it
only shows the text for the position.
There is a requirement to show the position number, and whether it is vacant in the
drop down box as well.
We have to copy the generic service provided by SAP (S_MGRS_POSITIONS) to
meet our needs.
Personal Responsible

ABAP Developer

37

Details

Define new generic service

In IMG:

Step 4.2.A: Define Generic Service for Form Scenario

In this step we define the name for the new generic service.

Type in ZHR_MGRS_POSITIONS as the new name for the generic service.

Step 4.2.B: BADI: Implement Generic Services

In this step we define the BADI implementation for our generic service
Click on the create button.

38

Define the Enhancement Implementation

Define the BADI Implementation

I picked the naming convention ZCL_HRASR00_<GENERIC_SERVICE_NAME>

I took a short cut and copy the class CL_HRASR00_GS_MGRS_POSITIONS to
ZCL_ZHRASR00_ZHR_MGRS_POSITION first. This can save me a lot of copy and
paste afterwards. (Remember to activate the new class)

39

Go to SE19

Everything is here already!

40

Step 4.2.C Coding

Enter the filter value ZHR_MGRS_POSITIONS = SERVICEID.

This is to ensure this particular BADI implementation is triggered when the generic
service ZHR_MGRS_POSITIONS is used.

ACTIVATE THE BADI implementation!!

Now implement the methods inside the implementation class. (See the next section
for details of the methods)
Now we start coding.

41

Method GET_MGRS_POSITIONS
As everything is the same, we dont have to touch any other methods.
This method already returns a list of positions in a name value pair table.
All we have to do is enhance this method to bring back more information in the drop
down values.

Append the following code to the end of the form

* Highlight the vacant positions.
DATA: lt_vacant_position TYPE STANDARD TABLE OF hrobject,
ls_vacant_position TYPE hrobject.
DATA: ls_position_text TYPE string.
LOOP AT orgunit_positions INTO orgunit_position_wa.
ls_vacant_position-plvar = orgunit_position_wa-plvar.
ls_vacant_position-objid = orgunit_position_wa-objid.
ls_vacant_position-otype = orgunit_position_wa-otype.
APPEND ls_vacant_position TO lt_vacant_position.
ENDLOOP.
CALL FUNCTION 'RH_FILTER_VACANT_POSITIONS'
EXPORTING
plvar
= plvar
begda
= effective_date
endda
= effective_date
TABLES
position_tab
= lt_vacant_position
EXCEPTIONS
internal_error = 1
OTHERS
= 2.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
LOOP AT orgunit_positions INTO orgunit_position_wa.
CLEAR position_wa.
position_wa-objid = orgunit_position_wa-objid.
* Build the position text <position name> <(position id)> <VACANT> if vacant
clear ls_position_text.
CONCATENATE '(' orgunit_position_wa-objid ')' INTO ls_position_text.
READ TABLE lt_vacant_position INTO ls_vacant_position WITH KEY objid = orgunit_position_waobjid.
IF sy-subrc = 0.
CONCATENATE orgunit_position_wa-stext ls_position_text '- VACANT'
INTO position_wa-stext
SEPARATED BY SPACE.
ELSE.
CONCATENATE orgunit_position_wa-stext ls_position_text
INTO position_wa-stext
SEPARATED BY SPACE.
ENDIF.

42

Part 3
After understanding Part 2, we now have all the building blocks to start developing
the HCM P&F for Reporting Line Change.
This document will cover:
- Configuring the Form Scenario
- Configuring the HCM process
At the end of this document, the new process and form should be visible in the portal.

43

Step 5: Form Scenario Definition

The form scenario from ZOC1 should already be copied to ZRLC (Step 1)
Reason

We need to change the form scenario ZRLC (copied from ZOC1) to meet the business
requirement.
Person Responsible

Process designer (functional consultant) with the help of developer if necessary.

Details

The process designer must be clear about what fields are used in the form.
They need to know:
- Define fields you want to appear in the form if they display variable data, such
as employee number, position id, text etc.
- Define fields you need to help update backend system if necessary
- How these fields will be determined/calculated
- The different scenarios this form is going to be used.
- How these fields are going to appear/used by different scenarios.

Scenario Steps

We first need to define the scenario steps.

We have three scenarios:
1) Initiating manager (SENDING_MANAGER)
2) Receiving manager (RECEIVING_MANAGER)
3) HR Administrator (HR_ADMIN)

Rules
We have to define some rules (Boolean expressions/conditions) for the scenario to
know what to do depending on the circumstances.
We have defined two rules, ZIS_STEP_HR_ADMIN,
ZPOSITION_SELECTION_ALLOWED.

44

Step 5A: Assign generic services ZHR_USER_NAME

When the user enters the user name of the receiving manager, and click on the button,
the users input must be verified and the full name of the receiving manager will be
determined.
As such, well attach the ZHR_USER_NAME to the fields.
Replace the S_USER_NAME service with our Z version.

1. Double click on Back-End Services

2. Remove all references to S_USER_NAME
3. Add ZHR_USER_NAME and the rule with which it should be triggered. In
this case there is no rule.
4. Go to Fields
5. Click on the button Service Fields
6. Select ZHR_USER_NAME
7. Do the mapping appropriately for fields RCV_MGR_FORMATTED_NAME
and RCV_MGR_UNAME. Click on the transfer checkbox, then select the
field you want to map to it.

8. Save the form scenario

9. Note that we dont apply a rule to this generic service as it doesnt matter what
scenario it is, we always want the value to be validated.
How to test:

You can only test this after youve defined the process. See below.

45

Step 5B: Assign generic services ZHR_MGRS_POSITIONS

1. Double click on Back-End Services

2. Remove all references to S_MGRS_POSITIONS

3. Add ZHR_MGRS_POSITIONS and the rule with which it should be
triggered. We only want this to be triggered for the Receiving managers step,
so we assign the rule ZPOSITION_SELECTION_ALLOWED.
4. Go to Fields
5. Click on the button Service Fields
6. Select ZHR_MGR_POSITIONS
7. Do the mapping appropriately for fields RCV_MGR_UNAME and
PLANS_NEW. Click on the transfer checkbox, then select the field you want
to map to it.

8. Finally, we must map this generic service to the input help. Click on the input
help column, and select ZHR_MGRS_POSITIONS

46

Assign the field properties

You need to determine how the fields react depending on the scenario -- whether they
are mandatory input, read only, invisible, etc.
There are two changeable fields in this form:
1. Receiving Manager user name by the sending manager
2. New position by the receiving manager.
There are two options, you can set let the form scenario automatically determine this
for you. Alternatively, you can make it step dependent and change it yourself.
Go to Fields, Ive made my fields Step Dependent for this example.

47

For our Receiving Manager username field, we only want the sending manager (the
originator) to change this. Therefore we change the
Go to Scenario Steps > SENDING_MANAGER > Fields, change the fields
RCV_MGR_UNAME to MANDATORY, and the other position fields to be invisible.

48

For our Position fields, we only want the receiving manager (the originator) to
change this. We also dont want the receiving manager to change the user name.
Therefore we change the it as follows.
Go to Scenario Steps > RECEIVING_MANAGER > Fields, change the fields
RCV_MGR_UNAME to READONLY, and the position field to be MANDATORY.

Now the scenario is completely defined. Save accordingly.

49

Step 6: Define HCM Process

Reason

A HCM Process is required for every scenario. Its a mandatory configuration.

Person Responsible

Process designer
Details

Copy ORG_CHANGE process to our own ZHR_REPORTING_LINE_CHANGE

50

Select the checkbox Permit Parallel Run.

This should be checked in DEV and QA environment.
It indicates whether a process can be called multiple times in parallel.

Attach our ZRLC form scenario to the process.

Leave the workflow as it is for now.

51

Ensure the initiating role is a manager if you want the manager to start the process.

Save the process.

Finally:
Transport the configuration to client 101 for testing. Please note that this step is
required whenever you want to move your changes to client 101 for testing.

How to test:

Log into the portal as MSSUSER02

Our new process should now be visible.

52

Step 7 Unit testing Generic Services

Reason

The generic service was built in the previous step, however the method
DO_OPERATION could not be tested.
Now that we have the form up and running you can trigger DO_OPERATION.
Person Responsible

ABAP Developer (responsible for building the Generic Service)

Details

Start the process Reporting Line Change

Note that this form is still the one copied from SOC1. It is not our final form, however
the fields we are interested in still exist.
Type in MSS* and click on the Derive Data button.
Note that you can debug by setting an external breakpoint at the start of
DO_OPERATION. (for the user you are logged in as in the portal).

53

I get a warning message saying its found more than one user with my search string,
and it has picked MSSUSER01 for now.

54

Step Optional. Create start application

Reason

This step is just to highlight you can maintain your HCM configuration outside of the
design time. For example, you might want to quickly switch off a form from the
portal, rather than changing this inside the design time, you can activate/deactivate
forms via configuration.
Person Responsible

Process designer
Details

You can activate or deactivate processes using Versions in the design time
environment.
An alternative approach other than the Design Time is described below.
Now we are ready to test the form

55

By checking/unchecking the validity checkbox, you can switch the forms on/off.

56

Part 4
After understanding Part 3, we now have to change the form to meet business
requirement.

Step 8: Form
Reason

The form must be changed to meet business requirement.

What we have to do for this scope is quite straight forward so I wont go into too
much detail.
Person Responsible

Form Developer
Details

The form developer must have at least Adobe Life Cycle Designer 7.1 (with patch)
installed. Version 8.0 with patches will also work.

HR Admin Library UI Controls

The prerequisite is that you have the newest form library controls installed on the
developers machine.
HR_Admin_Controls.
zip

These controls are downloaded from OSS note 973170.

Extract the zip file into the Adobe Designer object directory.
For example, my Adobe LifeCycle Designer is installed in
C:\Program Files\Adobe\Designer 7.1\EN\objects

Note the LocalLibrary.xml file.

57

Now you have to edit the LocalLibrary.xml file.

Open it with your text editor (Notepad for example). Add the line for the HR Admin
Controls library
<?xml version="1.0" encoding="UTF-8"?>
<objectLibraryTabSet>
<tab name="Standard" directory=".\Standard" permission="adm"/>
<tab name="Barcodes" directory=".\Barcodes" permission="adm"/>
<tab name="Custom" directory=".\Custom" permission="adm"/>
<tab name="Web Dynpro ActiveX" directory=".\WebDynproActiveX" permission="adm"/>
<tab name="Web Dynpro Native" directory=".\WebDynproNative" permission="adm"/>
<tab name="Form Builder" directory=".\FormBuilder" permission="adm"/>
<tab name="ISR Controls" directory=".\ISR Controls" permission="adm"/>
<tab name="HR Admin" directory=".\HR_Admin_Controls" permission="adm"/>
</objectLibraryTabSet>

If you open the form now, you should see a new tab in the Library.

You MUST use these controls otherwise the in the form scenario field configuration,
it will always show a warning.

58

It only matters when you want these UI controls to be controlled using from the form
scenario configuration. Standard SAP forms dont use these controls, and hence they
all have this warning. It is recommended that you use the correct controls. Note the
green plus icon in the diagram. It means the UI control is adequate for the field.
[Note***: Depending on the Adobe LifeCycle Designer version, this warning flat is
not always accurate]

59

Changing the form

We have to change a few things in the form, most of which are superficial, so I will
not go into too much detail here.
More importantly, there are a few things that must be done.
We must replace the UI controls copied from the old form which are deemed as too
old, and replace them with the ones in the HR Admin Control library (described
above).

Click on the change button and it will take you to the form designer (effectively
transaction SFP).

You can also include scripts for example, the script behind the button Derive Data:

In this script, when the button is clicked, the USER_EVENT_CHECK is triggered.

This event is a standard event in the HCM P&F framework.
60

Also, when we are in approve or display mode, the button is not visible.
Remember to activate your form.
Should you need to change the fields in the form scenario, remember to reactivate
your form so that the form interface is in synch with the form.
Ive replaced the text edit UI control for the Receiving Managers user name.

61

Adding a drop down list box

http://help.sap.com/erp2005_ehp_03/helpdata/en/43/1d639b3fce3566e10000000a114
66f/frameset.htm
I had to replace the drop down list box for new position.
First I drag the Drop Down list box control from the HR Admin Controls Library into
the form.

Change the Caption

Change the binding

Finally change the item values mapping. Click on Specify Item Values.

62

Change the Items to: $record.sap-vhlist.PLANS_NEW\.DATA\.FIELD.item[*]

All done!
If you want to add an action to the drop down box so that it triggers a call to the
backend as the dropdown is changed, see standard help document.
How to test

You can either click on the preview button, or load the form from the portal to view
your changes. (see unit testing section of previous document)

63