Search Results line_currency_code




Overview

APFV_EXPENSE_REPORTS is a business view owned by the APPS schema and defined within the Oracle Payables (AP) module. It presents a consolidated, reporting-oriented projection of expense report and credit card invoice activity, joining invoice headers, invoice distributions, holds, accounting code combinations, suppliers, and HR person/assignment data into a single denormalized structure. The view is marked VALID in the ETRM 12.2.2 repository, confirming its availability for query and reporting purposes in Oracle EBS 12.1.1 and 12.2.2 environments.

The primary role of this view is to support operational and analytical reporting where a user needs expense report data tied back to the submitting employee and that employee's supervisor. Because the view text joins PER_ALL_PEOPLE_F twice — once as EMP (the employee) and once as SUP (the supervisor) — it exposes both the employee identifiers and the manager's identifiers, including supervisor employee number, first name, last name, and full name. This is directly relevant to the search term "manager_full_name," since the manager's name is surfaced through the SUP alias derived from PER_ALL_PEOPLE_F. Organizations typically use this view for auditing, expense analysis, and integration extracts where the reporting hierarchy is meaningful.

Underlying Base Objects

The view is defined over the following documented base objects:

Key Columns

Common Use Cases and Queries

A frequent requirement is listing expense reports alongside the manager's full name. The following illustrates that pattern:

  • SELECT invoice_num, total, full_name AS employee_name, supervisor_id FROM apfv_expense_reports;
  • SELECT invoice_num, total, supervisor_id FROM apfv_expense_reports WHERE supervisor_id IS NOT NULL;
  • Audit queries joining hold codes to supplier names, or filtering by ORG_ID and SET_OF_BOOKS_ID for multi-org reporting.

Note that the view aliases the supervisor's FULL_NAME without a distinct output alias, so in practice the manager attribute appears through the SUP join; consumers should select and alias appropriately. All queries should be run against the APPS schema or a synonym granted to the reporting user.