Oracle HRMS Tutorial (SSHR)

In this forum you can share stuff related to Oracle 11g, 10g, 9i.
Post Reply
mahendrab1983
Posts: 1
Joined: Mon Mar 02, 2009 8:15 am
Location: India

Oracle HRMS Tutorial (SSHR)

Post by mahendrab1983 »

Experienced Oracle HRMS configuration consultants with at 2 full end-to-end implementations. Module experience should cover aspects of at least two of the following:
- Core HR;
- Time and Labor;
- Self Service and basic workflow;
- Payroll.

Implementing Oracle Self-Service Human Resources (SSHR) 3.x / 4.0 Oracle Workflow Guide

1. Introduction

2. The Approvals Process
2.1 Approvals Initialization Process
2.2 The Approvals Chain
2.3 Saving Data Changes
2.4 The Approved Process
2.5 The Rejected Process

3. Configuring the Approvals Process
3.1 Controlling Which Changes Require Approval
3.2 Informing People Outside the Approvals Chain
3.2.1 Set Routing Details
3.2.2 Set URL Details
3.3 Customizing Final Approver Processing
3.4 Customizing Next Approver processing

4. Dynamic Approvals
4.1 Setting Up Dynamic Approvals
4.2 Using Dynamic Approvals
4.3 Approval Levels

1. Introduction

you use Approvals in SSHR to allow certain users - often managers - to stay informed of changes to a person's record. The system notifies the approver by email or via Self-Service applications using the View Notifications function and they may approve or reject the change.

Therefore, when an employee makes a change to his basic details via the SSHR Personal Information function a notification goes to his supervisor informing him of the change and asking him to accept or reject it. If he accepts it, the transaction is saved. If he rejects it, the transaction is abandoned.

The SSHR approvals process is configurable, so you can change the way approvals work in line with your business needs. You can create as many different configured versions of the approvals process as you require - each function could use its own 'Approvals Process,' or they could all use the same one.

For example, when an employee enrolls in a training course using the SSHR 'Enroll in a Class' function, you may want the employee's supervisor to approve the enrollment and the company Training Administrator to be informed. If the enrollment is approved, a notification is sent to the employee, which includes a link to the company's training webpage where they can get further details of the course.

Dynamic approvals were introduced in SSHR V3.2. Their usage is optional. They are only available for MEE (manager) functions. In any function that you choose to use it, the dynamic 'Approvals Process' replaces the standard 'Approvals Process' and it works in a similar way. When the manager completes his transaction, he sees the usual review screen where he is able to check the changes he has made before confirming them. He also sees a list of all the
people who will be notified for approval of his transaction. He can add any additional people he wishes to this list. He can also specify any people he chooses to be informed of the transaction, but they do not have the opportunity to approve or reject it.

2. The Approvals Process

There is a seeded process in the Workflow 'Human Resources Self-Service Applications' Item Type called Approvals Process. It is called from the following SSHR functions:

1. Appraisals
2. Apply for a Job
3. Enroll in a Class
4. Personal Information
5. Professional Information

and the following US Only functions:

1. Deploy Person
2. Change Conditions
3. Termination
4. Change of Hours
5. Change Location
6. Promotion
7. Change Supervisor

you can also configure other functions to call the 'Approvals Process.'
The generic 'Approvals Process' consists of three customizable workflow processes:

1. Approvals Process
2. Approved Process
3. Rejected Process

The process 'Approvals Process' contains a sub-process called Approval Initialization, which is not customizable. It sets up values for workflow attributes used in 'Approvals Process.'

2.1 Approvals Initialization Process

The Approvals Initialization process initializes a number of workflow attributes used in the 'Approvals Process.' The procedure HR_APPROVAL_WF.INITIALIZE_ITEM_ATTRIBUTES (hrapprwf.pkb) is called by the workflow function 'Initialize Approval Item Attributes.' It begins by creating rows in WF_ITEM_ATTRIBUTE_VALUES for a number of workflow attributes used by
the 'Approvals Process.'

All workflow attributes are held in WF_ITEM_ATTRIBUTES and when a workflow is run, the values for each attribute for that run (defined by a combination of Item type and Item Key) are held in WF_ITEM_ATTRIBUTE_VALUES. The actual value is not mandatory and many of the rows created do not have a value assigned to them.

The Approvals Initialization process then sets values for some of the attributes used by the 'Approvals Process':

APPROVAL_CREATOR_PERSON_ID is copied from the attribute value for
CREATOR_PERSON_ID, the creator is the user performing the transaction, and
APPROVAL_CREATOR_USERNAME and APPROVAL_CREATOR_DISPLAY_NAME are set accordingly.

The following FORWARD_TO_? Attributes are set to the creator in case this is the only person in the Approvals Chain:

FORWARD_TO_USERNAME
FORWARD_TO_DISPLAY_NAME
FORWARD_TO_PERSON_ID

The following FORWARD_FROM_... attributes are set to the creator, too. These must be set because if the person has no supervisor, the function
GET_NEXT_APPROVER (see 2.2 The Approvals Chain) will never be called:

FORWARD_FROM_USERNAME
FORWARD_FROM_DISPLAY_NAME
FORWARD_FROM_PERSON_ID

Finally, the attribute PROCESS_NAME is set to the name of the process that is running and the attributes APPROVAL_COMMENT and APPROVAL_COMMENT_COPY, which are used in the body of the approval messages, are set to null.

The Approvals Initialization process also controls the Approvals Chain, i.e. who is going to be notified (see section 2.2 The Approvals Chain), and controls the results from the notifications, i.e. whether the approvers approved or rejected the update.

The process, once complete, has a status of either 'Approved' or 'Rejected.'

2.2 The Approvals Chain

The Approvals Chain selects the people to whom an approval notification will be sent. This will be the supervisor of the employee making the change, the creator, the supervisor of that supervisor, and all the supervisors up in the chain. This is clearly far more than is necessary and so the Approvals Chain will usually need some customization.

The Approvals Chain is constructed by finding the first approver, i.e. the supervisor of the creator. The Person_ID of this supervisor is assigned to the workflow attribute FORWARD_TO_PERSON_ID. This person then receives an approval notification. The workflow then checks to see if that person is the person at the top of the Approvals Chain. It does this by running an SQL statement to find the Person_ID of the supervisor at the top of the supervisor chain from the creator. If that Person_ID matches the value in the attribute FORWARD_TO_PERSON_ID then we have reached the end of the Approvals Chain. If
they do not match, the next person up the Approvals Chain must be found.

The Workflow function Find Next Approver calls HR_APPROVAL_WF.GET_NEXT_APPROVER
(hrapprwf.pkb) to select the next supervisor up in the supervisor chain. The Person_ID of the person identified as the next approver is returned from this process.

The Workflow function Final Approver calls HR_APPROVAL_WF.CHECK_FINAL_APPROVER
(hrapprwf.pkb) to check if the current approver is the highest approver in the Approvals Chain. The function returns on of the following values:

Y - the person is the highest approver in the Approvals Chain
N - the person is not the highest approver in the Approvals Chain
E - the highest approver cannot be found

The initialization function sets the value of the FORWARD_TO_PERSON_ID attribute to the Person_ID of the creator, the employee who made the change, and so the Check_Final_Approver can be called first.

See sections 3.3 Customizing Final Approver Processing, and 3.4 Customizing Next Approver Processing for a more detailed technical description of the Approvals Chain.

2.3 Saving Data Changes

When an employee makes a change to information that requires approval, the change cannot be committed to the database right away - only when all approvers have approved the change. This means that the details of the transaction and the new data must remain ready for use, but not saved in the base HR tables.

The transaction is stored in HR_API_TRANSACTIONS. The API required to insert/update/delete the database is held in HR_API_TRANSACTION_STEPS, and the actual field and new value information is held in HR_API_TRANSACTION_VALUES.

