Search Results group_txn_status




Overview
Explore in AI Chat

Overview

CSD_REPAIR_ORDER_GROUPS is a core table within the Oracle E-Business Suite Depot Repair (CSD) module. It stores Repair Order group records, where each group serves as a logical container that translates into one or more individual repair order lines. In Depot Repair operations, a single customer return or service request frequently involves multiple units, and this table allows those units to be managed under a common grouping header — capturing the shared attributes of the request such as the originating incident, the repair type, the inventory item being repaired, and the discrete job driving the work.

From a Data Vault modeling perspective, the mined foreign key structure suggests this table is satellite-leaning. Its primary key is surrogate rather than a composite business key, and it holds numerous descriptive and status attributes (quantities, approvals, transaction status, repair mode). It qualifies as a satellite candidate whose parent hub or link would typically be derived from the business key REPAIR_GROUP_NUMBER and its inbound relationships to CSD_REPAIRS and CSD_MRO_SERIAL_NUMBERS. This classification is a heuristic recommendation, not a mandated Oracle design.

Key Information Stored

The table is owned by the CSD schema and contains 42 documented columns in the ETRM 12.2.2 physical schema. The surrogate primary key is REPAIR_GROUP_ID, enforced by the constraint CSD_REPAIR_ORDER_GROUP_PK1 and mirrored by the unique index CSD_REPAIR_ORDER_GROUP_U1. The business-key candidate is REPAIR_GROUP_NUMBER, the user-facing identifier for the group.

Operationally significant columns include:

Common Use Cases and Queries

Typical reporting scenarios include tracking group-level repair progress, reconciling RMA receipts against completed units, and auditing approval status across outstanding groups.

  • Group status dashboard: select REPAIR_GROUP_NUMBER, GROUP_TXN_STATUS, GROUP_APPROVAL_STATUS, and the quantity columns filtered by status to monitor open workload.
  • Incident-to-repair traceability: join CS_INCIDENTS_ALL_B on INCIDENT_ID to report which service incidents generated which repair groups.
  • Line-level drilldown: join CSD_REPAIRS on REPAIR_GROUP_ID to expand each group into its repair order lines, comparing GROUP_QUANTITY against per-line quantities.
  • WIP linkage: join WIP_DISCRETE_JOBS on WIP_ENTITY_ID to review manufacturing progress for repair jobs.

A representative query pattern:

SELECT g.REPAIR_GROUP_NUMBER, g.GROUP_QUANTITY, g.COMPLETED_QUANTITY, r.REPAIR_NUMBER FROM CSD_REPAIR_ORDER_GROUPS g JOIN CSD_REPAIRS r ON r.REPAIR_GROUP_ID = g.REPAIR_GROUP_ID WHERE g.GROUP_TXN_STATUS = 'OPEN';

Related Objects

The following objects are most significant to CSD_REPAIR_ORDER_GROUPS through documented foreign key relationships:

  • CSD_REPAIRS — the primary dependent table; each repair line references REPAIR_GROUP_ID, and this is the central join for expanding groups into lines.
  • CSD_MRO_SERIAL_NUMBERS — references REPAIR_GROUP_ID, associating serialized units to the group.
  • CSD_GROUP_JOB_PARAM_TEMP — references REPAIR_GROUP_ID, holding temporary job parameter data during group processing.
  • CS_INCIDENTS_ALL_B — referenced by INCIDENT_ID; the source service incident.
  • CSD_REPAIR_TYPES_B — referenced by REPAIR_TYPE_ID; defines repair type behavior.
  • WIP_DISCRETE_JOBS — referenced by WIP_ENTITY_ID; the manufacturing job executing the repair.
  • FND_SECURITY_GROUPS — referenced by SECURITY_GROUP_ID for data security partitioning.