Results for “pjo_attribute1”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PER_PREVIOUS_JOBS_V is a PL/SQL view owned by the APPS schema within the Oracle E-Business Suite Human Resources (PER) product family. It exposes prior employment history for persons and assignments, presenting data originally captured in the PER_PREVIOUS_JOBS table. The view is a thin projection layer rather than a consolidating or aggregating view: it surfaces the base columns of PER_PREVIOUS_JOBS while decoding a single descriptive attribute for presentation. Its primary role is to provide a stable, published object name that concurrent programs, Oracle Reports, Oracle Forms, and external integrations can query without referencing the underlying table directly. The decoded employment category column allows consumers to render a human-readable value without embedding lookup logic.

Underlying Base Objects

According to the ETRM 12.2.2 metadata, the view references two objects. The first is the synonym PER_PREVIOUS_JOBS, which resolves to the base table of the same name holding the previous employment records. The second is HR_GENERAL, a PL/SQL package invoked through the HR_GENERAL.DECODE_LOOKUP function to translate the stored EMPLOYMENT_CATEGORY lookup code into a display value. The view thus depends on both a data object and a code object: if HR_GENERAL is invalidated, the view becomes unusable even though the base table remains intact. This dependency is significant during patching and node failover, where an invalid HR_GENERAL state can cascade invalidation to dependent views. Because the view is owned by APPS and defined with fully qualified references, it is safe to reference from custom code in the same schema.

Key Columns

The view exposes the full column set of PER_PREVIOUS_JOBS. Principal identification columns are PREVIOUS_JOB_ID and PREVIOUS_EMPLOYER_ID, which link each historical job record to its employer entry. DATE columns START_DATE and END_DATE, together with PERIOD_YEARS and PERIOD_DAYS, describe the tenure of prior employment. Descriptive attributes include JOB_NAME, DESCRIPTION, and EMPLOYMENT_CATEGORY. The view adds D_EMPLOYMENT_CATEGORY, produced by SUBSTR(HR_GENERAL.DECODE_LOOKUP('EMPLOYEE_CATG', PJO.EMPLOYMENT_CATEGORY), 1, 80), which resolves the lookup code against the EMPLOYEE_CATG lookup type and truncates the result to eighty characters for display.

Two descriptive flexfield groups are preserved in full. The PJO_ATTRIBUTE_CATEGORY plus PJO_ATTRIBUTE1 through PJO_ATTRIBUTE30 columns carry the attribute flexfield, while PJO_INFORMATION_CATEGORY plus PJO_INFORMATION1 through PJO_INFORMATION30 carry the information flexfield. The information flexfield is the segment family that includes PJO_INFORMATION30, the column most frequently targeted by users searching on this identifier. Standard audit columns OBJECT_VERSION_NUMBER, CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN complete the projection and support optimistic locking and audit reporting.

Common Use Cases and Queries

Typical uses include prior-employment verification reports, recruiting and background-screening extracts, and HR data migrations in which historical job data must be validated or reconciled. The view also supports ad hoc queries retrieving DFF context values.

• Retrieve history for a specific employee, filtering on the previous job key: SELECT previous_job_id, job_name, start_date, end_date FROM per_previous_jobs_v WHERE previous_employer_id = :employer_id;
• Report prior jobs with the decoded category: SELECT job_name, d_employment_category, period_years FROM per_previous_jobs_v ORDER BY start_date;
• Extract the information flexfield, including the segment sought by users of pjo_information30: SELECT previous_job_id, pjo_information_category, pjo_information1, pjo_information30 FROM per_previous_jobs_v WHERE pjo_information_category IS NOT NULL;
• Reconcile flexfield usage: SELECT pjo_information_category, COUNT(*) FROM per_previous_jobs_v GROUP BY pjo_information_category;

Because D_EMPLOYMENT_CATEGORY invokes HR_GENERAL.DECODE_LOOKUP row by row, large extracts should be filtered before selecting that column, and joins against the base table should generally be preferred in high-volume batch processes.