If an SSHR user views information which is still awaiting approval, the system displays a message informing the user that this is the case.

Each notification has 'timeout' details defined in Workflow Builder. This allows it to be possible to process an approval when a supervisor does not respond to a notification. If there is no response received, the workflow will continue processing according to the rules defined for timeouts. The time elapsed before a timeout occurs can be set for any notification.

2.4 The Approved Process

If the 'Approvals Process' completes with a status of 'Approved' then the 'Approved Process' begins. This actually commits the data to the database via the 'Commit Transaction' Workflow function. This function calls the procedure HR_TRANSACTION_WEB.COMMIT_TRANSACTION (hrtrnweb.pkb) which looks in HR_API_TRANSACTION_STEPS and calls the relevant API to save the data. The 'Approved Process' then sends notifications of the approval to interested users.

2.5 The Rejected Process

Similarly, the 'Rejected Process' starts when the 'Approvals Process' has a status of 'Rejected.' It uses the 'Remove Transaction' Workflow function to call HR_TRANSACTION_WEB.ROLLBACK_TRANSACTION (hrtrnweb.pkb). This calls
HR_TRANSACTION_API.ROLLBACK_TRANSACTION (petrnapi.pkb) to remove the changed data.

3. Configuring the Approvals Process

Configuring the 'Approvals Process' allows you to control your approvers and the information they see. You can create a different 'Approvals Process' for each SSHR function or share the same process for some or all of the functions.

3.1 Controlling Which Changes Require Approval

Using the seeded HRSSA workflow, you will find that the 'Approvals Process' is initiated when some fields are modified and not for others. You should decide for your business which data changes require approval. To control which changes require approval, you need to modify the appropriate Workflow process.

For example, if you want to use the approvals process for changes to Employees' contact details you should open the Personal Information Workflow process and go into the Properties of the function 'Maintain Personal Information.' Select the Attribute Values tab and then select the Attribute 'Contacts.' Change the Value field to 'Update For Approval' and press OK. You will then need to send the 'Change To Contacts' transaction through the 'Approvals Process. ?In Workflow Builder, create a new transition line from the function 'Maintain Personal Information' to the 'Approvals Process.' Do this by holding down the right-hand mouse button on the function and dragging it to the destination activity, the Display Message activity in this case. The Result of this transition will be 'Contacts Changed.' See the Oracle Workflow Guide Release 2.0.3 (PDF) or Workflow Builder online help for more details on how to do this.

3.2 Informing People Outside the Approvals Chain

It is possible to select additional people to receive a notification to inform them about an approval. Using the five 'Set Routing Details' workflow functions, you can select up to five different people and those people can be included in any of your configured approvals processes. In the example in the introduction of this article, the training administrator received a notification informing him that an employee had enrolled in a class. His details were retrieved using
one of the 'Get Routing Details' functions. Other people may have been retrieved using the other 'Get Routing Details' functions but they would perhaps be used in the approvals process for a different SSHR function.

The five 'Set URL Details' workflow functions hold up to five URL addresses.These may be included in any of the notifications used in the approvals process, or a new notification may be created. In the 'Enroll in a Class' example, a new notification was created which was sent to the employee when the enrollment had been approved and it included a link to the company's training web page. The employee can click the link and go to the site.

3.2.1 Set Routing Details

After initializing the necessary item attributes via the procedure HR_APPROVAL_WF.INITIALIZE_ITEM_ATTRIBUTES (hrapprwf.pkb) (see section 2.1), the
initialization process runs the function 'Set Routing Details 1 to 5.' You can assign a value to one or more of these 5 routing detail workflow attributes by customizing this function. The value will be the Person_ID of someone to whom you want to send an information notification.

