Search Results so_valid_results_v




Overview
Explore in AI Chat

Overview

SO_VALID_RESULTS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, registered with a VALID status and classified under the Order Entry (OE) product family. In the context of EBS 12.1.1 and 12.2.2, the view functions as a denormalized access point that joins result definitions to their associated action bindings. Oracle Order Management uses a Results framework to describe the discrete outcomes that an order, line, or workflow activity can produce — for example, a successful booking, a failed credit check, or a conditional hold. The SO_VALID_RESULTS_V view presents each result together with the actions that are configured to fire when that result occurs. This makes it the canonical reference for administrators, support analysts, and integration developers who need to enumerate which result-action combinations are active in a given environment without navigating the underlying modeling tables directly.

Underlying Base Objects

Per the documented ETRM metadata, the view is defined over two base objects, both referenced through APPS synonyms: SO_RESULTS and SO_ACTION_RESULTS. The view text is a straightforward inner join between these two tables:

  • SO_RESULTS (alias R) — the master table of result definitions, holding the result identifier, its name, and its description.
  • SO_ACTION_RESULTS (alias AR) — the association table that maps each result to one or more actions configured against it.
  • Join condition — AR.RESULT_ID = R.RESULT_ID, which restricts output to results that possess at least one associated action.

Because the join is an equi-join on RESULT_ID with no outer construct, a result defined in SO_RESULTS but never linked to an action in SO_ACTION_RESULTS will not appear in the view. This is consistent with the view's name: it is intended to surface valid, actionable results rather than the full catalog.

Key Columns

The view exposes four columns, two sourced from each base object:

  • RESULT_NAME — taken from SO_RESULTS.NAME; the developer-facing identifier of the result.
  • DESCRIPTION — taken from SO_RESULTS.DESCRIPTION; free-text explanation of the result's meaning and intent.
  • RESULT_ID — taken from SO_ACTION_RESULTS.RESULT_ID; the foreign key linking back to the result definition.
  • ACTION_ID — taken from SO_ACTION_RESULTS.ACTION_ID; the identifier of the action bound to that result.

The column ordering in the view definition surfaces RESULT_NAME and DESCRIPTION first, which suits ad hoc query and reporting use where a human-readable label is more useful than a numeric key.

Common Use Cases and Queries

Typical scenarios include auditing result-action configuration following a patch or upgrade, troubleshooting why a workflow branch did not execute, and populating custom reports or extracts that must reference Order Management result metadata. Because the view carries only four columns, it is often joined back to SO_ACTIONS on ACTION_ID to obtain the action name and processing type. A representative query follows:

  • List all valid result-action pairs:
    SELECT result_name, description, result_id, action_id FROM apps.so_valid_results_v ORDER BY result_name;
  • Check whether a specific result has any configured action:
    SELECT * FROM apps.so_valid_results_v WHERE UPPER(result_name) = UPPER(:p_result_name);
  • Resolve action details for a result:
    SELECT v.result_name, v.action_id, a.action_name
    FROM apps.so_valid_results_v v, apps.so_actions a
    WHERE v.action_id = a.action_id
    AND v.result_id = :p_result_id;

Queries should be executed against the APPS schema or through a synonym, with appropriate read privileges granted to custom reporting users. Since the underlying tables are seeded and maintained by Oracle, the view should be treated as read-only.