Results for “csd_mtl_consumed_f”

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

Overview

CSD_MTL_CONSUMED_F is a table owned by the CSD schema within the Oracle E-Business Suite Depot Repair module. Its documented purpose is to store an aggregated count of materials consumed during depot repair activity. Rather than recording each individual material issue transaction at the point of consumption, the table holds consolidated quantities tied to a specific repair line, making it a summarized fact-style object suited to reporting and analytical workloads rather than transactional processing.

The table resides in the CSD product, which governs the full lifecycle of a repair order — from receipt of a defective unit through diagnosis, material consumption, and final shipment back to the customer. Within that flow, CSD_MTL_CONSUMED_F provides a lightweight rollup of inventory items consumed against each repair line, allowing the application to avoid re-aggregating raw inventory transactions on every query.

From a Data Vault modeling perspective, the metadata classifies this object as standalone, based on a heuristic review of its foreign key structure. This classification suggests that CSD_MTL_CONSUMED_F most closely resembles a satellite attached to the repair line hub, since it carries descriptive and quantitative measures about a repair line rather than participating in multiple foreign key relationships of its own. This is offered as a modeling suggestion only; the table is a native, denormalized EBS table, not a Data Vault construct.

Key Information Stored

The table contains 13 documented columns. Its most significant columns fall into three groups: relational keys, consumed-material detail, and standard EBS audit/request metadata.

• REPAIR_LINE_ID — The primary foreign key linking each aggregated row to its parent repair line in CSD_REPAIRS. This is the dominant business-key candidate for joining and filtering.
• INVENTORY_ITEM_ID — Identifies the inventory item consumed, referencing the master item definition. Combined with REPAIR_LINE_ID, this forms the natural business key for a consumed-material aggregate.
• PRIMARY_QUANTITY — The aggregated quantity of the item consumed, expressed in the item's primary unit of measure.
• PRIMARY_UOM_CODE — The unit of measure in which PRIMARY_QUANTITY is expressed, ensuring the quantity is unambiguous.

The remaining documented columns are standard Oracle EBS audit and concurrent-program attributes: CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, PROGRAM_ID, PROGRAM_LOGIN_ID, PROGRAM_APPLICATION_ID, and REQUEST_ID. No dedicated surrogate primary key column is documented in the provided metadata; the identifying key is effectively the combination of repair line and inventory item.

Common Use Cases and Queries

The table is typically used for repair costing, material-consumption reporting, and reconciliation between depot repair activity and inventory transaction history. A representative query totals consumed quantity per repair line:

• SELECT repair_line_id, SUM(primary_quantity) FROM csd_mtl_consumed_f GROUP BY repair_line_id;
• Joining to CSD_REPAIRS on REPAIR_LINE_ID to attribute consumed materials to a specific repair order, customer, or unit.
• Joining to MTL_SYSTEM_ITEMS_B on INVENTORY_ITEM_ID to translate item identifiers into descriptions and categories for reporting.
• Audit traceability using REQUEST_ID and PROGRAM_ID to identify which concurrent program generated or refreshed a given aggregate.

Related Objects

The most significant related objects, grounded in the documented foreign key relationship, are:

• CSD_REPAIRS — The parent repair header/line object; joined via CSD_MTL_CONSUMED_F.REPAIR_LINE_ID = CSD_REPAIRS.REPAIR_LINE_ID.
• MTL_SYSTEM_ITEMS_B — Master item definition, joined on INVENTORY_ITEM_ID for item validation and description.
• MTL_UNITS_OF_MEASURE — Resolves PRIMARY_UOM_CODE to a descriptive unit of measure.
• CSD_REPAIR_ORDERS and related CSD repair tables that depend on the repair line context.
• FND_CONCURRENT_REQUESTS — Correlates REQUEST_ID to the concurrent request that produced the aggregate.