Search Results sum_of_qty_scrapped

Overview

APPS.WIP_CUMULATIVE_SCRAP_V is a reporting view in the Oracle E-Business Suite Work in Process (WIP) module. Its purpose is to expose work orders where the cumulative scrap quantity has not yet been recorded on the WIP_OPERATIONS row, and to provide a running total of the quantity scrapped at preceding operations. In effect, the view reconstructs the cumulative scrap figure at each operation level for work orders that are still active.

Because Oracle EBS stores the aggregated cumulative scrap in the CUMULATIVE_SCRAP_QUANTITY column of WIP_OPERATIONS only after it has been calculated and saved, transactions that have been entered but not yet rolled into the cumulative value would otherwise be invisible to standard scrap reporting. This view fills that gap by deriving the cumulative figure at query time using an analytic window function, rather than relying on a stored value. It is a read-only data source, owned by APPS, and is typically consumed by reporting tools, custom concurrent programs, and integration routines that need visibility of in-flight scrapped quantities.

Underlying Base Objects

The view is defined over three base objects, all referenced through public synonyms in the APPS schema:

• WIP_OPERATIONS — the primary driving table, aliased WO. Each row represents an operation step on a work order, carrying the operation sequence number, organization, repetitive schedule reference, and the stored cumulative scrap quantity.
• WIP_DISCRETE_JOBS — aliased WDJ, joined through an EXISTS subquery on WIP_ENTITY_ID to restrict the result set to discrete jobs whose status type is not one of 12, 5, or 7 (excluded statuses such as closed or cancelled).
• WIP_REPETITIVE_SCHEDULES — aliased WRS, joined in the same EXISTS subquery via UNION ALL to cover repetitive work orders, applying the identical status filter.

The EXISTS predicate means a WIP_OPERATIONS row is returned only when a corresponding, still-open discrete job or repetitive schedule exists. This drives the view toward work orders that remain in an actionable state.

Key Columns

• ROW_ID — the ROWID of the underlying WIP_OPERATIONS row, useful as a unique identifier for the operation record.
• WIP_ENTITY_ID — the work order identifier linking the operation to its discrete job or repetitive schedule.
• CUMULATIVE_SCRAP_QUANTITY — the stored cumulative scrap value from WIP_OPERATIONS. The view's filter (IS NULL) means this column is always null in the returned rows, confirming the view targets operations whose cumulative figure has not been persisted.
• SUM_OF_QTY_SCRAPPED — a derived analytic column computing the running sum of QUANTITY_SCRAPPED across all preceding operations for the same work order, organization, and repetitive schedule, ordered by OPERATION_SEQ_NUM.

Note that QUANTITY_SCRAPPED and OPERATION_SEQ_NUM appear in the window function and ordering but are not projected in the SELECT list; only the four listed columns are exposed.

Common Use Cases and Queries

Typical scenarios include scrap reconciliation reporting, quality analysis of in-process work orders, and feeding derived scrap totals into custom dashboards or legacy integrations.

Retrieve all derived scrap rows for open work orders:

• SELECT wip_entity_id, cumulative_scrap_quantity, sum_of_qty_scrapped FROM apps.wip_cumulative_scrap_v;

Filter to a single work order to inspect the running total by operation:

• SELECT wip_entity_id, sum_of_qty_scrapped FROM apps.wip_cumulative_scrap_v WHERE wip_entity_id = :p_wip_entity_id ORDER BY wip_entity_id;

Aggregate derived scrap across open orders for a summary report:

• SELECT wip_entity_id, MAX(sum_of_qty_scrapped) total_scrapped FROM apps.wip_cumulative_scrap_v GROUP BY wip_entity_id;

Because the view depends on analytic processing and EXISTS subqueries, queries should be scoped by WIP_ENTITY_ID or organization where possible to limit full-table scans on the large WIP_OPERATIONS table.