Search Results person_title

Overview

AMW_PEOPLE_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the AMW – Internal Controls Manager product. Its documented purpose is simply to present "peoples" — a consolidated people listing that joins Oracle Human Resources person records, Trading Community Architecture (TCA) party records, and FND application user accounts into a single row per individual. The view serves reporting and integration consumers, such as BI Publisher reports, Discoverer worksheets, custom concurrent programs, or inbound/outbound interface logic within Internal Controls Manager, that need a lightweight, pre-joined list of internal staff with their login and e-mail details. Because AMW deals with internal control structures, certifications, and process ownership, it requires a stable roster of active internal users; AMW_PEOPLE_V supplies that roster rather than a full person directory.

Underlying Base Objects

The view text defines three base tables in the FROM clause: HZ_PARTIES, FND_USER, and PER_ALL_PEOPLE_F. The join is driven from FND_USER to PER_ALL_PEOPLE_F on PERSON_ID = U.EMPLOYEE_ID, then to HZ_PARTIES on P.PARTY_ID = PER.PARTY_ID. Several filters restrict the result set to currently active internal staff: U.EMPLOYEE_ID must be non-null; the HR person record must be effective as of SYSDATE (EFFECTIVE_START_DATE <= SYSDATE and EFFECTIVE_END_DATE null or greater than SYSDATE); CURRENT_EMPLOYEE_FLAG must equal 'Y'; and the application user account must likewise be active (START_DATE <= SYSDATE, END_DATE null or >= SYSDATE). The ETRM metadata for 12.2.2 documents no referenced base objects, so the view text above is the authoritative structural source. Note that because PER_ALL_PEOPLE_F is a date-tracked table, the join is effective-dated and reflects the current person version only.

Key Columns

The view exposes twenty-three columns. PERSON_ID and PERSON_NAME are drawn from HZ_PARTIES (PARTY_ID and PARTY_NAME), while USER_NAME and USER_ID come from FND_USER and EMAIL_ADDRESS from PER_ALL_PEOPLE_F through PER.EMAIL_ADDRESS. PERSON_TYPE is a hard-coded literal, 'INTERNAL', distinguishing these rows from external party types. A significant set of columns is defined as NULL placeholders — COMPANY_ID, COMPANY_NAME, PERSON_TITLE, PERSON_PREFIX, PERSON_FIRST_NAME, PERSON_MIDDLE_NAME, PERSON_LAST_NAME, PERSON_NAME_SUFFIX, PHONE_COUNTRY_CODE, PHONE_AREA_CODE, PHONE_NUMBER, PHONE_EXTENSION, FAX_COUNTRY_CODE, FAX_AREA_CODE, FAX_NUMBER, FAX_EXTENSION, and KNOWN_AS. This is directly relevant to a search on "fax_number": FAX_NUMBER exists in the projection but always returns NULL, as do the related FAX_COUNTRY_CODE and FAX_EXTENSION columns. These placeholders exist so that the view conforms to a common person/party column signature shared with other AMW people sources (for example external-party variants); the telephone and fax attributes are simply not populated from HZ_PARTIES here. Consumers requiring fax data must query HZ_CONTACT_POINTS or a TCA-based view instead.

Common Use Cases and Queries

Typical uses include populating LOVs and value sets, driving certification and delegation reports, and resolving user names for workflow notifications. A basic roster query is:

• SELECT person_id, person_name, user_name, email_address FROM apps.amw_people_v ORDER BY person_name;
• SELECT user_name, email_address FROM apps.amw_people_v WHERE person_id = :party_id; — resolve a single internal person.
• SELECT COUNT(*) FROM apps.amw_people_v; — count active internal users visible to AMW.
• SELECT person_name, fax_number FROM apps.amw_people_v; — illustrates that FAX_NUMBER is returned as NULL; it is not a usable source for fax reporting.

Because the view is date-filtered at run time, results naturally reflect the current effective HR and user-account state. Reporting that must show historical or inactive people cannot use this view and should query PER_ALL_PEOPLE_F and FND_USER directly with appropriate date predicates.