Results for “job_level”

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

Overview

PA_JOB_LEVELS_V is a Projects (PA) module database view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. The ETRM documentation classifies this object as "10SC Only," indicating that it is restricted to a specific implementation, localization, or configuration context rather than being a general-purpose, globally deployed view. Despite its placement in the Projects product family, the view does not expose project-level transaction data; instead, it surfaces a distinct list of job-level segment values drawn from Oracle Human Resources job definitions. Its status is recorded as VALID, meaning the view compiles correctly and can be queried in supported environments.

Because the view returns only a single column, its role is narrow and utilitarian. It functions as a lookup source for valid job level codes in environments where the job definition segment (SEGMENT1) is used to represent a job level or grade-tier value. Reporting components, concurrent programs, and integration routines that require an authoritative list of job levels can query this view rather than joining the PER_JOBS, PER_JOB_DEFINITIONS, and PA_IMPLEMENTATIONS tables directly.

Underlying Base Objects

The view is defined over three referenced base objects, each accessed through APPS-owned synonyms: PA_IMPLEMENTATIONS, PER_JOBS, and PER_JOB_DEFINITIONS. The view text documents the join logic as follows:

• PER_JOBS J — the driving table containing the job records. It supplies BUSINESS_GROUP_ID and JOB_DEFINITION_ID.
• PER_JOB_DEFINITIONS JD — provides the descriptive definition of each job, including SEGMENT1, which is the source of the exposed JOB_LEVEL value.
• PA_IMPLEMENTATIONS I — the Projects implementation table, which stores the business group context for the PA installation. It constrains results so that only jobs belonging to the business group configured for Projects are returned.

The join predicates are: J.BUSINESS_GROUP_ID = I.BUSINESS_GROUP_ID and J.JOB_DEFINITION_ID = JD.JOB_DEFINITION_ID. The SELECT DISTINCT clause removes duplicate SEGMENT1 values that can arise when multiple job records share the same definition segment value, yielding a de-duplicated list of job levels scoped to the relevant business group. Because PER_JOB_DEFINITIONS is date-effective and multilanguage, the effective result set reflects the definition rows that satisfy the join condition at query time.

Key Columns

The view exposes a single column:

• JOB_LEVEL — maps directly to PER_JOB_DEFINITIONS.SEGMENT1. In HR terminology, SEGMENT1 in the job definition acts as the job code or short identifier used to distinguish one job definition from another. Within the context of this view it is surfaced under the name JOB_LEVEL, implying that the implementation uses this segment to carry the level or grade designation. Values are character strings and are returned as distinct entries only.

No other columns are projected, so consumers needing job names, business group identifiers, or effective dates must retrieve them from the base tables independently.

Common Use Cases and Queries

The primary use case is populating a list of valid job levels for validation lists (LOVs), data-entry pages, or integration mappings. A basic query follows:

• SELECT job_level FROM apps.pa_job_levels_v ORDER BY job_level;

For a validation check against a supplied value, a conditional query can confirm existence:

• SELECT job_level FROM apps.pa_job_levels_v WHERE job_level = :p_job_level;

Because the view is limited to the business group linked to the PA implementation, it should be treated as a configuration-specific lookup rather than a global master list. In reporting, it is commonly joined to HR job or assignment data to translate stored level codes into validated labels, or used in Projects costing setups where job level drives rate derivation. Given the "10SC Only" designation, implementers should verify the view's presence and population before relying on it in custom concurrent programs, and should not assume it is available or populated in every EBS environment.