Search Results ece_tp_location_code

Overview

The APPS.PO_HR_LOCATIONS view is a Purchasing (PO) module database object that exposes Human Resources location information in a flattened, purchasing-friendly form. It belongs to the Oracle E-Business Suite (EBS) releases 12.1.1 and 12.2.2 and carries a status of VALID in the APPS schema. The ETRM metadata describes the object as "Retrofitted," indicating that its definition was reconstructed or reintroduced to preserve backward compatibility with an earlier data model, most likely the legacy PO_LOCATIONS structure that existed prior to the integration of HRMS location tables into the purchasing data flow. The view presents ship-to, bill-to, receiving, office, and inventory-organization site indicators alongside full address and descriptive attributes, effectively acting as a compatibility layer between the HR location model and reporting or integration components that expect a purchasing-oriented location shape. Because it is a read-only view, it is used principally for querying and for feeding concurrent programs, reports, and extracts rather than for transactional inserts or updates.

Underlying Base Objects

The view text is constructed from two primary HRMS synonyms: HR_LOCATIONS_ALL (aliased LOC) and HR_LOCATIONS_ALL_TL (aliased LOT), joined to produce a single denormalized row per location. HR_LOCATIONS_ALL supplies the master location record—identifiers, site flags, address elements, DFF and global DFF attribute columns, and audit columns—while HR_LOCATIONS_ALL_TL supplies the translated location code and description. The documented referenced base objects further include the HR_GENERAL package, HZ_LOCATIONS synonym, and the HR_LOCATIONS_ALL and HR_LOCATIONS_ALL_TL synonyms. The predicate filters on the NVL of a location column, and the literal 'HR' is projected as a source indicator column, confirming that the view normalizes HR-sourced locations into the purchasing namespace. The BUSINESS_GROUP_ID is exposed as LOC.BUSINESS_GROUP_ID+0, a defensive conversion that guarantees a numeric result.

Key Columns

Identity and site classification are carried by LOCATION_ID, LOCATION_CODE, and BUSINESS_GROUP_ID. Operational flags include SHIP_TO_LOCATION_ID, SHIP_TO_SITE_FLAG, RECEIVING_SITE_FLAG, BILL_TO_SITE_FLAG, IN_ORGANIZATION_FLAG, OFFICE_SITE_FLAG, and DESIGNATED_RECEIVER_ID, with INVENTORY_ORGANIZATION_ID linking a location to a warehouse. Address attributes comprise ADDRESS_LINE_1 through ADDRESS_LINE_3, TOWN_OR_CITY, COUNTRY, POSTAL_CODE, REGION_1 through REGION_3, and TELEPHONE_NUMBER_1 through TELEPHONE_NUMBER_3. TAX_NAME, INACTIVE_DATE, and STYLE provide tax and lifecycle context. Descriptive flexfield columns ATTRIBUTE1–ATTRIBUTE20 and GLOBAL_ATTRIBUTE1–GLOBAL_ATTRIBUTE20, together with ATTRIBUTE_CATEGORY and GLOBAL_ATTRIBUTE_CATEGORY, are fully exposed. Audit columns LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE, and ENTERED_BY support change tracking, while TP_HEADER_ID and ECE_TP_LOCATION_CODE support trading-partner and EDI location mapping, and OBJECT_VERSION_NUMBER enables optimistic locking patterns in downstream logic.

Common Use Cases and Queries

Typical usage includes validating a supplier or ship-to address before creating a purchase order, populating location lists in purchasing reports, and joining location data to EDI or trading-partner extracts. A representative query returning active receiving locations is:

• SELECT location_id, location_code, description, town_or_city, country, receiving_site_flag FROM po_hr_locations WHERE NVL(inactive_date, SYSDATE+1) > SYSDATE AND receiving_site_flag = 'Y' ORDER BY location_code;
• SELECT l.location_id, l.location_code, l.address_line_1, l.town_or_city, l.postal_code FROM po_hr_locations l WHERE l.ship_to_site_flag = 'Y' AND l.business_group_id = :p_business_group_id;
• SELECT location_id, location_code, inventory_organization_id, designated_receiver_id FROM po_hr_locations WHERE office_site_flag = 'Y';

Because the view draws from HR_LOCATIONS_ALL and HR_LOCATIONS_ALL_TL, report logic should account for translated location codes and should filter on INACTIVE_DATE to exclude retired sites. Compliance teams also query DFF attributes (ATTRIBUTE1–ATTRIBUTE20) to surface site-specific configuration used by purchasing and receiving transactions.