Results for “csd_ro_defect_codes”

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

Overview

CSD_RO_DEFECT_CODES is a transactional table in the CSD (Depot Repair) module of Oracle E-Business Suite. It stores the defect codes that have been recorded against individual repair lines on a depot repair order. Each row associates a specific defect code with a repair line, allowing service organizations to capture the failure symptoms, conditions, or fault categories identified during the diagnosis and repair of a returned item. The table is owned by the CSD schema and is valid in both EBS 12.1.1 and 12.2.2.

In the documentation metadata, the Data Vault classification for this table is listed as standalone, derived heuristically from its foreign-key structure. From a dimensional modeling perspective, this suggests the object behaves primarily as a link between a repair line and an external defect code definition, with a small set of descriptive attributes attached. Because it references only CSD_REPAIRS (via REPAIR_LINE_ID) and does not itself serve as a parent for other FK relationships, it is best treated as an association or detail entity rather than a central hub.

Key Information Stored

The table contains 25 documented columns. The most significant of these are:

• RO_DEFECT_CODE_ID — the surrogate primary key, defined by the unique index CSD_RO_DEFECT_CODES_P1. It uniquely identifies each defect-code assignment record.
• REPAIR_LINE_ID — the foreign key that links the defect code to the parent repair line in CSD_REPAIRS. This is the primary join column for relating defect codes back to repair activity.
• DEFECT_CODE — the actual defect code value captured for the repair line. This is the principal business attribute and the most common filter for reporting on failure categories.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY — the standard EBS audit columns that track who created or modified each row and when.
• LAST_UPDATE_LOGIN — records the login session associated with the last update.
• OBJECT_VERSION_NUMBER — supports optimistic locking, ensuring concurrent updates do not silently overwrite one another.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard Oracle Federal Flexfield (descriptive flexfield) columns, allowing installation-specific descriptive data to be captured against each defect-code assignment without schema changes.

No unique business-key index beyond the primary key is documented in the supplied metadata. DEFECT_CODE is a strong business-key candidate in practice, since a defect code is normally unique per repair line, but this constraint is not confirmed in the ETRM data.

Common Use Cases and Queries

Typical uses include defect-frequency reporting, repair cost/warranty analysis, and vendor or product quality tracking. A common query pattern joins defect codes to their repair lines:

SELECT r.REPAIR_LINE_ID, d.DEFECT_CODE, r.CREATION_DATE
FROM   CSD_RO_DEFECT_CODES d,
       CSD_REPAIRS r
WHERE  d.REPAIR_LINE_ID = r.REPAIR_LINE_ID
AND    d.DEFECT_CODE = :defect_code;

Aggregate reporting can count defects by code, by repair line, or over a date range, and the descriptive flexfield columns can be decoded with FND_FLEX_APIS or the standard flexfield views for installation-specific analysis.

Related Objects

The principal related object is CSD_REPAIRS, joined on REPAIR_LINE_ID, which provides the repair-line context for every defect-code record. Defect codes themselves are typically defined in a reference or lookup table (for example, CSD_DEFECT_CODES or a code-lookup view), and reporting views or concurrent programs within the Depot Repair module read CSD_RO_DEFECT_CODES to expose defect data to users. Related configuration and diagnosis tables in the CSD schema may also be linked at the application level, but the primary enforced relationship documented here is the foreign key to CSD_REPAIRS.