HR Training Basics - Imp

Oracle Projects and Human Resources
HTTP://PORTAL.ITCONVERGENCE.COM/PORTAL/PAGE?
_PAGEID=33,67471&_DAD=PORTAL&_SCHEMA=PORT
AL
http://southwestregionaloracleapplicationsusergroup.tech.officelive.com/library.aspx
http://repo.solutionbeacon.net/Collab07AutomatingProcuretoPayProcess.pdf
ORACLE PROJECTS AND HR/PAYROLL CAN

ACCOMMODATE YOUR CHANGING ORGANIZATION
STRUCTURE
Susan Beals, BOSS Corporation Inc.,
INTRODUCTION
In todays business world companies are facing many challenges and in order to be
competitive they are faced with changing the environment they operate in. Many of you
reading this paper will have been involved in a corporate merger, acquisition or sale and
have experienced this type of change first hand. When one of these events happens there
are many changes that evolve, one of the first changes involve structural (organization)
name changes. The second change is the merger of data from multiple ERP Systems into
a single system.
Companies using Oracle HRMS know that changing your organizations is core
functionality and when all is considered it is quite an easy accomplishment. However,
when you have an integrated system, including Oracle Projects and the Financials you
add an element of complexity. The merger of data from different systems is a challenge to
any organization, just the element of change management, but this to can be simplified if
approached correctly.
Do not panic, again this is functionality within the system, however, there are some
complexities and considerations that must addressed and planned. The purpose of this
white paper is to take the reader through a real business case to demonstrate how the
introduction of an organizational change, coupled with loading external data, can be done
successfully, where the challenges lay and some of the problems you can expect and
hopefully avoid.
Copyright (C) 2002 BOSS Corporation

All Rights Reserved
Paper #29767
BACKGROUND
In December 2000 TMP Worldwide, a company you may better know as the parent
company to Monster.com, purchased SPEC Group Holding Inc (located in Pittsburgh). In
October 2001 TMP, formerly SPEC Group, engaged a BOSS consultant to:
Assist changing the existing organization structure at SPEC Group and aligning it to
the TMP parent (including name changes) and;
Migrate approximately 400 employees from a separate and distinct operation (in
Tampa) that was purchased by TMP Worldwide. The Tampa operations ran PeopleSoft;
TMP Worldwide runs Oracle and wanted all their newly acquired operations running
on Oracle, including Tampa.
The current Oracle applications were implemented at SPEC Group Holdings (now known
as TMP eResourcing) in January 2000. The modules implemented were Human
Resources, Payroll, General Ledger, Accounts Payable, Accounts Receivable, Purchasing
(limited) and Project Accounting. Multi-organization functionality was not implemented
to support the operations at that time however the existing system can be upgraded to
multi-org if necessary.
TMP eResourcing undertook the organizational changes in their existing system, Oracle
Release 11.03.
Organizations in Oracle are owned by Human Resources, however, they impact several
of the other Oracle Applications in an integrated system, including:
Oracle Human Resources / Payroll
Oracle Accounts Payable
Oracle Purchasing
Oracle Project Accounting (billing and costing)
Each of the above is impacted by changes made to the organization structure and
therefore each must be given consideration and included in the test plan.
Further each of these applications has different dates that they require the changes to be
made. Human Resources processes bi-weekly and weekly payrolls. The final payrolls of
2001 were (W) Dec 17-23 and (B) Dec 03-16, meaning their year-end was December 23 rd
and they had to have the organizational changes in place for the 2002 payroll after this.
Project Accounting however requires the original organizations and hierarchy in place
until December 31st, after their year-end closing they require the new organizational
structure.
SCOPE
AND OBJECTIVES
The following elements comprise the scope of the Organization Change Project and were
included in the Project Plan. The appropriate resources were provided by TMP
eResourcing to support these functions along with one external BOSS Consultant.
TMP eResourcing commenced a project, changing their organization structure to meet
the changes set out by their global management team. TMP eResourcing wanted to be
proactive, not only have a hierarchy and organizations in place for the New Year, but also
to be closer to moving to the global instance when the time came. TMP eResourcing
knows that in early 2002 their operations will become part of a global implementation
that not only requires a multi-org environment but also is using this functionality now.
All Rights Reserved
Paper #29767
The time line, aggressive, the project challenging, however, it was achievable if all the
critical success factors were in place and recognized.
The key objectives for the initiative were quite simple:
Accurate organization setup in the current instance based on the global structure;
Ability to realize growth potential prior to moving to the global instance;
Enable TMP eResourcing to accommodate and move both the Tampa financial
operations and human resources and payroll onto their current system;
Flexibility to meet changing market demands and conditions;
Complete the organization changes for Human Resources by Sunday December 23 rd,
2001;
Complete the organization changes for Project Accounting by Sunday January 6 th,
2002;
Use the standard Oracle applications, Release 11.03;
Minimize business process redesign and customization;
Minimize the amount of conversion and programming required, insuring timeline can
be met and;
Change the SPEC name to TMP where the system permits, do not impact the
timeline to make these changes.
The scope of this project includes the following areas.
PROCESS REENGINEERING
It is anticipated that the changes to the organizations will not change the processes
currently in place and therefore there will be no need to reengineer any of the processes.
However communication will be required with the Tampa group.
CUSTOMIZATIONS
The change in the organizational structure was undertaken around the fiscal year-end
calendar and period year-end to eliminate the need for data conversion, balances or any
other concerns with changes made in mid-cycle.
AUTOMATED PROCESSING
It was decided that the project would benefit from using automated processes in two
areas of the organizational change project, namely:
Updating employee assignments and pay methods and;
Loading new employees from a separate legal entity purchased by TMP Worldwide in
Tampa, (approx. 400)
UPDATING EMPLOYEE ASSIGNMENTS

There are approximately 1200 active employees in the current system that must be linked
to a new organization and their people group must be changed. Originally this task was
going to be handled manually! Using the HR/Payroll specialists within the organization
manually to update each and every active employees record. As we moved forward in
All Rights Reserved
Paper #29767
the project and time became an issue and this approach was tabled. The outcome of
these discussions was to have someone write an update program for both the existing
assignments and pay methods. A BOSS technical consultant with a time line of eighty
(80) hours wrote, and executed the program, including the testing!
ENTERING NEW EMPLOYEES

There were to be an estimated 400 employees that had to be setup in the Oracle 11.03
system from the separate operation in Tampa, PeopleSoft System. There were two ways
to approach this the first, manual entry. Simply have in-house specialists enter the
employees manually into the Oracle system using the basic functionality.
The second alternative considered was to write a program that would automatically hire
the employees from the legacy PeopleSoft system using the existing APIs available. This
approach would require technical resources, data collection, development and testing
time.
The decision was to use the second alternative. However, instead of loading directly from
PeopleSoft the data was downloaded to an Excel Spreadsheet and loaded to Oracle from
Excel through the APIs.
SYSTEM INTERFACES
TMP eResourcing had one external interface to their existing system that had to continue
to work when the organizations were changed and new people loaded. This interface, the
Employee Roster interface is a process that imports timecard and expense data from a
spreadsheet into a custom Oracle table, performs data validation and applies business
rules and then inserts the data in the appropriate Payroll and Projects interface tables.
The Roster Interface would be tested as part of the test program and a review
undertaken to determine if the roster would be impacted by changes to the organization
hierarchy and then corrected if required.
TRAINING
Training was not required or included in the scope of this project. The TMP eResourcing
employees in Pittsburgh were already using the applications and had a full
understanding of how to operate the system and were well aware of the expected
outputs.
TESTING
Application testing consisted of:
Module unit testing and;
Integration testing
MODULE UNIT TESTING

Module Unit Testing included testing each module stand, alone which were impacted
directly by the change to the organization structure. Included in the test plan were
Project Accounting, Human Resources, Payroll, Accounts Payable and Purchasing.
The purpose of module unit testing is to confirm that the module operates as expected
and designed and to insure that the basic transactions can be successfully completed
after the organization hierarchy has been changed. Module testing took place after the
organization changes within the modules had been setup.

All Rights Reserved
Paper #29767
INTEGRATION TESTING
Integration Testing included fully testing the functionality of the applications by
simulating TMP eResourcings current business environment and gaining acceptance
from the team leaders involved in the testing. The external interface, the roster process,
was also tested along with existing reports and SQL queries.
Where applicable, results of the integration tests were compared to existing system
output to confirm the accuracy of the Organization changes. Time constraints did not
allow for a full production parallel and it was not deemed a critical success factor to this
initiative.
CRITICAL SUCCESS FACTORS

In order to achieve a successful organization structural change, several critical success
factors inherently exist. The key factors include:
Strong sponsorship and management support of the project mission and project team;
Adequate project staffing for the expected goals and timeline to be met;
A comprehensive project work plan to meet the timeline and goals of the project;
A test instance ready to work in by October 22nd to begin the changes required and;
Agreed upon goals for both Human Resources and Project Accounting team (including
Org Names).
KEY ASSUMPTIONS
TMP eResourcing currently uses Release 11.03, however the objective is to move to
Oracle Release 11i in a single global instance in 2002.
The purpose of aligning the system setup as closely as possible to the global installation
is to reduce rework when TMP eResourcing begins their global implementation.
The assumptions include:
One (1) set of books will be maintained, the one currently setup;
One (1) business group will be maintained, but will be renamed to follow the naming
convention: TMP eResourcing Business Group
The business group setups will not be changed manual employee numbering,
flexfield structures or legislation
The two- (2) legal entities were identified by TMP eResourcing and were to be setup
by renaming existing legal entities.
PROJECT APPROACH
The approach to change the existing organization structure is comprised of the following
high level tasks that are supported by the project plan and each of these is discussed
briefly later in this section.
OVERVIEW
All the initial work on the organization structure change occurred in the Test Instance.
This was then to be replicated in Production at year-end, prior to commencing fiscal year
2002 business.
All Rights Reserved
Paper #29767
The approach was structured to provide TMP eResourcing with a process, supported by a
plan to change their existing Oracle Organization Structure in Release 11.03 by
December 31, 2001. The approach was highly task driven, aggressive and designed to
leverage the unique skill sets of the TMP eResourcing organization and BOSS consultant.
Task
No.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Configuration Task Descriptions

