Results for “lookup_value”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

FND_CONC_STATE_LOOKUPS is a reference (lookup) table owned by the APPLSYS schema within the FND – Application Object Library product of Oracle E-Business Suite. Its documented description is "Values for Concurrent States." In practice, the table stores the enumerated set of state codes that a concurrent request or concurrent program may occupy during its lifecycle — for example, states denoting a request that is running, completed normally, completed with warnings, completed with errors, pending, scheduled, or on hold. These values form the controlled vocabulary that other concurrent processing objects reference when recording status information.

The table is essentially a specialized lookup container rather than a transactional fact store. Its rows are configuration-level metadata that define and constrain the state values used across the concurrent manager subsystem. From a Data Vault modeling perspective, the mined relationship structure classifies this object as satellite-leaning: it holds descriptive attributes (the state definitions and their enable/active flags) keyed against a parent lookup type, and is referenced by other tables rather than aggregating business events itself. This classification is offered as a heuristic modeling suggestion, not as a statement of Oracle's internal design intent.

Key Information Stored

The documented physical schema in ETRM 12.2.2 consists of thirteen columns in the APPLSYS schema. The most significant are:

• LOOKUP_TYPE_ID — foreign key to FND_CONC_STATE_LOOKUP_TYPES; identifies the lookup type (category) to which the state value belongs.
• LOOKUP_VALUE — the state code itself; the human-recognizable token stored and matched against concurrent processing data.
• ENABLED_FLAG — controls whether the state value is active and selectable.
• OWNER_REQ_ID — request identifier of the owning concurrent request, where applicable.
• OWNER_SCH_ID and OWNER_SCH_APP_ID — identifiers of the owning scheduling entity and its application context.
• START_DATE_ACTIVE and END_DATE_ACTIVE — the effective date range over which the lookup value is considered valid.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns tracking row authorship and maintenance.

The composite primary key, FND_CONC_STATE_LOOKUPS_PK, is defined over (LOOKUP_TYPE_ID, LOOKUP_VALUE). A unique index, FND_CONC_STATE_LOOKUPS_U1, is also documented over the same two columns, making (LOOKUP_TYPE_ID, LOOKUP_VALUE) the business-key candidate: the pairing that uniquely identifies a state value within its type. There is no separate surrogate key column beyond the composite key documented.

Common Use Cases and Queries

Typical reporting and diagnostic scenarios include decoding state codes into meaningful descriptions, validating configuration of concurrent states, and reconciling release-state records against their definitions. A representative join retrieves the translations for a given state:

• Join FND_CONC_STATE_LOOKUPS to FND_CONC_STATE_LOOKUPS_TL on LOOKUP_TYPE_ID and LOOKUP_VALUE to obtain language-specific display text.
• Filter by ENABLED_FLAG and the START_DATE_ACTIVE / END_DATE_ACTIVE window to return only currently valid states.
• Join to FND_CONC_RELEASE_STATES on LOOKUP_TYPE_ID (and its STATUS column) to associate release states with their defining lookup values.
• Join to FND_CONC_STATE_LOOKUP_TYPES on LOOKUP_TYPE_ID to group or categorize state values.

Such queries support operational dashboards that summarize concurrent request outcomes, configuration audits confirming that all required states are enabled, and migration checks that compare state definitions across environments.

Related Objects

The following objects are documented as related through foreign key and translation relationships:

• FND_CONC_STATE_LOOKUP_TYPES — parent table; joined via LOOKUP_TYPE_ID.
• FND_CONC_STATE_LOOKUPS_TL — translation table; joined via LOOKUP_TYPE_ID and LOOKUP_VALUE.
• FND_CONC_RELEASE_STATES — references this table through LOOKUP_TYPE_ID and STATUS.
• FND_USER — referenced via CREATED_BY and LAST_UPDATED_BY.
• FND_LOGINS — referenced via LAST_UPDATE_LOGIN.

These relationships establish FND_CONC_STATE_LOOKUPS as the central definition point for concurrent request states, with dependent satellite and referencing tables consuming its values throughout the concurrent processing subsystem.