Search Results csd_tasks




Overview
Explore in AI Chat

Overview

CSD_TASKS is a transaction table within the Oracle E-Business Suite Depot Repair module (product code CSD), owned by the CSD schema. As documented in the ETRM repository for release 12.2.2, its stated purpose is to support Task-QA integration — that is, it binds repair tasks to the quality assurance plans that apply to them during the depot repair lifecycle. Each row represents a task-level record associated with a repair line, carrying the applicable QA plan assignments that drive inspection and quality verification activity in the repair flow.

The heuristic Data Vault classification supplied in the metadata is standalone. In dimensional modeling terms this suggests the table is best treated as an independent entity rather than as a pure hub, link, or satellite, since no incoming foreign-key relationships to CSD_TASKS were mined. The single outgoing foreign key to CSD_REPAIRS does, however, imply a natural link role between repair lines and task/QA plan definitions, so a modeler may reasonably choose to represent it as a link table joining repair lines to task and QA plan entities even though the automated classification labels it standalone.

Key Information Stored

The documented physical schema contains ten columns. The most significant are:

  • REPAIR_TASK_ID — the surrogate primary key, enforced by constraint CSD_TASKS_PK. It uniquely identifies each task-QA integration row and is the column downstream objects use to reference a specific record.
  • TASK_ID — identifies the repair task to which the QA integration applies; this is a principal business-key candidate linking the row to task definitions.
  • REPAIR_LINE_ID — foreign key to CSD_REPAIRS, tying the task record to the originating repair line. Together with TASK_ID it forms the natural business key of the row.
  • APPLICABLE_QA_PLANS — stores the QA plan or plans applicable to the task, the functional payload of the Task-QA integration.
  • OBJECT_VERSION_NUMBER — the standard EBS optimistic locking column used by the framework to detect concurrent updates.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns recording row creation and last modification metadata.

No unique index beyond the primary key is documented, so REPAIR_TASK_ID is the only confirmed unique identifier; TASK_ID and REPAIR_LINE_ID serve as business-key candidates rather than enforced unique keys.

Common Use Cases and Queries

Typical reporting scenarios include identifying which QA plans apply to a given repair line, reconciling tasks against their QA coverage, and auditing changes to task-QA assignments. A representative join to the parent repair record is:

  • SELECT t.repair_task_id, t.task_id, t.repair_line_id, t.applicable_qa_plans FROM csd_tasks t WHERE t.repair_line_id = :repair_line_id;
  • SELECT t.* FROM csd_tasks t, csd_repairs r WHERE t.repair_line_id = r.repair_line_id AND r.repair_line_id = :id;
  • Audit query using the WHO columns: SELECT repair_task_id, last_updated_by, last_update_date FROM csd_tasks WHERE last_update_date >= :since;
  • Coverage check: SELECT task_id, COUNT(*) FROM csd_tasks WHERE applicable_qa_plans IS NULL GROUP BY task_id;

These patterns support depot repair dashboards, QA compliance reporting, and integration extracts that feed downstream quality systems.

Related Objects

The most significant related objects, based on the documented relationship data, are:

  • CSD_REPAIRS — referenced via CSD_TASKS.REPAIR_LINE_ID; the parent repair line for each task record.
  • CSD_TASKS_PK — the primary key constraint on REPAIR_TASK_ID that governs uniqueness.
  • Task definition entities (referenced through TASK_ID) and QA plan definition entities (implied by APPLICABLE_QA_PLANS), which supply the business keys and plan content consumed by this table.

Because the table is classified standalone with only one documented outgoing foreign key, CSD_REPAIRS is the principal join partner, and any additional relationships should be validated against the live data dictionary before being relied upon in custom code or reports.