Tuesday, December 1, 2009
Peopletools 8.50 supports UK English!
Cheers to that!
Sunday, November 22, 2009
Peoplesoft HRMS 9.1: Changes to Time Approval setup and Functional Implications
A note on Time Approval in Time and Labor: Time can be approved at two levels - Reported Time or/and Payable Time. Whether reported time/payable time requires approval can be setup at the Workgroup as well as TRC level. If a TRC is set to have Reported Time approval, then the Time Administration process will not pick up time reported under that TRC unless it is approved. Similarly if a TRC is setup to have Payable Time approval, then a payable time row under that TRC will not be sent to any payroll system unless the payable time is approved.
How Approval Used to happen prior to 9.1: The approve reported time/payable time component in versions 8.9/9.0 was designed to retrieve all rows requiring approval for employees a user's security had access to. The logic used to derive the employees a user can see in a T&L MSS page is explained in this post. This meant that the user could approve the time of all users that he/she had access to as per the security settings.
What has changed in version 9.1: In 9.1, time approval is driven by the approval workflow engine (AWE). Oracle has delivered a number of approval definition ids - for example - approval by position management, supervisor id, department manager, position department manager, position supervisor, T&L approval group etc. Also, the approver in an AWE definition is determined by the 'User List' attached to the defintion id as shown below:
A 'User List' can be a SQL/Application Package code/Query or a Role that determines the operatorids to which the request should be routed for approval. Thus, the approvers of a certain request are determined by the user list attached to the AWE definition id. This means that HRMS security/T&L security no longer plays a role in determining the approver - and more importantly the fact that a certain user has security to view a particular employee in Time and Labor does not guarantee the fact that he/she will be able to view the time requiring approval of those employees.
What is the functional implication of this change:
> The biggest functional implication of this change will be the way Time and Labor administrators approve time. In previous versions, administrators could approve time of all employees they had access to by their core row level security or time and labor security. This will no more be the case in version 9.1 - even if the administrators will be able to view the employees' timesheets, they will no longer be able to approve reported/payable time by default. The user list logic of the AWE process definition will have to be customized to return administrators also as legitimate approvers if they have to have access to approve reported/payable time. In effect I would say that from version 9.1 - search security and approval security have been differentiated in Time and Labor with row level security controlling search and AWE user list controlling approval security.
> There is an option to 'Push Back' reported time in version 9.1. In previous versions, managers could either Approve or Deny reported time, but with version 9.1, managers can even push back reported time. This is a useful feature especially in case of an elapsed time configuration and users can make use of the notification functionality of AWE to notify the requester when an approver has pushed back the request.
> Challenges in data migration to version 9.1: In versions 8.9 and 9.0, there were only two tables related to reported/payable time approval and they were TL_RPTD_TIME and TL_PAYABLE_TIME. The SUBMITTED_STATUS and PAYABLE_STATUS fields in the respective tables were enough to pick out rows requiring approval and no special logic was required to find the approver of a request as approval and search security were unified. But this has undergone a sea change in version 9.1. With 9.1, there are separate AWE tables that store the 'header' and 'line' information of each transaction done in time and labor and the approval details will be picked from these header and line tables. For example, assume that you are moving from version 8.9 to 9.1 and at the time you are going live with Time and Labor 9.1, there are a bunch of Payable Time entries that have not yet been approved. How do you bring over this data to 9.1 and ensure that when the managers log into the 9.1 application, they will be able to see the pending payable time entries for approval? It will not be enough to just migrate the TL_PAYABLE_TIME table to 9.1, but the AWE tables will also have to be populated to ensure that time entries pending approval show up in version 9.1. Note that the AWE tables related to Time and Labor are newly introduced in version 9.1 and are not present in any previous version. I am noting below the important AWE tables for Time and Labor in 9.1:
Payable Time Approval:
Cross Reference Table: TL_APP_PAY_XREF
Header Record : TL_APP_PAY_HDR
Line Record : TL_APP_PAY_LINE
Note that this change could potentially affect any custom reports/processes that were designed around time approval in Time and Labor also.
Sunday, November 1, 2009
Peoplesoft 9.1 - Time and Labor: Dynamic Groups are dead, long live Dynamic Groups!
So do we need Dynamic Groups anymore in Time and Labor?
There are two areas where the use of Dynamic Groups are significant:
1. As a parameter for running the Time Administration process. Dynamic Groups will still remain to be a very useful run control parameter for running the time administration process.
2. Grouping approvers together for use in some of the T&L specific AWE definition Ids. This is a change introduced in version 9.1 in the definition of a dynamic group. A new field called 'TL Approval Group' has been introduced in 9.1 as shown below:
When a Dynamic/Static group is selected as a 'TL Approval Group' - it will be used only as a group of potential approvers and not for row security. Row Level security cannot be attached to these groups and they can be used in the AWE Definition Ids for Time and Labor to specify the user list that approves time.
Peoplesoft 9.1 - Time and Labor: Changes to TRC Setup
- A completely new page called 'Approvals and Comments' has added to the component. This is in conjunction with the introduction of the Approval Workflow Engine (AWE) framework in Time and Labor. The introduction of AWE is a major change and changes the way approvals are handled in Time and Labor. Earlier, the field called 'Approval Option' (where one could choose 'Reported Time', 'Payable Time' or 'None') controlled the way in which the TRC had to be approved. But this field has been taken off the page in 9.1 and a completely new page has been provided to fill in the AWE details for each TRC. This setup is similar to the familiar 'Country Take' setup in Absence Management, where we attach an Approval Process Id to each Absence Take that is exposed in Self Service.
- The fields that were present in the page called 'TRC2' in prior versions have been moved over to the first page of the definition. These fields include Effect on Comp/Leave, Hours Represent, Interface options etc.
- The tabs have been renamed to Definition and Approval and Comments from TRC1 and TRC2.
------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------The major change as seen above is the introduction of the approval framewok settings. The adoption of AWE in Time and Labor has far fetched consequences, especially when one considers security and integration with Absence Management (it will now be imperative to synch up T&L security, Approval framework and Absence Approval framework). I am studying the technical architecture of the approval framework in T&L and will post about it in detail soon.
Peoplesoft 9.1 - Time and Labor: Changes to TRC Category Setup

