Search Results per_kr_grades




Overview
Explore in AI Chat

Overview

PER_KR_GRADES is a Human Resources (PER) grade definition table stored in the HR schema, holding Korea-specific (KR) grade records. Its role is to provide the grade master for Korean localization requirements, where grades are used to classify employees into structured seniority or pay bands. In the Oracle EBS 12.1.1 and 12.2.2 data model, this table serves as a localization extension to the standard grade infrastructure, carrying its own business group scoping, activation windows, and secondary detail tables for amounts and grade points.

Based on the foreign key topology documented in ETRM, the table is heuristic-classified as hub-leaning in a Data Vault model. This designation reflects that PER_KR_GRADES holds a stable, uniquely identified business entity (a grade) whose relationships to dependent tables are many-to-one. Because the table itself carries descriptive and system-audit attributes alongside its surrogate key, a hybrid design of a hub (GRADE_ID) plus a satellite for descriptive columns is a reasonable modeling suggestion rather than a prescriptive requirement.

Key Information Stored

The table contains 13 documented columns, with the primary identifier and business keys established through unique indexes.

  • GRADE_ID — the surrogate primary key defined by PER_KR_GRADES_PK. This should be treated as the technical identifier and used for all joins to dependent detail tables.
  • BUSINESS_GROUP_ID — the foreign key to HR_ALL_ORGANIZATION_UNITS and the first column of both unique indexes. This scopes the grade record to a specific business group, applying the standard EBS multi-tenant partition.
  • GRADE_NAME — the business-key candidate defined by PER_KR_GRADES_UK1 (BUSINESS_GROUP_ID, GRADE_NAME). Grade names must be unique within a business group.
  • SEQUENCE — the second business-key candidate, defined by PER_KR_GRADES_UK2 (BUSINESS_GROUP_ID, SEQUENCE), governing the ordering of grades within the business group.
  • ENABLED_FLAG — the standard EBS flag indicating whether the grade is available for use.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — the effective dating bounds for the grade record.
  • OBJECT_VERSION_NUMBER — the optimistic locking column used by the application (for example, the OAF-based UI) to detect concurrent updates.
  • The remaining columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, and CREATION_DATE — form the standard WHO audit set applied to all EBS transactional and setup tables.

Common Use Cases and Queries

These records are queried when reporting on Korean employee grade structures, validating that a grade exists and is enabled for a given business group, or preserving the textual grade definition on detailed payroll and grade-amount extracts.

SELECT grade_id, grade_name, sequence, enabled_flag
FROM   hr.per_kr_grades
WHERE  business_group_id = :p_business_group_id
AND    enabled_flag = 'Y'
ORDER  BY sequence;

Joining the grade to its amount bands and grade points is the typical reporting pattern:

SELECT g.grade_name,
       a.amount,
       p.points
FROM   hr.per_kr_grades g
       LEFT JOIN hr.per_kr_grade_amount_f a ON a.grade_id = g.grade_id
       LEFT JOIN hr.per_kr_g_points p      ON p.grade_id = g.grade_id
WHERE  g.business_group_id = :p_business_group_id;

Because PER_KR_GRADE_AMOUNT_F and PER_KR_G_POINTS are child tables, any grade with no rows in those tables is excluded by an inner join; a LEFT JOIN is preferred for completeness checks. Validation queries should check START_DATE_ACTIVE and END_DATE_ACTIVE so that only currently active grades are selected.

Related Objects

  • HR_ALL_ORGANIZATION_UNITS — referenced via PER_KR_GRADES.BUSINESS_GROUP_ID; defines the business group that owns the grade.
  • PER_KR_GRADE_AMOUNT_F — child table joined on GRADE_ID, storing grade amount details.
  • PER_KR_G_POINTS — child table joined on GRADE_ID, storing grade point values.
  • PER_GRADES and the grade-related APIs and views in the PER module — the standard grade infrastructure with which the KR-specific table is used in reporting and integration.

All three foreign key relationships above should be treated as the authoritative join paths when integrating or reporting on this object.