Search Results csd_job_header_v




Overview
Explore in AI Chat

Overview

CSD_JOB_HEADER_V is a seeded APPS-owned database view within the Oracle E-Business Suite Depot Repair (CSD) module. Its documented purpose is to retrieve header information for a repair job that is about to be submitted. The view supplies data to the header block of the Submit Repair Job screen, specifically the header screen that is invoked when navigating from the Repair Order Workbench. It is classified as a VALID view in the ETRM registry for both 12.1.1 and 12.2.2.

Functionally, the view consolidates attribute data that would otherwise require multiple joins across repair, incident, customer, and lookup entities. This makes it a convenient read-only interface for reporting, extensions, and integrations that need a denormalized snapshot of a repair order header. Because it exposes standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) alongside a ROW_ID and the descriptor flexfield attribute columns (ATTRIBUTE_CATEGORY through ATTRIBUTE15), it is also suitable for use as a query source in custom forms or concurrent programs that must remain consistent with the delivered Depot Repair UI.

Underlying Base Objects

The view is defined over a fixed join of four primary sources, with additional references to PL/SQL and lookup infrastructure. The documented referenced base objects are:

  • CSD_REPAIRS (synonym, aliased DRA) — the driving repair order line table.
  • CS_INCIDENTS_ALL_B (synonym, aliased SR) — the service request / incident header.
  • CSD_REPAIR_TYPES_VL (view, aliased RTYPE) — repair type translated values.
  • FND_LOOKUPS (view, aliased FND) — lookup meanings for the repair status.
  • HZ_PARTIES (synonym, aliased HZP) — the customer party record.
  • FND_GLOBAL (package) — referenced for session context within the view definition.

The join conditions link repair line to incident via INCIDENT_ID, to repair type via REPAIR_TYPE_ID, to the lookup via STATUS = LOOKUP_CODE restricted to LOOKUP_TYPE = 'CSD_REPAIR_STATUS', and to the customer party via SR.CUSTOMER_ID = HZP.PARTY_ID. Note that the customer name is conditionally derived: for organization callers the PARTY_NAME is used, while for person callers the first and last name are concatenated.

Key Columns

  • ROW_ID — the ROWID of the underlying CSD_REPAIRS row; useful for row-level locking or correlation.
  • REPAIR_LINE_ID — primary key of the repair order line.
  • OBJECT_VERSION_NUMBER — optimistic locking column.
  • REPAIR_ORDER_NUMBER — the human-readable repair order identifier (from REPAIR_NUMBER).
  • CUSTOMER_NAME — derived customer name based on caller type.
  • REPAIR_ORDER_QUANTITY and RECEIVED_QUANTITY — ordered versus received quantities (RECEIVED_QUANTITY is NVL-defaulted to zero).
  • REPAIR_TYPE — translated repair type name.
  • REPAIR_ORDER_STATUS — the lookup meaning of the repair status.
  • REPAIR_PROMISE_DATE — the promised completion date.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield segments.

Common Use Cases and Queries

Typical uses include custom reports on repair order headers, extensions of the Submit Repair Job flow, and integration extracts that need customer and status descriptions in a single query. A representative query is:

SELECT repair_order_number,
       customer_name,
       repair_type,
       repair_order_status,
       repair_order_quantity,
       received_quantity,
       repair_promise_date
FROM   apps.csd_job_header_v
WHERE  repair_order_number = :p_repair_number;

For workbench-style listings, filtering by status is common:

SELECT repair_line_id,
       repair_order_number,
       customer_name,
       repair_promise_date
FROM   apps.csd_job_header_v
WHERE  repair_order_status = 'Awaiting Repair';

Because the view already resolves the status lookup and the customer party, it reduces the number of joins required in downstream logic. As the underlying objects are owned by APPS, access should be granted through standard EBS responsibility and grants rather than direct privilege escalation.