A maximum of three categories can be chosen to be displayed in the reported time and payable time approval pages. We can classify this change more as a cosmetic one impacting the layout of the time approval pages and the structure of the TRC Category changes - all in all, goes one small step in improving the usability of the application.
Peoplesoft 9.1 - Time and Labor: Viewing Unprocessed Time
The new pages can be found under the following navigation:
Time and Labor --> View Time --> View Unprocessed Time.
The page to view unprocessed payable time is given below:
On the flip side - I am slightly let down by the fact that Oracle did not come out with more delivered reports in 9.1 - we are still stuck with the same old Time Card, Scheduled Hours, Payable Status and TCD Usage reports. Any area related to Payroll requires extensive reporting and auditing and it would be great for Oracle to come out with something like a Payroll dashboard that would integrate data between AM, T&L and NA Payroll. The job to audit the data consistency between these three modules is not straight forward and easy, while it is critical for business to get the numbers spot on - wouldn't it be wonderful to have an off the shelf suite to audit the entire payroll data and certify that what is being paid out is the correct amount? I would love to see that!Peoplesoft 9.1 - Time and Labor Rule Utilities
Oracle has introduced three new pages for exporting, importing and recompiling rules. This is pretty similar to the Rule Packager utility in Global Payroll and can be found under the familiar navigation of:
Setup HRMS --> System Administration --> Utilities --> Build Time and Labor rules.
The utility uses an Application Engine program to create DMS scripts in the location mentioned on the page. The utility used for exporting rules is shown below:

The page used for recompiling rules is shown below:

My thumps up to Oracle for providing these very needed utilities in 9.1 - this is something the developer community was longing for a long time. In hindsight, projects that are not yet on 9.1, should be looking at building a custom process mimicking the ones mentioned above to automate the process of T&L rule migration, may be I will write on this in detail sometime later.