Search Results to_job_name




Overview
Explore in AI Chat

Overview

PA_JOB_RELATIONSHIPS_VIEW is a Projects (PA) module view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It exposes the job-to-job relationships defined in Oracle Projects through the master group job construct. In the Projects security and resource model, jobs are assigned to employees and are grouped into job groups; the master group job acts as the pivot through which an HR job becomes eligible for use as a Projects job. The view flattens this three-tier chain — HR job, master group job, and Projects job — into a single, query-friendly row set, presenting the originating job and job group alongside the target job and job group for each valid relationship.

Because the underlying relationship table is keyed on internal identifiers, the view's primary practical value is denormalization: it resolves JOB_ID and JOB_GROUP_ID values into human-readable names and group display names. This makes it suitable for reporting, data validation, and integration extracts without requiring callers to join PER_JOBS and PER_JOB_GROUPS themselves, or to reproduce the master-group filtering logic.

Underlying Base Objects

The view is defined over the following documented objects:

The view body is a UNION of two branches. The first branch traverses the relationship table twice (aliased JR1 and JR2) to resolve a chain in which an HR job maps through the master group job to a Projects job, constrained by GRP.MASTER_FLAG = 'Y' and GRP1/GRP2.MASTER_FLAG = 'N'. The second branch, added for Bug 1654186, handles the case where the HR job is itself the master job, fetching rows via a single relationship record. Business group visibility is enforced through the PA_CROSS_BUSINESS_GRP.ISCROSSBGPROFILE profile: when set to 'N', only the session business group's jobs are returned; when 'Y', the business group predicate is bypassed.

Key Columns

  • FROM_JOB_NAME — name of the originating job, resolved from PER_JOBS.
  • FROM_JOB_ID — internal identifier of the originating job.
  • FROM_JOB_GROUP_NAME — display name of the job group that owns the originating job.
  • FROM_JOB_GROUP_ID — internal identifier of the originating job group.
  • TO_JOB_NAME — name of the destination (Projects) job.
  • TO_JOB_ID — internal identifier of the destination job.
  • TO_JOB_GROUP_NAME — display name of the job group that owns the destination job.
  • TO_JOB_GROUP_ID — internal identifier of the destination job group.

Each returned row therefore represents one permitted relationship path, with the group columns documenting the membership context at both ends.

Common Use Cases and Queries

Typical uses include validating that a Projects job was correctly derived from its HR source job, generating cross-reference reports between HR and Projects job structures, and troubleshooting why a given employee's assignment job is unavailable for Projects use. The view is also convenient for integration extracts into external reporting layers.

  • List all job relationships with descriptive names: 
    SELECT from_job_name, from_job_group_name,
       to_job_name, to_job_group_name
  FROM pa_job_relationships_view
 ORDER BY from_job_name;
  • Find the Projects jobs derived from one HR job: 
    SELECT to_job_id, to_job_name, to_job_group_name
  FROM pa_job_relationships_view
 WHERE from_job_name = :p_job_name;
  • Locate the HR source for a given Projects job: 
    SELECT from_job_id, from_job_name
  FROM pa_job_relationships_view
 WHERE to_job_id = :p_job_id;

Because the returned rows depend on the PER_BUSINESS_GROUP_ID and ISCROSSBGPROFILE profile settings, callers in multi-organization or multi-business-group environments should confirm the profile context of the session before interpreting results.