Search Results biosketch_type




Overview
Explore in AI Chat

Overview

IGW_BIOSKETCH_TYPES_V is a reporting view owned by the APPS schema within the IGW (Grants Proposal) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. Its purpose is narrow and well-defined: it presents the set of valid biosketch type codes and their corresponding user-facing names, drawn from the Oracle Application Object Library (FND) lookup infrastructure. A "biosketch" in the grants context is a structured summary of a researcher's professional background, qualifications, publications, and prior support, typically submitted as part of a proposal package. The view exposes the controlled vocabulary used to categorize these biosketches, which the IGW application references during proposal authoring and review.

Because the view is a simple lookup translation layer rather than a transactional or denormalized reporting object, it plays a supporting role in EBS reporting and integration. Downstream reports, concurrent programs, and interfaces that need to resolve a stored biosketch type code into a meaningful label can query this view instead of joining directly to FND_LOOKUPS with a hard-coded lookup type. This encapsulates the lookup type string ('IGW_BIOSKETCH_TYPES') and reduces duplication across customizations and extensions.

Underlying Base Objects

The view is defined over a single documented base object: FND_LOOKUPS, the central application object library table that stores all lookup types, lookup codes, meanings, descriptions, and related attributes across every Oracle EBS module. No other base objects are documented in the ETRM metadata. The view applies a filter predicate restricting rows to those whose LOOKUP_TYPE equals 'IGW_BIOSKETCH_TYPES', so it returns only the biosketch category lookup values relevant to the Grants Proposal module.

Because FND_LOOKUPS is a shared, multi-tenant-style reference table within an EBS instance, the view implicitly depends on the enabled and effective state of the lookup rows. Only lookup codes that are active and available within the current language and date-effective window are typically returned by the underlying lookup mechanism, though the view text itself performs no explicit date or enabled-flag filtering beyond the LOOKUP_TYPE predicate. This means the effective content of IGW_BIOSKETCH_TYPES_V is administered through the Application Lookups maintenance form rather than through any IGW-specific configuration screen.

Key Columns

The view projects exactly two columns, both aliased from columns on FND_LOOKUPS:

  • BIOSKETCH_TYPE — sourced from LOOKUP_CODE. This is the stored, internal identifier for a biosketch category. It is the value most likely to be persisted on IGW transaction tables and compared programmatically.
  • BIOSKETCH_TYPE_NAME — sourced from MEANING. This is the translatable, human-readable label displayed to users on forms, reports, and self-service pages. Because MEANING is language-sensitive in FND_LOOKUPS, this column returns text in the session's current language.

The pairing of a stable code with a descriptive name is the canonical EBS lookup pattern, and it is the entirety of what this view exposes.

Common Use Cases and Queries

Typical uses include populating a selection list of biosketch categories, resolving a stored type into a display value for a report, and validating inbound values during an interface load. A representative query to list all available biosketch types is:

  • SELECT BIOSKETCH_TYPE, BIOSKETCH_TYPE_NAME FROM APPS.IGW_BIOSKETCH_TYPES_V ORDER BY BIOSKETCH_TYPE_NAME;
  • To resolve a single category for display: SELECT BIOSKETCH_TYPE_NAME FROM APPS.IGW_BIOSKETCH_TYPES_V WHERE BIOSKETCH_TYPE = :p_type;
  • To validate an inbound code during an interface: SELECT COUNT(*) FROM APPS.IGW_BIOSKETCH_TYPES_V WHERE BIOSKETCH_TYPE = :p_incoming;

Where the IGW data model stores a biosketch type on a proposal or person record, joining that table to this view on BIOSKETCH_TYPE yields a fully described result set suitable for reporting. Customizations that hard-code the lookup type should instead select from this view to remain consistent with the delivered, supported interface.