Search Results deal_linking_code




Overview
Explore in AI Chat

Overview

XTR_DEAL_LINKING_V is a reporting and integration view owned by the APPS schema in Oracle EBS Treasury (XTR). It exposes the deal linking lookup values that drive the linkage relationships between Treasury deals and their associated source or counterpart documents. In EBS 12.1.1 and 12.2.2 the view is registered as VALID and is defined over the XTR_DEAL_LINKING base object. Unlike transactional Treasury tables, this view is reference/lookup in nature: it enumerates the available deal linking codes and their human-readable descriptions. It therefore plays the role of a controlled vocabulary that reporting layers, concurrent programs, and integration interfaces reference when they need to translate a stored deal linking code into a meaningful label, or when they need to validate that a code passed into an interface is legitimately recognised by the Treasury module.

Because the view is owned by APPS and is not a table, no DML should be issued against it. Consumers treat it strictly as a read-only projection of the underlying lookup table.

Underlying Base Objects

The documented view text is straightforward:

  • SELECT DEAL_LINKING_CODE, DESCRIPTION FROM XTR_DEAL_LINKING — the view is a simple two-column projection of the XTR_DEAL_LINKING lookup table with no joins, filters, or aggregations.
  • XTR_DEAL_LINKING — the referenced base object, registered in the ETRM metadata as a SYNONYM pointing to the physical APPS table. In a standard EBS 12.1.1 or 12.2.2 installation this synonym resolves to APPS.XTR_DEAL_LINKING.

Because there are no joins or WHERE clauses, the view returns exactly one row per row in XTR_DEAL_LINKING, and the row count semantics of the view match the table exactly. This 1:1 relationship means the view can be treated as an alias for the lookup table wherever a stable, APPS-owned access point is preferred over direct table access — a common convention in EBS to insulate custom code from underlying table changes.

Key Columns

  • DEAL_LINKING_CODE — the primary descriptive attribute of the view. It is the stored code value that identifies a deal linking category. This is the value persisted in Treasury deal records and referenced when two deals are linked. In custom queries the column is frequently aliased as DEAL_LINKING_CODE in concatenations and reports.
  • DESCRIPTION — the translatable display text associated with the code. It is the value presented to end users on Treasury forms, in concurrent program output, and in ad hoc reports, and is the column most often used in ORDER BY and concatenation expressions.

No additional columns are documented in the EBS 12.2.2 metadata, and no date, enabled flag, or language column is exposed by the view text. Where enabled/disabled filtering is required, it must be applied against the base table rather than the view.

Common Use Cases and Queries

The most frequent use is simple code-to-description resolution in reports and interfaces:

  • Populating an LOV or parameter list in a custom concurrent program or OAF page, so that users select a valid deal linking code without hard-coding values.
  • Decoding a stored code in a query, e.g. joining XTR_DEAL_LINKING_V on DEAL_LINKING_CODE to present readable text alongside Treasury deal rows.
  • Validating inbound interface data, where an external system supplies a deal linking code and the interface must confirm it exists before inserting or updating Treasury deal data.
  • Reconciliation and audit extracts that list all configured deal linking codes and their descriptions for control purposes.

Representative SQL:

  • SELECT DEAL_LINKING_CODE, DESCRIPTION FROM APPS.XTR_DEAL_LINKING_V ORDER BY DESCRIPTION;
  • SELECT DEAL_LINKING_CODE FROM APPS.XTR_DEAL_LINKING_V WHERE DESCRIPTION LIKE :p_search;
  • SELECT d.deal_number, v.DESCRIPTION FROM xtr_deals d, APPS.XTR_DEAL_LINKING_V v WHERE d.deal_linking_code = v.DEAL_LINKING_CODE;

In all cases, schema-qualify the view as APPS.XTR_DEAL_LINKING_V and grant access through the standard EBS responsibility/role model rather than direct table grants.