Search Results repair_history_id
Overview
The CSD_REPAIR_HISTORY table is a core transactional entity within the Oracle E-Business Suite (EBS) Depot Repair (CSD) module. Its primary function is to serve as a comprehensive audit trail for every significant event that occurs during the lifecycle of a repair order. By capturing a sequential log of activities—from initial receipt of a broken product to its final shipment—this table provides essential operational visibility and historical tracking. It is critical for process monitoring, reporting on repair cycle times, and analyzing workflow bottlenecks. The integrity of this data is enforced through a primary key and a foreign key relationship linking each history record to its parent repair order.
Key Information Stored
While the provided metadata does not list specific columns beyond the keys, based on its documented purpose and standard EBS design patterns, the table typically stores several key attributes. The primary key, REPAIR_HISTORY_ID, uniquely identifies each event record. The foreign key column, REPAIR_LINE_ID, links the event to a specific line in the CSD_REPAIRS table. Other standard columns would include a timestamp (e.g., CREATION_DATE), the event type or code (e.g., 'RECEIVED', 'JOB_CREATED', 'SHIPPED'), a description of the event, and the user or responsibility that performed the action. This structure allows the system to reconstruct the complete sequence of events for any given repair.
Common Use Cases and Queries
The primary use case is generating reports on repair order status and turnaround time. Analysts frequently query this table to determine the time elapsed between critical events. A common query pattern involves joining to CSD_REPAIRS to filter by customer, product, or date range, and then analyzing the history records. For example, to find all repairs where the product was received but a job has not yet been created, one would look for a 'BROKEN_RECEIVED' event without a subsequent 'JOB_CREATED' event for the same REPAIR_LINE_ID. Support personnel also use this data to provide customers with detailed status updates, proving when specific actions were completed.
Related Objects
The CSD_REPAIR_HISTORY table has a direct and documented foreign key relationship with the primary repairs table. This relationship is fundamental to the data model.
- CSD_REPAIRS: This is the master table for repair orders. The foreign key constraint is defined on the column CSD_REPAIR_HISTORY.REPAIR_LINE_ID, which references the CSD_REPAIRS table. All history records must be associated with a valid repair line. Standard queries join these tables on this column to retrieve repair header information alongside the event history.
-
Table: CSD_REPAIR_HISTORY
12.2.2
owner:CSD, object_type:TABLE, fnd_design_data:CSD.CSD_REPAIR_HISTORY, object_name:CSD_REPAIR_HISTORY, status:VALID, product: CSD - Depot Repair , description: This table stores all the events (e.g. Broken Product Received, Job Created, Product Shipped) associated with a repair order. , implementation_dba_data: CSD.CSD_REPAIR_HISTORY ,
-
Table: CSD_REPAIR_HISTORY
12.1.1
owner:CSD, object_type:TABLE, fnd_design_data:CSD.CSD_REPAIR_HISTORY, object_name:CSD_REPAIR_HISTORY, status:VALID, product: CSD - Depot Repair , description: This table stores all the events (e.g. Broken Product Received, Job Created, Product Shipped) associated with a repair order. , implementation_dba_data: CSD.CSD_REPAIR_HISTORY ,
-
View: CSD_REPAIR_HISTORY_V
12.1.1
owner:APPS, object_type:VIEW, fnd_design_data:CSD.CSD_REPAIR_HISTORY_V, object_name:CSD_REPAIR_HISTORY_V, status:VALID, product: CSD - Depot Repair , description: The view for getting repair order history. , implementation_dba_data: APPS.CSD_REPAIR_HISTORY_V ,
-
View: CSD_REPAIR_HISTORY_V
12.2.2
owner:APPS, object_type:VIEW, fnd_design_data:CSD.CSD_REPAIR_HISTORY_V, object_name:CSD_REPAIR_HISTORY_V, status:VALID, product: CSD - Depot Repair , description: The view for getting repair order history. , implementation_dba_data: APPS.CSD_REPAIR_HISTORY_V ,