Create New Locations
Rename Business Group
Rename Legal Entities
Create new Operating Unit, disable old operating unit
Create new Chart of Account Values
Rename Set of Books Name
Enter New Organizations
Create New Hierarchy
Enter People Group value
Review, Change Consolidation Set
Create New Payment Methods
Create New Payroll Names
Assign Pay Methods to New Payrolls
Employee Data Load via APIs
End date Element Links and Create New Links
Run Payroll Roster (Dec 10)
Run Payroll (Dec 17)
Update Employee Assignments (automated program)
Update Pay Methods (automated program)
Re-link Elements to Employees (element entry)
Run payroll Roster (Dec 17)
Run Payroll (Dec 24)
Run Payroll Roster (Dec 24) final 2001 payroll
Run Payroll (Dec 31) final 2001 payroll
Set New Organization as the Primary Hierarchy
Run Payroll Roster (Dec 31) first of 2002
Run Payroll (Jan 7) first of 2002
Process and complete 2001 Financial Year-end
Disable Project Classes
Close 2001 Projects
Change PA Implementation Options
Update Project Burdening Hierarchy
All Rights Reserved
Paper #29767
Completion Date
December 3
December 3
December 3
December 3
Not Applicable
December 4
December 4
December 4
December 4
Not Applicable
December 10
December 10
December 10
December 16
December 12
December 11
December 13
December 14
December 14
December 21
December 17
December 21
December 24
December 27
January 2
December 24
December 27
January 6
January 6
January 6
January 6
January 2
33
34
35
36
37
38
33
34
January 2
January 2
January 2
January 2
January 2
January 2
January 10
On-Going
Change Burden Structure

Update Burden Schedules
Change Non-Labor Resources
Create New Templates
Change Project Owning Organizations
Auto Accounting Rules
System Delivery
Lessons Learned
Figure 1: Project Task List
PROJECT PLAN
The project plan is the document that the team used to provide the boundaries and
timeline of the project. The plan was a rolling document and continually changed as we
moved through the project. Below is a high level timeline of the milestones targeted
based on the scope and objectives, year-end and budget.
Task Description
Oct
Nov
Dec
Jan
Kick Off
Technical Requirements System
Available
Test Scripts Unit and Integration
HR and Payroll Test Configuration
Develop Data Load Program
Develop Assignment Update
Program
Develop Pay Method Update
Program
Collect Data Load Information
Cleanse Data Load Information
Create Assignment Spreadsheets
Create Pay Method Spreadsheets
Projects & Financial
Configuration
Module & Integration Testing
Identify issues, Correct and
Retest
Configure Production
Figure 2: Project Plan Summary Timeline
DETAILS
AND
SETUP
The following briefly describes what has to be done during each task and the timeline for
completion. This is an aggressive timeline so it is imperative that each task is completed
All Rights Reserved
Paper #29767
on time to move forward to meet the target dates. We had 10 weeks to complete the
project in order to avoid issues relating to year-end and payroll. In addition, the project
team had to address the normal payroll year-end procedures and insure that they were
completed prior to the need to apply year-end patches and prepare W-2s.
KICK OFF
The kickoff meeting was held to make all the key project members aware of what the
timeline was the objective and the roles each person would play in the project going
forward.
TECHNICAL REQUIREMENTS
The Database Administrator had to insure there was a test system available to the project
team, that would be able to meet the requirements and that there was enough disk space.
Further, this individual granted access to the test system.
HR/PAYROLL CONFIGURATION
In order to configure the system the team members had to know what areas had to be
configured. This was managed by the consultant and documented into manageable
tasks with explanations of what had to be done and the timeline for each task. There
were some that took only minutes, such as setting the PA Implementation Options and
others that took several days, for example end dating the over 1,970 element links in the
system.
The configuration task summary included:
CREATE NEW LOCATIONS
All organizations require a location. The new organizations being created required a
location be setup and available to select from the list of values in the organization
window.
RENAME BUSINESS GROUP
TMP eResourcings current system is not Multi-Org. Therefore, only one business group
will be recognized in this environment. In order to successfully achieve the goal set we
renamed the existing business group.
RENAME LEGAL ENTITIES
Legal entities are those organizations that are recognized as legal companies for tax
reporting purposes. TMP eResourcing had five legal entities in their existing structure,
but were going to one that supported only two legal entities. The approach taken was to
rename the two legal entities that remained and end date the ones that were no longer
required by the organization.

Figure 3: Before the Rename
All Rights Reserved
Paper #29767
Figure 4: After the Rename

CREATE NEW OPERATING UNIT
Operating units are what partition the data and are important in a multi-org environment.
In the original configuration of the system the Business Unit was classified as the
Operating Unit. It was decided to setup a separate operating unit that will allow TMP
eResourcing the ability to shift to the global multi-org environment in 2002.
CHART OF ACCOUNT VALUES

The chart of account values are used by the key flexfields, including the costing flexfield
used by Payroll (found on the element link) and on the organization setup screen under
the classification HR Organization. The chart of accounts had to be updated to include
the new organizations since TMP eResourcing costs based on Reporting Unit.
Note: The actual Value column cannot be change, only the description can be changed.
Where possible the description will be changed. If this is not possible then the value will
be disabled and a new value created in its place.

All Rights Reserved
Paper #29767
Figure 5: Value Sets, Account Flexfield. Insert new values
SET OF BOOKS NAME

The current set of books was defined as using SPEC, this is found in the Name,
Description and Short Name of the set of books definition. Two of the three fields can be
changed, Short Name and Description. The Name itself cannot be changed and was left
as SPEC.
Figure 6: Set of Books Window

CREATE NEW ORGANIZATIONS
The main reason TMP eResourcing undertook this initiative was to recognize the
organization changes resulting from the sale of SPEC Group Holdings Inc. to TMP
All Rights Reserved
Paper #29767
Worldwide. These changes had to be implemented into their Oracle System.

