Search Results eng_change_relation_objects

Overview

APPS.ENG_CHANGE_RELATIONS_V is a reporting and integration view in Oracle E-Business Suite that exposes the set of valid relationships between an engineering change object and the change order categories (change management types) defined in Oracle Engineering. The view reconciles two independent lookup domains: FND lookup values of type ENG_CHANGE_RELATIONSHIPS, which describe the nature of the relationship, and FND lookup values of type ENG_CHANGE_RELATION_OBJECTS, which identify the object against which the relationship is expressed. Where the relationship object is tagged ENG_CHANGE, the view cross-joins those relationships with the change order types held in ENG_CHANGE_ORDER_TYPES and its translation table, producing one row per relationship per applicable change order category. The remaining combinations are returned as a flat union.

The view is therefore the authoritative source for populating relationship-type list of values in Engineering Change Management (ECM) forms and for downstream reporting on which relationships apply to which change order categories. It is owned by APPS and is intended for read-only consumer access.

Underlying Base Objects

The view is defined over five documented base objects:

• ENG_CHANGE_ORDER_TYPES — master definition of change order types, including the TYPE_CLASSIFICATION and CHANGE_MGMT_TYPE_CODE attributes used to filter and label the relationship rows.
• ENG_CHANGE_ORDER_TYPES_TL — the translation (language) table supplying the TYPE_NAME column; joined on CHANGE_ORDER_TYPE_ID with LANGUAGE restricted to userenv('LANG').
• FND_LOOKUP_VALUES_VL — referenced twice as aliases LK1 and LK2, supplying lookup codes and meanings for the ENG_CHANGE_RELATIONSHIPS and ENG_CHANGE_RELATION_OBJECTS lookup types respectively.
• ENG_CHANGE_TYPE_APPLICATIONS — used in the correlated EXISTS subquery that enforces responsibility-level (application-level) security on which change order types are visible.
• FND_PROFILE — the profile option package, invoked to resolve RESP_APPL_ID for the responsibility-based filtering described above.

Rows are restricted to change order types whose TYPE_CLASSIFICATION is CATEGORY, and the change management type codes ATTACHMENT_APPROVAL and ATTACHMENT_REVIEW are explicitly excluded.

Key Columns

• LOOKUP_CODE (composite first column) — for ENG_CHANGE-tagged relationships, the concatenation of the relationship-object lookup code with the change management type code; this is the value actually presented in LOVs.
• NAME — the translated change order type name from ENG_CHANGE_ORDER_TYPES_TL; null in the union branch that does not involve change order types.
• Relationship lookup code and meaning — sourced from LK1 under lookup type ENG_CHANGE_RELATIONSHIPS, describing the relationship itself.
• TAG — the tag from the relationship lookup value; distinguishes the ENG_CHANGE object class from all other relationship object classes.
• Object class identifier — the literal 'ENG_CHANGE' in the first branch, or the relationship-object lookup code (LK2.LOOKUP_CODE) in the union branch.
• CHANGE_MGMT_TYPE_CODE — the change management type code from ENG_CHANGE_ORDER_TYPES, null in the union branch.

Common Use Cases and Queries

The view supports LOV population, responsibility-aware configuration reporting, and validation of relationship definitions for specific change order categories.

• Listing all relationships available to the current responsibility for engineering change order types:

  SELECT lookup_code, name, meaning, tag
  FROM   apps.eng_change_relations_v
  WHERE  tag = 'ENG_CHANGE';

• Identifying every category to which a given relationship applies:

  SELECT name, change_mgmt_type_code
  FROM   apps.eng_change_relations_v
  WHERE  lookup_code LIKE '&object_code%'
  ORDER  BY name;

• Auditing the complete relationship/object matrix, including non-ENG_CHANGE objects:

  SELECT tag, lookup_code, meaning, change_mgmt_type_code
  FROM   apps.eng_change_relations_v
  ORDER  BY tag, lookup_code;

Because the view depends on FND_PROFILE.VALUE('RESP_APPL_ID'), results vary with the active responsibility, and queries executed outside a defined responsibility context return the unrestricted set. Consumers should treat the view as read-only and avoid direct DML.