Search Results employee_num




Overview
Explore in AI Chat

Overview

HR_EMPLOYEES_ALL_V is an APPS-owned database view registered in the Oracle E-Business Suite environment under the Purchasing (PO) product. Its status is VALID and it is identified in the ETRM repository as a retrofitted object, meaning it was introduced or adjusted to preserve compatibility with prior reference implementations while the surrounding EBS codebase evolved. The view functions as a simplified projection of the HR_EMPLOYEES view, exposing a narrowly defined set of employee attributes rather than the full column set available in Oracle Human Resources.

In Oracle EBS 12.1.1 and 12.2.2, HR_EMPLOYEES_ALL_V serves as a reporting and integration surface for purchasing-related components that require employee identification data — buyer names, requester names, and contact e-mail addresses — without depending on the complete HR employee record. Because it is a view and not a table, it inherits the row-level security behavior of the underlying HR objects, which is an important consideration for any query executed outside the standard application security context.

Underlying Base Objects

The view text documented in the ETRM metadata is a direct column-list projection over HR_EMPLOYEES, selecting EMPLOYEE_ID, EMPLOYEE_NUM, FULL_NAME, FIRST_NAME, MIDDLE_NAME, LAST_NAME, and EMAIL_ADDRESS. No joins, filters, or aggregations are applied at the HR_EMPLOYEES_ALL_V layer itself.

The documented dependency list for the 12.2.2 metadata records additional referenced base objects: FND_PROFILE (PACKAGE), HR_EMPLOYEES (VIEW), HR_GENERAL (PACKAGE), HR_PERSON_NAME (PACKAGE), and HR_SECURITY (PACKAGE). These dependencies indicate that the data returned by the view is resolved through the standard HR security and name-formatting infrastructure. HR_SECURITY supplies the security profile logic that restricts the visible employee set, HR_GENERAL and HR_PROFILE resolve session-level business group and security context, and HR_PERSON_NAME governs how FULL_NAME is constructed from the name components. Consequently, HR_EMPLOYEES_ALL_V is not a flat copy of employee data; it is a secured, session-sensitive projection.

Key Columns

  • EMPLOYEE_ID — The internal surrogate key for the employee record. This is the column used in foreign key relationships throughout EBS and is the most reliable join key to HR and PO tables.
  • EMPLOYEE_NUM — The user-visible employee number assigned within the business group. This is the value most commonly searched for by end users and reported in purchasing documents, and it is the column referenced by the search term "employee_num".
  • FULL_NAME — The formatted display name of the employee, derived through the HR person-name infrastructure. Formatting follows the name style configured for the business group.
  • FIRST_NAME, MIDDLE_NAME, LAST_NAME — The individual name components exposed separately for reporting layouts that require discrete name fields.
  • EMAIL_ADDRESS — The employee's work e-mail address, used for notification and supplier communication workflows.

Common Use Cases and Queries

The most frequent application of this view is resolving an employee number to an internal employee identifier, or vice versa, when reporting on purchasing activity. A typical lookup by the searched term "employee_num" is shown below:

SELECT employee_id,
       employee_num,
       full_name,
       email_address
FROM   apps.hr_employees_all_v
WHERE  employee_num = :employee_num;

For buyer-oriented purchasing analysis, the view is commonly joined to PO_HEADERS_ALL or PO_AGENTS using EMPLOYEE_ID:

SELECT ph.segment1        AS po_number,
       hev.employee_num   AS buyer_num,
       hev.full_name      AS buyer_name
FROM   apps.po_headers_all   ph,
       apps.hr_employees_all_v hev
WHERE  ph.agent_id = hev.employee_id
AND    ph.segment1 = :po_number;

Another frequent scenario is e-mail notification reporting, where EMAIL_ADDRESS is extracted for a set of employees identified by number. Because the view enforces HR security, queries executed under an application session return only employees visible to the current security profile; direct SQL sessions that bypass HR security initialization may see a broader or narrower result set than the application reports. Report developers should therefore validate row counts against the corresponding application screen before publishing results.