Search Results repair_order_status

Overview

APPS.CSD_JOB_HEADER_V is a reporting view within the Oracle E-Business Suite Depot Repair module (CSD). It presents a consolidated, denormalized header-level picture of repair orders (repair jobs), joining the core repair transaction record to its originating service incident, its repair type, its status lookup, and the customer party. In EBS 12.1.1 and 12.2.2 the view is owned by the APPS schema and serves as a convenient read-only interface for forms, concurrent programs, OBIEE/BIP extracts, and custom integrations that need human-readable repair job information without reconstructing the joins against the underlying depot repair tables.

The view is especially relevant to the user search term csd_repair_status, since the repair order status is exposed through a lookup-based column (REPAIR_ORDER_STATUS) resolved from the CSD_REPAIR_STATUS lookup type. The view therefore returns the translated meaning of the status code rather than the raw code stored on the repair line.

Underlying Base Objects

The documented base objects referenced by the view are:

• CSD_REPAIRS (synonym) — the primary depot repair line table; aliased as DRA. It supplies the repair number, quantities, status code, promise date, and the WHO columns and descriptive flexfield attributes.
• CSD_REPAIR_TYPES_VL (view) — the repair type translated view; aliased as RTYPE, supplying the repair type name.
• CS_INCIDENTS_ALL_B (synonym) — the service request/incident base table; aliased as SR, providing caller type and customer reference.
• FND_LOOKUPS (view) — the lookup values view; aliased as FND, translating the repair status code into its meaning for lookup type CSD_REPAIR_STATUS.
• HZ_PARTIES (synonym) — the trading community party table; aliased as HZP, supplying customer name information.
• FND_GLOBAL (package) — referenced for session context (org/user environment) in the deployed metadata.

The joins are inner joins on incident_id, repair_type_id, status lookup code, and customer_id, meaning rows are returned only where these related records exist.

Key Columns

• REPAIR_ORDER_NUMBER — the repair number from CSD_REPAIRS, the natural business identifier of the repair job.
• REPAIR_LINE_ID / ROW_ID — unique identifiers of the repair line, useful for drill-down and row-level integration.
• CUSTOMER_NAME — derived via DECODE on the incident caller type: organizations resolve to PARTY_NAME, persons to the concatenated first and last name.
• REPAIR_ORDER_STATUS — the lookup MEANING for the CSD_REPAIR_STATUS code stored on the repair line; this is the status column most commonly used in repair status reporting.
• REPAIR_TYPE — the translated repair type name.
• REPAIR_ORDER_QUANTITY and RECEIVED_QUANTITY — ordered quantity and the received quantity (with NVL to zero).
• REPAIR_PROMISE_DATE — the promised completion date for the repair.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit/WHO columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — the descriptive flexfield context and segment values from the repair record.

Common Use Cases and Queries

The view is typically used for repair status dashboards, aging reports, and customer-facing repair tracking. A basic status query follows:

• SELECT repair_order_number, customer_name, repair_order_status, repair_type FROM apps.csd_job_header_v WHERE repair_order_status = 'Awaiting Repair';

Additional scenarios include listing open repairs against a promise date window:

• SELECT repair_order_number, repair_promise_date, repair_order_status FROM apps.csd_job_header_v WHERE repair_promise_date BETWEEN :from_date AND :to_date ORDER BY repair_promise_date;

Or aggregating workload by status for operational monitoring:

• SELECT repair_order_status, COUNT(*) FROM apps.csd_job_header_v GROUP BY repair_order_status;

Because the view resolves the repair status meaning through FND_LOOKUPS and the customer name through HZ_PARTIES, it removes the need for custom joins and provides consistent, presentation-ready data for both in-application reporting and external extracts.