Search Results eng_change_summary_page

Overview

APPS.ENG_CHANGE_OBJ_RELATIONSHIPS_V is an Oracle E-Business Suite view that presents the relationships defined between engineering change orders (ECOs) and the objects they affect. It belongs to the Engineering Change Management (ECM) module and is built on top of the ENG_CHANGE_OBJ_RELATIONSHIPS table, which stores the physical relationship records between a change and the objects linked to it—other engineering changes, items, revisions, projects, or tasks. The view enriches those raw relationship rows with descriptive context such as the relationship meaning, the type name of the target object, the status of the related change, and its need-by date.

The view is used primarily for reporting and integration, including Oracle Application Framework (OAF) pages such as the Change Summary page. Because it exposes a ready-made object_to_url column, the view is convenient for building navigable links from a relationship row to the detail record of the object on the other side of the relationship. In EBS 12.1.1 and 12.2.2 the view is delivered as an APPS synonym-based object and is referenced by OA framework regions and by custom inquiry reports that need a denormalized view of ECO-to-object links.

Underlying Base Objects

The ETRM metadata records that the view is defined over the following base objects: ENG_CHANGE_OBJ_RELATIONSHIPS, ENG_CHANGE_ORDER_TYPES, ENG_CHANGE_ORDER_TYPES_TL, ENG_CHANGE_STATUSES_TL, ENG_ENGINEERING_CHANGES, FND_LOOKUP_VALUES (via the FND_LOOKUP_VALUES_VL view), MTL_ITEM_REVISIONS_VL, MTL_SYSTEM_ITEMS_KFV, PA_PROJECTS_ALL, and PA_TASKS.

• ENG_CHANGE_OBJ_RELATIONSHIPS (ECA) is the driving table, holding change_id, change_relationship_id, relationship_code, object_to_name, and the object_to_id1/id2/id3 keys.
• ENG_CHANGE_ORDER_TYPES and ENG_CHANGE_ORDER_TYPES_TL supply the type classification and translated type name (CATEGORY classification).
• ENG_ENGINEERING_CHANGES supplies the related change number, name, status, and need-by date.
• ENG_CHANGE_STATUSES_TL supplies the translated status name.
• FND_LOOKUP_VALUES_VL resolves the relationship code into a meaning and tag for the ENG_CHANGE_RELATIONSHIPS lookup type.
• MTL_ITEM_REVISIONS_VL, MTL_SYSTEM_ITEMS_KFV, PA_PROJECTS_ALL, and PA_TASKS supply descriptions for item, revision, project, and task objects referenced by the object_to_id keys.

The view is a UNION ALL of multiple branches, each handling a different case of object_to_name (for example, ENG_CHANGE versus item, revision, project, or task), so all supported target object types are presented through a single consistent column set.

Key Columns

• change_id – identifier of the engineering change being reported on.
• change_relationship_id – primary key of the underlying relationship row.
• relationship_code / relationship – code and translated meaning of the relationship (from ENG_CHANGE_RELATIONSHIPS).
• object_to_name – the type of the related object, such as ENG_CHANGE, ITEM, or REVISION.
• object_to – the descriptive type name of the related object.
• object_to_id1, object_to_id2, object_to_id3 – the key values identifying the related object; usage varies by object type (for example, object_to_id1 carries the change_id or item identifier depending on the union branch).
• object_to_url – a pre-built OA Framework function URL (OAFunc=ENG_CHANGE_SUMMARY_PAGE) that navigates to the related change summary page.
• relationship_to_number / relationship_to_name – change notice number and name of the related engineering change.
• relationship_type – lookup tag classifying the relationship direction.
• wused_relationship – flag ('Y'/'N') indicating whether the relationship branch flags the companion relationship.
• status – translated status name of the related change.
• need_by_date, creation_date, last_update_date, revision, revision_label – supporting attributes; revision and revision_label are returned as NULL in the documented branches.

Common Use Cases and Queries

Typical uses include listing all objects linked to an ECO, displaying the related change notice for a given relationship, and generating navigable links to the change summary page. A common query retrieves the objects related to a specific change:

• SELECT change_id, relationship, object_to, object_to_id1, object_to_url FROM apps.eng_change_obj_relationships_v WHERE change_id = :p_change_id;
• SELECT relationship_to_number, relationship_to_name, status, need_by_date FROM apps.eng_change_obj_relationships_v WHERE object_to_name = 'ENG_CHANGE' AND object_to_id1 = :p_change_id;
• SELECT object_to_name, COUNT(*) FROM apps.eng_change_obj_relationships_v GROUP BY object_to_name;

Because the view performs a UNION ALL across multiple object types, queries should filter on object_to_name or the appropriate object_to_id columns to avoid scanning branches that are not relevant. Joins back to ENG_ENGINEERING_CHANGES on change_id facilitate status or date filtering, and the object_to_url column can be consumed directly by OAF pages or custom JSP/HTML reports to render hyperlinks to the related change. The view is read-only by nature and should be queried rather than updated; relationship maintenance is performed against ENG_CHANGE_OBJ_RELATIONSHIPS through the ECM application programming interfaces.