Search Results fn_postal_code




Overview
Explore in AI Chat

Overview

The view APPS.IGS_SV_CRT_STDT_FADDR_V is a reporting and integration object within the Oracle E-Business Suite (EBS) Student System (formerly Oracle Student System) module, exposed under the APPS schema. Its role is to present records from a student-administration address staging structure that represent the "first" address of a person — that is, the foreign address of record with an address type of 'F'. The view exposes a curated subset of address columns, renamed with an FN_ prefix, which distinguishes the "first name/foreign" attribute mapping from the base table's raw column names.

The view is non-financial and does not participate in Subledger Accounting or General Ledger posting flows. Instead, it is consumed by interfaces, extracts, and reports that need to retrieve the standard address of a person or a person linked to a student record. Users searching for the term fn_postal_code will encounter this view because it is the object that exposes the postal_code column from the underlying address table under the alias FN_POSTAL_CODE. This naming convention is typical of the IGS (Integrated Graduate System / Student System) address views, where the FN_ prefix denotes the foreign/native attribute set.

Underlying Base Objects

The view is defined over a single base table: IGS_SV_ADDRESSES, aliased in the view text as FADD. No additional joins, functions, or grouped objects are present, making this a relatively simple projection view. The ETRM metadata documents no additional referenced base objects, and the view is constructed purely as a column-level alias mapping over the address table.

The WHERE clause applies two filters to IGS_SV_ADDRESSES:

  • fadd.ACTIVITY_SITE_CD IS NULL — excludes addresses that are tied to an activity site, ensuring only non-site-specific addresses are returned.
  • fadd.address_type = 'F' — restricts rows to the address type designated as "F" (foreign / first address in the IGS convention).

Because the view contains no join, all columns surfaced are drawn directly from the address table, and no aggregation or analytical processing occurs at the view layer.

Key Columns

The view exposes eight columns, each derived from IGS_SV_ADDRESSES. The important columns include:

  • BATCH_ID — the batch identifier associated with the address record, used for grouping extracts or reconciliation.
  • PERSON_ID — the unique identifier of the person (student or applicant) to whom the address belongs. This is the primary join key to person and student tables such as HZ_PERSON or IGS person entities.
  • FN_ADDRESS_LINE1 — first line of the foreign address.
  • FN_ADDRESS_LINE2 — second line of the foreign address.
  • FN_CITY — the city for the foreign address.
  • FN_PROVINCE — the province, state, or region for the foreign address.
  • FN_COUNTRY_CODE — the country code for the foreign address.
  • FN_POSTAL_CODE — the postal code (ZIP or equivalent) for the foreign address. This is the column users typically target when searching for fn_postal_code, since the underlying base table column is simply postal_code.

Note that the FN_ prefix on the descriptive columns acts as a namespace distinguishing these attributes from similarly named columns that may exist on other address views (for example, domestic or mailing address variants).

Common Use Cases and Queries

Typical uses of this view include person address extracts, mailing/label generation for foreign addresses, and integration feeds that must supply postal codes for downstream processing. A representative query retrieving the foreign address for a given person is:

  • SELECT person_id, fn_address_line1, fn_address_line2, fn_city, fn_province, fn_country_code, fn_postal_code FROM apps.igs_sv_crt_stdt_faddr_v WHERE person_id = :p_person_id;
  • SELECT person_id, fn_postal_code FROM apps.igs_sv_crt_stdt_faddr_v WHERE fn_country_code = :p_country;
  • SELECT batch_id, COUNT(*) FROM apps.igs_sv_crt_stdt_faddr_v GROUP BY batch_id;

Because the view applies the address_type = 'F' and activity_site_cd IS NULL predicates internally, callers do not need to re-filter on those columns. However, consumers should be aware that the view returns at most the filtered subset of IGS_SV_ADDRESSES rows and does not enforce uniqueness on PERSON_ID; a person may have multiple qualifying rows, so a DISTINCT or ROWNUM guard may be advisable in single-address integrations.