Search Results oe_def_attr_condns




Overview

OE_DEF_ATTR_CONDNS is an Oracle Order Management (ONT) configuration table that associates a defaulting condition, defined at the entity level, to a specific attribute. In consequence, it functions as the attribute-level binding layer of the Order Management defaulting framework: a condition established for an entity in OE_DEF_ATTR_DEF_RULES is given concrete effect only when a row exists in this table naming the attribute (identified by DATABASE_OBJECT_NAME and ATTRIBUTE_CODE) to which the condition applies, together with the order of evaluation. Without rows in OE_DEF_ATTR_CONDNS, an entity-level condition has no attribute target.

Under the heuristic Data Vault classification mined from the foreign-key structure, this object is hub-leaning. This classification should be treated as a modeling suggestion rather than a documented architectural fact. The table is owned by the ONT schema and is valid in both Oracle EBS 12.1.1 and 12.2.2. The documented physical schema exposes 29 columns, the standard WHO audit columns, a set of descriptive flexfield segments, two flag columns, and the editioning column ZD_EDITION_NAME used in the 12.2.x Online Patching model.

Key Information Stored

The primary key is the OE_DEF_ATTR_CONDNS_PK constraint, defined on the single column ATTR_DEF_CONDITION_ID. This value is a system-generated surrogate identifier and is not normally surfaced to end users.

A second unique index, OE_DEF_ATTR_CONDNS_U1, exists on (ATTR_DEF_CONDITION_ID, ZD_EDITION_NAME). Because the leading column duplicates the surrogate primary key, these two constraints jointly enforce uniqueness in the context of the editioning model rather than defining an independent business key; the edition column is what distinguishes otherwise identical identifiers across editions.

The functionally significant columns are the following:

  • ATTR_DEF_CONDITION_ID — surrogate primary key and the target of the foreign-key reference from OE_DEF_ATTR_DEF_RULES.
  • CONDITION_ID — the identifier of the defaulting condition being attached to an attribute.
  • DATABASE_OBJECT_NAME — the entity (database object) against which the condition is evaluated.
  • ATTRIBUTE_CODE — the specific attribute to which the condition applies.
  • PRECEDENCE — determines the evaluation sequence when multiple conditions target the same attribute.
  • ENABLED_FLAG — controls whether the condition–attribute association is active.
  • SYSTEM_FLAG — identifies rows seeded by Oracle as opposed to user-defined configuration.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — descriptive flexfield segments reserved for customer-defined extensions.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit and concurrency columns.
  • ZD_EDITION_NAME — edition discriminator supporting the 12.2.x editions-based data model.

Common Use Cases and Queries

The most frequent use of this table is diagnostic: establishing why an order attribute defaulted to a particular value, or failed to default at all. A typical pattern resolves the rule, then the condition, then the attribute binding, then the attribute value itself, and finally the defaulting source that produced it.

  • Attribute coverage report — join OE_DEF_ATTR_CONDNS to OE_DEF_ATTR_DEF_RULES on ATTR_DEF_CONDITION_ID to list every entity-level rule and the attributes it targets.
  • Duplicate precedence detection — group by DATABASE_OBJECT_NAME and ATTRIBUTE_CODE and select rows where more than one ENABLED_FLAG = 'Y' associates competing conditions to the same attribute, which can produce nondeterministic defaulting behavior.
  • Seed versus configuration audit — filter on SYSTEM_FLAG to distinguish Oracle-seeded associations from those created by implementers, useful prior to upgrades.
  • Edition-aware lookups — in 12.2.x, restrict on ZD_EDITION_NAME to read the current edition's configuration and avoid reading rows belonging to other editions.

Related Objects

The documented relationships place this table at the centre of the attribute defaulting configuration model.

  • OE_DEF_ATTR_DEF_RULES — the primary referencing table; OE_DEF_ATTR_DEF_RULES.ATTR_DEF_CONDITION_ID references OE_DEF_ATTR_CONDNS, so this is the mandatory join path from rule to attribute binding.
  • OE_DEF_ATTR_CONDNS_PK and OE_DEF_ATTR_CONDNS_U1 — the primary key and unique index definitions described above.
  • OE_DEF_ATTR_CONDNS itself is referenced by OE_DEF_ATTR_DEF_RULES, making the rule table the principal dependency to interrogate when tracing defaulting behavior.
  • The Order Management defaulting engine and its associated setup APIs consume these rows during order entry and order import, deriving the effective default value for each attribute.

Because the FK metadata identifies OE_DEF_ATTR_DEF_RULES as the sole documented referencing object, it should be treated as the first and most significant join target in any investigation involving OE_DEF_ATTR_CONDNS.