Search Results hr_positions




Overview

HR_POSITIONS is a date-effective, security-aware view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the PER (Human Resources) product family. In both EBS 12.1.1 and 12.2.2, the object is documented in the E-Business Suite Technical Reference Manual (ETRM) as a VIEW and reported with a status of VALID. Its stated description is concise and precise: it is a date-effective view based on the secured positions view.

This dual characteristic — date effectiveness and row-level security — is what makes HR_POSITIONS the standard reporting and integration entry point for position data. Because it derives from the secured positions view, it honours the security profile applied to the querying session, ensuring that users and concurrent programs return only those business group and organization positions to which they are entitled. It is not a transactional base table but a curated projection intended for enquiry, extracts, interfaces, and downstream reporting against positions rather than a table that should be written to directly.

Underlying Base Objects

The ETRM documentation for release 12.2.2 lists the referenced base objects for HR_POSITIONS as FND_PROFILE (PACKAGE), FND_SESSIONS (SYNONYM), HR_GENERAL (PACKAGE), HR_POSITIONS_F (VIEW), and HR_SECURITY (PACKAGE). The relationships are informative:

  • HR_POSITIONS_F is the underlying date-effective positions view that supplies the core position rows, including the effective start and end dates that make the view date effective.
  • HR_SECURITY is the package that applies position security, filtering the secured positions view so that only permitted rows are exposed to the session.
  • FND_PROFILE and FND_SESSIONS provide session and profile-option context (such as business group and user session information) used to resolve security and date-effective behaviour at runtime.
  • HR_GENERAL is the general HR utilities package; its function GET_POSITION_DATE_END is called inline in the view definition to derive the DATE_END column for each position.

Key Columns

The view exposes a comprehensive position attribute set. Important columns include POSITION_ID (primary identifier), NAME and DATE_EFFECTIVE_NAME (date-effective position name), EFFECTIVE_START_DATE and EFFECTIVE_END_DATE (date-effectiveness boundaries), and the derived DATE_EFFECTIVE plus DATE_END (the latter computed via HR_GENERAL.GET_POSITION_DATE_END).

Organizational and classification columns include BUSINESS_GROUP_ID, ORGANIZATION_ID, LOCATION_ID, JOB_ID, and POSITION_TYPE. Grade and step attributes are exposed through ENTRY_GRADE_ID, ENTRY_GRADE_RULE_ID, and ENTRY_STEP_ID. Staffing and capacity attributes include FTE, MAX_PERSONS, WORKING_HOURS, PAY_BASIS_ID, and PERMANENT_TEMPORARY_FLAG. Position relationships are captured by SUPERVISOR_POSITION_ID, SUPERVISOR_ID, SUCCESSOR_POSITION_ID, RELIEF_POSITION_ID, and PRIOR_POSITION_ID. Recruitment-related flags include PERMIT_RECRUITMENT_FLAG, REPLACEMENT_REQUIRED_FLAG, and FILL_BY_DATE, while STATUS and AVAILABILITY_STATUS_ID indicate the position's current state. Thirty generic flexfield-style columns (INFORMATION1 through INFORMATION30) support client-specific extensions.

Common Use Cases and Queries

Typical uses include headcount and establishment reporting, validating position availability for recruitment, integrating positions into third-party HR or payroll systems, and auditing position hierarchies. The following example lists current, secured positions for a business group:

  • SELECT position_id, name, organization_id, job_id, fte, status FROM apps.hr_positions WHERE business_group_id = :p_bg_id AND SYSDATE BETWEEN effective_start_date AND effective_end_date AND status = 'ACTIVE';
  • To count incumbents against MAX_PERSONS, developers commonly join HR_POSITIONS to HR_ASSIGNMENTS on POSITION_ID for the same effective window.
  • Hierarchical extracts use SUPERVISOR_POSITION_ID to navigate the reporting structure, while vacancy extracts filter on PERMIT_RECRUITMENT_FLAG and FILL_BY_DATE.

Because security and date effectiveness are resolved dynamically, queries against HR_POSITIONS should always constrain effective dates and rely on the view rather than its base objects to guarantee consistent, secured results.