Results for “csd_repairs”

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

Overview

CSD_REPAIRS is the master transactional table for Oracle Depot Repair (product family CSD) in Oracle E-Business Suite 12.1.1 and 12.2.2. Every repair order created, tracked, or processed through the Depot Repair module is represented by a row in this table, making it the central operational record for the repair lifecycle — from intake and approval through execution, closure, and shipment. The table is owned by the CSD schema and is documented with 131 columns, confirming its role as a broad, detail-rich entity that captures both header-level attributes and repair-line specifics.

From a data-modeling perspective, the relationship metadata suggests classifying CSD_REPAIRS as a hub in a Data Vault model. This is a modeling suggestion derived heuristically from the foreign-key structure: the table carries a single surrogate primary key (REPAIR_LINE_ID) and is referenced by a large number of downstream tables, while itself referencing many dimension-like entities. It functions as the anchor point around which repair activity, estimates, actuals, transactions, quality results, and messages are organized.

Key Information Stored

The table exposes a surrogate primary key, REPAIR_LINE_ID, defined through CSD_REPAIRS_PK. Three unique indexes are documented as business-key candidates: CSD_REPAIRS_U1 on REPAIR_LINE_ID, CSD_REPAIRS_U2 on REPAIR_NUMBER (the user-facing repair order identifier), and CSD_REPAIRS_U3 on ORDER_LINE_ID. Among the most operationally significant columns are:

• REPAIR_NUMBER — the human-readable identifier of the repair order; a primary access path for users and reports.
• INCIDENT_ID — links the repair to the originating service request in CS_INCIDENTS_ALL_B.
• CUSTOMER_PRODUCT_ID — identifies the specific customer product or installed base instance being repaired (references CS_CUSTOMER_PRODUCTS_ALL and CSI_ITEM_INSTANCES).
• INVENTORY_ITEM_ID and INVENTORY_ORG_ID — the item and the inventory organization handling the repair.
• REPAIR_TYPE_ID — classification of the repair, driven by CSD_REPAIR_TYPES_B.
• STATUS and STATUS_REASON_CODE — current lifecycle state and the reason associated with it.
• QUANTITY, QUANTITY_RCVD, QUANTITY_SHIPPED, and QUANTITY_IN_WIP — quantities across intake, shipment, and work-in-process.
• RESOURCE_ID — the resource assigned to the repair (references JTF_RS_RESOURCE_EXTNS).
• ORDER_LINE_ID — the associated order line originating in OE_ORDER_LINES_ALL, uniquely indexed and important for order-to-repair traceability.
• CONTRACT_LINE_ID — warranty or service contract line governing entitlement (references OKC_K_LINES_B).
• PROJECT_ID and TASK_ID — optional project and task associations for cost capture.
• DATE_CLOSED, PROMISE_DATE, and RESOLVE_BY_DATE — key scheduling and closure dates.
• REPAIR_GROUP_ID — grouping of related repair orders.
• SPLIT_FLAG and SPLIT_FROM_REP_LINE_ID — support for splitting repair lines.

The table also carries standard multi-org and audit columns, including SECURITY_GROUP_ID and the CREATED_BY/CREATION_DATE/LAST_UPDATED_BY/LAST_UPDATE_DATE set, along with a large block of descriptive flexfield (ATTRIBUTE1–ATTRIBUTE30) and return flexfield columns.

Common Use Cases and Queries

Typical reporting and integration scenarios center on retrieving repair orders by number, incident, customer product, or status. A common pattern joins the repair header to the incident and installed base:

• Open repair order listings filtered by STATUS or RO_TXN_STATUS, joined to CS_INCIDENTS_ALL_B on INCIDENT_ID.
• Installed-base history queries joining CSI_ITEM_INSTANCES on CUSTOMER_PRODUCT_ID to trace all repairs against a specific serialized unit.
• Order-to-repair traceability joining OE_ORDER_LINES_ALL on ORDER_LINE_ID, used for RMA and shipment reconciliation.
• Warranty and contract analysis joining OKC_K_LINES_B on CONTRACT_LINE_ID alongside IN_WARRANTY_CODE and RO_WARRANTY_STATUS_CODE.
• Financial roll-ups joining the child tables CSD_REPAIR_ESTIMATE, CSD_REPAIR_ACTUALS, and CSD_REPAIR_ACTUAL_LINES on REPAIR_LINE_ID to compare estimated versus actual cost and effort.
• Message and notification tracing via CS_MESSAGES.SOURCE_OBJECT_INT_ID, which references the repair line; this is the relationship most relevant to a search on "cs_messages".

A representative query might select REPAIR_NUMBER, STATUS, and DATE_CLOSED from CSD_REPAIRS where TRUNC(CREATION_DATE) = TRUNC(SYSDATE) to produce a daily intake report, or resolve a repair from a message by joining CS_MESSAGES.SOURCE_OBJECT_INT_ID to CSD_REPAIRS.REPAIR_LINE_ID.

Related Objects

CSD_REPAIRS is both a major FK reference consumer and the target of numerous child tables. The most significant related objects are:

• CS_INCIDENTS_ALL_B — the service request driving the repair; joined on INCIDENT_ID.
• CS_CUSTOMER_PRODUCTS_ALL and CSI_ITEM_INSTANCES — the installed-base product being repaired; joined on CUSTOMER_PRODUCT_ID.
• OE_ORDER_LINES_ALL — the sales order line associated with the repair; joined on ORDER_LINE_ID.
• OKC_K_LINES_B — the contract line providing warranty or service coverage; joined on CONTRACT_LINE_ID.
• CSD_REPAIR_TYPES_B and CSD_REPAIR_ORDER_GROUPS — repair classification and grouping; joined on REPAIR_TYPE_ID and REPAIR_GROUP_ID.
• JTF_RS_RESOURCE_EXTNS — the assigned technician or resource; joined on RESOURCE_ID.
• CSD_REPAIR_ACTUALS, CSD_REPAIR_ESTIMATE, and CSD_REPAIR_ACTUAL_LINES — cost and effort detail keyed by REPAIR_LINE_ID.
• CSD_REPAIR_HISTORY and CSD_PRODUCT_TRANSACTIONS — status history and material transactions tied to the repair line.
• CS_MESSAGES — messages referencing repairs through SOURCE_OBJECT_INT_ID.
• QA_RESULTS and CS_ESTIMATE_DETAILS — quality outcomes and estimation detail linked by REPAIR_LINE_ID and SOURCE_ID.

Because CSD_REPAIRS sits at the intersection of service, order management, installed base, contracts, and quality, it is the definitive join point for cross-functional repair reporting in Oracle Depot Repair.