Search Results igw_biosketch_types




Overview
Explore in AI Chat

Overview

APPS.IGW_PRPO_BIOSKETCH_V is a reporting view within the Oracle E-Business Suite Grants and Proposal Management (formerly Oracle Grants/Proposal) application family. It consolidates person-level biosketch information associated with a proposal so that proposal administrators, grants specialists, and downstream reporting or integration components can retrieve the biosketch types and descriptive text attached to each key person on a proposal. The view resolves the coded biosketch type (BIOSKETCH_TYPE) into its user-facing description through a lookup join against the IGW_BIOSKETCH_TYPES lookup type, which is the precise object that a user searching for "igw_biosketch_types" is attempting to locate. Because the view exposes a denormalized, human-readable result set, it is commonly used as a foundation for OBIEE/XML Publisher reports, concurrent program extracts, and interface logic rather than for direct transactional data entry.

Underlying Base Objects

The view is defined as a UNION of two nearly identical SELECT statements joined across four base objects. Each branch combines IGW_PROP_PERSON_BIOSKETCH (aliased PPPB), IGW_PERSON_BIOSKETCH (aliased PPB), IGW_PROP_PERSONS (aliased KEY), and IGW_LOOKUPS_V (aliased VAL).

  • IGW_PROP_PERSON_BIOSKETCH (PPPB) — the proposal-to-biosketch association, supplying proposal_id, person_biosketch_id, show_flag, and the shared person_biosketch_id.
  • IGW_PERSON_BIOSKETCH (PPB) — stores the person-level biosketch record, including person_id, party_id, biosketch_type, line_description, and the enable_flag used to filter active records.
  • IGW_PROP_PERSONS (KEY) — the proposal person roster, contributing key_person_flag and the join keys person_id, person_party_id, and proposal_id.
  • IGW_LOOKUPS_V (VAL) — the lookups view filtered to lookup_type = 'IGW_BIOSKETCH_TYPES', translating lookup_code into the displayed meaning.

The UNION's two halves differ only in their person-matching strategy. The first branch matches on KEY.person_id = PPB.person_id, resolving biosketches tied to a person who has a formal person_id. The second branch matches on KEY.person_party_id = PPB.party_id with KEY.person_id IS NULL, capturing persons recorded at the party level who lack a person_id. This dual-path design allows the view to return biosketches regardless of whether the proposal person was captured through the person or party identifier. Junction filters PPB.enable_flag = 'Y' and PPPB.show_flag = 'Y' restrict output to enabled and displayable records, and the result is ordered by columns 2 and 4 (person_id, biosketch_type).

Key Columns

  • PROPOSAL_ID — identifier of the proposal to which the biosketch belongs.
  • PERSON_ID — the person identifier for the biosketch holder, where available.
  • PARTY_ID — the party (TCA) identifier, permitting person-parties to be resolved when no person_id exists.
  • BIOSKETCH_TYPE — the lookup code describing the biosketch category (for example, the codes defined under IGW_BIOSKETCH_TYPES).
  • MEANING — the translated lookup meaning for the biosketch type, derived from IGW_LOOKUPS_V.
  • LINE_DESCRIPTION — the descriptive or narrative text of the biosketch.
  • KEY_PERSON_FLAG — indicates whether the associated proposal person is flagged as a key person.

Common Use Cases and Queries

Typical applications include producing personnel biosketch sections for proposal print packages, validating that key persons have appropriate biosketch types configured against the IGW_BIOSKETCH_TYPES lookup, and extracting biosketch narratives for grants reporting. A representative query is:

  • SELECT proposal_id, person_id, party_id, biosketch_type, meaning, line_description, key_person_flag FROM apps.igw_prpo_biosketch_v WHERE proposal_id = :p_proposal_id ORDER BY person_id, biosketch_type;
  • SELECT biosketch_type, meaning, COUNT(*) FROM apps.igw_prpo_biosketch_v WHERE key_person_flag = 'Y' GROUP BY biosketch_type, meaning;

Because the view is owned by APPS and is not documented as exposing base-table columns directly, consumers should treat it as a read-only reporting artifact and rely on the lookup meaning rather than the raw code where user-facing output is required.