Results for “manager_comments”

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

Overview

PER_SUCCESSION_PLANNING_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the PER (Human Resources) product family. The ETRM metadata describes its purpose simply as "Used to support user interface," which is consistent with the pattern of Oracle HRMS views that expose a flat, query-ready projection of a base table for use by OAF pages, forms, and concurrent programs rather than as an independent business entity. In 12.1.1 and 12.2.2 the view is registered as VALID, meaning its definition compiles cleanly against the current dictionary.

The object surfaces succession planning records, which associate a person with a position for the purpose of identifying and tracking incumbents who are candidates to move into that position. Because the underlying data revolves around a single primary key, SUCCESSION_PLAN_ID, the view is the natural entry point for any query, report, or interface that needs to resolve a succession plan identifier into person, position, and eligibility information. This makes it relevant both to end-user reporting (BI Publisher, Discoverer, OBIEE extracts) and to technical integrations that must read or reconcile succession data without touching the base table directly.

Underlying Base Objects

The view text is a direct projection of the base table PER_SUCCESSION_PLANNING, exposed through the APPS synonym PER_SUCCESSION_PLANNING. No joins, filters, or aggregations appear in the definition; every column is passed through unchanged, including the DFF columns ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE20, the OBJECT_VERSION_NUMBER used for optimistic locking, and the WHO audit columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE).

The documented referenced base objects are wider than the view text alone and reflect the runtime dependencies of the succession-planning user interface: FND_PROFILE, HR_GENERAL, HR_PERSON_NAME, HR_POSITIONS_X, HR_SECURITY, PER_PEOPLE_F, PER_SUCCESSION_PLANNING, and the underlying synonym. In practice this means the view is queried in pages that also apply security predicates via HR_SECURITY, resolve person display names via HR_PERSON_NAME and PER_PEOPLE_F, and validate positions via HR_POSITIONS_X. Since the view itself performs no security filtering, row-level access must be enforced by the calling application or by joining to the security packages.

Key Columns

• SUCCESSION_PLAN_ID — Primary key of the succession plan record; the column most commonly used in WHERE clauses and joins.
• PERSON_ID — Foreign key to the person (candidate or incumbent) associated with the plan; joins to PER_PEOPLE_F and PER_ALL_PEOPLE_F.
• POSITION_ID — Foreign key to the position for which succession is being planned; joins to HR_ALL_POSITIONS_F / HR_POSITIONS_X.
• BUSINESS_GROUP_ID — The HR business group that owns the record; essential for multi-organization and security filtering.
• START_DATE / END_DATE — Effective dates bounding the plan's validity window.
• TIME_SCALE — Indicates the time basis (for example, days, months, or years) associated with the plan's duration or readiness period.
• AVAILABLE_FOR_PROMOTION — Flag indicating whether the person is currently considered promotable.
• MANAGER_COMMENTS — Free-text commentary entered by the manager.
• OBJECT_VERSION_NUMBER — Optimistic locking token used by the OAF layer.
• ATTRIBUTE_CATEGORY, ATTRIBUTE1–ATTRIBUTE20 — Descriptive flexfield segments for customer-defined extensions.
• WHO columns — Standard audit fields suitable for change tracking and incremental extracts.

Common Use Cases and Queries

Typical scenarios include succession pipeline reports for a business group, roster extracts for talent-review meetings, and integration loads that publish succession candidates to a downstream HR data warehouse. A basic lookup by identifier is the most frequent access pattern:

SELECT succession_plan_id, person_id, position_id, business_group_id,
       start_date, end_date, available_for_promotion, manager_comments
  FROM apps.per_succession_planning_v
 WHERE succession_plan_id = :p_succession_plan_id;

Reporting by person or position requires joins to resolve display values, for example to PER_PEOPLE_F for the incumbent's name and to HR_ALL_POSITIONS_F for the position title. A representative query lists active plans for a business group as of SYSDATE:

SELECT sp.succession_plan_id, sp.person_id, sp.position_id, sp.available_for_promotion
  FROM apps.per_succession_planning_v sp
 WHERE sp.business_group_id = :p_business_group_id
   AND SYSDATE BETWEEN sp.start_date AND NVL(sp.end_date, SYSDATE + 1);

Incremental interfaces should filter on LAST_UPDATE_DATE to capture changed rows, and any query executed on behalf of a restricted user must apply HR security predicates (for example via HR_SECURITY) because the view provides no row-level filtering of its own. Because the view is a straight projection, it should not be used for direct DML; inserts and updates are performed against PER_SUCCESSION_PLANNING through the supported HRMS APIs.