Search Results eng_change_relation_objects

Overview

ENG_CHANGE_RELATIONS_V is an Oracle E-Business Suite (EBS) reporting view owned by the APPS schema within the Engineering (ENG) product module. It exposes the set of valid relationships that can exist between an Engineering Change Order (ECO) and other objects in the EBS data model, combining engineering change management categories with system lookups. The view is a read-only, denormalized construct intended for inquiry, reporting, and integration rather than transactional data entry.

In the context of both EBS 12.1.1 and 12.2.2, the view serves as a reference source that answers the question "which objects or change management categories may be related to an engineering change?" It merges two distinct relationship populations: change order types classified as categories (restricted by responsibility application access) and generic relationship objects tagged outside of the 'ENG_CHANGE' scope. Because it is defined entirely over synonyms and lookup views rather than base tables directly, it is stable across releases and suitable for custom reports, forms, and interface programs.

Underlying Base Objects

The ETRM documentation records the following referenced objects:

• ENG_CHANGE_ORDER_TYPES (synonym) — the base definition of change order types, filtered to those with TYPE_CLASSIFICATION = 'CATEGORY'.
• ENG_CHANGE_ORDER_TYPES_TL (synonym) — the translation table supplying the language-specific TYPE_NAME, joined on CHANGE_ORDER_TYPE_ID and restricted to USERENV('LANG').
• ENG_CHANGE_TYPE_APPLICATIONS (synonym) — used in the responsibility-driven EXISTS subquery to restrict visible change types by RESP_APPL_ID.
• FND_LOOKUP_VALUES_VL (view) — joined twice (aliased LK1 and LK2) to resolve lookup types 'ENG_CHANGE_RELATIONSHIPS' and 'ENG_CHANGE_RELATION_OBJECTS'.
• FND_PROFILE (package) — supplies the RESP_APPL_ID profile value at runtime.

The view is a UNION of two SELECT statements. The first concatenates LOOKUP_CODE values and joins the change order type tables filtered by category classification and application access; the second addresses non-'ENG_CHANGE' tagged relationship objects. Both branches rely on the standard FND lookup infrastructure.

Key Columns

• RELATION_OBJECT_NAME — the display name of the related object or relationship.
• RELATION_OBJECT — the underlying code identifying the related object.
• RELATIONSHIP_CODE — the coded identifier for the relationship type.
• RELATIONSHIP — the human-readable meaning of the relationship.
• RELATIONSHIP_TYPE — the tag indicating the relationship category.
• OBJECT_NAME — the concatenated object name, in the first branch built from LOOKUP_CODE and CHANGE_MGMT_TYPE_CODE; in the second branch drawn from LOOKUP_CODE.
• CHANGE_MGMT_OBJECT_NAME — the change management object name, populated in the first branch from CHANGE_MGMT_TYPE_CODE and NULL in the second (the second branch is not filtered on ATTACHMENT types).

Common Use Cases and Queries

The view is typically used to populate LOVs, validate relationship selections, and drive custom engineering change reports. The two UNION branches are excluded from ATTACHMENT_APPROVAL and ATTACHMENT_REVIEW change management type codes in the category branch, keeping those out of general relationship lists.

SELECT relationship_code,
       relationship,
       relation_object,
       relation_object_name,
       object_name
FROM   apps.eng_change_relations_v
ORDER BY relationship_code;

A more targeted query restricts to change management object names for a specific relationship:

SELECT object_name, change_mgmt_object_name
FROM   apps.eng_change_relations_v
WHERE  relationship_type = 'ENG_CHANGE';

Because the view applies profile-based filtering through FND_PROFILE.VALUE('RESP_APPL_ID'), results can vary by responsibility context, so reports should be run or tested under the intended responsibility. When NVL defaults the profile to 1, all categories become visible, which is the behavior expected during system administration or setup validation checks.