Results for “qrm_deals_analyses”

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

Overview

QRM_DEALS_ANALYSES is a table in the QRM (Risk Management) product schema of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. It maps deal calculations to the analyses to which they belong. In practical terms, this object acts as an associative container: it records that a given deal calculation, already defined in QRM_DEAL_CALCULATIONS, participates in a named analysis. The table carries the QRM owner designation, has a VALID status, and is documented with twelve physical columns in the ETRM 12.2.2 schema.

Under a heuristic Data Vault classification mined from its foreign key structure, this table is best modeled as a link. It resolves a many-to-many style association between analyses and deal calculations, and it points outward to QRM_DEAL_CALCULATIONS and XTR_PARTY_INFO. This classification is a modeling suggestion rather than a mandated design, but it aligns with the table's evident role as a relationship carrier rather than a descriptive satellite or an independent hub.

Key Information Stored

The table's identity is defined by two business columns and a complement of audit columns. The most significant fields documented are:

• ANALYSIS_NAME — the name of the analysis to which a deal calculation is assigned. This is the business label that drives reporting and grouping.
• DEAL_CALC_ID — the identifier of the deal calculation belonging to the analysis; it links to QRM_DEAL_CALCULATIONS.
• COMPANY_CODE — the party or company context, referencing XTR_PARTY_INFO and supporting multi-company separation of analysis data.
• CREATED_BY, CREATION_DATE — standard WHO columns recording row creation.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO columns recording the most recent modification.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context columns that identify which batch process wrote or last touched the row.

The primary key is QRM_DEALS_ANALYSES_PK, defined over ANALYSIS_NAME and DEAL_CALC_ID. There is no separate surrogate key column documented; instead, the composite of these two columns functions as the unique row identifier. A unique index, QRM_DEALS_ANALYSES_U1 (DEAL_CALC_ID, ANALYSIS_NAME), provides an alternate business-key access path over the same two columns in reverse order. Because the primary key and the unique index cover the same column pair, no additional business-key candidate exists beyond this combination.

Common Use Cases and Queries

Typical uses center on enumerating the deal calculations attached to an analysis and on tracing an analysis set back to its underlying calculations. A reporting query joins to QRM_DEAL_CALCULATIONS to resolve calculation detail:

• SELECT a.ANALYSIS_NAME, a.DEAL_CALC_ID, a.COMPANY_CODE FROM QRM.QRM_DEALS_ANALYSES a WHERE a.ANALYSIS_NAME = :analysis;
• SELECT a.* FROM QRM.QRM_DEALS_ANALYSES a, QRM.QRM_DEAL_CALCULATIONS c WHERE a.DEAL_CALC_ID = c.DEAL_CALC_ID;
• SELECT a.COMPANY_CODE, COUNT(*) FROM QRM.QRM_DEALS_ANALYSES a GROUP BY a.COMPANY_CODE;

Audit-oriented queries use REQUEST_ID and PROGRAM_ID to isolate rows written by a specific concurrent request. Because COMPANY_CODE references party information, multi-organization reporting can filter by company to reconcile analyses per legal entity.

Related Objects

The following objects are most significant to this table based on documented relationships:

• QRM_DEAL_CALCULATIONS — parent of the DEAL_CALC_ID foreign key; supplies the calculation definition for each mapped row.
• XTR_PARTY_INFO — parent of the COMPANY_CODE foreign key; supplies company and party attributes.
• QRM_DEALS_ANALYSES_PK — the primary key constraint over ANALYSIS_NAME and DEAL_CALC_ID.
• QRM_DEALS_ANALYSES_U1 — unique index over DEAL_CALC_ID and ANALYSIS_NAME, serving as the alternate access path.

Together these objects define the analysis-to-calculation mapping used by QRM risk processing and downstream reporting.