Setting up the organizations was not as simple as might have been expected; our testing
revealed an issue, outlined as follows:
Issue #1: Organization Classifications
When you create a new organization you must classify it. TMP eResourcing had four
classifications that needed to be attached to their reporting units; they were HR
Organization, Project Expenditure/Event Organization, Project Invoice Collection
Organization and Project Task Owning Organization.
There is an issue with classifying organizations when using both the Project Owning and
HR Organizations. After creating the new organizations and classifying them with the
four classifications required, they were put into the new hierarchy. When opening a
Project in Oracle Projects and opening the List of Values in the Project Organization we
could not see any of the new organizations created in the list of values.
A workaround was found on Meta Link as well as associated information on a TAR raised
in July 2000. The workaround enabled us to get where we needed to be. In order to see
organizations in List of Values we must:
Pre-Requisite: PA Implementation Options Must Point to the New Hierarchy
Setup the new organization (this step had already been completed);
Classify organizations with Project information only (do not classify it as a HR

Organization at this point);
Connect the organization to the new hierarchy;
Classify organization as HR Organizations;
Open Oracle Projects and in any project confirm that you can see the organization in
the list of values, when you have confirmed that you can see the organization then
continue and the setup steps as shown above.
Although this is a somewhat tedious method of setting up organizations it did get us past
the problem.
Of course we discovered the problem after we had created our
organizations, classified them and linked them to the new hierarchy. In order to fix the
problem we had to remove them from the hierarchy, disable all classifications and then
begin the workaround steps.
Note: This issue is also a bug and has an associated number assigned to it by Oracle,
#1136773
NEW ORGANIZATION HIERARCHY
A new hierarchy was created, but it was not turned on as the primary hierarchy. The new
hierarchy had to exist with the original Primary hierarchy until year-end when HR/Payroll
was ready to change the primary hierarchy.
Issue #2: Organization Classified as Project Expenditure/Event Organizations
After creating the organizations and the hierarchy Unit Testing began in Accounts
Payable. Very simple and high level to confirm organizations were available and in the
drop down list (if classified as Project Expenditure/Event Organizations).
The problem was in our Development Instance, which we had patched with the
mandatory year-end patches. The new organizations did not appear in the list of values
All Rights Reserved
Paper #29767
in the distribution lines of AP when we were trying to charge a project. We could only see
organizations that were classified as both Project Owning and Project Expenditure.
However, in out TEST Instance, where the patches had not been applied we could see all
the organizations.
Figure 7: Development Instance, Accounts Payable Invoice Expenditure Organization

List of Values
Our first problem, identifying where this problem falls Is it an AP Problem? HR? or PA?
Resolution Steps:
1. We searched Meta Link and found nothing;
2. Raised a TAR which was bounced from AP to HR to PA where it remained;
3. Eliminated the possibility that the problem resulted from the application of the
mandatory patch set;
4. Oracle PA support felt it was a PA Patch that was required.
5. Finally, on November 7th, support finally offered, The issue is an AP Bug and there is
no current resolution.
The workaround, you must classify organizations as both Expenditure and Project
Owning in order to have them appear in the list of values in AP, at least until the Bug is
corrected.

All Rights Reserved
Paper #29767
Figure 8: Organization Classification Project Information

DEFINE PEOPLE GROUP VALUE
The current People Group was defined to point to the reporting unit organization for the
purpose of costing in the balancing segment. During our review and requirements the
financial team determined that this information was not necessary and that summary
information was acceptable for payroll costing. The details after all come from Oracle
Projects. Therefore we created a Default Value for the people group to assign to all
current and future employees.
Note 1: The original People Group was going to be numeric however the when loading
data through the API having a numeric value made the load more difficult. To
accommodate the load the value was changed to alpha and was loaded without incident
(we were confident this could have easily been corrected, but time constraints prevented
us from making the fix when an easier solution presented itself). Something you may
want too keep in mind if you are undertaking this type of data load.
Note 2: When the program to update the assignment screen was being run the
programmer could not see the value = Default. We discovered that in order to see it in
the tables it had to be manually entered and committed in at least one employee record.
After the value was committed to one employees assignment it appeared in the table.
CONSOLIDATION SET
Originally we were going to rename the consolidation set, however since this does not
appear anywhere other then in payroll, it was decided to leave it alone and eliminate any
testing time that could be used elsewhere.
CREATE NEW PAY METHODS
The pay methods define the method employees are paid. Examples include Nacha and
All Rights Reserved
Paper #29767
Check. The current payment methods used SPEC in the names and this had to be
changed to reflect the TMP name. Pay Methods cannot be renamed, you must create new
pay methods.
RENAME PAYROLLS
The payrolls were defined during the original implementation and used the SPEC Group
name. The system allows you to rename payrolls. The benefit of this, initially, before we
were going to automate the assignment update, was that the name change would simply
carry through to the assignment screen for employees, in all but one case. The following
illustrates:
IT Solutions BiWeekly eliminated
SPEC ATS TMP MGMTWeekly (renamed)
SPEC ATS BiWeekly TMP MGMTBiWeekly (renamed)
SPEC Group BiWeekly TMP HOLDING-BiWeekly (renamed)
SPEC Group Weekly eliminated
Life Cycle - eliminated
As you can see from the above anyone who was in the SPEC ATS or SPEC Group Biweekly because of the renaming of the payroll it carried through to their assignment
screen. The problem was with the IT Solutions Group. Although the payroll was being
eliminated these individuals had to be updated to one of the other new payrolls.
ASSIGN VALID PAY METHODS TO PAYROLLS
The new payment methods had to be assigned to the payrolls so they could be used on
the employee pay methods.

