Results for “cst_std_cost_adj_debug”

34 results




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

Overview

CST_STD_COST_ADJ_DEBUG is a diagnostic table owned by the BOM schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. Its documented purpose is to store intermediate data generated while debugging the standard cost update process. Rather than representing a permanent business entity, the table functions as a transient landing area for adjustment rows produced during a standard cost rollup or update, allowing technical consultants and support analysts to inspect the quantities, rates, and values that the cost processor computed before or alongside the final posted adjustments.

Because the table captures the outcome of a process execution against specific cost updates, items, organizations, and work-in-process entities, its heuristic Data Vault classification is link. This modeling suggestion reflects the presence of multiple foreign key relationships (COST_UPDATE_ID, WIP_ENTITY_ID, DEPARTMENT_ID, RESOURCE_ID, COST_GROUP_ID) that connect otherwise independent hubs. It is a transaction-scoped intersection of cost update, item, organization, and WIP context rather than a standalone hub or a descriptive satellite.

Key Information Stored

The documented physical schema contains 31 columns. The most significant columns for diagnosis and reporting are:

The composite primary key CST_STD_COST_ADJ_DEBUG_PK is defined as (COST_UPDATE_ID, ORGANIZATION_ID, INVENTORY_ITEM_ID, SUBINVENTORY, WIP_ENTITY_ID). This combination acts as the business-key candidate that uniquely identifies a debug row within a cost update. Standard audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) are also present.

Common Use Cases and Queries

The principal use case is troubleshooting a standard cost update that produced unexpected inventory or WIP valuation. Because the table records applied quantities and values tied to a specific COST_UPDATE_ID, consultants can isolate a single run and review how each item, subinventory, or WIP entity was treated.

SELECT d.organization_id,
       d.inventory_item_id,
       d.subinventory,
       d.transaction_type,
       d.adjustment_quantity,
       d.applied_resource_value
FROM   cst_std_cost_adj_debug d
WHERE  d.cost_update_id = :cost_update_id
ORDER  BY d.organization_id, d.inventory_item_id;

A second common pattern joins the debug rows to the cost update header to correlate the run with its request and program identifiers:

SELECT u.cost_update_id,
       u.request_id,
       d.inventory_item_id,
       d.adjustment_quantity
FROM   cst_std_cost_adj_debug d,
       cst_cost_updates u
WHERE  d.cost_update_id = u.cost_update_id
AND    d.request_id = :request_id;

Reporting use cases include auditing WIP resource adjustments by department and resource, reconciling inter-organization transfers through FROM_ORGANIZATION_ID and TO_ORGANIZATION_ID, and validating that standard charge and standard rate flags were applied as intended. Because the content is debug-oriented, it should be treated as diagnostic evidence rather than a system of record.

Related Objects

The foreign keys documented for this table identify the objects it depends on and with which it is most commonly joined:

  • CST_COST_UPDATES — joined on CST_STD_COST_ADJ_DEBUG.COST_UPDATE_ID; the parent standard cost update definition.
  • WIP_ENTITIES — joined on CST_STD_COST_ADJ_DEBUG.WIP_ENTITY_ID; the work-in-process entity context.
  • BOM_DEPARTMENTS — joined on CST_STD_COST_ADJ_DEBUG.DEPARTMENT_ID; the department owning the resource adjustment.
  • BOM_RESOURCES — joined on CST_STD_COST_ADJ_DEBUG.RESOURCE_ID; the resource applied during the update.
  • CST_COST_GROUPS — joined on CST_STD_COST_ADJ_DEBUG.COST_GROUP_ID; the cost group associated with the adjustment.

Related standard cost adjustment processing references CST_COST_UPDATES and the WIP and BOM costing structures listed above. The table itself is referenced by no downstream foreign keys in the documented relationship data, confirming its role as a terminal diagnostic store rather than a parent of dependent objects.