Search Results eng_revised_items_schedule_v

Overview

ENG_REVISED_ITEMS_SCHEDULE_V is an APPS-owned view in the Oracle E-Business Suite Engineering (ENG) module that presents engineering change order (ECO) schedules for revised items. It consolidates data from engineering change headers, revised item lines, bill of materials definitions, item master records, lookup values, and HR organization units into a single denormalized row per revised item schedule. The view is implemented with the /* ORDERED FIRST_ROWS */ hint, indicating that it is tuned for online, form-driven querying where rapid retrieval of the first rows takes precedence over full-result-set cost. Its primary role is to serve as the data source for the Engineering Change Order schedule window and related inquiry screens, and it is commonly reused in custom reports, OAF pages, and interfaces that require ECO schedule information without the overhead of assembling joins manually. Because the view is owned by APPS and exposed as a read-only object, it is safe to reference directly in custom SQL, though the underlying base tables should be preferred for any DML operations against the source records.

Underlying Base Objects

The view is defined over a join of eleven documented base objects. The driving tables are ENG_ENGINEERING_CHANGES (consumed via a synonym) and ENG_REVISED_ITEMS (also a synonym), which supply the change order header and the revised item line respectively. These two are joined on CHANGE_NOTICE and ORGANIZATION_ID. BOM_BILL_OF_MATERIALS provides the alternate bill designator, linked through BILL_SEQUENCE_ID. Item information is sourced from MTL_SYSTEM_ITEMS_B_KFV (concatenated segments) and MTL_SYSTEM_ITEMS_TL (description). Change order types come from ENG_CHANGE_ORDER_TYPES_VL. Four instances of MFG_LOOKUPS supply translated meanings for revised item status, disposition, approval status, and ECO status, while FND_COMMON_LOOKUPS provides the item type meaning. HR_ORGANIZATION_UNITS supplies DEPARTMENT_NAME, which is the column most frequently targeted by users searching this object. Several packages—FND_GLOBAL, FND_PROFILE, HR_GENERAL, and HR_SECURITY—are referenced, primarily to enforce organization-level access and profile-driven filtering.

Key Columns

• CHANGE_NOTICE / ORGANIZATION_ID — composite key identifying the engineering change and its owning organization.
• REVISED_ITEM / REVISED_ITEM_DESCRIPTION — concatenated item flexfield segments and the item description.
• NEW_ITEM_REVISION — the revision to be applied when the change is implemented.
• REVISED_ITEM_STATUS / REVISED_ITEM_STATUS_TYPE — decoded and coded status of the revised line.
• SCHEDULED_DATE / EARLY_SCHEDULE_DATE / IMPLEMENTATION_DATE / AUTO_IMPLEMENT_DATE — key scheduling dates driving ECO workflow.
• AUTO_IMPLEMENTED_FLAG — DECODE flag returning 1 when AUTO_IMPLEMENT_DATE is populated, otherwise 2.
• DEPARTMENT_NAME — the name of the HR organization unit, sourced from HR_ORGANIZATION_UNITS.
• DISPOSITION / DISPOSITION_TYPE — decoded disposition meaning for the revised item.
• APPROVAL_STATUS / ECO_STATUS — decoded meanings for change approval and overall ECO status.
• ROW_ID — the ROWID of ENG_REVISED_ITEMS, enabling direct row-level back-reference.

Common Use Cases and Queries

Typical usage includes listing pending ECO schedules by department, monitoring auto-implement dates, and producing change-order reports for specific organizations. A representative query filtering on department name is:

• SELECT change_notice, revised_item, department_name, scheduled_date, revised_item_status FROM apps.eng_revised_items_schedule_v WHERE department_name = :dept AND organization_id = :org ORDER BY scheduled_date;
• SELECT change_notice, revised_item, auto_implement_date FROM apps.eng_revised_items_schedule_v WHERE auto_implemented_flag = 1 AND implementation_date > SYSDATE;
• SELECT eco_status, approval_status, COUNT(*) FROM apps.eng_revised_items_schedule_v GROUP BY eco_status, approval_status;

Because the view returns one row per revised item schedule, aggregate queries should be grouped on CHANGE_NOTICE and REVISED_ITEM_ID to avoid over-counting.