Search Results flm_ekb_preference_levels




Overview
Explore in AI Chat

Overview

FLM_EKB_PREFERENCE_LEVELS is a configuration table in the Oracle E-Business Suite Flow Manufacturing (FLM) module. It stores preference-level definitions that drive how Flow Manufacturing evaluates and prioritizes production lines, schedules, and resource selections during planning and execution. The table is owned by the FLM schema and is marked VALID in both Oracle EBS 12.1.1 and 12.2.2. The documented physical schema in ETRM 12.2.2 shows eleven columns, with the table participating in only one foreign-key relationship — an outbound reference to MSD_LEVELS through LEVEL_ID. Because of this single-FK profile, the ETRM Data Vault heuristic classifies the table as standalone. In Data Vault terms this suggests treating it as a reference or hub-like entity rather than a transactional link: it holds stable, reusable level definitions keyed by a surrogate identifier and scoped by organization and edition, rather than capturing event history or many-to-many associations.

Key Information Stored

The table's most important columns fall into three groups: identity, business scope, and audit/versioning.

  • LEVEL_ID — The surrogate primary key column and the FK to MSD_LEVELS. It uniquely identifies each preference-level row.
  • LEVEL_CODE — The human-readable, business-facing code used in forms, reports, and lookups. Together with LEVEL_ID and ZD_EDITION_NAME, it makes up the unique index FLM_EKB_PREFERENCE_LEVELS_U1 (LEVEL_ID, ZD_EDITION_NAME), confirming the business-key candidate is the combination of the level identifier and the edition name.
  • ORGANIZATION_ID — The operating-unit or inventory-organization scope for the preference level. This is critical for multi-org querying and row-level security.
  • MODULE_ID — Identifies the module or functional area to which the preference level applies, allowing the same level definitions to be reused across different configurations.
  • ZD_EDITION_NAME — The edition name supporting the Oracle EBS multi-edition (ZD) architecture, enabling versioned or staged definitions within the same table.
  • Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide standard who/when auditing, while OBJECT_VERSION_NUMBER supports optimistic locking and concurrency control during updates.

Common Use Cases and Queries

Typical scenarios include validating which preference levels are configured for a given organization, joining to MSD_LEVELS to retrieve descriptive level attributes, and filtering by module and edition when generating configuration reports. A representative query is:

  • SELECT p.LEVEL_ID, p.LEVEL_CODE, p.ORGANIZATION_ID, p.MODULE_ID, l.* FROM FLM.FLM_EKB_PREFERENCE_LEVELS p JOIN MSD_LEVELS l ON p.LEVEL_ID = l.LEVEL_ID WHERE p.ORGANIZATION_ID = :org_id AND p.ZD_EDITION_NAME = :edition;
  • Audit reporting: SELECT LEVEL_CODE, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM FLM.FLM_EKB_PREFERENCE_LEVELS ORDER BY LAST_UPDATE_DATE DESC;
  • Existence check for a multi-org setup: SELECT COUNT(*) FROM FLM.FLM_EKB_PREFERENCE_LEVELS WHERE ORGANIZATION_ID = :org_id AND MODULE_ID = :module_id;

These patterns support setup verification, migration comparison between 12.1.1 and 12.2.2, and diagnostic troubleshooting of Flow Manufacturing preference behavior.

Related Objects

The documented relationships and module context point to the following significant objects:

  • MSD_LEVELS — Referenced via FLM_EKB_PREFERENCE_LEVELS.LEVEL_ID → MSD_LEVELS; provides the descriptive definition of each level.
  • FLM_EKB_* configuration tables — Sibling EKB (Engineering Knowledge Base) tables in the FLM schema that share the LEVEL_ID and organization-scoping pattern.
  • FLM Flow Manufacturing line and schedule entities — Consume preference-level definitions during line balancing and scheduling.
  • ORG_ORGANIZATION_DEFINITIONS — Standard join for resolving ORGANIZATION_ID to organization names.
  • FND_APPLICATION / FND_MODULES — Optional joins for interpreting MODULE_ID.

Because the ETRM metadata classifies this object as standalone with a single FK, downstream dependencies should be confirmed through the FLM application forms and APIs rather than inferred from additional foreign keys.