Results for “action_id”

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

Overview

SO_ACTION_CLAUSES is an Order Entry (OE) module table in the Oracle E-Business Suite database, owned by the OE schema. Its documented description — "Cycle action where clauses" — identifies its function as a repository of SQL WHERE clause fragments evaluated during order cycle actions. Oracle's order management framework allows administrators to attach conditional logic to cycle actions so that actions execute only when specified criteria are satisfied; SO_ACTION_CLAUSES stores the predicate text that drives this conditional branching. In ETRM 12.2.2 the table is documented as VALID with thirteen physical columns and a composite primary key, SO_ACTION_CLAUSES_PK, defined over ACTION_ID, TYPE, and SEQUENCE.

Under the heuristic Data Vault classification mined from its foreign key structure, SO_ACTION_CLAUSES is satellite-leaning. It carries descriptive, version-like attributes — the clause text and its ordering — subordinate to the parent SO_ACTIONS record, rather than representing an independent business entity or an association between two hubs. A Data Vault model would therefore typically place this content in a satellite hanging off the SO_ACTIONS hub, keyed by ACTION_ID plus a sequence or load-date component.

Key Information Stored

The table's identity is established by SO_ACTION_CLAUSES_PK, whose columns are ACTION_ID, TYPE, and SEQUENCE. A separately documented unique index, SO_ACTION_CLAUSES_U1, enforces the same column triplet (ACTION_ID, TYPE, SEQUENCE), marking it as the business-key candidate and confirming that a given action may own multiple clauses distinguished by type and ordinal position. ACTION_ID is also the sole documented foreign key, referencing SO_ACTIONS.ACTION_ID, which binds every clause row to its parent cycle action.

The most significant business column is WHERE_CLAUSE, which holds the conditional expression evaluated at runtime. TYPE classifies the clause role, and SEQUENCE orders multiple clauses belonging to the same action. Standard EBS audit and concurrency columns are present: CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, and the concurrent-program context columns PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, and REQUEST_ID. These last five capture the program invocation that inserted or modified the clause, which is valuable when tracing why a cycle action behaved differently after a configuration change.

Common Use Cases and Queries

Typical usage centers on diagnosing why a cycle action did or did not fire. A clause listing joined to the parent action exposes the stored predicates:

• Clause inventory by action: SELECT c.action_id, c.type, c.sequence, c.where_clause FROM oe.so_action_clauses c WHERE c.action_id = :action_id ORDER BY c.type, c.sequence;
• Join to actions for context: SELECT a.action_id, a.name, c.type, c.sequence, c.where_clause FROM oe.so_actions a, oe.so_action_clauses c WHERE a.action_id = c.action_id;
• Change auditing: filter on LAST_UPDATE_DATE and LAST_UPDATED_BY to identify recently altered conditional logic, or on REQUEST_ID to correlate a clause with the concurrent request that wrote it.
• Migration and comparison reporting: extract WHERE_CLAUSE text between environments to verify that cycle-action conditions were promoted consistently.

Because the primary key mirrors the unique index, queries should always constrain ACTION_ID to avoid full scans of the clause text column, which is typically the widest field in the table.

Related Objects

The documented foreign key relationship ties SO_ACTION_CLAUSES.ACTION_ID to SO_ACTIONS.ACTION_ID, making SO_ACTIONS the dominant parent object and the natural join path for any reporting or troubleshooting query. Beyond this direct relationship, the table participates in the broader Order Entry cycle-action configuration set, which includes the cycle definition and cycle action assignment objects that determine when actions and their clauses are evaluated during order, line, and workflow processing. Functional administrators maintain the WHERE_CLAUSE content through the Order Management setup user interface rather than direct DML, so the table is best treated as read-only reference data for reporting. When tracing end-to-end behavior, analysts should join upward through ACTION_ID to SO_ACTIONS and then onward to the cycle and workflow configuration objects that reference those actions, using ACTION_ID and SEQUENCE as the stable correlation keys throughout.