Results for “per_job_evaluations_v”

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

Overview

PER_JOB_EVALUATIONS_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite, registered under the PER (Human Resources) product family. Within the ETRM repository it is documented as a UI-support view — a construct whose primary purpose is to present denormalized data to Oracle Forms, OAF pages, and similar user-interface layers rather than to serve as a transactional or integration interface. The view exposes one row per job evaluation record, enriched with decoded lookup descriptions, and is therefore a convenient access point for any reporting or extension logic that needs to surface job-evaluation data with human-readable code meanings instead of raw lookup codes.

The object is validated in both 12.1.1 and 12.2.2. It contains no business logic of its own; all transformation is confined to outer-join lookups, making its output deterministic and safe to consume from custom reports, concurrent programs, and outbound interfaces.

Underlying Base Objects

Per the documented view text, PER_JOB_EVALUATIONS_V is defined as a three-way join:

• PER_JOB_EVALUATIONS (referenced through a SYNONYM) — the driving table, holding all fact columns including JOB_EVALUATION_ID, JOB_ID, POSITION_ID, DATE_EVALUATED, OVERALL_SCORE, SYSTEM, MEASURED_IN, COMMENTS, all twenty descriptive flexfield ATTRIBUTEn columns, and the standard WHO audit columns.
• HR_LOOKUPS (referenced twice) — a lookup view supplying the decoded meanings for the MEASURED_IN column (lookup type EVAL_SYSTEM_MEAS) and the SYSTEM column (lookup type EVAL_SYSTEM).
• HR_API (PACKAGE) — the PL/SQL API package associated with the HR product, used as a dependency for validation and retrieval logic elsewhere in the module.

Both HR_LOOKUPS joins are outer joins (marked with the (+) operator on the lookup side), so an evaluation row is never discarded when its MEASURED_IN or SYSTEM code lacks a matching lookup entry; the corresponding *_NAME column simply returns NULL in that case.

Key Columns

• JOB_EVALUATION_ID — primary identifier of the evaluation record; the unique key for joining back to PER_JOB_EVALUATIONS.
• JOB_ID / POSITION_ID — the job or position being evaluated. These drive context for any evaluation report.
• OVERALL_SCORE — the numeric score assigned to the job or position during evaluation. This is the column most frequently targeted in analytical queries and is the term the user searched for.
• MEASURED_IN and MEASURED_IN_NAME — the code and decoded meaning indicating the unit or basis for the score.
• SYSTEM and SYSTEM_NAME — the code and decoded meaning of the evaluation methodology used.
• DATE_EVALUATED — the effective date of the evaluation, useful for trend and periodicity analysis.
• BUSINESS_GROUP_ID — the HR security organization; filters almost every production query.
• ATTRIBUTE1–ATTRIBUTE20 and ATTRIBUTE_CATEGORY — descriptive flexfield segments.
• CreatiON_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY — audit columns.

Common Use Cases and Queries

Typical consumers include job-evaluation comparison reports, compensation-linked analyses, and data extracts feeding external HR systems. A representative query retrieving scores for a business group is:

• SELECT jev.job_evaluation_id, jev.job_id, jev.position_id, jev.overall_score, jev.measured_in_name, jev.system_name, jev.date_evaluated FROM apps.per_job_evaluations_v jev WHERE jev.business_group_id = :p_bg_id AND jev.overall_score IS NOT NULL ORDER BY jev.date_evaluated DESC;
• SELECT jev.system_name, COUNT(*) evals, AVG(jev.overall_score) avg_score FROM apps.per_job_evaluations_v jev WHERE jev.business_group_id = :p_bg_id GROUP BY jev.system_name;
• SELECT jev.job_id, jev.overall_score FROM apps.per_job_evaluations_v jev WHERE jev.job_id = :p_job_id AND jev.date_evaluated = (SELECT MAX(date_evaluated) FROM apps.per_job_evaluations_v WHERE job_id = jev.job_id AND business_group_id = :p_bg_id);

Because the view is not secured by row-level security beyond BUSINESS_GROUP_ID, custom code must apply the appropriate business group filter explicitly. Always query the APPS synonym rather than the underlying table to obtain the decoded lookup names.