Results for “updated_flag”

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

Overview

FND_CONC_RELEASE_DISJS is an Application Object Library (FND) table owned by the APPLSYS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the disjunction definitions used by the Concurrent Processing "Advanced Schedules" feature, which allows administrators to build complex release-time conditions from combinations of conjunctions and disjunctions. A disjunction represents an OR-style grouping of schedule criteria; the related conjunction members and disjunction members tables assemble these operators into complete schedule expressions.

Under a heuristic Data Vault classification derived from its foreign-key topology, FND_CONC_RELEASE_DISJS leans toward a satellite role, since it carries descriptive attributes and audit columns rather than acting as a pure association between two business hubs. This classification is a modeling suggestion only; in native EBS terms the table functions as a definitional master for Advanced Schedule disjunctions.

Key Information Stored

The table is defined with 15 documented columns. The most significant are:

• APPLICATION_ID and DISJUNCTION_ID — the composite primary key, FND_CONC_RELEASE_DISJS_PK, which uniquely identifies each disjunction within its owning application.
• DISJUNCTION_NAME — the user-visible identifier for the disjunction. Together with APPLICATION_ID it forms the unique business key documented as FND_CONC_RELEASE_DISJS_UK1 (and the unique index FND_CONC_RELEASE_DISJS_U1), making it the natural key for lookups.
• OWNER_REQ_ID — the concurrent request that owns or created the disjunction definition.
• OWNER_SCH_ID and OWNER_SCH_APP_ID — the owning schedule identifier and its application, linking the disjunction back to the parent Advanced Schedule.
• ENABLED_FLAG — indicates whether the disjunction is active and eligible for evaluation at release time.
• START_DATE_ACTIVE and END_DATE_ACTIVE — the effective date range during which the disjunction applies.
• UPDATED_FLAG — a modification indicator retained for internal change tracking.
• Standard audit columns: CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN.

The primary key is a surrogate composite (APPLICATION_ID, DISJUNCTION_ID), while DISJUNCTION_NAME serves as the documented business-key candidate through the unique index.

Common Use Cases and Queries

Typical uses center on diagnosing why a concurrent program released or failed to release under a complex schedule. Administrators query the table to enumerate disjunctions for a given application or schedule, and reporting scripts join it to its members and to the base schedule tables.

• Listing enabled disjunctions: SELECT disjunction_id, disjunction_name FROM fnd_conc_release_disjs WHERE application_id = :app AND enabled_flag = 'Y';
• Locating disjunctions by business key: SELECT * FROM fnd_conc_release_disjs WHERE disjunction_name = :name;
• Checking date-effective validity: filter on START_DATE_ACTIVE and END_DATE_ACTIVE relative to SYSDATE.
• Audit reporting: join CREATED_BY and LAST_UPDATED_BY to FND_USER, and LAST_UPDATE_LOGIN to FND_LOGINS, to trace who defined or changed a disjunction.

Related Objects

The following objects are documented as directly related through the FK structure:

• FND_CONC_REL_CONJ_MEMBERS — references this table via DISJUNCTION_APPLICATION_ID and DISJUNCTION_ID; stores conjunction members participating in the disjunction.
• FND_CONC_REL_DISJ_MEMBERS — references this table via DISJUNCTION_APPLICATION_ID and DISJUNCTION_ID; stores nested disjunction members.
• FND_CONC_RELEASE_DISJS_TL — the translation table, joined on APPLICATION_ID and DISJUNCTION_ID, holding language-specific disjunction names.
• FND_USER — referenced by CREATED_BY and LAST_UPDATED_BY.
• FND_LOGINS — referenced by LAST_UPDATE_LOGIN.