Results for “descriptive_flexfield_name”

50+ results




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

Overview

INV_LOT_SERIAL_CONTEXT_V is a reporting and integration view owned by the APPS schema within the INV – Inventory product of Oracle E-Business Suite. Its stated purpose, per the ETRM documentation, is to present a "View of Lot and Serial Descriptive Flex Field Context." In practical terms, the view exposes the enabled descriptive flexfield (DFF) contexts associated with lot and serial number attributes, allowing consumers to determine which context codes are available for lot-level and serial-level descriptive flexfield segments without navigating the underlying flexfield definition tables directly.

Descriptive flexfields in EBS are configured through the Flexfields application and are governed by the FND_DESCR_FLEX_CONTEXTS_VL family of views. Because lot and serial DFFs are registered under application identifier 401 (Inventory), retrieving only the relevant contexts requires both an application filter and a flexfield-name filter. This view encapsulates that filtering logic and, importantly, normalizes the two flexfield names ('LOT ATTRIBUTES' and 'SERIAL ATTRIBUTES') into a simplified business-facing label exposed through the QUERY_FOR column. This makes the view convenient for reports, concurrent programs, and integration interfaces that need to present or validate lot and serial contexts in end-user terminology.

Underlying Base Objects

The ETRM metadata documents two referenced base objects:

  • FND_DESCR_FLEX_CONTEXTS_VL (VIEW) — the core descriptive flexfield context definition view, supplying the flexfield name, the descriptive flex context code, and status flags such as ENABLED_FLAG. This is the primary source of the view's row data.
  • DUAL (SYNONYM) — used in the UNION to inject two synthetic "placeholder" rows representing the base, context-free lot and serial flexfield designations.

The view definition selects DESCRIPTIVE_FLEXFIELD_NAME, DESCRIPTIVE_FLEX_CONTEXT_CODE, and a derived QUERY_FOR column from FND_DESCR_FLEX_CONTEXTS_VL, restricting to APPLICATION_ID = 401 and flexfield names in ('LOT ATTRIBUTES', 'SERIAL ATTRIBUTES') where ENABLED_FLAG = 'Y'. It then performs a UNION with two SELECT statements from DUAL that supply the literal context code of a single space for each flexfield name, with QUERY_FOR hard-coded to 'LOT' and 'SERIAL' respectively. This construction ensures that even when no specific enabled contexts exist, the base lot and serial entries remain selectable in the dependent UI or process.

Key Columns

  • DESCRIPTIVE_FLEXFIELD_NAME — the internal name of the descriptive flexfield, either 'LOT ATTRIBUTES' or 'SERIAL ATTRIBUTES'. This identifies the flexfield to which the context belongs.
  • DESCRIPTIVE_FLEX_CONTEXT_CODE — the context code defined for the flexfield. For real contexts this is the configured context value; for the synthetic DUAL rows the code is a single space, indicating no specific context.
  • QUERY_FOR — a decoded, business-friendly label. The DECODE maps 'LOT ATTRIBUTES' to 'LOT' and the default case ('SERIAL ATTRIBUTES') to 'SERIAL'. This column is the primary discriminant used by callers to distinguish lot-related from serial-related records.

Common Use Cases and Queries

The view is typically used to populate context-of lists in lot and serial entry forms, reporting, and validation logic. A representative query lists enabled contexts for lots:

SELECT DESCRIPTIVE_FLEXFIELD_NAME,
       DESCRIPTIVE_FLEX_CONTEXT_CODE,
       QUERY_FOR
FROM   APPS.INV_LOT_SERIAL_CONTEXT_V
WHERE  QUERY_FOR = 'LOT'
ORDER  BY DESCRIPTIVE_FLEX_CONTEXT_CODE;

To retrieve all contexts across both flexfields, the QUERY_FOR filter is simply omitted. Integrations may join the view to FND_DESCR_FLEX_CONTEXTS_VL on DESCRIPTIVE_FLEXFIELD_NAME and DESCRIPTIVE_FLEX_CONTEXT_CODE to obtain additional context metadata such as descriptions. Because the view already restricts to APPLICATION_ID = 401 and ENABLED_FLAG = 'Y', callers are spared the need to reapply those predicates, though the view remains read-only and should not be used as a target for DML.