Search Results std_process_rev_num

Overview

The view AMW_NONSTANDARD_VARIATIONS_VL is a descriptive (VL, "view label") dictionary object belonging to the AMW product family, historically known as Internal Controls Manager, now classified as obsolete within the Oracle E-Business Suite 12.1.1 and 12.2.2 data model. Its documented purpose is to display non-standard variation justifications — that is, the recorded business reasons and life-cycle attributes associated with deviations (non-standard variations) that were introduced in place of a defined standard process, revision, or child object.

Because it is a VL view, it joins a base table (AMW_NONSTANDARD_VARIATIONS_B) with a translation table (AMW_NONSTANDARD_VARIATIONS_TL) so that the free-text justification field (REASON) is returned in the session's current language. This makes the view suitable for multilingual reporting and for direct integration reads where a language-independent identifier set is combined with a language-specific descriptive column. The metadata notes that the view is "Not implemented in this database," indicating it is a legacy dictionary definition that may be absent or empty in an EBS 12.2.2 instance even though its definition persists in the ETRM repository.

The std_process_rev_num column that a user searches for in connection with this object is the standard process revision number — the revision of the standard (governed) process that a controlled non-standard variation was granted against. It appears alongside the analogous non_std_process_rev_num, allowing direct comparison between the standard and non-standard revision contexts.

Underlying Base Objects

The ETRM metadata records no separate referenced base objects, but the embedded view text makes the dependencies explicit. The view is defined as an inner join between:

• AMW_NONSTANDARD_VARIATIONS_B — the base table storing the variation row, the standard and non-standard process/revision identifiers, child identifiers, effective dates, and standard WHO columns.
• AMW_NONSTANDARD_VARIATIONS_TL — the translation table holding the language-specific REASON text.

The join condition is B.VARIATION_ROW_ID = T.VARIATION_ROW_ID, filtered by T.LANGUAGE = USERENV('LANG'). This is the canonical VL pattern: one row per variation, with the descriptive reason resolved to the caller's language. No _B/_TL objects are documented as separately implemented in the target database.

Key Columns

• VARIATION_ROW_ID — primary surrogate key for the variation record; the join key between the _B and _TL tables.
• STD_PROCESS_ID — identifier of the standard process from which the variation departs.
• STD_PROCESS_REV_NUM — revision number of that standard process; the primary focus of a search on this view.
• NON_STD_PROCESS_ID / NON_STD_PROCESS_REV_NUM — identifier and revision of the substituted non-standard process.
• STD_CHILD_ID / NON_STD_CHILD_ID — child (sub-process) identifiers for the standard and non-standard variants.
• REASON — the language-resolved justification for the variation.
• START_DATE / END_DATE — validity window of the variation.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY — standard WHO audit columns.
• SECURITY_GROUP_ID — multi-org / security partitioning column.
• OBJECT_VERSION_NUMBER — optimistic locking token.

Common Use Cases and Queries

Typical use cases include governance and compliance reporting (listing all approved non-standard variations and their justifications), traceability audits (correlating a variation to a specific standard process revision), and integration extracts feeding GRC or audit tools. A representative query returning variations against a particular standard process revision is:

• SELECT v.variation_row_id, v.std_process_id, v.std_process_rev_num, v.non_std_process_rev_num, v.reason, v.start_date, v.end_date FROM amw_nonstandard_variations_vl v WHERE v.std_process_rev_num = :rev_num;

To list active variations only:

• SELECT v.variation_row_id, v.reason FROM amw_nonstandard_variations_vl v WHERE SYSDATE BETWEEN v.start_date AND NVL(v.end_date, SYSDATE);

Because the object is documented as obsolete and "not implemented" in the surveyed database, queries should be preceded by a metadata check against ALL_VIEWS to confirm existence before execution in a given EBS 12.1.1 or 12.2.2 environment.