Results for “hr_fedrep_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

HR_FEDREP_V is an APPS-owned database view within the Oracle E-Business Suite Human Resources (PER) product family. Its documented description — "View for VETS/EEO on Generic Hierarchy" — identifies it as a reporting construct built to support federal regulatory reporting obligations, specifically the VETS-4212 (formerly VETS-100/100A) veterans' employment report and the EEO-1 Employer Information Report administered by the U.S. Equal Employment Opportunity Commission. Both submissions require employers to report establishment-level data, and Oracle delivers HR_FEDREP_V as a flattened, generic hierarchy representation that supplies location and establishment identifying information in a form suitable for extraction and integration with external federal reporting tools or custom concurrent programs.

The view carries a VALID status in the APPS schema in both Oracle EBS 12.1.1 and 12.2.2, and its structure is intentionally minimal. Rather than exposing the full breadth of the HR_LOCATIONS_ALL table, HR_FEDREP_V projects a small, focused column set that maps a location to a human-readable hierarchy node name. This design reflects the "Generic Hierarchy" concept: Oracle HRMS supports configurable hierarchies (business groups, organizations, locations, and their relationships), and this view shields downstream processes from that configuration complexity by delivering a single concatenated node label per location.

Underlying Base Objects

The view is defined over a single documented base object: HR_LOCATIONS_ALL, resolved through a synonym. HR_LOCATIONS_ALL is the core HRMS table that stores every location definition for a business group, including address elements, location codes, and associated flexfield and reference data. HR_FEDREP_V does not aggregate, join, or union multiple tables; it is a straightforward projection with inline string concatenation performed against the columns of HR_LOCATIONS_ALL. Because the view reads directly from HR_LOCATIONS_ALL and applies only TO_CHAR conversion and concatenation, it inherits that table's row-level security context and returns one row for every location record accessible to the querying session. No performance-critical joins exist, and the view can be treated as a lightweight, read-only address formatter for reporting purposes.

Key Columns

• ENTITY_ID — A character representation of LOCATION_ID, produced via TO_CHAR(LOCATION_ID). The column name suggests it is intended to serve as the reporting entity identifier in federal data extracts, where the establishment or reporting unit must be uniquely identified.
• NODE_NAME — A concatenated display label assembled from LOCATION_CODE, ADDRESS_LINE_1, ADDRESS_LINE_2, TOWN_OR_CITY, REGION_2, and COUNTRY. Each element is followed by DECODE logic that inserts a comma and space only when the preceding element is not null, preventing stray delimiters in the output string.
• LOCATION_ID — The native numeric location identifier from HR_LOCATIONS_ALL, retained as the third column to allow callers to join back to the base table or to other HRMS objects.
• REGION_2 — The state, province, or secondary region component of the location address. It is a constituent element of the NODE_NAME concatenation and is commonly the field of interest when users build ad hoc queries against this view, since EEO-1 and VETS reporting frequently require establishment data segmented by state.

Common Use Cases and Queries

The principal use case is the assembly of establishment-level address data for federal affirmative action and EEO reporting. A typical query retrieves the entity identifier, formatted address label, and underlying location identifier for all locations assigned to a business group:

SELECT entity_id, node_name, location_id FROM apps.hr_fedrep_v ORDER BY node_name;

Analysts commonly filter or group by region when validating data prior to submission, which in this view means parsing the concatenated NODE_NAME or, more reliably, joining back to HR_LOCATIONS_ALL on LOCATION_ID to access REGION_2 directly:

SELECT f.entity_id, f.node_name, l.region_2 FROM apps.hr_fedrep_v f, apps.hr_locations_all l WHERE f.location_id = l.location_id AND l.region_2 = 'CA';

A third scenario extracts the formatted address string for loading into an external reporting utility or spreadsheet template. Because NODE_NAME is a single concatenated value, it is well suited to flat-file generation in a custom concurrent program, eliminating the need for downstream delimiter handling. The REGION_2 element, whether read directly from HR_LOCATIONS_ALL or extracted from the node label, remains the most frequently referenced attribute for jurisdictional breakdowns in both VETS and EEO submissions.