Results for “per_recruitment_activities_v”

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

Overview

The PER_RECRUITMENT_ACTIVITIES_V view is an APPS-owned database view in the Oracle E-Business Suite PER – Human Resources product family. Per the documented metadata, its stated purpose is to support the user interface, meaning it serves as a denormalized presentation layer that joins the recruitment activity base table to related people, organization, and lookup information. Rather than exposing raw foreign keys alone, the view resolves them to human-readable names and descriptive values, which makes it suitable for both UI rendering and downstream reporting or integration consumption. The view carries the standard EBS concurrency columns and descriptive flexfield attributes, so it is fully consistent with the conventions used across the HR schema. Because it is a view and not a table, it holds no data of its own; all values are derived at query time from the underlying objects.

Underlying Base Objects

The view is defined over several synonyms and other objects in the APPS schema. The primary driver is PER_RECRUITMENT_ACTIVITIES, aliased as RCA, which supplies the recruitment activity rows themselves. Two outer-joined instances of PER_ALL_PEOPLE_F (PP1 and PP2) resolve the authorizing person and the internal contact person, while HR_ALL_ORGANIZATION_UNITS and HR_ALL_ORGANIZATION_UNITS_TL provide the run-by organization and its translated name. A self-join to a second instance of PER_RECRUITMENT_ACTIVITIES (RCA1) resolves the parent recruitment activity. HR_LOOKUPS is joined twice to decode the activity type and the parent activity type. The view also references the HR_CHKFMT package, whose CHANGEFORMAT function formats cost amounts using a currency mask, and the ETRM metadata lists the HR_API package among the referenced objects. All joins to people and lookups use the Oracle outer-join (+) syntax, so activities without an assigned person or matching lookup code still return rows.

Key Columns

• RECRUITMENT_ACTIVITY_ID – Surrogate primary key of the recruitment activity.
• PARENT_RECRUITMENT_ACTIVITY_ID – Self-referencing foreign key to the parent activity; the column the user searched for. It is exposed alongside PARENT_REC_NAME, which resolves the parent's name, and D_PARENT_REC_TYPE and C_PARENT_REC_TYPE_CODE, which carry the decoded and raw type values of the parent.
• BUSINESS_GROUP_ID – Business group owning the row, central to multi-organization security.
• AUTHORISING_PERSON_ID / AUTH_PERSON_NAME / AUTH_EMP_NUMBER – The person authorizing the activity and their resolved name and employee number.
• INTERNAL_CONTACT_PERSON_ID / INT_CONTACT_NAME / INT_CONT_EMP_NUM – The internal contact and associated person details.
• RUN_BY_ORGANIZATION_ID / ORG_RUN_BY_NAME – Organization responsible for running the activity.
• NAME, TYPE, D_TYPE – Activity name, raw type code, and decoded type meaning from the REC_TYPE lookup.
• DATE_START, DATE_CLOSING, DATE_END – Activity scheduling dates.
• CURRENCY_CODE, ACTUAL_COST, PLANNED_COST and the formatted D_ACTUAL_COST / D_PLANNED_COST – Cost figures masked via HR_CHKFMT.CHANGEFORMAT.
• ATTRIBUTE1–ATTRIBUTE20, ATTRIBUTE_CATEGORY – Descriptive flexfield segments.
• ROW_ID – The ROWID of the base activity row, useful for update-through-view operations.

Common Use Cases and Queries

The view is typically used to report on recruitment campaigns and their hierarchy, particularly where parent-child activity relationships must be shown. A representative query filtering by business group and ordered by the parent key is:

SELECT recruitment_activity_id, name, d_type, parent_recruitment_activity_id, parent_rec_name, date_start, date_closing FROM per_recruitment_activities_v WHERE business_group_id = :p_bg ORDER BY parent_recruitment_activity_id, name;

To list top-level activities whose parent is null, add WHERE parent_recruitment_activity_id IS NULL, while child activities are obtained with WHERE parent_recruitment_activity_id = :activity_id. Because the view already resolves person and organization identifiers, it is well suited to integration extracts and concurrent programs that must avoid additional lookups. Queries should generally be constrained by BUSINESS_GROUP_ID to respect organization security, and any reporting joining additional tables should key off RECRUITMENT_ACTIVITY_ID.