Results for “cst_wip_value_history_u2”

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

Overview

BOM.CST_WIP_VALUE_HISTORY is a cost management table in Oracle E-Business Suite that stores historical snapshots of Work in Process (WIP) valuation. Each row records the before-and-after state of a discrete job or repetitive schedule's accumulated costs at the moment a costing transaction is processed. The table captures cost elements at two levels of granularity — this level (TL) and previous level (PL) — covering material, material overhead, resource, overhead, outside processing, and scrap, each expressed as inbound value, outbound value, and variance. This design allows the Cost Management module to reconstruct how a job or schedule's valuation changed over time, which is essential for cost rollups, variance analysis, and audit trail reporting.

The heuristic Data Vault classification for this object is standalone. In modeling terms, this suggests the table functions as a self-contained transaction fact or history satellite rather than participating in a classic hub-and-link structure. Practitioners treating it as a satellite should note that its natural business key — the transaction identity combined with the WIP asset identity — is embedded directly in the row rather than resolved through hub relationships. The table resides in the APPS_TS_TX_DATA tablespace with PCTFREE 10 and carries the Oracle Internal Use Only warning, meaning it should be accessed only through standard Oracle Applications programs, not through custom direct-write logic.

Key Information Stored

The physical schema documents 78 columns. The most consequential are the identity and dimensional columns that anchor each history record:

• TRANSACTION_ID and TRANSACTION_SOURCE_CODE — together these form the surrogate primary key (CST_WIP_VALUE_HISTORY_PK) and the first unique index (CST_WIP_VALUE_HISTORY_U1). They identify the specific costing transaction that generated the history row.
• TRANSACTION_DATE — the effective date of the transaction, used for period-based reporting.
• WIP_ENTITY_ID — the WIP job or schedule identifier, the primary business anchor for discrete manufacturing.
• REPETITIVE_SCHEDULE_ID — the repetitive schedule identifier, the anchor for repetitive manufacturing. It is a foreign key to WIP_REPETITIVE_SCHEDULES.
• ORGANIZATION_ID — the inventory organization that owns the job or schedule.
• CLASS_TYPE — the accounting class type that drives cost element classification.
• The PRIOR_* and NEW_* column families — pairs such as PRIOR_TL_RESOURCE_IN / NEW_TL_RESOURCE_IN, PRIOR_PL_MATERIAL_IN / NEW_PL_MATERIAL_IN, and their OUT and VAR counterparts — record the value before and after the transaction for each cost element at each level.

A second unique index (CST_WIP_VALUE_HISTORY_U2) spans WIP_ENTITY_ID, REPETITIVE_SCHEDULE_ID, TRANSACTION_DATE, TRANSACTION_ID, and TRANSACTION_SOURCE_CODE. This composite is the strongest business-key candidate, since it uniquely identifies a job-or-schedule cost event on a given date. Standard WHO columns (LAST_UPDATE_DATE, CREATED_BY, and so on) plus REQUEST_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE are also present, supporting concurrent program traceability.

Common Use Cases and Queries

The predominant use case is historical WIP cost reconstruction: determining what a job or repetitive schedule was worth before and after a specific costing event. A typical query retrieves the cost movement for a given organization and date range:

• SELECT WIP_ENTITY_ID, TRANSACTION_DATE, PRIOR_TL_RESOURCE_IN, NEW_TL_RESOURCE_IN, PRIOR_PL_MATERIAL_IN, NEW_PL_MATERIAL_IN FROM BOM.CST_WIP_VALUE_HISTORY WHERE ORGANIZATION_ID = :org AND TRANSACTION_DATE BETWEEN :from_date AND :to_date ORDER BY TRANSACTION_DATE;
• Joining on REPETITIVE_SCHEDULE_ID to WIP_REPETITIVE_SCHEDULES to resolve schedule attributes for repetitive environments.
• Aggregating variance columns (PRIOR_*_VAR and NEW_*_VAR) by WIP_ENTITY_ID to report scrap and resource variance trends.
• Period-close reconciliation, comparing NEW_* balances against the WIP valuation tables for the same period.

Because the table is documented as internal-only, these queries are appropriate for read-only reporting and analytics rather than custom transaction logic.

Related Objects

The documented foreign key establishes a direct association with WIP_REPETITIVE_SCHEDULES via REPETITIVE_SCHEDULE_ID. Beyond that, the table's cost elements and WIP anchors imply relationships with the following significant objects, joined on the columns shown:

• WIP_REPETITIVE_SCHEDULES — join on REPETITIVE_SCHEDULE_ID, the only documented FK.
• WIP_DISCRETE_JOBS — join on WIP_ENTITY_ID to resolve job attributes.
• WIP_ENTITIES — join on WIP_ENTITY_ID to resolve entity type and description.
• CST_WIP_VALUE_HISTORY peer costing tables such as the WIP valuation and accounting distributions objects, linked by TRANSACTION_ID and TRANSACTION_SOURCE_CODE.
• MTL_SYSTEM_ITEMS_B — joined indirectly via WIP_ENTITY_ID to reach the assembly item.
• ORG_ORGANIZATION_DEFINITIONS — join on ORGANIZATION_ID for organization context.

No documented API is provided in the metadata; access is expected through standard Cost Management and WIP concurrent programs.