Results for “per_requisitions_v”

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

Overview

APPS.PER_REQUISITIONS_V is a reporting and user-interface support view owned by the APPS schema within the Oracle E-Business Suite Human Resources (PER) product family. It is documented as VALID in ETRM for both release 12.1.1 and 12.2.2, and its stated purpose is "Used to support user interface." Rather than storing data, the view projects a denormalized, inquiry-friendly result set assembled from the requisition entity and the person entity, so that forms, concurrent programs, and integration layers can retrieve requisition records together with the name and employee number of the person who raised them.

Because the object is a view, it carries no independent storage or indexing. All access is resolved at runtime against the underlying base tables through the APPS synonyms, which means its behavior and performance characteristics are inherited directly from those tables and from the join condition defined in the view text. In reporting and integration contexts the view functions as a convenience layer that shields consumers from having to repeat the person-name lookup and the date-effective join logic themselves.

Underlying Base Objects

ETRM documents two referenced base objects, both exposed through synonyms in the APPS schema:

• PER_REQUISITIONS — the driving table, aliased REQ, supplying the requisition identifiers, dates, descriptive text, and the WHO columns and descriptive flexfield attribute columns.
• PER_ALL_PEOPLE_F — the date-effective person table, aliased PP1, supplying the raiser's full name and employee number.

The view definition joins the two on REQ.PERSON_ID = PP1.PERSON_ID(+), an outer join that preserves requisitions even where no matching person row exists. A correlated date-effective predicate, REQ.DATE_FROM BETWEEN PP1.EFFECTIVE_START_DATE AND PP1.EFFECTIVE_END_DATE, restricted by the PP1.PERSON_ID IS NULL escape clause, ensures the person attributes returned correspond to the effective-dated person record in force on the requisition's DATE_FROM. The view also exposes REQ.ROWID as ROW_ID.

Key Columns

• ROW_ID — the rowid of the underlying PER_REQUISITIONS row, useful for direct row identification.
• REQUISITION_ID — the primary identifier of the requisition record.
• BUSINESS_GROUP_ID — the business group (HR security organization) owning the record.
• PERSON_ID — the person who raised the requisition.
• RAISED_BY / RAISED_BY_NUMBER — denormalized full name and employee number drawn from PER_ALL_PEOPLE_F.
• DATE_FROM / DATE_TO — the effective window of the requisition.
• NAME, DESCRIPTION, COMMENTS — descriptive attributes of the requisition.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent request tracking columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE20 — descriptive flexfield segments.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — standard WHO audit columns.

Common Use Cases and Queries

Typical scenarios include LOV population in HR forms, listing open requisitions with the raiser's identity, and extraction feeds for downstream systems. A basic query returning current requisitions with raiser details is:

• SELECT requisition_id, name, date_from, date_to, raised_by, raised_by_number FROM apps.per_requisitions_v WHERE business_group_id = :p_bg_id AND TRUNC(SYSDATE) BETWEEN date_from AND NVL(date_to, TRUNC(SYSDATE));
• SELECT r.requisition_id, r.raised_by, r.raised_by_number FROM apps.per_requisitions_v r WHERE r.person_id = :p_person_id ORDER BY r.date_from DESC;
• SELECT r.requisition_id, r.name, r.attribute1, r.attribute2 FROM apps.per_requisitions_v r WHERE r.date_from >= :p_start_date;

Queries should always constrain on BUSINESS_GROUP_ID or PERSON_ID where possible, since the underlying outer join to the date-effective person table can otherwise require broad access paths. Note that the view is a read-only projection; DML against requisition data must target PER_REQUISITIONS directly, with the appropriate business-group security and WHO column population, and not this interface view.