Search Results previous_last_name




Overview
Explore in AI Chat

Overview

The APPS.IRC_REGISTERED_USERS view is a reporting and integration object owned by the APPS schema and delivered as part of the PER (Human Resources) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. It exposes person-level profile attributes for those individuals who have registered to receive iRecruitment communications — specifically, those whose notification preferences permit access. The view is defined as a join between HZ_PERSON_PROFILES and IRC_NOTIFICATION_PREFERENCES, filtered by the condition ALLOW_ACCESS = 'Y'.

In practice, this view serves as a convenience layer for iRecruitment and HR reporting. Rather than requiring developers and integrators to reconstruct the underlying relationship and permission filter, the view presents a ready-to-query set of registered-user records with derived column aliases. Because it is a view and not a table, it carries no independent storage, inherits the read privileges of its base objects, and reflects the current state of its source rows at query time. The view is documented as VALID in the ETRM metadata, indicating that its compilation status is consistent with its referenced synonyms in the supported 12.2.2 environment.

Underlying Base Objects

The view is defined over two documented referenced base objects, both exposed as synonyms:

  • HZ_PERSON_PROFILES (SYNONYM) — aliased as HPP in the view text, this is the source of all person attributes: name components, phonetic name variants, the previous last name, known-as value, and demographic fields such as date of birth, place of birth, date of death, marital status, and pre-name adjunct.
  • IRC_NOTIFICATION_PREFERENCES (SYNONYM) — aliased as INP, this supplies the registration/access flag. The join condition HPP.PARTY_ID = INP.PARTY_ID links the two objects on the party identifier, and the filter INP.ALLOW_ACCESS = 'Y' restricts the result set to parties who have opted to allow access.

The relationship is therefore a one-to-one (or effectively party-keyed) association: person profile data is returned only when a matching notification-preference row exists and explicitly grants access. Because the view text relies on PARTY_ID, the underlying person identifier is converted to a numeric PERSON_ID via TO_NUMBER(HPP.PERSON_IDENTIFIER), which is significant when joining to other HR or party-based tables.

Key Columns

The view exposes fifteen columns. The most functionally relevant include:

Common Use Cases and Queries

Typical scenarios include identifying registered iRecruitment users for communication campaigns, auditing who has granted access, and reporting on known-as or previous-last-name attributes for name-change tracking.

SELECT person_id, first_name, last_name, previous_last_name, known_as
FROM   apps.irc_registered_users
WHERE  previous_last_name IS NOT NULL;

SELECT person_id, first_name, last_name, name_phonetic
FROM   apps.irc_registered_users
ORDER  BY last_name, first_name;

Because the view already enforces the ALLOW_ACCESS = 'Y' filter, queries against it do not need to restate the notification-preference condition; however, consumers should be aware that records without a qualifying preference row are intentionally absent from the result set.