Results for “action_code”

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

Overview

CS_SR_EVENT_ACTIONS is a Service (CS) module table in Oracle E-Business Suite 12.1.1 and 12.2.2 that defines the valid associations between service request events and the actions that may be performed in response to them. In the Service Request framework, an event represents a state transition or business occurrence raised against a service request, while an action represents an executable operation, workflow invocation, or notification triggered by that event. This table functions as the authoritative mapping that the Service Request runtime engine consults to determine which actions are permitted for a given event.

From a Data Vault modeling perspective, the heuristic classification derived from the foreign key structure is a link table. It resolves a many-to-many relationship between two descriptive hubs, CS_SR_EVENT_CODES_B and CS_SR_ACTION_CODES_B, and carries a limited set of descriptive attributes. This classification is a modeling suggestion only; the physical implementation is a standard Oracle EBS intersection table with audit columns and edition tracking.

Key Information Stored

The table stores the pairing of an event with an action, together with activation dates and standard audit and multi-tenant metadata. The most significant columns are:

• EVENT_CODE — Foreign key to CS_SR_EVENT_CODES_B, identifying the service request event that raises the association.
• ACTION_CODE — Foreign key to CS_SR_ACTION_CODES_B, identifying the action permitted for that event.
• START_DATE_ACTIVE / END_DATE_ACTIVE — Effective dating controls that determine the window during which the event-action association is active.
• SEEDED_FLAG — Indicates whether the association was shipped as seed data by Oracle or created by the customer.
• APPLICATION_ID — Identifies the owning application context for the row.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the EBS framework during concurrent updates.
• ZD_EDITION_NAME — Editioning column supporting Online Patching (adop) in Edition-Based Redefinition architecture.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard who-columns capturing audit lineage.

The surrogate primary key is defined by CS_SR_EVENT_ACTIONS_PK over (ACTION_CODE, EVENT_CODE). A documented unique index, CS_SR_EVENT_ACTIONS_U1, covers (EVENT_CODE, ACTION_CODE, ZD_EDITION_NAME), which acts as the business-key candidate and preserves uniqueness across editioned rows. The table contains thirteen documented columns in total.

Common Use Cases and Queries

Typical usage centers on resolving the permitted action set for a given event, validating configuration completeness, and reporting on seeded versus custom associations.

• Listing all actions bound to a specific event:

  SELECT action_code
  FROM   cs.cs_sr_event_actions
  WHERE  event_code = :p_event_code
  AND    TRUNC(SYSDATE) BETWEEN NVL(start_date_active, TRUNC(SYSDATE))
                            AND NVL(end_date_active, TRUNC(SYSDATE));

• Identifying customer-defined configurations: filter on SEEDED_FLAG = 'N' to isolate extensions added by implementers.
• Joining to the event and action base tables to produce a readable event-to-action matrix for configuration review:

  SELECT e.event_code, e.name, a.action_code, a.name
  FROM   cs.cs_sr_event_actions ea,
         cs.cs_sr_event_codes_b e,
         cs.cs_sr_action_codes_b a
  WHERE  ea.event_code  = e.event_code
  AND    ea.action_code = a.action_code;

• Auditing stale associations by checking END_DATE_ACTIVE against the current date.

Related Objects

The table sits between two reference tables and is consumed by the Service Request processing layer. The most significant related objects are:

• CS_SR_EVENT_CODES_B — joined via EVENT_CODE; holds event definitions.
• CS_SR_ACTION_CODES_B — joined via ACTION_CODE; holds action definitions.
• CS_SR_EVENT_ACTIONS_PK — the primary key constraint enforcing uniqueness of the action/event pair.
• CS_SR_EVENT_ACTIONS_U1 — the unique index supporting business-key and edition lookups.
• Service Request runtime APIs — the CS_SR public APIs that read this table to resolve valid transitions at execution time.

Because both foreign keys point to descriptive base tables, referential integrity ensures that no association can exist without a corresponding event and action definition, and deletions in the base tables are typically restricted. Implementers should treat rows with SEEDED_FLAG of 'Y' as Oracle-maintained and avoid direct modification.