Search Results resides_at

Overview

APPS.IGF_SL_ADDR_V is a reporting and integration view in Oracle E-Business Suite that exposes party address information for student and person records maintained by the Student System (the IGF product family). Its name reflects its primary purpose: to retrieve the "resides at" and "home" address of a party. The resides_at search term maps directly to the view's filter predicate, where PSU.SITE_USE_TYPE IN ('HOME','RESIDES_AT') restricts output to residential address usages. The view flattens the normalized TCA (Trading Community Architecture) address model into a single denormalized row per party site, making it convenient for downstream consumers such as financial aid, admissions, letters, and third-party interfaces that require a person's residential address without navigating the underlying relationship tables. The IGF_ prefix indicates that the object is delivered as part of the Oracle Student System and is typically referenced by other views, concurrent programs, and reports within that module. As a view rather than a table, it holds no data of its own and always reflects the current state of the source TCA records.

Underlying Base Objects

The view is defined over three Trading Community Architecture tables:

• HZ_PARTY_SITES (PS) — the association between a party and a location, supplying PARTY_ID (aliased to PERSON_ID), LOCATION_ID, PARTY_SITE_ID, and the effective dating columns START_DATE_ACTIVE and END_DATE_ACTIVE.
• HZ_LOCATIONS (L) — the physical address itself, providing ADDRESS1 through ADDRESS4, CITY, STATE, PROVINCE, COUNTY, COUNTRY, POSTAL_CODE, and LAST_UPDATE_DATE.
• HZ_PARTY_SITE_USES (PSU) — the usage assignments for a party site, supplying SITE_USE_TYPE and STATUS.

The three tables are joined on PS.LOCATION_ID = L.LOCATION_ID and PS.PARTY_SITE_ID = PSU.PARTY_SITE_ID. No other referenced base objects are documented in the ETRM metadata. The Legal Notices section confirms the view text is Oracle proprietary and confidential.

Key Columns

• PERSON_ID — sourced from HZ_PARTY_SITES.PARTY_ID; identifies the person whose address is returned.
• SITE_USE_TYPE — the usage code taken from HZ_PARTY_SITE_USES; constrained by the view to HOME or RESIDES_AT.
• ADDR_LINE_1 … ADDR_LINE_4 — the free-form street address lines from HZ_LOCATIONS.
• CITY, STATE, PROVINCE, COUNTY, COUNTRY, POSTAL_CODE — the geographic components of the location record.
• LAST_UPDATE_DATE — the last modification timestamp from HZ_LOCATIONS, commonly used for incremental extraction and change detection.

Common Use Cases and Queries

Typical consumers use the view to resolve a student's or person's residential address for correspondence, financial aid verification, residency determination, or data migration. A standard query retrieving the resides-at address for a single party is:

SELECT person_id, addr_line_1, addr_line_2, city,
       state, postal_code, country
FROM   apps.igf_sl_addr_v
WHERE  person_id = :p_person_id;

Because a party may hold more than one qualifying site use, applications should anticipate multiple rows per person. Filtering by usage is straightforward:

SELECT person_id, addr_line_1, city, postal_code
FROM   apps.igf_sl_addr_v
WHERE  site_use_type = 'RESIDES_AT'
AND    person_id IN (SELECT person_id FROM ...);

For incremental interfaces, the LAST_UPDATE_DATE column supports delta extraction:

SELECT * FROM apps.igf_sl_addr_v
WHERE  last_update_date >= :p_since_date;

Administrators should note that the view applies an effective-date filter of SYSDATE BETWEEN NVL(PS.START_DATE_ACTIVE, SYSDATE) AND NVL(PS.END_DATE_ACTIVE, SYSDATE), meaning only currently active party sites are returned. Additionally, only records with PSU.STATUS = 'A' are exposed, so inactive or obsolete site uses are excluded automatically.