Results for “per_job_requirements”

50+ results




Overview
Explore in AI Chat

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

Overview

PER_JOB_REQUIREMENTS is a Human Resources (PER) table in the Oracle E-Business Suite 12.1.1 and 12.2.2 data model. It stores the requirements defined against specific jobs or positions — for example, required skills, qualifications, experience, and training. In Oracle EBS, this table supports competency and requirement management functionality, allowing HR administrators to associate analysis criteria (the requirement definitions held in PER_ANALYSIS_CRITERIA) with jobs (PER_JOBS) or positions (PER_ALL_POSITIONS), with effective dating and essential/non-essential flags to govern how each requirement applies.

The table is owned by the HR schema and is documented as VALID in the ETRM 12.2.2 metadata, with 40 documented columns. It carries Oracle EBS audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and the standard OBJECT_VERSION_NUMBER column used for optimistic locking in the Oracle Application Framework (OAF) and HRMS APIs. The presence of REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE indicates the table is maintained through concurrent program processing as well.

From a Data Vault modeling perspective, the heuristic classification derived from the foreign key structure is satellite-leaning. This suggests PER_JOB_REQUIREMENTS is best modeled as a satellite attached to a hub or link representing the job/position-plus-criteria relationship, with the descriptive attributes and effective-dating columns carried as satellite payload.

Key Information Stored

The most significant columns include:

  • JOB_REQUIREMENT_ID — The surrogate primary key, defined by the PER_JOB_REQUIREMENTS_PK unique index. This is the column users search for as "job_requirement_id" and is the join key for dependent objects.
  • BUSINESS_GROUP_ID — Foreign key to HR_ALL_ORGANIZATION_UNITS, identifying the business group that owns the requirement record.
  • ANALYSIS_CRITERIA_ID — Foreign key to PER_ANALYSIS_CRITERIA, defining the requirement itself (skill, qualification, experience, training).
  • JOB_ID — Foreign key to PER_JOBS, identifying the job to which the requirement applies.
  • POSITION_ID — Foreign key to PER_ALL_POSITIONS, identifying the position to which the requirement applies.
  • DATE_FROM / DATE_TO — Effective start and end dates of the requirement.
  • ESSENTIAL — Flag indicating whether the requirement is essential.
  • COMMENTS — Free-text notes on the requirement.
  • OBJECT_VERSION_NUMBER — Optimistic-locking version for DML through the application layer.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard audit trail columns.
  • REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Concurrent program context of the last update.
  • ATTRIBUTE_CATEGORY, ATTRIBUTE1–ATTRIBUTE20 — Descriptive flexfield (DFF) columns for customer-specific extensions.

The documented unique index PER_JOB_REQUIREMENTS_PK (JOB_REQUIREMENT_ID) is the only business-key candidate; the surrogate key is therefore the primary identifier. A system-generated LOB index (SYS_IL0000043409C00040$$) is also present, associated with a large object column.

Common Use Cases and Queries

Typical reporting scenarios retrieve requirements for a job or position, join them to analysis criteria for descriptive text, and filter by effective dates to obtain current requirements. A representative query joining the requirement to its criteria and job might resemble:

  • SELECT pjr.job_requirement_id, pjr.job_id, pjr.position_id, pjr.analysis_criteria_id, pjr.essential, pjr.date_from, pjr.date_to FROM per_job_requirements pjr WHERE pjr.business_group_id = :bg_id AND TRUNC(SYSDATE) BETWEEN pjr.date_from AND NVL(pjr.date_to, TRUNC(SYSDATE));
  • Joining to PER_ANALYSIS_CRITERIA on ANALYSIS_CRITERIA_ID to obtain the requirement name/description, and to PER_JOBS or PER_ALL_POSITIONS on JOB_ID/POSITION_ID for the associated object name.
  • Tracing approval workflow and transaction data by joining to PQH_TXN_JOB_REQUIREMENTS on JOB_REQUIREMENT_ID.

Other uses include auditing updates through REQUEST_ID/PROGRAM_ID, validating effective-date overlaps before inserts or updates, and extracting DFF attributes for custom reporting.

Related Objects

  • PER_ANALYSIS_CRITERIA — referenced via PER_JOB_REQUIREMENTS.ANALYSIS_CRITERIA_ID; provides the requirement definition.
  • PER_JOBS — referenced via PER_JOB_REQUIREMENTS.JOB_ID; the job to which requirements attach.
  • PER_ALL_POSITIONS — referenced via PER_JOB_REQUIREMENTS.POSITION_ID; the position to which requirements attach.
  • HR_ALL_ORGANIZATION_UNITS — referenced via PER_JOB_REQUIREMENTS.BUSINESS_GROUP_ID; the owning business group.
  • PQH_TXN_JOB_REQUIREMENTS — references PER_JOB_REQUIREMENTS.JOB_REQUIREMENT_ID; holds transaction/approval data for job requirements.
  • PQH_TJR_SHADOW — references PER_JOB_REQUIREMENTS.JOB_REQUIREMENT_ID; a shadow table used in the transaction/approval architecture.