Each of the 5 functions performs in the same way. 'Set Routing Details 1' calls HR_APPROVALS_WF.SET_ROUTING_DETAILS1 (hrapprwf.pkb). This procedure gets the
value of the workflow attribute CREATOR_PERSON_ID. The customizable function
HR_APPROVAL_CUSTOM.GET_ROUTING_DETAILS1 (hrapcuwf.pkb) is then called with a
parameter of Creator_ID to return a value for the approval routing ID. You can insert your own custom logic into this function, or leave it the way it is if you do not want to customize this area. Therefore, by using the Creator_ID parameter, you could code the procedure to select an approver unique to that creator, or you could ignore the parameter and return the Person_ID of the creator. Once the approval routing ID has been retrieved, (this will be null if
no customization has been added) the procedure HR_APPROVALS_WF.SET_ROUTING_DETAILS
sets the values for the workflow attributes APPROVAL_ROUTING_PERSON_ID1,
APPROVAL_ROUTING_USERNAME1, and APPROVAL_ROUTING_DISPLAY_NAME1 based on that
Person_ID.

For example, you want to inform someone who is not in the supervisor chain of any changes made which require approval. You modify HR_APPROVAL_CUSTOM.GET_ROUTING_DETAILS1 to return a value of the Person_ID you wish to inform and you recompile the package. You go into Workflow Builder and create a message, maybe by taking a copy of an existing approval message and making any necessary changes, and you create a notification that calls the message. You can also modify a copy of an existing one. Make a copy of the Approvals Workflow Process and modify it to include the notification in an appropriate place, maybe after the Final Approver has been identified. Add the notification activity and add transition lines to and from it by dragging the right mouse button from the source activity to the destination activity. For any SSHR function for which you want to use this new approvals process, modify the relevant workflow process by replacing the original Approval Process (HR_HRSSA_APPROVALS_PRC) with your new customized version of this process. Go to File -> Load Roles From Database and ensure that the role for the username of the person to whom you are sending the new approval notification
(APPROVAL_ROUTING_USERNAME1) is loaded.

3.2.2 Set URL Details

The functions 'Set URL Details 1 to 5' also run. This allows you to define URLs that can be included in any of your approvals notifications. Each of the 5 functions performs in the same way. 'Set URL Details 1' calls HR_APPROVALS_WF.SET_URL1 (hrapprwf.pkb). This procedure calls the customizable function HR_APPROVAL_CUSTOM.GET_URL1 (hrapcuwf.pkb) to get a value for the required URL. You can insert your own custom logic into this function so that it returns the value of the required URL, or leave it as it is if you do not want to customize this area. Once the URL has been retrieved, (this will be null if no customization was added) the procedure HR_APPROVALS_WF.SET_URL is called to copy the URL address into the workflow attribute APPROVAL_URL1.

For example you want to include a link to a specific URL within the body of the message sent to the additional approver (APPROVAL_ROUTING_USERNAME1 - see above). You will need to create a new message attribute which points to the seeded attribute APPROVAL_URL1 and has a Type of 'URL' and a Source of 'Send.' Message attributes for a message are listed under the message in the Workflow navigator screen. The attribute values APPROVAL_URL1-5 are defined with a Type of URL. You should modify the message you created to include the string '&APPROVAL_URL1'.
The '&' makes the attribute into a link rather than just displaying the actual value of the attribute.

3.3 Customizing Final Approver Processing

The seeded approvals process goes up the line of supervisors from the creator until it finds a person with no supervisor. This person is assumed the final approver and the top of the Approvals Chain for that creator. You may want to define a different way of finding the top of the chain.

The workflow activity for the function Final Approver calls HR_APPROVALS_WF.CHECK_FINAL_APPROVER (hrapprwf.pkb). This procedure finds out
from workflow attribute values who the Creator is and who the next Forward_To
person is (i.e. the next person selected to receive an approval notification).
It then calls the customizable function HR_APPROVAL_CUSTOM.CHECK_FINAL_APPROVER
(hrapcuwf.pkb). Two parameters are passed to this function - the Person_ID of
the next approver (P_Forward_To_Person_ID) and the Person_ID of the creator i.e.
the person who performed the transaction (P_Person_ID).

This function contains an SQL statement that selects each supervisor Person_ID, starting with the Creator's supervisor, to that supervisor's supervisor, and so on up the chain. It loops through selecting each supervisor in hierarchical order ending with the one at the top of the supervisor chain. It then compares this value with the FORWARD_TO_PERSON_ID that was brought in as a parameter from the call. If the two Person_IDs are the same (i.e. the next
FORWARD_TO_PERSON_ID equals the Person_ID of the supervisor at the top of the supervisor chain) then a 'Y' is returned. If they are different then an 'N' is returned.

This function is customizable so you could, for example, decide that instead of having approval notifications going to the top of the supervisor chain you only want the direct supervisor to be notified. In that case, you could create a new cursor that selects the Person_ID of the creator's supervisor. E.g.:

cursor csr_sup(l_effective_date in date) is
select supervisor_id
from per_all_assignments_f
where Person_ID = p_Person_ID
and l_effective_date between effective_start_date and effective_end_date;

l_Person_ID per_people_f.Person_ID%type := null

begin
open csr_sup(trunc(sysdate));
fetch csr_sup into l_Person_ID;
if csr_sup%notfound then
l_Person_ID := null;
end if;
close csr_sup;

if p_forward_to_Person_ID = l_Person_ID then
return('Y');
else
return('N');
end if;
exception
when others then retrun('E');

end check_final_approver;

This code would replace the cursor csr_pa and the looped call to it. The return statements are the same.

This will mean that the Person_ID of the Creator's supervisor will be compared with the FORWARD_TO_PERSON_ID and if they match, the approval chain is complete.

The Final Approver activity is the next activity in the seeded workflow Approvals process after the Initialize Approval Item Attributes. The initialization process sets the FORWARD_TO_USERNAME, FORWARD_TO_PERSON_ID, and FORWARD_TO_DISPLAY_NAME to the values of the Creator.

3.4 Customizing Next Approver processing

The seeded approvals process selects the supervisor of the employee who performed the transaction to be the next approver. Then that supervisor's supervisor is selected as the next approver, and so on up the supervisor chain. You may want to define a different method for selecting who will be the next approver.

Whenever the Final Approver activity returns a value of 'No' then the Find Next Approver activity is started which calls HR_APPROVAL_WF.GET_NEXT_APPROVER (hrapprwf.pkb). This procedure finds out from the workflow attribute FORWARD_FROM_PERSON_ID who the last approver was. It then calls the customizable function HR_APPROVAL_CUSTOM.GET_NEXT_APPROVER (hrapcuwf.pkb) passing in a parameter value of the value found in FORWARD_FROM_PERSON_ID.

The customizable function defines an SQL cursor to select the Person_ID of the
supervisor of the FORWARD_FROM_PERSON_ID. This runs, and the Person_ID
retrieved is returned from the function. The HR_APPROVALWF.GET_NEXT_APPROVER
checks the value returned and sets the workflow attributes FORWARD_TO_PERSON_ID,
FORWARD_TO_DISPLAY_NAME, and FORWARD_TO_USERNAME with the appropriate values
for that person. The FORWARD_FROM_PERSON_ID, FORWARD_FROM_DISPLAY_NAME, and
FORWARD_FROM_USERNAME are also set to the same values in preparation for finding
the next approver.

The customizable function can be modified to select a person other than the supervisor. For example, you could select not the person's supervisor, but the second level supervisor as the next approver. Alternatively, you could define some more complicated cursor code to find the person whose position is one up from the Forward_From person in the position hierarchy. It is worth remembering that if you are modifying this, you will probably have to modify the Final
Approver processing, too.

4. Dynamic Approvals

Dynamic approvals were introduced as an optional feature in SSHR v3.2. It can be used in functions within the Line Manager responsibility and allows the user to add additional approvers to an approvals process and to add people to be sent notifications once the change has been submitted or approved. It also allows a limit to be placed on how many levels up the Approvals Chain approvals shouldbe sent.

In SSHR V4.0 the standard approvals module is called Approvals with Corrections V4.0. It is an enhanced version of the SSHR V3.x Dynamic Approvals process. To allow managers to see and add approvers in V4.0 the set up for dynamic approvals below must be followed. This is also the case for SSHR V4.1 onwards, but it is usual for OAM to be used for approvals and so this is not relevant.

4.1 Setting up Dynamic Approvals

You do the setup for dynamic approvals in Workflow builder. You need to select the process for which you want to use dynamic approvals.Go to the 'Properties' window of the Review activity.
In Attribute Values select Dynamic Approval and set the value to 'Yes.' Decide if the approval should pass right through the Approvals Chain.

If you don't want it to, then set the Dynamic Approval Level attribute appropriately (see section 4.3 Approval Levels). Remove the Approvals Process from the workflow process diagram and replace it with the Dynamic Approvals Process adding the necessary transition lines for
Approved and Rejected. Any changes you want to make to the web page prompts can be made in AK Developer responsibility under the HR_DYNAMIC_APPROVALS_WEB region fields.

4.2 Using Dynamic Approvals

When using a line manager SSHR function that uses dynamic approvals you will see an Approvals/Notifications area at the bottom of the standard review screen where you can review the changes made before finally submitting them. Under a heading of 'Approvals' is a list of each approver, and under a heading of 'People To Notify' is a list of any people who will be notified of this transaction.

Pressing the Approvals/Notifications button will open a new window.The top zone is headed Approvers. Here is a list of all approvers in the order that they will be sent an approval notification. An 'Add' button allows you to include other people at any point in this list so they are included as approvers.

In the 'People To Notify' zone you can use an 'Add' button to select people to whom you would like a notification sent for the transaction. You can select this notification be sent on submission or on final approval, or both, of the transaction.

You can add up to ten additional approvers and people to notify. Once you have added the people you require, you will return to the review screen and the Approvals/Notifications area will have been updated to include the people you added.

The workflow process 'Dynamic Approvals Process' is very similar to the Approvals Process. However, it includes two new sub-processes:

After the 'Approval Initialization' sub-process is run, the sub-process 'OnSubmission Notification Process' is run which sends a notification to all the people you requested to be notified on submission of the transaction. This uses its own version of 'Find Next Approver' (Find Next Onsubmit Notifier) and 'Find Final Approver' (Final Onsubmit Notifier).

After the 'Find Final Approver' function completes with a status of 'T' then the sub-process 'OnApproval Notification Process' runs, which sends a notification to all the people you requested to be notified on approval of the transaction.

This uses its own version of 'Find Next Approver' (Find Next OnApproval Notifier) and 'Find Final Approver' (Final OnApproval Notifier). The Dynamic Approvals Process also uses its own versions of the 'Find Next Approver' and 'Final Approver' functions (Find Next Dynamic Approver and Final Dynamic Approver) so that it picks up the people specified dynamically as approvers.

4.3 Approval Levels

Using dynamic approvals allows you to configure the approval level. That is, how many levels of the Approvals Chain the approvals process needs to go through before a transaction can be approved. The default is to go to the top of the chain. There is nothing actually 'dynamic' about approval levels but the level can only be set when the Dynamic Approvals Process is used.

To change the number of approval levels for a LMDA function, you need to open the process for that function in Workflow Builder. Click on the Review function activity to bring up the Properties box and go into Attribute Values. Select the attribute Dynamic Approval Level. The default value is an Item Attribute with a value of 'Approval Level. You can change this so that only a certain
number of supervisors up the chain are involved in the approval. To do this, change the Value Type to 'Constant' and the Value to the number of levels you want to go up the Approvals Chain. For example, a value of 1 will allow the transaction to be approved after approval from the immediate supervisor, a value of 2 would need to go to 2 levels up the Approvals Chain, etc
Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests