Search Results cst_std_wip_adj_view




Overview
Explore in AI Chat

Overview

In Oracle E-Business Suite 12.1.1 and 12.2.2, CST_STD_WIP_ADJ_VIEW is a single-organization reporting view owned by the APPS schema and associated with the Bills of Material (BOM) product family. It exposes the results of a standard cost update as they apply to discrete jobs and repetitive schedules. When a standard cost update is executed in Oracle Cost Management, the difference between the old and new standard unit costs must be revalued against open work in process balances. CST_STD_WIP_ADJ_VIEW presents these work in process revaluation amounts already aggregated and pivoted across cost elements and transaction directions, so that a single row summarizes the total adjustment for a given cost update, organization, job, and inventory item.

Because the view is single-org in scope, each row is anchored to one ORGANIZATION_ID. This makes it suitable for organization-specific reporting, period-end reconciliation, and integration extracts where the standard cost update impact on a job or schedule must be quantified without scanning the underlying detail table directly.

Underlying Base Objects

The documented referenced base object for CST_STD_WIP_ADJ_VIEW is CST_STD_COST_ADJ_VALUES, accessed through a synonym in the APPS schema. CST_STD_COST_ADJ_VALUES is the standard cost adjustment values table populated during a standard cost update. It holds the granular adjustment records that drive revaluation, including the cost update identifier, organization, work in process entity, inventory item, cost element, level type, in/out direction, old unit cost, new unit cost, and adjustment quantity.

CST_STD_WIP_ADJ_VIEW applies a SELECT with GROUP BY over these granular rows and reduces them to aggregated columns. For each combination of COST_UPDATE_ID, ORGANIZATION_ID, WIP_ENTITY_ID, and INVENTORY_ITEM_ID, the view sums the adjustment value computed as (NEW_UNIT_COST - OLD_UNIT_COST) * ADJUSTMENT_QUANTITY. The view therefore acts as a thin aggregation and pivoting layer over its base object rather than introducing independent data of its own.

Key Columns

  • COST_UPDATE_ID — Identifier of the standard cost update that produced the adjustment; groups all related rows.
  • ORGANIZATION_ID — The single inventory organization whose work in process balances are revalued.
  • WIP_ENTITY_ID — The discrete job or repetitive schedule affected by the cost update.
  • INVENTORY_ITEM_ID — The item whose standard cost changed and against which the job balance is held.
  • Aggregated adjustment amounts — Distinct SUM columns hold the revaluation value, decoded by LEVEL_TYPE and COST_ELEMENT_ID, and split by IN_OUT_FLAG (+1 versus -1) to separate increases from decreases.

The DECODE logic keys off LEVEL_TYPE, COST_ELEMENT_ID, and IN_OUT_FLAG. LEVEL_TYPE 1 typically represents material-related elements and LEVEL_TYPE 2 resource-related elements, while COST_ELEMENT_ID 1 through 5 distinguish material, material overhead, resource, outside processing, and overhead. The result is a compact cost roll-up per job and item.

Common Use Cases and Queries

Typical uses include reconciling the work in process revaluation generated by a standard cost update, auditing the impact on specific jobs before and after a period close, and feeding downstream reporting extracts.

A representative query viewing adjustments for one cost update follows:

  • SELECT cost_update_id, organization_id, wip_entity_id, inventory_item_id FROM apps.cst_std_wip_adj_view WHERE cost_update_id = :p_update_id AND organization_id = :p_org_id;

For job-level analysis, filter on WIP_ENTITY_ID and INVENTORY_ITEM_ID, joining to WIP_ENTITIES and MTL_SYSTEM_ITEMS_VL using ORGANIZATION_ID for descriptive context. Because the view is single-org, callers should always constrain ORGANIZATION_ID to avoid cross-organization aggregation ambiguity, and should treat the aggregated columns as reporting figures rather than transactional balances.