Figure 9: Assign Valid Payment Methods to Payroll
EMPLOYEE DATA LOAD
There were approximately 400 employees that resided in the Tampa Operations. These
individuals were to be moved from the existing PeopleSoft system and into Oracle Payroll.
They had to be in system for inclusion in the 2002 payroll; however, they did not have to
be in the system for any 2001 processing.
An in-house resource wrote the program to call the APIs and load the employee
information required:
People Information
Address
Assignment Screen
Pay Method
All Rights Reserved
Paper #29767
The information that was not included in the data load, the main reason being time
constraints, were Salary Basis, Federal and State Withholding and Contact Information
The problems we encountered with the data load were primarily found in the data
collection. We had a very difficult time getting someone in the Tampa Operations who
could provide what was needed to load. There were also concerns with the integrity of
the data.
Issues: We faced several issues we were not prepared for including:
1. Lack of support and willingness to assist;
2. Not wanting to change from PeopleSoft to Oracle;
3. No point person for us to obtain information from and approach on validation;
4. Poor record keeping and system maintenance
5. No accountability
GRES AND OTHER DATA UPDATING
The government reporting entity and timecard required information had to be updated as
part of the employee data load. As noted TMP went from five legal entities to two. The
legal entities are tied to the payroll the program was able to identify which legal entity an
employee belonged to based on their payroll. The timecard required was to be defaulted
to YES for all employees.

Figure 10: GREs and other data
During the data load, one employee was set to No in the timecard required field. The
impact of this, an employee who did not have hours submitted during a pay period were
paid based on their standard conditions (40 hours per week). As a bi-weekly employee
this meant they were paid for 80 hours when in fact they should not have been paid at all.
How did we find out about this? We were lucky, this individual knew they should not have
been paid and notified the payroll department of the error. If the employee had not
notified payroll, this error could easily have gone undetected.
Figure 11: Standard Conditions (40 hour work week)

All Rights Reserved
Paper #29767
When the payroll is processed and the Timecard Required is set to NO the results are
shown in Figure 12, the system uses the Regular Wages to pay the person based on their
working conditions above. This is incorrect at TMP, everyone should be paid through
their REGULAR PAY element and in some cases they are not paid if they had no hours
worked.
Figure 12: Statement of Earnings (Incorrect Results)
ELEMENT LINKING
The elements were linked with approximately 20 links per element thereby creating
1,978 element links. The reason for the numerous links was based on the original need
to populate the reporting unit segment in the balancing entry. Based on the decisions by
the financial team, they didnt need payroll costing at a detail level, we were able to
eliminate all the People Group Criteria on their Element Links. We setup costing at the
balancing segment level that pointed to the natural account and a default legal entity.
This reduced the number of element links down to approximately 139!
The big decision and one that took a lot of time and consideration was the Effective
Dating of the various components in the system. It was ultimately decided that:
Element Links end dated on 16-Dec-01
Element Links re-linked on 17-Dec-01
Employee Assignments end dated on 16-Dec-01, the new assignment started on 17Dec-01
Employee Pay Methods same as the employee assignments
Payment Methods created on 17-Dec-01
Element Entry effective start date of 17-Dec-01 at the employee level.
When looking at the payrolls, both bi-weekly and weekly this seemed appropriate and no
issues were anticipated. However there were issue coming!
Note: when attempting to end date elements, we ran into situations where we could not
end date an element because someone had added the element at a future date for an
employee. Using Toad we were able to query the database and isolate the individuals
who had the elements future dated and then remove them.
UPDATE EMPLOYEE ASSIGNMENTS
The changes we made particularly to Organizations, People Group, Legal Entities and
Payroll Names all impact the employee assignments. The result was that all active
All Rights Reserved
Paper #29767
employees had to have their assignment screen UPDATED to reflect the change.
As noted above, this was going to be achieved through manual input, however it was
decided on or about December 1st that we should automate this process. Requirements
were developed and a BOSS Programmer was engaged to create the program necessary
for us within 90 hours!
While the programmer was developing the program the payroll group realized that not all
employees could be updated on the same date, 17-Dec (problem note above in Element
Linking). Instead, the weekly employees had to be updated on 24-Dec in order to run
their final 2001 payroll (Dec 17-23).
These changes were communicated to the
programmer who included them in the program.
The results of the program are displayed below, showing an employees assignment
screen and the changes made to:
Organization
Group
Payroll (this person was formerly part of the IT Solutions Payroll)
Effective Date
Figure 13: Employee Assignment after Update Program Completed
PAY METHOD UPDATING

Like the assignments, pay methods for all the existing employees had to be updated or
manually changed. It was decided that the pay methods should be updated as part of the
same program that updated the assignment screens and the programmer included this in
the requirements.
Employees pay methods were updated on the same date as their Effective Assignment
start date (17-Dec or 24-Dec). The final consideration was pre-noting. As you know prenoting is something the Oracle Payroll system does as part of the new hire process.
Simply, pre-noting insures that a persons direct deposit information is valid and will
All Rights Reserved
Paper #29767
process correctly to their banking institution.

TMP eResourcing did not want to interrupt payroll processing (they wanted it
transparent to employees, both current and those loaded into Oracle). The programmer
communicated that there is no field in the tables that can be selected for override.
Although most things can be done it is not recommended you override this at the table
level. Based on this recommendation it was decided that Payroll Specialists would
manually override the pre-note on all 1200 employees. This also afforded them the
opportunity to eyeball the update.
This really was not the best decision. It would have been better to let the system
operate, as it was designed and do the pre-noting. Even though employees would have
been inconvenienced somewhat by receiving a check, it would have prevented an error
that could have been quite large and potentially very costly for TMP eResourcing.
Pre Note Issue our means of collecting existing employees data, both assignment and
pay method was using Excel Spreadsheets created from a database dump. There were
many people who had access to the spreadsheet and it was changed many times by many
people.
The programmer used this spreadsheet and formatted it further for the program update.
What happened and was discovered on 24-Dec after payroll and direct deposit
processing, was that approximately 60 employees had incorrect account information in
their pay method screen. The result, some were paid twice; some were not paid at all.
There were many moments of panic when the initial errors were found, actions
determined to correct the situation and then contacting banks to recover the funds.
What happened? In essence know one can definitely say This Happened, This Was the
Cause. We simply cannot determine the exact cause or who was to blame. What we do
know that somehow the spreadsheet columns and rows were shifted, how only 60
employees in the middle were affected we do not know. What we do know is it could have
been avoided by using the functionality of Oracle and letting the system pre-note the
employees for us.
PAYROLL RUN (2001)

