Results for “xtr_counterparty_limits”

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

Overview

XTR_COUNTERPARTY_LIMITS is a Treasury (XTR) module table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores counterparty credit limit definitions together with the amounts authorised and utilised against those limits. Each row represents a limit facility granted by a company to a specific counterparty under a named limit code, providing the master data against which deals and rollover transactions are validated for credit exposure purposes. The table is owned by the XTR schema and is documented as VALID, containing 38 columns in the 12.2.2 physical schema.

From a data-modelling perspective, the metadata suggests a hub-leaning classification under Data Vault heuristics, derived from the structure of its foreign key relationships. The composite primary key of company, counterparty and limit code behaves as a durable business key referenced by transactional tables, which is characteristic of a hub entity. This classification is a modelling suggestion only and should not be treated as a formal Oracle implementation statement.

Key Information Stored

The primary key is enforced through XTR_COUNTERPARTY_LIMITS_PK, defined on COMPANY_CODE, CPARTY_CODE and LIMIT_CODE. A unique index, XTR_COUNTERPARTY_LIMITS_U1, covers LIMIT_CODE, CPARTY_CODE and COMPANY_CODE and serves as the documented business-key candidate; because it spans the same three columns as the primary key in a different order, it confirms that the natural identity of a limit record is the combination of legal entity, counterparty and limit identifier rather than a generated surrogate key.

• COMPANY_CODE – the legal entity or treasury company granting the limit.
• CPARTY_CODE – the counterparty to whom the limit is extended.
• LIMIT_CODE – the identifier of the specific limit facility or line.
• LIMIT_AMOUNT – the authorised ceiling for the facility.
• UTILISED_AMOUNT – the amount currently consumed against the limit.
• LIMIT_TYPE – classification of the limit (for example settlement, trading or credit line).
• UTILISATION_CALC_BASIS and UTILIZATION_STRUCTURE_BASIS – the rules governing how utilisation is derived and structured.
• AUTHORISED – indicates whether the limit has received formal approval.
• EXPIRY_DATE and INITIAL_FEE_DATE – validity period and fee commencement date.
• COMMITMENT_FEE_PERCENT and UTILISATION_FEE_PERCENT – fee rates applicable to commitment and drawn amounts.
• BENCHMARK_REF, FREQUENCY and CROSS_ALLOCATION_GROUP_CODE – pricing reference, reset frequency and allocation grouping.
• AUDIT_INDICATOR, SEQUENCE_NUMBER, and the standard CREATED_BY, CREATED_ON, UPDATED_BY, UPDATED_ON and ATTRIBUTE1–15 descriptive flexfield columns.

Common Use Cases and Queries

The most frequent requirement is exposure reporting: comparing UTILISED_AMOUNT to LIMIT_AMOUNT to identify available headroom by counterparty. A typical pattern joins the limit table to XTR_DEALS on COMPANY_CODE, CPARTY_CODE and LIMIT_CODE to reconcile deal-level exposure against the authorised line. A second pattern aggregates utilisation across limit codes for a single counterparty to produce a consolidated credit exposure position. A third supports limit maintenance, selecting rows where EXPIRY_DATE is approaching or where AUTHORISED is null, to drive periodic review workflows.

Sample reporting query:

• SELECT company_code, cparty_code, limit_code, limit_amount, utilised_amount, (limit_amount - utilised_amount) available_amount FROM xtr.xtr_counterparty_limits WHERE authorised = 'Y' ORDER BY cparty_code, limit_code;

Exposure reconciliation against transaction tables uses the same three-column key, for example joining XTR_DEALS to XTR_COUNTERPARTY_LIMITS on COMPANY_CODE, CPARTY_CODE and LIMIT_CODE to detect deals that exceed the defined ceiling.

Related Objects

• XTR_DEALS – references XTR_COUNTERPARTY_LIMITS through XTR_DEALS.COMPANY_CODE, XTR_DEALS.CPARTY_CODE and XTR_DEALS.LIMIT_CODE; a second relationship links XTR_DEALS.COMPANY_CODE, XTR_DEALS.RISKPARTY_CODE and XTR_DEALS.RISKPARTY_LIMIT_CODE, allowing a deal to consume both a counterparty limit and a risk-party limit.
• XTR_ROLLOVER_TRANSACTIONS – references the limit table on XTR_ROLLOVER_TRANSACTIONS.COMPANY_CODE, XTR_ROLLOVER_TRANSACTIONS.CPARTY_CODE and XTR_ROLLOVER_TRANSACTIONS.LIMIT_CODE, so rolled positions continue to draw against established lines.
• Treasury deal entry and limit-checking APIs that validate new deals and rollovers against the authorised and utilised amounts recorded here.

Collectively these dependencies confirm the table's role as the credit-limit hub referenced by the principal Treasury transaction tables.