Results for “xla_conditions_t”

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

Overview

XLA_CONDITIONS_T is an interface table in the XLA (Subledger Accounting) schema of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. Its documented purpose is to load the conditions associated with Accounting Definition Rule (ADR) rule details into Subledger Accounting. Conditions determine whether a given rule line or rule detail applies to a particular transaction, based on values evaluated against sources, flexfield segments, constants, or other operands. This table therefore functions as a staging and interface structure through which rule condition metadata is imported into the SLA rule engine rather than as an end-user operational table.

The ETRM metadata classifies XLA_CONDITIONS_T heuristically as standalone for Data Vault modeling purposes, with a single documented foreign key from SEGMENT_RULE_DETAIL_ID to XLA_SEG_RULE_DETAILS. Under a Data Vault interpretation, this suggests treating the table primarily as a satellite-like structure attached to the segment rule detail business entity, rather than modeling it as a hub or link in its own right. Note that this classification is a mined heuristic derived from the FK structure and should be validated against actual rule-population and loading patterns before being adopted as a formal model.

Key Information Stored

The documented physical schema contains 21 columns. The most significant columns include:

• CONDITION_ID — the surrogate primary key for each condition row.
• SEGMENT_RULE_DETAIL_ID — foreign key to XLA_SEG_RULE_DETAILS, associating the condition with a specific ADR rule detail; this is the primary business linkage.
• APPLICATION_ID — identifies the application owning the condition context.
• AMB_CONTEXT_CODE — the Application Message Board (AMB) context code defining the transaction context in which the condition applies.
• USER_SEQUENCE — controls evaluation order when multiple conditions exist for a rule detail.
• BRACKET_LEFT_CODE and BRACKET_RIGHT_CODE — control grouping/bracketing of the condition expression.
• VALUE_TYPE_CODE — indicates the type of the left-hand operand (source, constant, flexfield segment, etc.).
• SOURCE_APPLICATION_ID, SOURCE_TYPE_CODE, SOURCE_CODE — identify the left-hand source operand when the condition compares a source value.
• FLEXFIELD_SEGMENT_CODE — the flexfield segment used when the operand is a flexfield value.
• VALUE_FLEXFIELD_SEGMENT_CODE — identifies the flexfield segment used on the right-hand/value side.
• VALUE_SOURCE_APPLICATION_ID, VALUE_SOURCE_TYPE_CODE, VALUE_SOURCE_CODE — identify the right-hand source operand.
• VALUE_CONSTANT and INDEPENDENT_VALUE_CONSTANT — literal constant operands.
• LINE_OPERATOR_CODE and LOGICAL_OPERATOR_CODE — the comparison operator (e.g., =, >, <) and the logical connector (AND/OR) joining this condition line to the next.
• ERROR_VALUE — captures error handling value for invalid condition evaluation.

CONDITION_ID is the documented surrogate primary key. Business-key candidates are not enumerated in the metadata, though SEGMENT_RULE_DETAIL_ID combined with USER_SEQUENCE and the operand codes typically forms the logical uniqueness for a rule detail's condition set.

Common Use Cases and Queries

Typical use cases center on inspecting, validating, and tracing the conditions that control how SLA generates accounting for a transaction. Practical reporting scenarios include:

• Listing all conditions belonging to a given segment rule detail, in evaluation order, to reconstruct rule logic.
• Auditing rule conditions before or after a rule load into SLA.
• Tracing why a specific transaction did not produce the expected accounting entry by checking which conditions matched.
• Verifying operator pairing and bracket balance for complex conditional expressions.

A representative query joins back to the rule detail to display ordered condition lines:

SELECT c.condition_id,
       c.segment_rule_detail_id,
       c.user_sequence,
       c.value_type_code,
       c.source_code,
       c.value_constant,
       c.line_operator_code,
       c.logical_operator_code,
       c.error_value
  FROM xla_conditions_t c
 WHERE c.segment_rule_detail_id = :detail_id
 ORDER BY c.user_sequence;

Conditions can also be grouped by AMB_CONTEXT_CODE to analyze how many rule details depend on a particular context, which is useful when planning changes to transaction contexts.

Related Objects

The most significant related objects, grounded in the documented FK relationship, are:

• XLA_SEG_RULE_DETAILS — the parent rule detail; joined via SEGMENT_RULE_DETAIL_ID = XLA_CONDITIONS_T.SEGMENT_RULE_DETAIL_ID.
• XLA_SEG_RULE_DETAILS parent rule structures, typically reached through the rule detail's own rule header foreign keys (e.g., rule and application rule associations).
• XLA_APPLICATION_RULES — the owning ADR rule set to which the rule details, and consequently the conditions, belong.
• XLA_RULES / XLA_EVENT_RULES — rule definitions that reference the rule details that carry these conditions.
• XLA_AMB_CONTEXTS — source of AMB_CONTEXT_CODE values used in the condition definitions.
• SLA import/conversion programs that populate this interface table during ADR rule loading, plus related interface tables for rule details and rules.
• The Subledger Accounting rule inquiry pages (SLA accounting rules setup) that surface these conditions to end users.

Because the table is an interface structure, its dependency direction is toward the rule detail hierarchy owned by XLA_SEG_RULE_DETAILS; conditions cannot exist independently of a rule detail.