Results for “csd_ahl_w_claim_xref”

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

Overview

CSD_AHL_W_CLAIM_XREF is a transactional table within the CSD (Depot Repair) product of Oracle E-Business Suite, documented in the ETRM reference for releases 12.1.1 and 12.2.2. The table stores supplier warranty claim cross-reference data, capturing the linkage between repair activity performed in Depot Repair and the warranty claims raised against a supplier or warranty contract. Its documented description is "Supplier Warranty Claim table," and it resides in the CSD schema with a status of VALID.

The object carries a mined Data Vault classification of standalone, indicating that its foreign key structure does not support modelling it as a classical hub, link, or satellite. From a data-modelling suggestion perspective, this reflects that the table behaves primarily as an association record rather than a governed core entity; integrators should treat it as a cross-reference construct rather than a master. The primary key is the single-column constraint CSD_AHL_W_CLAIM_XREF_PK, defined on WARRANTY_CLAIM_XREF_ID, which serves as the surrogate identifier for each row.

Key Information Stored

The table is documented with 31 physical columns in the 12.2.2 schema. The columns most significant for functional and integration purposes are:

• WARRANTY_CLAIM_XREF_ID — the surrogate primary key defined by CSD_AHL_W_CLAIM_XREF_PK; unconditionally unique per row.
• REPAIR_LINE_ID — foreign key to CSD_REPAIRS, tying the claim cross-reference to the specific repair line.
• WARRANTY_CLAIM_ID — foreign key to AHL_WARRANTY_CLAIMS_B, identifying the supplier warranty claim header.
• WARRANTY_CONTRACT_ID — foreign key to AHL_WARRANTY_CONTRACTS_B, identifying the governing warranty contract.
• CLAIM_AMOUNT — the monetary value attributed to this claim cross-reference.
• SOURCE_TABLE, SOURCE_COLUMN, SOURCE_ID, INSTANCE_ID — descriptive attributes recording the originating object and instance from which the cross-reference was derived.
• OBJECT_VERSION_NUMBER — the optimistic locking column used by the Oracle EBS framework for concurrent update control.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns applied to transactional tables.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the DFF (descriptive flexfield) column set reserved for customer-defined extensions.

No secondary unique index is documented beyond the primary key, so WARRANTY_CLAIM_XREF_ID remains the sole guaranteed unique identifier. The combination of REPAIR_LINE_ID, WARRANTY_CLAIM_ID and WARRANTY_CONTRACT_ID functions as a practical business-key candidate for reconciliation, but it is not enforced as unique in the documented metadata.

Common Use Cases and Queries

The table is typically queried when reconciling repair activity against warranty recoveries. A common reporting pattern joins the cross-reference to the claim header to report claim value by supplier and by repair line:

• Listing all cross-references for a given warranty claim: SELECT * FROM CSD.CSD_AHL_W_CLAIM_XREF WHERE WARRANTY_CLAIM_ID = :claim_id;
• Aggregating claim value per repair line: SELECT REPAIR_LINE_ID, SUM(CLAIM_AMOUNT) FROM CSD.CSD_AHL_W_CLAIM_XREF GROUP BY REPAIR_LINE_ID;
• Auditing provenance via the SOURCE_TABLE / SOURCE_COLUMN / SOURCE_ID triple to trace which upstream record generated the cross-reference.

Extracts for data-warehouse loading should include OBJECT_VERSION_NUMBER and the WHO audit columns to support incremental and change-detection logic.

Related Objects

The foreign key relationships documented for this table identify the principal related objects:

• CSD_REPAIRS — joined on CSD_AHL_W_CLAIM_XREF.REPAIR_LINE_ID; the parent repair line record.
• AHL_WARRANTY_CLAIMS_B — joined on WARRANTY_CLAIM_ID; the base table holding the warranty claim header.
• AHL_WARRANTY_CONTRACTS_B — joined on WARRANTY_CONTRACT_ID; the base table holding the warranty contract.

Because the mined classification is standalone, no other tables reference CSD_AHL_W_CLAIM_XREF through an outbound foreign key, so dependency analysis should proceed upward from these three parents rather than downward.