Understanding Job Data

Adding New Job Records through the PeopleSoft Services Procurement Integration

A new job record may also be created in the system if your organization uses the PeopleSoft Services Procurement product within the PeopleSoft Supply Chain Management (SCM) database. The PeopleSoft applications deliver integration points that enable you to use PeopleSoft Human Resources as your system of record for contingent workers who are brought in to fill PeopleSoft Services Procurement requisitions.

When a work order is submitted in Services Procurement, the Services Procurement application does the following:

1. If the Services Procurement service provider is a new candidate, Services Procurement sends a message to Human Resources requesting Human Resources to add this person with an organizational relationship of contingent worker, add a job assignment, and create a user profile.

2. If the Services Procurement candidate already exists in the Human Resources system, Services Procurement sends a message with this person's ID requesting Human Resources to create a new job assignment for this person.

3. When a Services Procurement work order is closed or cancelled, Services Procurement sends a termination message to Human Resources. Human Resources then terminates the associated job assignment.

Human Resources uses the Component Interface (CI) and internal services to add the person, job, and user profile. This integration is automated and requires manual intervention only if there is a problem. For example, let's say Human Resources has successfully added a person profile from a Services Procurement request but encountered errors when creating the job assignment, such as an incorrect job code or location code. Human Resources sends a message back to Services Procurement stating that the person was created but the job assignment and user profile were not created and lists the error details. A Services Procurement administrator will then access the error correction page, correct the data, and resubmit the request. Human Resources will process the updated information, create the job assignment and user profile, and send an acknowledgement back to Services Procurement.

Additional integration enables you to use Services Procurement to search for contingent workers as an alternate source of filling job postings in PeopleSoft Talent Acquisition Manager. When you use this integration, and a new Services Procurement candidate is sent to Talent Acquisition Manager for hiring. Talent Acquisition Manager initiates the hire process and sends all necessary Human Resources data to Services Procurement to add the contingent worker information. When the hire is successful, Talent Acquisition Manager sends a message to Services Procurement stating that the candidate was added. At this point, Services Procurement will send a message to Human Resources to add a user profile for this candidate in the Human Resources system. Human Resources will add the user profile and send an acknowledge message. Services Procurement continues to send messages directly to the Human Resources system when it is time to terminate the Services Procurement service provider.

See PeopleSoft Services Procurement

See Posting Jobs to PeopleSoft Services Procurement.

Understanding the Job Data Pages

The information that you enter when you add a new employment, contingent worker, or POI instance is the foundation for most of the business processes that you carry out later. That information includes the following:

• General employment information.

  Includes business title and work phone. This information is optional, but useful for reporting purposes.

• Specific job data.

  Includes the person's department, job code, company, supervisor, and compensation information.

• Earnings data.

  This information is included if the person's compensation comes from more than one department or category. You specify how to distribute the person's earnings among the sponsoring groups.

• Benefits program.

After you enter job information into the system, you can work with it in a variety of ways. For example, you can generate printed reports, view summary data pages, and perform ad hoc queries online. You can also use job data as the basis for performing tasks in all other aspects of human resources management, such as salary administration, regulatory requirements, payroll, and benefits.

Understanding Employment Information Data

Unlike the data on the Job Data pages, the information on the Employment Information page isn't effective-dated, so the data that you enter and review on this page tells you about the worker's current information for this employment record number.

This means that if you rehire a worker and enter a future effective date, the system deselects the Termination Date and Assignment End Date fields. To review information that is in other data rows, use the Job Data component.

This page tracks data at two different levels: organizational and assignment. The organizational instance is the occurrence of an employment, contingent worker, or POI relationship with an organization, initiated when you create the person's first job data record. The system uses an organizational instance record number to distinguish between organizational instances. The organizational instance number is the same as the Employment Record (ERN) of the original (controlling) job data record under that instance.

The assignment level is the actual job data record, or records, associated with the instance. Since people can have more than one job data record under an instance (for example, an additional job or a temporary assignment), tracking the dates of the assignments separately from the dates of the instance enables you to distinguish between when a person was hired (tracked at the instance level) and terminated and when they started and completed an assignment or job.

The system uses the dates of the original job data record under an instance (when there are more than one job data records under an instance, this job data record is the controlling instance) to determine the dates of the instance. All other assignments under the instance inherit the instance dates from the original assignment.

The system also uses the actions you use on a job data record to determine which dates to update. For example, when you use the action of HIR (hire), the system assumes that the new job data record represents a new instance for a new hire, with its own hire dates. However, if you use the action of ADL (additional job), the system assumes that the new job data record is in addition to an existing instance and will use the hire dates from the controlling instance.

This example illustrates how the system establishes and tracks the organizational record numbers, ERNs, instance dates, and assignment dates for someone with multiple organizational relationships and job data records:

Bobby Singh joined company XYZ on February 2, 2002. At the end of 2006, company ABC bought company XYZ; it completed the takeover on January 1, 2007. When the HR administrator at company ABC first enters Bobby in the system, he creates a job data record with the action of HIR and an effective date of January 1, 2007, reflecting Bobby's hire date with the new company.

The fields on the Employment Data page have the following values:

From June 3, 2007 to September 10, 2007, Bobby has an additional assignment with the company. The HR administrator uses the action of ADL when creating the additional assignment so the system does not treat the new job data record as a separate instance with it's own hire date. The fields on the Employment Data page for the new assignment's job data record have the following values:

The organizational instance dates come from the original, controlling instance and cannot be changed on the Employment Data page for the non-controlling instance.

On September 15, 2007, Bobby takes on a new job with company ABC. The HR administrator creates a new employment instance and uses the action of HIR when creating the instance. The fields on the Employment Data page for the new job have the following values:

This organizational instance is completely separate from the first organizational instance and Bobby is treated as a new hire, as reflected in his original start date and service date. A company with different business rules may choose to acknowledge his past service for this instance, but company ABC does not and, because the two instances are separate, it doesn't have to.

Bobby is offered an additional assignment with the second job starting on January 14, 2008 and so he tenders his resignation for his original job, effective January 15, 2008. The fields on the Employment Data page for the first organizational instance have the following values:

The fields on the Employment Data page for the new assignment under the second organizational instance have the following values:

Image: Bobby's organizational relationships and assignments for organizational record 0 (1 of 2)

Finally, the division in which Bobby has worked the two jobs in his second organizational instance closes, terminating both the controlling instance and, by association, the assignment effective September 30, 2008 and Bobby is rehired into his original job with a new, additional job on the side, effective September 15, 2008.

The following graphic illustrates Bobby's organizational instance record 0 and assignments:

Image: Bobby's organizational relationships and assignments for organizational record 2 (2 of 2)

The following graphic illustrates Bobby's organizational instance record 1 and assignments:

Notice that all of the instance dates come from the controlling assignment and that the termination date is refreshed when Bobby is rehired.

Differences Between the Add Employment Instance, Add Contingent Worker Instance, and Add POI Instance Components

The Add Contingent Worker Instance and Add POI Instance components are almost identical to the Add Employment Instance component with the following exceptions:

Security Considerations for Users Managing Employees and Contingent Workers

PeopleSoft Human Resources enables human resources administrators to create job records for people in departments that they can't access for updates. This enables them to transfer workers from one department to another.

If you want to prevent administrators from creating job records for people in departments to which they don't have access, the system contains an optional view (DEPT_TBL_ACCESS) that shows only the department IDs. The administrator can access the view based on user security. To use this view, update the JOB record in PeopleSoft Application Designer so that the prompt table for the DEPT_ID field is DEPT_TBL_ACCESS.

Managing Job Data When You Use the Manage Positions Business Process

If you drive part or all of PeopleSoft Human Resources by position, the process of adding a new job data record is somewhat different from the one that is described in these topics. You still enter some data on the pages that are described in these topics, but because you've already set up most job-related data on the Position Data component (POSITION_DATA), the system inserts default data automatically in many fields.

Adding Versus Updating Job Records

After you set up job records for a member of the workforce, you can enter more data, build a comprehensive history of the person's career with the organization, and support workforce-related planning and decision-making for all areas of the organization.

The pages that you use when you add an organizational instance are the same ones that you use later to update existing job data records but are contained on different components. Use the Job Data component to update job data information.

See Understanding the Process of Updating Person and Job Information.

See Understanding the Administering PAR System.

(JPN) Assigning Internal Identification Numbers

This feature enables you to assign to a person's job record identification numbers that have some meaning to the organization. For example, the third digit of an internal ID may indicate employment type; the fifth might indicate work location; and the sixth, job type. You can store a standard ID, which doesn't have meaning and is used for keying the database, and an alternative, meaningful ID that can be changed as the person's circumstances change.

The system assigns IDs to people as you add them to the system in the Personal Information component. The system uses this ID to identify the person in all job records. Enter a meaningful internal ID number for a person in the Internal Empl ID field on the Work Location page to capture information about the person's job situation.

You can update the internal ID each time that you insert a new row into the Job Data component. You can see those changes at a glance on the employee's Job Summary page, and you can search employees by their internal IDs.

The following examples illustrate how a person's internal emplID changes as their relationship to the organization changes, while their standard ID remains constant.

Example 1

In the Internal EmplID column of the following table, the first two numbers indicate the year (2004) that the person is hired as a full-time employee and the 2 in 20091 indicates part-time employment:

Example 2

In the Internal EmplID column of the following table, the first two numbers indicate the year (2000 and 2005) that the person is hired as an employee with the company and the next three numbers indicate the company (014 and 034) that the person is working for: