Results for “incident_number”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

ISC_DR_CURR_01_MV is a materialized view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Although the ETRM documentation classifies its product under FND — Application Object Library, the column composition and foreign key topology tie the object directly to the Depot Repair module. The view presents a curated, denormalized snapshot of open repair lines joined to inventory, customer, and promise-date context, which makes it a reporting convenience object rather than a transactional base table. Its name suffix "_MV" confirms it is a materialized view; the "_01_" segment suggests it is one of a series of purpose-built Depot Repair extracts intended for high-volume read access.

From a Data Vault modeling perspective, the mined FK structure yields a heuristic classification of standalone link. It carries multiple foreign-key references (to CSD_REPAIRS and CSD_REPAIR_TYPES_B) while owning no downstream dependents. A modeler treating this as a link table would place REPAIR_LINE_ID as the driving key and attach descriptive attributes as satellite candidates.

It is worth noting that the ETRM metadata marks this object as "Not implemented in this database," meaning it may exist only in certain patch levels or be excluded from specific environments. Developers should verify existence in DBA_OBJECTS before referencing it. Its 20 documented columns are consistent between the 12.1.1 and 12.2.2 schemas.

Key Information Stored

The most operationally significant columns fall into four groups:

• REPAIR_LINE_ID — the surrogate key governing record uniqueness and the primary join key back to the transactional repair line.
• REPAIR_NUMBER and SERIAL_NUMBER — business-key candidates used for user-facing lookups and unique identification of the physical unit under repair.
• REPAIR_TYPE_ID — FK to CSD_REPAIR_TYPES_B, describing the type of repair being performed.
• INVENTORY_ITEM_ID, ITEM_ORG_ID, REPAIR_ORGANIZATION_ID, MASTER_ORGANIZATION_ID, and PRODUCT_CATEGORY_ID — the item and organization context for the repair line.
• CUSTOMER_ID — the owning customer for the repair.
• QUANTITY and UOM_CODE — quantity requested and its unit of measure.
• STATUS and FLOW_STATUS_ID — the current workflow state of the repair line.
• PROMISE_DATE, PAST_DUE_DAYS, and PAST_DUE_FLAG — the service-level commitment metrics used in aging and SLA reporting.
• INCIDENT_NUMBER and INCIDENT_ID — linkage to the service incident that originated the repair.

REPAIR_LINE_ID functions as the primary key; no secondary unique index is documented in the metadata, so SERIAL_NUMBER plus REPAIR_ORGANIZATION_ID should be treated as a probable natural key.

Common Use Cases and Queries

Because the view is pre-denormalized, it is commonly consumed by operational dashboards tracking open repairs, past-due lines, and promise-date adherence. Typical queries filter on PAST_DUE_FLAG = 'Y' or aggregate PAST_DUE_DAYS by organization. A representative pattern:

• SELECT REPAIR_NUMBER, SERIAL_NUMBER, CUSTOMER_ID, PROMISE_DATE, PAST_DUE_DAYS FROM ISC_DR_CURR_01_MV WHERE PAST_DUE_FLAG = 'Y' AND REPAIR_ORGANIZATION_ID = :org_id;
• Grouping by PRODUCT_CATEGORY_ID for workload distribution reports.
• Joining CUSTOMER_ID to customer master views for SLA breach reporting.
• Filtering by FLOW_STATUS_ID to build repair funnel metrics.

Since it is a materialized view, refresh timing determines data freshness; users requiring real-time status should query CSD_REPAIRS directly.

Related Objects

• CSD_REPAIRS — joined on REPAIR_LINE_ID; the primary transactional parent.
• CSD_REPAIR_TYPES_B — joined on REPAIR_TYPE_ID; supplies repair type descriptions.
• MTL_SYSTEM_ITEMS_B — joined on INVENTORY_ITEM_ID for item descriptions.
• HR_ALL_ORGANIZATION_UNITS — joined on REPAIR_ORGANIZATION_ID.
• HZ_CUST_ACCOUNTS — joined on CUSTOMER_ID for customer detail.
• CS_INCIDENTS_ALL_B — joined on INCIDENT_ID for the originating incident.