Results for “appl_attribute20”

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

Overview

PER_APPLICATIONS_V is a view owned by the APPS schema within the PER (Human Resources) product of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. The ETRM metadata designates its purpose as "Used to support user interface," indicating that it exists primarily to drive Oracle Forms and OAF-based pages rather than to serve as a general-purpose reporting object. The view presents a curated projection of the PER_APPLICATIONS base table, enriched with a decoded termination reason and constrained to a single "current" application row per person as of the user's effective date. Because it embeds session and date logic, the row set it returns is context-dependent, which distinguishes it from a simple denormalized reporting view. Customers who search the view for the token "date_received" are typically tracing how the application received date is filtered and surfaced in the application-registration and recruitment flows.

Underlying Base Objects

The documented base objects referenced by the view are PER_APPLICATIONS (accessed via a synonym), HR_LOOKUPS (a view), FND_SESSIONS (a synonym), and the HR_API package. PER_APPLICATIONS supplies all substantive columns—identifiers, dates, comments, employer information, the successful flag, the termination reason code, the twenty APPL_ATTRIBUTE descriptive flexfield columns, and the standard WHO audit columns. HR_LOOKUPS is outer-joined on LOOKUP_TYPE = 'TERM_APL_REASON' to translate TERMINATION_REASON into REASON_MEANING. FND_SESSIONS participates in a correlated predicate: the row returned for each person is the one whose DATE_RECEIVED equals the maximum DATE_RECEIVED among that person's applications that is less than or equal to the session's EFFECTIVE_DATE. HR_API is the HR date-tracking package whose logic underpins the effective-date semantics. The join to FND_SESSIONS on SESSION_ID = USERENV('SESSIONID') means the view must be queried from within an established EBS session to resolve correctly.

Key Columns

• ROW_ID — the rowid of the underlying PER_APPLICATIONS row, exposed for Forms row identification.
• APPLICATION_ID — primary key of the application record.
• PERSON_ID — the applicant or employee to whom the application belongs; the driver of the effective-date subquery.
• BUSINESS_GROUP_ID — the HR business group partitioning the record.
• DATE_RECEIVED — the date the application was received; the decisive column for selecting the most recent qualifying application.
• CURRENT_EMPLOYER, DATE_END, PROJECTED_HIRE_DATE — recruitment-related descriptors of the applicant's current employment and hire expectations.
• SUCCESSFUL_FLAG — indicates whether the application was successful.
• TERMINATION_REASON / REASON_MEANING — the stored lookup code and its decoded meaning from HR_LOOKUPS.
• APPL_ATTRIBUTE1 through APPL_ATTRIBUTE20 — the descriptive flexfield segment columns, plus APPL_ATTRIBUTE_CATEGORY.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — standard audit (WHO) columns.

Common Use Cases and Queries

The view is most useful where the "latest application as of the effective date" semantic is required, such as an application summary region or a self-service page. A typical query retrieves the current application and its decoded reason:

• SELECT application_id, person_id, date_received, current_employer, successful_flag, reason_meaning FROM per_applications_v WHERE person_id = :p_person_id;
• SELECT person_id, date_received, projected_hire_date FROM per_applications_v WHERE date_received BETWEEN :p_from AND :p_to;

Because the view depends on FND_SESSIONS and USERENV('SESSIONID'), ad hoc SQL run outside an active EBS session may return no rows. For ETL, interface, or reporting extracts—especially those spanning history—the base table PER_APPLICATIONS joined directly to HR_LOOKUPS is generally preferred, since the view suppresses all but one application per person. The correlated DATE_RECEIVED subquery also carries a performance cost on large person populations, so indexed access on PERSON_ID is advisable.