Search Results prior_cost

Overview

CST_XLA_ACTUAL_REF_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite, appearing under the BOM (Bills of Material) product family. Its name signals its purpose: "CST" identifies the Cost Management application, "XLA" identifies the Subledger Accounting (XLA) engine, and "ACTUAL_REF" denotes a reference view that exposes actual cost detail for accounting and reconciliation purposes. The view is reported as VALID in the ETRM dictionary for both EBS 12.1.1 and 12.2.2.

The view is a thin projection layer. Rather than storing data itself, it presents a curated subset of columns from the cost detail table used by Cost Management to record the before-and-after cost impact of inventory and manufacturing transactions. Its intended role is to give Subledger Accounting, cost variance reporting, and custom integration programs a stable, consistently named access point for actual cost data without requiring those consumers to query the underlying transaction table directly. Because the view belongs to the APPS schema, it can be granted to custom schemas and referenced in SQL, PL/SQL, and BI Publisher reports using the standard APPS synonym convention.

Users searching for the base table name "mtl_cst_actual_cost_details" are typically tracing how actual cost detail flows into accounting events. CST_XLA_ACTUAL_REF_V is the documented view that surfaces that table's cost-relevant columns.

Underlying Base Objects

According to the documented view text, CST_XLA_ACTUAL_REF_V is defined over a single base object:

• MTL_CST_ACTUAL_COST_DETAILS (exposed to the view as a SYNONYM) — the Cost Management table that records actual cost detail rows for inventory and work-in-process transactions.

The view definition is a straightforward SELECT with no joins, unions, or aggregation. It projects seven columns directly from the base table and applies no WHERE clause, so every row present in MTL_CST_ACTUAL_COST_DETAILS is visible through the view, subject to the privileges of the querying user. The relationship is therefore one-to-one at the row level: the view is a column-restricted alias of the base table, not a transformed or filtered data set. This makes it inexpensive to query and ideal for lookups, but it also means that any data-quality issue in the base table propagates directly to the view.

Key Columns

The view exposes the following columns, each drawn directly from MTL_CST_ACTUAL_COST_DETAILS:

• ORGANIZATION_ID — The inventory organization to which the cost detail belongs. Required for multi-org filtering in any query.
• TRANSACTION_ID — Identifier of the inventory or WIP transaction that generated the cost detail row; the primary join key back to transaction tables.
• ACTUAL_COST — The actual cost recorded for the transaction.
• PRIOR_COST — The cost value held before the transaction was costed, useful for audit and revaluation analysis.
• NEW_COST — The cost value after the transaction is applied.
• VARIANCE_AMOUNT — The cost variance arising from the transaction, typically the difference between prior and new cost components.
• PAYBACK_VARIANCE_AMOUNT — The variance amount attributable to payback processing, used where standard costing payback logic applies.

Common Use Cases and Queries

Typical uses include reconciling actual costs to subledger accounting entries, investigating cost variances by organization and transaction, validating a costing run, and feeding downstream reports that need actual cost detail without touching the base table directly.

A representative query retrieving all cost detail for one organization:

• SELECT organization_id, transaction_id, actual_cost, prior_cost, new_cost, variance_amount, payback_variance_amount FROM apps.cst_xla_actual_ref_v WHERE organization_id = :p_org_id ORDER BY transaction_id;

To isolate transactions carrying a material variance:

• SELECT transaction_id, actual_cost, new_cost, variance_amount FROM apps.cst_xla_actual_ref_v WHERE organization_id = :p_org_id AND variance_amount <> 0;

To trace a single transaction back to its cost movement:

• SELECT * FROM apps.cst_xla_actual_ref_v WHERE organization_id = :p_org_id AND transaction_id = :p_txn_id;

Because the view is unfiltered, always constrain queries by ORGANIZATION_ID and, where possible, TRANSACTION_ID to avoid full-table scans on large cost detail volumes.