Search Results dual_authorised_by




Overview
Explore in AI Chat

Overview

The XTR_LIMIT_EXCESS_LOG_V view is a reporting and integration object in the Oracle E-Business Suite Treasury (XTR) module. It resides in the APPS schema and carries a VALID status in both 12.1.1 and 12.2.2 environments. The view exposes the historical record of limit excess events captured by Treasury's counterparty and limit management functionality, presenting one row per recorded excess occurrence.

In ETRM, limit excess records are generated when a deal, transaction, or exposure breaches an established limit line associated with a counterparty, company, or instrument. The base log is written by the limit-checking engine at the moment a breach is detected or subsequently authorised. The _V view is essentially a denormalised read interface over that base log, allowing reporting tools, concurrent programs, and external integrations to retrieve excess history without directly referencing the underlying transactional table. It is not a user-maintained entity; all rows are produced as a by-product of Treasury limit processing.

Underlying Base Objects

The documented view text is a direct projection:

The only referenced base object is XTR_LIMIT_EXCESS_LOG, resolved through a synonym in the APPS schema. Because the view performs a straightforward column projection with no joins, filters, or aggregation, it is a thin abstraction layer. Practically, this means row counts and filtering behaviour mirror the base table exactly, and the view adds no independent business logic.

Key Columns

  • LOG_ID — Primary identifier for the excess log entry; the natural unique key for the row.
  • LIMIT_CODE / LIMIT_PARTY / COMPANY_CODE — Identify the limit line that was breached and the party or organisation against which the limit is defined.
  • LIMIT_CHECK_TYPE / EXCEPTION_TYPE — Classify the nature of the check performed and the type of excess exception raised.
  • LIMITING_AMOUNT / EXCEEDED_BY_AMOUNT / HCE_AMOUNT — Quantify the limit threshold, the amount by which the limit was exceeded, and the home-currency equivalent amount respectively.
  • AMOUNT_DATE / EXCEEDED_ON_DATE — The value date of the exposure and the date on which the excess was detected.
  • DEAL_NUMBER / TRANSACTION_NUMBER / DEALER_CODE — Trace the excess back to the originating instrument and the dealer responsible.
  • AUTHORISED_BY / DUAL_AUTHORISED_BY / DUAL_AUTHORISED_ON — Capture the authorisation trail, including the dual-authorisation approver and timestamp where a second approval was required.
  • CURRENCY — Currency of the reported amounts.

Common Use Cases and Queries

Typical scenarios include excess reporting dashboards, audit extraction of authorisation trails, and downstream interfaces feeding credit-risk or monitoring systems. A basic listing of all excesses for a limit line:

  • SELECT LOG_ID, DEAL_NUMBER, LIMIT_CODE, LIMIT_PARTY, EXCEEDED_ON_DATE, EXCEEDED_BY_AMOUNT, CURRENCY FROM APPS.XTR_LIMIT_EXCESS_LOG_V WHERE LIMIT_CODE = :p_limit_code ORDER BY EXCEEDED_ON_DATE DESC;
  • SELECT EXCEPTION_TYPE, COUNT(*), SUM(EXCEEDED_BY_AMOUNT) FROM APPS.XTR_LIMIT_EXCESS_LOG_V WHERE EXCEEDED_ON_DATE BETWEEN :p_from AND :p_to GROUP BY EXCEPTION_TYPE;
  • SELECT LOG_ID, DEAL_NUMBER, AUTHORISED_BY, DUAL_AUTHORISED_BY, DUAL_AUTHORISED_ON FROM APPS.XTR_LIMIT_EXCESS_LOG_V WHERE DUAL_AUTHORISED_BY IS NOT NULL;

Because no filters or joins are embedded, performance is governed entirely by the base table and its indexes; appropriate predicates on LOG_ID, EXCEEDED_ON_DATE, LIMIT_CODE, or LIMIT_PARTY are advisable for large volumes.