Search Results per_phones

Overview

EGO_INTERNAL_PEOPLE_V is a public APPS-owned view in Oracle E-Business Suite 12.1.1 and 12.2.2, delivered under the EGO – Advanced Product Catalog product. As its ETRM description states, the view "contains all the Internal People" — that is, the employees and application users who exist as parties within the Trading Community Architecture (TCA) and Human Resources person model, presented in a flattened, report-ready form. It is a read-only integration and reporting object rather than a base table, and its status is VALID in the documented ETRM metadata. The view is widely referenced by product catalog, collaboration, sourcing, and workflow functionality that needs to identify an internal person by user name or party identifier while simultaneously resolving contact details such as e-mail address, telephone, and fax. Because it joins TCA parties with FND user accounts and PER_PHONES records, it provides a single access point for internal-person contact information that would otherwise require several joins across HZ, FND, and PER schemas.

Underlying Base Objects

The documented referenced base objects for EGO_INTERNAL_PEOPLE_V are AR_LOOKUPS (view), FND_USER (synonym), HZ_CONTACT_POINTS (synonym), HZ_PARTIES (synonym), HZ_RELATIONSHIPS (synonym), PER_ALL_PEOPLE_F (synonym), and PER_PHONES (synonym). The view text joins HZ_PARTIES twice — once as the employee party and once as the enterprise (company) party — and links them through HZ_RELATIONSHIPS (EMP_CMPY), establishing the employee-to-organization affiliation. FND_USER supplies the application user name and user identifier. HZ_CONTACT_POINTS provides the primary phone and fax contact point records, while PER_PHONES is consulted as a fallback source of phone and fax numbers by phone type. PER_ALL_PEOPLE_F supplies HR person attributes such as the known-as name and pre-name adjunct used for the person prefix. AR_LOOKUPS resolves the person's title from the CONTACT_TITLE lookup type, restricted to currently active lookup values.

Key Columns

The view exposes identity, organization, and communication columns. PERSON_ID and USER_ID carry the TCA party identifier and the FND user identifier respectively, while USER_NAME holds the application login name. PERSON_NAME, PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, PERSON_LAST_NAME, PERSON_NAME_SUFFIX, PERSON_PREFIX, and KNOWN_AS describe the person's name components, with PERSON_TITLE derived from AR_LOOKUPS. COMPANY_ID and COMPANY_NAME identify the enterprise party associated with the employee through HZ_RELATIONSHIPS. Communication attributes include EMAIL_ADDRESS, PHONE_COUNTRY_CODE, PHONE_AREA_CODE, PHONE_NUMBER, PHONE_EXTENSION, FAX_COUNTRY_CODE, FAX_AREA_CODE, FAX_NUMBER, and FAX_EXTENSION. Notably, both PHONE_NUMBER and FAX_NUMBER are computed with nested NVL expressions: the HZ_CONTACT_POINTS value is preferred, and if null the view falls back to PER_PHONES using phone type W1 (work) then H1 (home) for telephones, and WF then HF for faxes, in each case filtering on the current effective date range.

Common Use Cases and Queries

Because the object was surfaced by a search for "per_phones", it is frequently used to obtain an employee's current telephone or fax number without querying PER_PHONES directly, since the view already applies the preferred HZ contact point and the W1/H1, WF/HF fallback logic with effective dating. Typical scenarios include building internal contact directories, populating notification recipients in workflows, and enriching catalog or sourcing records with an internal owner's details. A representative query is:

• SELECT person_id, user_name, person_name, company_name, email_address, phone_number, fax_number FROM apps.ego_internal_people_v WHERE user_name = :user_name;
• SELECT person_name, phone_number, phone_extension FROM apps.ego_internal_people_v WHERE company_id = :company_id ORDER BY person_name;
• SELECT person_id, user_name FROM apps.ego_internal_people_v WHERE person_name LIKE :pattern;

Consumers should treat the view as read-only, avoid reliance on undocumented internal join behavior, and be aware that the phone and fax columns reflect effective-dated fallbacks at query time rather than stored single values.