The final payrolls had to be run for 2001 against the old organizations and payrolls, they
were:
Bi-Weekly:
03-Dec to 16-Dec
Weekly:
10-Dec to 16-Dec
Pay Date:
24-Dec-01
Weekly:
17-Dec to 23-Dec
Pay Date:
30-Dec
The bi-weekly and weekly payrolls both ran successfully, however, when the Nacha was
created for the bi-weekly payroll for the former IT Solutions Group there was a
processing error. The problem encountered was the date used for the assignment
update. The system was looking for the old legal entity IT Solutions on 24-Dec, of
All Rights Reserved
Paper #29767
course it was no longer valid, we changed it.

The quick fix was to correct the assignment screens for these employees, there were not
many (less then 50) so we were able to do this manually, after the payroll was rolled
back, assignments were updated on 25-Dec for these employees.
ELEMENT ENTRY (EMPLOYEE LEVEL)
When the elements were end dated this impacted the element entry level for all existing
employees. In order to insure that employees pay remained correct and that the process
was transparent too them the elements had to be re-linked for all employees.
In order to achieve this in the most efficient way available, base functionality of the
system was used, namely BEE (Batch Element Entry).
We used two methods to ascertain which elements employees had, the first was a data
dump was done on 16-Dec-01 (prior to element end dating). The second tool used was the
View / Lists / Emps by Elements within Oracle. This provided a list of every employee
who had specific elements.
Using these two tools we were able to create Batch Element Entries, using the effective
date of 17-Dec or 25-Dec (based on our findings with the payroll run above).
The first is the header or information screen. It is here that the information on the
batch is determined and a naming convention was determined to make it easy to find
batches if required.
Figure 14: Batch Element Entry Header Screen
The second form required is the actual element entry form and the information that is
mandatory is the element name and the employee number. In some cases there are input
values required, such as 401K percentages and coverage on medical deductions.

All Rights Reserved
Paper #29767
Figure 15: Batch Line Entry

Batches are created and saved. When completed and finalized they were validated and
then transferred (the status appears on the header batch).
The elements are
automatically linked to each of the employees in the batch along with the associated
input value.
SET PRIMARY HIERARCHY
When the setups are completed and human resources and payroll are processing in 2002
the primary hierarchy should be changed to the new Hierarchy, the one that contains all
the new organizations

Figure 16: Set primary hierarchy
PAYROLL RUN (2002)
It was time to run the first payroll for 2002 using the new hierarchy and new
organizations. The first payroll for 2002 included both bi-weekly (17-Dec to 30-Dec) and
weekly (24-Dec to 30-Dec). They ran successfully, however we did have problems with
the Wage Attachments. Those employees who had garnishments prior to our update
needed to be reviewed, as there were issues with the update.
The problem was the direct result of how the pay methods were originally setup for
employees. For example, an employee hired with direct deposit on 01-Jan-98 was given
the priority 1. Then on 01-Apr-00 the employee had a wage attachment added. As you
know when you setup a wage attachment the system automatically default the priority to
a 1, in several cases the person setting up the attachment did not change the direct
deposit of the employees pay to a different priority. This meant there were two pay
methods with a priority 1 in the system for the same person. The programmer who
wrote the update program did not account for this setup error and the update program
had issues when it encountered two Priority 1s.
PROCESS FINANCIAL YEAR-END
All Rights Reserved
Paper #29767
The year-end process had to be completed, financial statements generated and closings
completed for fiscal 2001 against the old organizations. When the fiscal year was closed,
then the modifications could be made in Oracle Projects to reflect the changes to
organizations.
DISABLE ORGANIZATION CLASSIFICATIONS
The old organizations classified as Project Owning Organizations could still be seen in the
list of values in project accounting. To avoid anyone in Projects using an erroneous
organization in error the radio button was turned off on the classification and the
organization end dated at 31-Dec-01.
Figure 17: Disable Org Classifications

