Search Results per_kr_g_points_v

Overview

The view APPS.PER_KR_G_POINTS_V is a Korea-specific (KR) Human Resources object shipped within the Oracle E-Business Suite, residing in the APPS schema and documented with a status of VALID in the ETRM reference. It belongs to the PER — Human Resources product family and is catalogued as "KR specific," indicating that it supports legislative localization requirements for Korean payroll and grade-step processing rather than global HR functionality.

The view exposes grade point definitions — the individual steps or "ho-bong" increments that comprise a grade in the Korean grade-step (호봉) model. In Oracle HRMS, grades describe a level of responsibility or compensation band; grade points subdivide that band into discrete, normally sequential steps that drive salary progression, seniority-based increments, and statutory pay calculations. The view presents this configuration data in a stable, read-only presentation layer that is suitable for reporting, fast formulas, concurrent program queries, and integration extracts without requiring direct access to the underlying transactional table.

Because it is a simple projection of a single base object, the view carries no aggregation or filtering logic of its own. All row-level filtering, effective-dating evaluation, and security must therefore be applied by the consuming query.

Underlying Base Objects

The view is defined over a single documented base object: the table PER_KR_G_POINTS, accessible within the APPS schema through the synonym of the same name. The view text selects all defined columns from that table, aliasing it internally as PKGP, with no joins, unions, or subqueries. Consequently, PER_KR_G_POINTS_V is a one-to-one projection: every row in the view corresponds to exactly one row in PER_KR_G_POINTS, and no rows are added or removed by the view definition.

In the 12.1.1 and 12.2.2 releases the view remains a passthrough object; the 12.2.2 documented metadata lists only PER_KR_G_POINTS as a referenced base object. Because the view exposes the base table's ROWID, it can be used for row identification and for certain Forms-based or API-driven operations that depend on the physical row locator. However, customers should treat the view as read-only and perform DML against the base table or the supported HRMS APIs rather than through the view.

Key Columns

• ROW_ID — The physical row identifier of the underlying PER_KR_G_POINTS record; useful for uniqueness and row lookups.
• GRADE_POINT_ID — Primary key of the grade point; the surrogate identifier referenced by dependent entities.
• GRADE_ID — Foreign key to the parent grade, linking each point to its grade definition.
• GRADE_POINT_NAME — User-facing name or step label for the grade point.
• SEQUENCE — Ordering value that establishes the step progression within the grade.
• ENABLED_FLAG — Indicates whether the grade point is active and selectable (typically Y/N).
• START_DATE_ACTIVE / END_DATE_ACTIVE — Effective date range controlling when the grade point is valid.
• OBJECT_VERSION_NUMBER — Optimistic locking token maintained by the underlying table.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — Standard Oracle WHO columns recording audit and creation metadata.

Common Use Cases and Queries

Typical uses include validating grade-step setup, driving seniority increment reports, and feeding grade point lookups into Korean payroll and compensation extracts. The following query lists all enabled grade points for a given grade in sequence order.

SELECT grade_point_id
     , grade_point_name
     , sequence
     , start_date_active
     , end_date_active
FROM   apps.per_kr_g_points_v
WHERE  grade_id = :p_grade_id
AND    enabled_flag = 'Y'
AND    TRUNC(SYSDATE) BETWEEN NVL(start_date_active, TRUNC(SYSDATE))
                          AND NVL(end_date_active, TRUNC(SYSDATE))
ORDER BY sequence;

A second common pattern joins the view to the grade definition to produce a complete grade-step listing for configuration review or data migration verification, filtering on the audit columns to isolate recently changed rows. Because the view performs no date filtering itself, always apply the START_DATE_ACTIVE and END_DATE_ACTIVE predicates explicitly when effective-dating is relevant.