Results for “hr_locations”

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

Overview

HR_LOCATIONS is a reporting view owned by the APPS schema within the PER (Human Resources) product family of Oracle E-Business Suite 12.1.1 and 12.2.2. It presents HRMS location information, exposing the physical and business addresses that are maintained in Oracle HRMS and shared across multiple EBS modules. The view is a denormalized, translation-aware projection of the underlying HR_LOCATIONS_ALL and HR_LOCATIONS_ALL_TL tables, combining the base location record with its language-specific descriptive text. Its principal role is to provide a stable, read-optimized interface for reporting, concurrent programs, and external integrations that require location details without navigating the full complexity of the base tables. The ETRM lists the object as VALID with a documented dependency on the HR_GENERAL package along with the HR_LOCATIONS_ALL and HR_LOCATIONS_ALL_TL synonyms.

Underlying Base Objects

The view is defined by a join between HR_LOCATIONS_ALL (aliased LOC) and HR_LOCATIONS_ALL_TL (aliased LOT). HR_LOCATIONS_ALL holds the operational location record, including address components, site flags, and DFF attributes; HR_LOCATIONS_ALL_TL holds the translatable description and location code. APPS.HR_LOCATIONS references these through the synonyms HR_LOCATIONS_ALL and HR_LOCATIONS_ALL_TL, and the documented metadata also records HR_GENERAL (PACKAGE) as a referenced base object, typically invoked for business-group context and utility logic. The view supplies a literal value of 'HR' as the source identifier and computes BUSINESS_GROUP_ID using an arithmetic offset (LOC.BUSINESS_GROUP_ID+0), a common EBS idiom to strip nullability hints and force a datatype in the projection.

Key Columns

• LOCATION_ID — Primary key for the location; the join key back to base tables.
• LOCATION_CODE — User-defined short code from the TL table, used as the unique location identifier in forms and reports.
• BUSINESS_GROUP_ID — Identifies the HR business group that owns the location.
• DESCRIPTION — Translatable long description of the location.
• Address columns — ADDRESS_LINE_1 through _3, TOWN_OR_CITY, COUNTRY, POSTAL_CODE, and REGION_1 through _3.
• Telephone columns — TELEPHONE_NUMBER_1 through _3.
• Site flags — SHIP_TO_SITE_FLAG, RECEIVING_SITE_FLAG, BILL_TO_SITE_FLAG, IN_ORGANIZATION_FLAG, OFFICE_SITE_FLAG, and the related SHIP_TO_LOCATION_ID.
• Operational columns — INVENTORY_ORGANIZATION_ID, DESIGNATED_RECEIVER_ID, TAX_NAME, INACTIVE_DATE, and STYLE.
• Descriptive flexfields — ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE20.
• Global flexfields — GLOBAL_ATTRIBUTE_CATEGORY and GLOBAL_ATTRIBUTE1 through GLOBAL_ATTRIBUTE20.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, ENTERED_BY, and OBJECT_VERSION_NUMBER.
• TP/ECE columns — TP_HEADER_ID and ECE_TP_LOCATION_CODE for trading-partner integration.

Common Use Cases and Queries

Typical usage includes LOV queries in concurrent programs, location validation during employee and assignment processing, and data extraction for interfaces and BI Publisher reports. Because the view already joins the translation table, reports can select descriptive text without performing an explicit TL lookup.

SELECT location_id, location_code, description, town_or_city, country
FROM   apps.hr_locations
WHERE  business_group_id = :p_business_group_id
AND    inactive_date IS NULL;

SELECT l.location_code, l.description, l.address_line_1, l.postal_code
FROM   apps.hr_locations l
WHERE  l.ship_to_site_flag = 'Y';

When querying, note that BUSINESS_GROUP_ID and other numeric offsets are projected as computed expressions, and that filters should respect the TL join so that only the appropriate language row is returned. For high-volume extraction, joining directly against the base tables may be preferable, but HR_LOCATIONS remains the standard API-facing source for location reporting in both 12.1.1 and 12.2.2.