Search Results igs_pe_hz_locations




Overview

IGS_PE_HZ_LOCATIONS is a table within the Oracle E-Business Suite Student System module (product code IGS), documented against release 12.1.1 and applicable to the 12.1.1 / 12.2.2 code lines. Per the ETRM metadata, the entity describes the locations associated with a person — that is, the address and venue location records that the Student System maintains for individuals such as students, applicants, and staff. The metadata notes the product as Obsolete and records that the object is "Not implemented in this database," indicating that in the surveyed installation the physical table is not deployed; the documentation nonetheless preserves the intended schema, which is materially useful for remediation, migration, and upgrade analysis.

Functionally, the table acts as a person-to-location association object. Its foreign key to HZ_LOCATIONS ties each IGS student-system record to the shared Oracle Trading Community Architecture (TCA) location repository, which is the enterprise-wide source for addresses. The heuristic Data Vault classification supplied in the relationship metadata is hub-leaning, which suggests modeling this entity as a hub keyed on the location identifier, with dependent descriptive attributes optionally split into a satellite. This classification follows from the primary key being a single surrogate identifier and the table's role as a stable, referenced endpoint rather than a transactional intersection.

Key Information Stored

The documented physical schema comprises sixteen columns. The primary columns of interest are:

  • LOCATION_ID — the surrogate primary key (IGS_PE_HZ_LOCATIONS_PK) and simultaneous business-key candidate, since it also carries the unique index IGS_PE_HZ_LOCATIONS_U1. It is the join column to HZ_LOCATIONS.
  • CORRESPONDENCE — indicates whether the location is used for correspondence purposes, a common address-type qualifier.
  • DATE_LAST_VERIFIED — the date on which the location information was last confirmed, supporting address quality and validation reporting.
  • CONTACT_PERSON — the individual associated with the location for contact purposes.
  • OTHER_DETAILS_1, OTHER_DETAILS_2, OTHER_DETAILS_3 — descriptive placeholder attributes for supplementary location context.

Standard EBS audit and concurrency columns are also present: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, and the concurrent-program audit set REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, and PROGRAM_UPDATE_DATE. These columns follow the conventional WHO columns pattern and are essential for lineage and change-tracking queries.

Common Use Cases and Queries

Typical usage centers on resolving a location identifier to its TCA address and determining whether that location serves as a correspondence address. A canonical join is:

  • SELECT l.location_id, l.correspondence, l.date_last_verified, h.address1, h.city, h.postal_code FROM igs_pe_hz_locations l, hz_locations h WHERE l.location_id = h.location_id;
  • Reporting on stale addresses by filtering DATE_LAST_VERIFIED beyond a threshold for data-quality remediation.
  • Reverse lookup from venue address records via IGS_AD_LOCVENUE_ADDR to the originating person location.
  • Audit queries against LAST_UPDATED_BY and LAST_UPDATE_DATE to trace who amended a person's location data.

Because the object is documented as obsolete and unimplemented, these patterns are chiefly relevant to historical extracts, upgrade gap analysis, and archive reconciliation rather than live transaction processing.

Related Objects

  • HZ_LOCATIONS — parent table; joined on IGS_PE_HZ_LOCATIONS.LOCATION_ID = HZ_LOCATIONS.LOCATION_ID. Provides the authoritative address attributes.
  • IGS_AD_LOCVENUE_ADDR — child table; references this entity through IGS_AD_LOCVENUE_ADDR.LOCATION_ID → IGS_PE_HZ_LOCATIONS.LOCATION_ID. Links locations to venue addresses used in admissions or scheduling.
  • IGS_PE_HZ_LOCATIONS_PK — the primary key constraint enforcing uniqueness on LOCATION_ID.
  • IGS_PE_HZ_LOCATIONS_U1 — the unique index on LOCATION_ID, serving as the documented business-key candidate.

Together, these relationships position IGS_PE_HZ_LOCATIONS as the IGS-side bridge between person-centric location assignments and the TCA location hub, with IGS_AD_LOCVENUE_ADDR as its principal downstream consumer.