CLOSE 2001 PROJECTS
The Open 2001 projects that are finished must be closed (part of the year-end process).
Further projects that require a new organization have to be changed to reflect the new
organization changes.
PA IMPLEMENTATION OPTIONS
The implementation options in Project Accounting tell the system where to look for
certain pieces of information; one of the key pieces used by the Implementation Options
is the Organization Hierarchy. PA points to the hierarchies it uses for a) Reporting
Organization b) Project/Task Owning Organization and c) Expenditure/Event Owning
Organization. When PA was initially configured the organization hierarchy used was the
Primary Hierarchy, however; this needs to be changed to point to the new hierarchy.
Note: You cannot select organizations in Projects if the organization you are trying to
select is not in the hierarchy structure the Options are pointed to.
All Rights Reserved
Paper #29767
BURDEN HIERARCHY
The burden hierarchy is the hierarchy used by projects to show which organizations are
Project Burdening Organizations. The burden hierarchy is found on the Business Group
organization in the Org Classifications. The problem (TAR #1799814.995) is that the
system does not allow you to change the burden hierarchy (select a new hierarchy).
Therefore, the only available workaround is to maintain the original hierarchy created
and include the new organizations. In fact, there are now two hierarchies with the same
organizations, the newly created primary hierarchy and the burden hierarchy, which in
this case was the original primary hierarchy.
Figure 18: Project Burdening Hierarchy (cannot be updated)
BURDEN STRUCTURE
Burden structures at TMP are used to apply additional costs incurred on work performed.
All Rights Reserved
Paper #29767
The structures were named with the prefix SPEC. Burden structures cannot be
changed when they are used by a Burden Schedule. One of the objectives included
changing SPEC to TMP where possible, however, if the system didnt permit this then the
name was to remain as SPEC.
BURDEN SCHEDULES
The schedules, like the structures include the name SPEC. It was decided to leave the
schedule names. However, the burden schedules use the organizations to apply the
multipliers and therefore the new organizations must be added. There are two options
available and TMP considered them both.
1. End date the existing burden schedule and create a new schedule with the new
organizations
2. Add the new organizations into the existing schedule.
The second option was decided upon for the simple reason, that if the schedules were
separated and end dated if an old organization was used or remained in the system there
would be processing errors. It was felt that Option #2 would avoid processing errors.
NON-LABOR RESOURCES
TMP only has one non-labor resource schedule, FILM-USAGE, and it points to
organizations. The organizations in this list had to include the new organizations. Again
the question arose, do we end date the old organizations or leave them open? It was
decided that they would be left open and that in mid-2002 the PA Administrator would go
back into the setups and end date the non-labor resources and the organization
classifications.
NEW TEMPLATES
The templates in Oracle Projects point to the old organizations at both the top task level
and at the lower level task. Unfortunately the system does not allow you to change the
organization at the top task level. The process at TMP is to copy from an existing
template and the individual setting up the project from the template automatically
changes the organization. Therefore, TMP opted to leave the templates, even though they
had an old organization, since there was no impact to the procedure used. In the future,
they will copy from the old template and change to a new organization when time
permits.
CHANGE PROJECT OWNING ORGANIZATIONS
The projects that will be active into the next fiscal year currently are pointing to the old
organizations. Therefore the owning organizations must be changed and pointed to the
new org. This can be done for projects, but not templates. TMP Worldwide has very few
projects that span multiple years, the majority of their projects end within the calendar
year so there are not a lot that require organization changes.
Remember: When you change an organization in a project you must make the changes at
the task level as well, it doesnt carry through like it did when you initially setup the
project.
UPDATE AUTO ACCOUNTING
The auto accounting rules pass the costing information from projects to general ledger.
TMP has several lookups that use Organizations to drive the value sets. Therefore these
rules had to be changed after all the year-end processing has been completed.
All Rights Reserved
Paper #29767
In order to avoid any auto accounting and processing errors the decision was made to
simply add the new organizations into the Lookups and leave the old organizations in the
lookup listing. This way the auto accounting rules could be changed at any time without
concerns for year-end. The PA Administrator will clean up the rules and remove the old
organizations form the lookups in mid-year.
MODULE
AND INTEGRATION
TESTING
Module testing for human resources and payroll was the first in the testing series. The
key focus areas for testing were:
1. Ability to hire and terminate
2. Ability to update and correct assignment and pay method screens
3. Run the Employee Roster against both new and updated employees
4. Process payrolls from the Roster data
5. Create checks
6. Create direct deposits
7. Run the reports required, delivered and custom
During the module testing the following issues were documented:
1. Inability to change the Project Burdening Hierarchy at the Business Group Level
2. Not able to view organizations in the list of values in Project Accounting
3. Correct and accurate data for the data load.
The integration testing occurred when both projects and human resources were
configured. The team had five days to complete the integration testing and fix error.
There were no issues documented during the testing, we were lucky.
Payroll processed and costing was transferred to General Ledger without incident.
Payable costs were also transferred between GL and PA.
The only change remaining was the Pay Groups in Payables where employee expenses
processes and the pay groups were based on the old organization names.
PAYABLES (SUPPLIER) ISSUE
Of course it was too good to be true, we did encounter an issue in Payables processing
employees expenses. When we pull the employee expenses from Projects into Payables
the system determines if the employee is setup as a supplier, if they are not then they are
setup.
Figure 19: Submit Request Window, Payables Invoice Import

All Rights Reserved
Paper #29767
Select Oracle Projects as the Source of the Import.
Figure 20:Parameters Window of Payables Invoice Import

The supplier setup occurs in Supplier Entry, pulling the information from the
PER_PEOPLE_ALL Table and includes the Employees Name, Number, Address and Bank
information, with the default pay method of Check.
Before we process an employee expense payment manual changes to the employees
supplier record are made. One of the changes made is changing the pay method from
Check to Electronic where applicable.
This is where we encountered our problem we encountered was a form error and
occurred on all regions under the SITE.
Figure 21: Error Message in Supplier Window

The error only occurred on employees we loaded into the system using the API. No other
employees were impacted. We searched Meta Link for a possible solution and found what
we suspected, an error in the data load, a leading or trailing space in the address screen.
Our technical resources searched the system and found no leading or trailing spaces.
While the technical team looked for the problem, the functional team sought a
workaround so that the people could be paid (ultimately we issued checks to employees
and for the few who had to have direct deposit wire transfers were arranged). One of the
things the functional team tried was to manually re-enter the employee address in
Human Resources whereby we changed 111 W Anywhere St to 111 West Anywhere
Street. Then we ran the processes again. The objective, the supplier screen in Payables
will update the Address information when changes are made in HR. We hoped that the
system would correct itself if we changed the address through the form. It did not.

All Rights Reserved
Paper #29767
Finally, we discovered another possibility, not spaces, but Unprintable Characters, such
as a CTL, DEL, TAB or some other keyboard stroke made during the load and inserted
into the database table that cannot be viewed or printed. Meta Link provided a script to
run to find these characters and we found that over 602 records had these types of
characters, we only loaded 569 records.
We did not have a test system at the time to verify that we could run the corrective script
on all the records because we were also testing year-end patches. The D.B.A. really did
not want to run the script against all the records when we were not sure of the
repercussions. Therefore, we opted to correct them one at a time (we only had six that
had to be updated) and when we did have a copy of PROD (expected 4 days hence) we
would correct all records and confirm that there were no problems with this fix.
SYSTEM DELIVERY
The system will be fully configured, processes completed, such as payroll and year-end
and the system will be ready for fiscal 2002. TMP must be able to use their system
without interruption to maintain their revenue cycle and their payrolls without any
impacts as a result of the organizational changes made.
LESSONS LEARNED
The key lessons learned from this project were quite simple, let Oracle function as it was
designed. Although it is always difficult to manage change, especially when employees
payroll is involved, this type of project did mean change and if we had addressed the
change and managed it instead of trying to accommodate employees we would have
avoided some of the issues we faced.
SUMMARY OF ISSUES ENCOUNTERED

Like all projects this was a learning experience and it provided us with insights for any
future organizational changes and has allowed us to identify the areas to approach
cautiously to avoid the pitfalls encountered.
To summarize the issues we faced, the were:
1. Unprintable characters that occurred during our data load;
2. The pre-note issue, if we had let the system process as designed we would not have
had the problems we did, the pre-noting would have found the incorrect account
information populated;
3. Inability to change the burdening hierarchy at the Business Group Level;
4. Setup of Organization Classifications in order to see the organizations in Project
Accounting;
5. Requirement to classify organizations as both Project Task Owning and Expenditure
Organizations in order for them to appear in the AP drop down list;
6. Necessity to assign one person to the new People Group value in order to see the
value at the database level;
7. The necessity of running confirmation and verification reports after a data load to
insure that all the fields expected to be populated were , for example the timecard
required field on the assignment screen;
8. End dating element links because of future dated entries on employees screen;
All Rights Reserved
Paper #29767
9. Finally, we realized that there are dimensions of human nature that must be
considered, especially in then presence of mergers and acquisitions such as;
Lack of support and accountability
Delays in receiving information
Inaccurate information received
It is important to remember that like all projects this project also had time constraints
and in the perfect world many of the issues above would have been found, like the
timecard required, because we would have had the time to run the verifications required.
The management decision made was we have to sacrifice somewhere and so some of the
things we should have done were not.
From these lessons we know what to watch for when we have to do this type of upload
again, what not to do, what to do and what to consider in the face of organizational
change, including the impacts on the people.

All Rights Reserved
Paper #29767

HR Training Basics - Imp

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

HR Training Basics - Imp

Enviado por

Direitos autorais:

Formatos disponíveis

Oracle Projects and Human Resources

ORACLE PROJECTS AND HR/PAYROLL CAN

Copyright (C) 2002 BOSS Corporation

Oracle Projects and Human Resources

Oracle Human Resources / Payroll

Oracle Accounts Payable

Oracle Project Accounting (billing and costing)

Oracle Projects and Human Resources

Ability to realize growth potential prior to moving to the global instance;

Flexibility to meet changing market demands and conditions;

Use the standard Oracle applications, Release 11.03;

Minimize business process redesign and customization;

The scope of this project includes the following areas.

Updating employee assignments and pay methods and;

UPDATING EMPLOYEE ASSIGNMENTS

Oracle Projects and Human Resources

ENTERING NEW EMPLOYEES

Module unit testing and;

MODULE UNIT TESTING

Copyright (C) 2002 BOSS Corporation

Oracle Projects and Human Resources

CRITICAL SUCCESS FACTORS

Oracle Projects and Human Resources

Configuration Task Descriptions

Oracle Projects and Human Resources

Change Burden Structure

Figure 1: Project Task List

Oracle Projects and Human Resources

required by the organization.

Oracle Projects and Human Resources

Figure 4: After the Rename

CHART OF ACCOUNT VALUES

Copyright (C) 2002 BOSS Corporation

Oracle Projects and Human Resources

Figure 5: Value Sets, Account Flexfield. Insert new values

SET OF BOOKS NAME

Figure 6: Set of Books Window

Oracle Projects and Human Resources

Worldwide. These changes had to be implemented into their Oracle System.

Classify organizations with Project information only (do not classify it as a HR

Connect the organization to the new hierarchy;

Classify organization as HR Organizations;

Oracle Projects and Human Resources

Figure 7: Development Instance, Accounts Payable Invoice Expenditure Organization

Copyright (C) 2002 BOSS Corporation

Oracle Projects and Human Resources

Figure 8: Organization Classification Project Information

Oracle Projects and Human Resources

the employee pay methods.

Oracle Projects and Human Resources

to YES for all employees.

Copyright (C) 2002 BOSS Corporation

Oracle Projects and Human Resources

Element Links end dated on 16-Dec-01

Element Links re-linked on 17-Dec-01

Employee Pay Methods same as the employee assignments

Payment Methods created on 17-Dec-01

Element Entry effective start date of 17-Dec-01 at the employee level.

Oracle Projects and Human Resources

Figure 13: Employee Assignment after Update Program Completed

PAY METHOD UPDATING

Oracle Projects and Human Resources

process correctly to their banking institution.